Re: [Gnu-arch-users] NEW POLICIES (draft)

[Thomas Lord]

    > From: Aaron Bentley <address@hidden>

    > > Apparently not obvious, given that people haven't been using this
    > > pattern.

    > Actually, I've been using this for the backbuilder.

Ok.

    > > The pattern has particular value for longer-term, multi-phased,
    > > multi-change development --- exactly the use described for it by the
    > > rel-src-mgt spec.

    > Phase 1: tlasrc--backbuild--0 backbuilding in arch_build_revision
    > Phase 2: tlasrc--backbuild--1 support for backbuilding with libraries

    > I can't say I'm thrilled with how it's working out. 
    > tlasrc--backbuild--0 doesn't get much testing attention, 

Wouldn't that be simply a resource limitation problem?

In any event, that you have separated out this work into two phases
should be a boon for you within the next few weeks:

I can't promise just yet but it is looking fairly solid that we'll
soon have someone (not me) doing nothing but mainline integration for
a reliable number of hours per week.   

Assuming that that comes on-line, then we can go over your design
choices and, assuming everything is kosher, review and test your phase
1 and merge it for inclusion in the subsequent testing candidates.

So, if all goes smoothly, you'll get some help with testing there.


    > and doesn't really do enough by itself.  

That's ok, so long as it is correctness preserving and we agree that
it is a step in a desirable direction.

    > So I can only recommend merging 
    > tlasrc--backbuild--1, 

I'll take that as a recommendation to make a goal of merging --1 but
not as a recommendation not to merge --0 first and test it separately.


    > Also, when upstream merges affect the lines I changed in 
    > tlasrc--backbuild--1, I sometimes have to resolve conflicts twice: once 
    > in tlasrc--backbuild--0, and once in tlasrc--backbuild--1 to resolve 
    > conflicts caused by my changes in tlasrc--backbuild--0.

That's just realistic.    The alternative is to only submit the larger
change and that would be harder to swallow from the
mainline-integrator's perspective.   Making the integrator's job
tractable implies distributing some of that work to keep pending
changes up-to-date.

-t