[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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)


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

> 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

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.


Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
                      ▶ http://RaphaelHertzog.fr (Français)

Reply to: