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

[Andrew Suffield]

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

> ** Casual Change Archive and Branching Structure
> 
>   Although exceptions may be permitted at the discretion of the
>   maintainer, or with the cooperation of an integration engineer who
>   will submit a casual change by proxy for a third party, normally
>   casual contributions must be branched as follows:
> 
>   First, casual changes must be presented in the form of arch
>   revisions.   Simple "diff-style" patch submissions are strongly
>   discouraged.

[BugGoo will broker these at some later date, converting them into
...]

>   Second, casual changes must exist on a branch of their own and
>   that branch should be a branch from the current development 
>   mainline.    For example, supposing that the archive name of 
>   the casual contributor is $CONTRIBUTOR, a contribution 
>   should be in a development line:
> 
>       $CONTRIBUTOR/tla--FEATURE--X.Y
> 
>         where the string FEATURE is replaced with an appropriate
>         short name for the contribution.
> 
>   The `base-0' revision of that version should be a tag of:
> 
>       $OFFICIAL/tla--devo--patch-N
> 
>   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

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

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

signature.asc
Description: Digital signature