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

[Thomas Lord]

    > From: Andrew Suffield <address@hidden>

    > On Sat, Oct 02, 2004 at 03:11:47PM -0700, Thomas Lord wrote:
    > >       Certain BugGoo headers are acceptable in summary lines and
    > >       should be used where applicable.   For example, if after a
    > >       change is committed, a particular bug can be closed, the=20
    > >       summary should read as in the example:

    > >           Summary: [CLOSE: 423] fix `commit --frob'

    > No, like this:

    > Summary: fix `commit --frob`
    > Bug: 423
    > Bug: 428
    > Merge: 21
    > Merge: 22

    > Makes no sense to limit it to one bug per revision, and it's silly to
    > overload the parser with more complicated constructs when there's a
    > perfectly adequete multiple-field system already available. Plus this
    > interfaces with other stuff more neatly.

Not quite like that.   I don't want Bug Goo header names mixed in with
log file headers.

I could live with:

        X-BugGoo-Bug: 423
        X-BugGoo-Bug: 428
        [etc.]

How about that?

    > >   The contributed change should be the *only* difference between
    > >   the contributors version and the mainline.  In particular,
    > >   casual contributions should be mergable with the commands:

    > >         % tla get $OFFICIAL/tla--devo--patch-N tla
    > >         % cd tla
    > >         % tla star-merge $CONTRIBUTOR/tla--FEATURE--X

    > This is essentially done for you automatically when you submit a
    > properly formed merge request, eliminating the effort of fanning out
    > the branches by hand; the revision then will be:

    >   address@hidden/tla-merges--merge-N--0

I would actually like to archive, for casual contributions, the
submitters signed archive.  I'm not sure that a
address@hidden recasting of the merge is particularly useful
here.

On the other hand, a *client-side* tool that turns a merge request
into an appropriate version from the submitter might have some value.

Even so, for casual contributions especially, client-side tools
(fairly trivial ones, really) to set up the proper branch in the first
place would be my first choice, if I had to pick just one.

    > > * Guidelines for Long-term Contributions, Including Integration
    > >   Branches

    > This stuff doesn't fit in so neatly just yet, we can figure out what
    > to do with it later.

Mmhm.

Thanks,
-t