On Thu, 28 Apr 2011, Stefano Zacchiroli wrote: > We might disagree with the process Raphael is proposing, but my reading > of [1] is that he is asking for comments on the *goals* that, in his > opinion, "rolling" is supposed to fulfill. We can discuss whether those > goals are worthwhile or not even if there is no plan (yet) on how to > implement them. Of course people might consider that a futile exercise, > but from an investigative point of view, it looks like an interesting > exercise to me.
Ack. Besides that, the plan is relatively straightforward and has been well described by Sean Finney in another answer here. Furthermore, I don't want to come up with a proposal where the release team just says "yes" or "no". I have outlined the goal to have a distribution that never freezes and I would like the release team to be involved in the design of the solution because no matter how we do it, it will have an impact on the release process and I would really prefer to have some buy-in from the release team. That's not to say that I want the current members of the release team to implement this, I am willing to join the team (or create a sub-team dedicated to rolling/CUT) and put the required effort to make this a reality. But I would like to do it with the approval of the current members. On Wed, 27 Apr 2011, Mehdi Dogguy wrote: > For example: What would be Rolling's content right after a release? > (comparing to testing, which starts from the stable just released). I Rolling doesn't magically change after a release. It's still the result of the migration of packages from unstable into it. I said in my blog post[1] that testing is "branched-off from rolling". This means: - rolling is the long-lasting distribution where packages migrate from unstable - at freeze time, instead of freezing rolling, we make a snapshot of rolling (I call it testing) and this is where we do the work left to make it ready for release - testing is really a temporary distribution that has a purpose only during freeze, if you use "testing" when there's no freeze you're just using "stable" because the testing symlink is still pointing to the distribution that has been released now > guess you cannot merge because testng will be lagging behind a bit. You > cannot just get what's in testing and restart from fresh, because there > might be users that won't like it. If you continue, there will be no > relation with testing anymore. The two suites will have their own set of > problems, I guess. I guess I should not haved called "testing" the distribution forked from rolling. This caused some confusion. Really you must think of rolling as being the current testing with no possibility to freeze it. On Wed, 27 Apr 2011, Philipp Kern wrote: > So this requires people to coordinate and finish transitions in parallel to a > massive load of patch review. And even better we can't even cherry-pick from > unstable or testing anymore because it got broken through transitions. > binNMUs > are even more fun because then your version in release N proposed updates > is higher than what's in new testing, which means that it should be propagated > from p-u to testing which breaks because it would miss the libraries for which > it got binNMUed in the first place. Which means in turn that you need to > binNMU into release N p-u and binNMU again with a higher version into testing. > > The whole thing only seems doable if you add a *lot* more people to the > relevant points in the process. (And yes, new testing would require > transition > hand-holding from unstable to it as usual.) Yes, all this is true. If the release team is open to try this out, I'm volunteering to help implement this (i.e. at the very least managing transitions while the rest of the release team is concentrated on patch review for finalizing the stable release). I'am also happy to invest some effort on updating our infrastructure to cope better with some of the problems that we will face. And also on writing documentation to make it easier to recruit new volunteers. That said I think we can changes some of our processe to reduce the load on the shoulders of the release team. More on this later. 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/20110428092928.gk...@rivendell.home.ouaza.com