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

[Andrew Suffield]

On Sat, Oct 02, 2004 at 05:25:04PM -0700, Thomas Lord wrote:
> 
>     > 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?

Doesn't interface anywhere near as neatly - and there's no particular
reason why these headers should be specific to any given system. If
you happen to be using bug goo, and the values you put in the headers
happen to coincide with its syntax, it all works out neatly; if you
happen to be using some other system, you could just as easily put
some string in which makes sense to that.

I've deliberately avoided introducing any system-specific names into
the interface so far, and I'd like to keep it that way; anything else
is useless diversity. We don't *need* BugGoo-Bug and Bugzilla-Bug and
Debbugs-Bug, and it would be a significant impediment to tools which
don't care what system you're using. Any non-server-side tool that
works for BugGoo should also work for just about anything else.

A 'Bug' header that takes an arbitrary string is *at least* as useful
as a 'Keywords' header that takes an arbitrary string, and almost
certainly more so.

And a --bug argument to commit is far more sensible than a set of
--buggoo-bug, --bugzilla-bug, [...] options.

>     > >   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.

Why?

> I'm not sure that a
> address@hidden recasting of the merge is particularly useful
> here.

Centralisation of stuff for mirroring and offline work; you should be
able to process merge requests given only a copy of that archive (and
it's the only possible way to get into the vote system; group
maintainership *requires* that you all be looking at the same thing).

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'                          |
   `-             -><-          |

signature.asc
Description: Digital signature