Re: Bits from the Release Team - Kicking off Wheezy

[sean finney <seanius@debian.org>]

Hi Mehdi,

On Wed, Apr 27, 2011 at 05:58:46PM +0200, Mehdi Dogguy wrote:
> Funny… reading your recent blogpost, you seem to not understand yet what
> you want to put into Rolling (and how). So, how can we comment on
> something that's not set or clearly described yet? Make a plan first, ask
> for questions later, please.
> 
> There are certainly some ideas flowing here and there… but I can't find a
> document that describes clearly what that suite is!

I can try and more clearly describe what *I* was proposing, though I'm
not sure that it 100% matches up with what others have been discussing
concerning CUT and "rolling".  To try to lower any ambiguity I'll
do my best at avoiding using those terms and instead stick with more
straightforward and boring terms:

 * unstable always feeds to testing
 * "release N" == "testing", until the "freeze".
 * when "freezing" for "release N"
   * "testing" is pointed at "release N+1", and no longer automatically
     feeds "release N".
   * a new RM controlled "release N proposed updates" area is opened, which
     feeds into "release N".
	 * packages migrate from this area to "release N" in a manner
	   similar to how unstable would feed into testing during previous
	   freezes (i.e. soft-freeze, hard-freeze, etc, __entirely at the
	   discretion of RM's__).
	 * this area would autobuild only with itself and "release N" build-deps.
   * RM's can still choose to migrate packages from (not frozen) testing as
     long as it's practical to do so.
   * When deps/transitions/etc prevent testing migration, "release N
     proposed updates" is used for one-off bin-NMU's and/or sourceful backports.
 * at "release time" for release N
   * remaining packages in "release N proposed updates" are either migrated
     to release N or deleted.
   * "release N proposed updates" is basically s-p-u at this point

What I see as the benefits of this:

 * no more freezes, or periods where the fun new things slow down.
 * releases can happen faster if we want them to, because "release N+1" has
   been moving along all the time.
 * no major earth-shaking changes to how the rest of the project works

Attempting to be self-critical, the problems that I see with this approach:

 * developer share is splintered, some people might not be as interested in
   helping prepare "release N" and focus only on unstable, or vice versa.  this
   is a given with any "paralellizing" solution though.
 * user/tester share is splintered.  likewise a given.  most important would
   be having enough people testing "release N proposed updates".
 * parallel process means some (hopefully minimizable) overhead for the RM's

But I'd think that we could work past these problems.  Of course I'm
not entirely objective so others may disagree or there may be further
shortcomings.

> For example: What would be Rolling's content right after a release?
> (comparing to testing, which starts from the stable just released). I
> guess you cannot merge because testng will be lagging behind a bit. You
> cannot just get what's in testing and restart from fresh, because there
> might be users that won't like it. If you continue, there will be no
> relation with testing anymore. The two suites will have their own set of
> problems, I guess.

I think the above should clarify this.


So maybe that could be taken as a starting point for further discussion?


	sean