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

[Matthew Dempsky]

Thomas Lord <address@hidden> writes:

> The archive containing this document is where you would expect to find
> it (same as address@hidden with appropriate s/2004/gnu-arch-2004).

James, can you mirror this on sourcecontrol?

> * The Official Project Archives
>
>   The GNU Arch project shall create a sequence of archives.
>   The history of releases and testing candidates will be 
>   recorded in these archives in such a way that any specific
>   release or testing candidate may be accurately reconstructed
>   on the basis of these archives alone.
>
>   At any one time, at most one archive (the latest) in this sequence
>   will be "active" (i.e., allowing new revisions to be committed).
>   All previous archives will be "frozen".

What happens when $OFFICIAL changes?  Is the entire release structure
rebuilt in the new archive?  (If so, via tags to the old version alone
or by simply recommiting everything?)  What happens if we release
tla-1.4pre0 this year, but don't release tla-1.4 until next year?
(i.e. where is version-0 commited to?)

> ** Major and Minor Releases
>
>  A major or minor release, 
>
>       tla-X.Y
>
>  can be reconstructed from the archive with:
>
>     % tla get $OFFICIAL/dists--tla--X.Y--version-0 tla
>     % cd tla
>     % tla buildcfg configs/gnu/This-release

Maybe I'm nitpicking, but that mixed capitalization just irks me.  Can
we use "this-release" or "release" or "This-Release" or the bash
favorite "=release"?

>       ~ correctness (absense of bugs) should be unchanged or
>         (ideally) improved by each change --- no introduction of
>           known-broken changes with the intention of "fixing them
>           later"

I propose asuffield be tasked with extending BugGoo to enforce
this. ;-)

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

Presumably that should have been $OFFICIAL/tla--devo--X.Y--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

Likewise,

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

You seemed to have copy/pasted this a few times in the next section as
well.

>   Therefore, casual contributions *must* include the addition of 
>   a file:
>
>       ./CONTRIBUTION-LOG
>
>   which contains a draft patch log entry to be used during the commit
>   of the change to the GNU mainline.
>
>   The draft patch log entry is subject to the rules given earlier for
>   patch log entries (see "Quality Standards for Development Branches").

This file is expected to be the same format as a regular patch log
then?

> [ cascade branch stuff ]

Suppose several patches independently depend upon another patch being
merged; could these still be represented as a cascade branch?