(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) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110413065004.gb...@rivendell.home.ouaza.com