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

[Thomas Lord]

    > From: Matthew Dempsky <address@hidden>

    > What happens when $OFFICIAL changes?  Is the entire release structure
    > rebuilt in the new archive?  

Yes.

    > (If so, via tags to the old version alone
    > or by simply recommiting everything?)  

The spec is deliberately silent on that although cachereved tags is a
good bet.   (I tried to avoid specifying anything that wasn't strictly
necessary and this is one example: whether the base-0 of the next
archive is a tag or not shouldn't matter much to anyone so long as the
patch logs are in order.)

    > 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?)

The year+sequence part of archive names refers to the year of creation
of the archive --- it doesn't limit the years of use.   So, if in June
2005, tla-1.4 is released from a -2004 archive, that might be a
convenient time to cycle to a -2005 archive.


    >>     % 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"?

Pehaps.  Something that sorts nicely and stands out visually is all I
care about.   I agree about StUDly CapS and it was a moment of
weakness when I typed "This-Release".

    > [various typos caught]

Thanks.

    > >         ./CONTRIBUTION-LOG
    [....]

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

Yes.


    > > [ cascade branch stuff ]

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


I see no problem with it in terms of patch-flow topology.   The naming
system given for cascades as submitted for mainline merger doesn't
anticipate "tree cascades" and, at this point, probably shouldn't.

A contributor can create a tree-cascade if they like, naming versions
however they like.   But the policy spec is about what gets submitted
for merging to the mainline.    I'm not too crazy, just yet, about
inviting people to submit tree-cascades as such.   Instead, they can
submit a normal cascade up to the fork in the cascade and then
separately submit whichever of those forks they like, each as another
linear cascade.

The situation would be different for something like, say, an OS
kernel.  You might have a single patch that tweaks a generic part of a
driver interface and then 50 different cascade-forks off of that, one
for each of 50 drivers.  Similar situations might arise in highly
interrelated parts of the kernel --- the tree-cascade being, in
essense, a game tree of possible changes to (e.g.) VM or scheduling
heuristics.  In cases like that, it *might* (depending on how common
the problem is) be worth it to formalize a submission process for
tree-cascades rather than just for (linear) cascades.


Thanks,
-t