Re: Bits from the Release Team - Kicking off Wheezy

[sean finney <seanius@debian.org>]

hi -release team,

On Sat, Apr 09, 2011 at 10:13:19AM +0100, Neil McGovern wrote:
> > Once again, we will use feedback@release.debian.org and welcome all
> > comments before 11th April.
> > 
> 
> We've had a rather poor response to this request, so I'd encourage
> anyone who's been putting it off to send in their thoughts so it can be
> taken into account!

Okay, here's my 0.02 `locale currency_symbol`

I think the quality of our releases has always been stellar, but the
freezes cause quite a bit of slowdown and even demotivation for those
who *also* want to work on new things in unstable.  Things really grind
to a halt towards the end.  Additionally, some people who "don't get the
message" may upload disruptive things to unstable anyway, causing
problems and extra work for the release team.

This also means that post release, unstable has not really budged much
from stable, and we're starting from a near stand-still on the next
release.  When the the floodgates open up, things get a bit chaotic,
and it feels like we're starting a race for the next release that we
could have already been working on.

My suggestion/feedback would be that we find a way where releases aren't
managed so linearly, and can be be handled in a more parallel manner
without such disruptive stoppage in unstable.  I've been mulling this idea
over quite a bit, but with all the CUT discussions I've been hesitant to
bring it up because it's sort of taking things in a different direction.

Basically, my suggestion for improvement to the process:

 * create new release
 * instead of freeze, "branch" testing to new release
 * testing is now release+1 and continues to be fed by unstable[1]
 * use release-proposed-updates for uploader-targeted changes earlier than
   usual.
 * -release team can use $tool[2] to "merge"/"cherry-pick" collecitons
   of source packages (rebuild+version bump) and/or binary packages
   (no change).


I guess the real concern here is whether there's enough person-power to handle
the extra work/overhead.  I'd hope that the workflows and tools could be
streamlined to minimize that as much as possible though, and that it might
also win back some work from the current way of doing things.

Anyway, that's my feedback, take it as you like :)


	sean

[1] or we introduce a new "name" into stable/testing/unstable to differentiate
    the now branched testing from the unstable->testing. alternatively,
    we just drop the name "testing" entirely and just use the release names.
[2] I don't know if existing -release tools can do this or if something needs
    to be extended, but that's kinda secondary.