Re: Bits from the Release Team - Kicking off Wheezy
sean finney wrote:
> 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.
Seeing not much conversation on this, I wanted to try to get it
started. I completely agree with Sean's viewpoint.
So I think this could probably be started independently from the release
team, and I don't really see how it would necessarily interfere with CUT
since that's going to follow testing anyway. In fact this seems very
much like the "rolling" idea that some have been contemplating for a
while, and has gotten thrown into the CUT meme anyway.
So I guess this just needs some DDs to say "hey, we're going to try
this". The first try could probably stay separate from the normal
release structures. Set up a rolling.debian.net that has an
unstable+1 release that uses britney to populate testing+1,
which also syncs regular testing updates that have versions greater
than the versions already there. Then after the release, convince the
release team to sync from the new testing+1 instead of stable.
Anyway, there are 18 months to get something ready, which seems like a
lot of time, but if it doesn't get relatively early, it probably won't
gain enough momentum to be ready in time.
Best wishes,
Mike
Reply to: