Re: Bits from the Release Team - Kicking off Wheezy
(Moving to -devel, since -release is not a discussion list, and keeping
lots of context because of this)
Hi,
On Sun, 10 Apr 2011, sean finney wrote:
> 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.
+1 I also mentionned this in my feedback mail (although much more
quickly/shortly).
> 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.
Why are you thinking this? On the contrary, this is something that was
suggested to implement the "rolling" distribution. I would very much like
to form a group of developers ready to put some work towards this goal.
And I would be glad if you could be part of it.
> 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 had in mind something very similar except I used different names:
- call "rolling" the distribution that always evolves from unstable
- call "testing" the branch of rolling that we use to prepare the next
stable
While I think this is the long-term goal, it might be more sensible
to start with rolling and testing in parallel. And I also think it
requires us to become involved in release matters and to develop
new tools to streamline the process.
> I guess the real concern here is whether there's enough person-power to handle
> the extra work/overhead.
And also whether release-proposed-updates is workable earlier in the cycle
as the release manager like to pick updates from unstable because it gives
some good prior-testing that release-proposed-updates might not provide.
> 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.
+1
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Follow my Debian News ▶ http://RaphaelHertzog.com (English)
▶ http://RaphaelHertzog.fr (Français)
Reply to: