The main feature of rolling is that it would never freeze. This is not without consequences.
Possible consequences
It can divert developers from working on the release
No freeze means developers are free to continue their work as usual in unstable. Will it be more difficult to release because some people will spend their time working on a new upstream version instead of fixing RC bugs in the version that is frozen? Would we lose the work of the people who do lots of NMU to help with the release?
It makes it more difficult to cherry-pick updates from unstable
No freeze also means that unstable is going to diverge sooner from testing and it will be more difficult to cherry-pick updates from unstable into testing. And the release team likes to cherry-pick updates that have been tested in unstable because updates that comes through testing-proposed-updates have often not been tested and need thus a more careful review.
My responses to the objections
Those are the two major objections that we’ll have to respond to. Let’s try to analyze them a bit more.
It’s not testing vs rolling
On the first objection I would like to respond that we must not put “testing” and “rolling/unstable” in opposition. The fact that a contributor can’t do its work as usual in unstable does not mean that he will instead choose to work on fixing RC bugs in testing. Probably that some do, but in my experience we simply spend our time differently, either working more on non-Debian stuff or doing mostly hidden work that is then released in big batches at the start of the next cycle (which tends to create problems of its own).
I would also like to argue that by giving more exposure to rolling and encouraging developers to properly support their packages in rolling, it probably means that the overall state of rolling should become gradually better compared to what we’re currently used to with testing.
The objection that rolling would divert resources from getting testing in a releasable shape is difficult to prove and/or disprove. The best way to have some objective data would be to setup a questionnaire and to ask all maintainers. Any volunteer for that?
Unstable as a test-bed for RC bugfixes?
It’s true that unstable will quickly diverge from testing and that it will be more difficult to cherry-pick updates from unstable into testing. This cannot be refuted, it’s a downside given the current workflow of the release team.
But I wonder if the importance of this workflow is not overdone. The reason why they like to cherry-pick from unstable is because it gives them some confidence that the update has not caused other regressions and ensures that testing is improving.
But if they’re considering to cherry-pick an update, it’s because the current package in testing is plagued by an RC bug. Supposing that the updated package has introduced a regression, is it really better to keep the current RC bug compared to trading it for a new regression? It sure depends on the precise bugs involved so that’s why they prefer to know up-front about the regression instead of making a blind bet.
Given this, I think we should use testing-proposed-updates (tpu) as a test-bed for RC bug fixes. We should ask beta-testers to activate this repository and to file RC bugs for any regression. And instead of requiring a full review by a release manager for all uploads to testing-proposed-updates, uploads should be auto-accepted provided that they do not change the upstream version and that they do not add/remove binary packages. Other uploads would still need manual approval by the release managers.
On top of this, we can also add an infrastructure to encourage peer-reviews of t-p-u uploads so that reviews become more opportunistic instead of systematic. Positive reviews would help reduce the aging required in t-p-u before being accepted into testing.
This changes the balance by giving a bit more freedom to maintainers but still keeps the safety net that release managers need to have. It should also reduce the overall amount of work that the release team has to do.
Comments welcome
Do you see other important objections beside the two that I mentioned?
Do you have other ideas to overcome those objections?
What do you think of my responses? Does your experience infirm or confirm my point of view?
hi,
what about this chain ?
sid->testing->next_stable_candidate->stable
updates to next_stable_candidate are pulled manualy from testing
next_stable_candidate act as rolling.
regards …
I’ve been distro hopping for a while because of wanting to try the latest desktops (xfce 4.8, gnome3 and kde4.6). Now that xfce4.8 has finally landed in unstable, I’m back to my comfort distro, but I don’t see how a rolling release would have brought 4.8 in any sooner.
When Xfce 4.10 is released, if it takes 3 months to get into unstable -> rolling, I think I’d still find myself elsewhere for that period of time. Would your proposed changes affect that do you think? From what I understand, 4.08 got hung up in the NEW queue while the release was happening, and then the massive backlog of new just meant it took some time to his experimental.
It really depends on what’s blocking. If the freeze was really the blocker reason why it was not uploaded to unstable, then yes it would help. But if it’s the time needed to package it, or time waited until the release team approves the transition, then it most probably would not.
Not that I know, but I’d imagine that during freeze the release team is pretty busy with approving things that are heading into the next stable; are you saying they will have a separate role in approving what gets into rolling as well?
In opensuse tumblweed its the maintainers who say if something is appropriate for tumbleweed, basically asking Greg K-H to pull it in. Perhaps tagging it as ‘also for rolling’ or some such. You can never eliminate the time it takes to package, obviously, but if the maintainer has built the packages but can’t upload because they need release team approval, well, maybe there is a way that rolling could avoid that queue.
Well, new upstream version of leaf packages do not require any coordination work to get them updated. But transitions require some work to get them migrated from unstable to rolling, so yes someone has to do that work during freeze. Traditionally it’s the release team who does this for testing, but I expect to form some sort of “rolling team” (part of the bigger release team) that takes over this duty of the release team during the freeze.
Yes introducing rolling needs supplementary work and volunteers for the work.
Is Debian artificially constraining developers by only having stable, testing/rolling, and unstable?
There was a rant (about a user mistake) earlier this week when X was broken in unstable. Rather than a team trying to collaborate in unstable for major changes – should Debian be providing a PPA – Project Package Archive (not the ubuntu *Personal*) for projects? That would allow the X, Gnome and KDE (and other) teams to both better support the release and work on the new stuff. Outside of the freeze window – especially a the beginning of the release cycle – it would allow them to get the whole set of packages in a major transition working before pushing breakage into unstable.
I realize anyone can setup a package archive of their own, this isn’t a new idea. Where the Debian PPA would be of value to the developers would be to add automatic reporting of conflicts with unstable, and as much of the FTP Master work as is automated. Those who want to follow the leading edge of development would be encouraged to do so, but for rolling this would mean an unstable to pull from that more reliably doesn’t have major breakage.
Warren, yes, there’s some truth in your analysis. We’re lacking good tools to prepare transitions outside of unstable. And I would like to see some sort of PPA layered over unstable for this. But it’s a different project, although a very important one IMO.
Few people will test testing?
IMO, you need to soft freeze unstable/rolling before branching Testing and an improved release process, because once branched you need to release quite fast to avoid some sort of rotting of the testing branch.
Still trying to wrap my head around what the idea is exactly.
It seems to me if, if this is going to be a ‘unstable –> rolling –> testing’ thing.
For the majority of a development cycle, the majority of the big transitions would have been coordinated for rolling. Would they really have to be coordinated again for testing?
If you consider that during a freeze there is an increase in stuff uploaded to experimental. should it be that during times of freeze stuff would continue to be uploaded in unstable that previously would have been uploaded to experimental only because of the freeze and that rolling becomes slushy so there is still change, but more measured change, and updates to testing cherry picked from rolling instead of unstable? And if rolling is intended to be what testing currently is but with more support (better QA?), might the times of freeze be shorter and the slushy period for rolling shorter still?
Later, Seeker
Seeker, too many questions in a single paragraph. 🙂 Transitions coordinated in rolling would not have to be redone in testing. Tesiting would only exist for the time needed to fix the remaining RC bugs so that we can call it stable. But during that time development could also continue as usual in unstable + rolling. Indeed, today we’re (sort of) forced to use experimental even when there’s nothing experimental in the update…
Being a user just tryin’ to wrap my head around things, not really looking to get too deep into details, I think I got it now.
I did have some question about who would actually run what, but I guess that would not be so different from the current situation between people who use unstable in their sources list versus people who use testing in their sources list versus people who jump in later in the development cycle and use the release name in their sources.list .
Later, Seeker
Thought of something else…..
I’m guessing if testing is short lived only existing for the time it takes to fix RC bugs, people using testing in their sources.list would be pulling from the frozen testing during these RC periods and pulling from rolling the rest of the time.
Later, Seeker
There seems to be a release name question too, for people who use the release name in their sources list.
I’m guessing for those people who jump in later in the development cycle using the release name in their sources.list so they stay with it when it becomes stable.
Rolling would get the next release name, then when the frozen testing is branched off, that release name migrates to frozen testing, and rolling gets the next one, so that release name can be used in the way people are currently used to doing it.
Later, Seeker
To quote you: “I would also like to argue that by giving more exposure to rolling and encouraging developers to properly support their packages in rolling, it probably means that the overall state of rolling should become gradually better compared to what we’re currently used to with testing.”
Somehow this argument is totally lost on my. Why do you think it would make any difference to people who do not yet properly support their packages in testing (or even stable!) that there is a new suite or just a new name? I absolutely fail to follow that reasoning.
We are already facing a huge resource problem, we have 265 release critical bugs in squeeze, and the release was just in february. I don’t even want to look at the RC bugs of lenny. Adding yet another layer would require even more resources that we simply don’t have.
Second quote: “Given this, I think we should use testing-proposed-updates (tpu) as a test-bed for RC bug fixes. We should ask beta-testers to activate this repository”
Given that part of the reasoning behind renaming volatile to updates was encouraging more users to use it – and that support for it actually has to get built into the installer to make it really happen, it is obvious that just “asking” doesn’t scale well, at all.
About the peer review suggestion, actually it’s already pretty hard to find people willing to do so, but I wish you luck with that challenge. Hope you are just not suggesting others to do it but are willing to do your own share here. Though given that you also wrote “Any volunteer for that?” for setting up a poll I’m uncertain whether that could hold true.
The only benefit over the current testing situation would be that it would still roll during freeze time. Or should. Because I would assume that some people still might want to have the release happen and rather postpone working on incorporating new upstream versions for the sake of getting the release happen. Yes, I know that there are people that don’t care about the releases (see above, resource issues with supporting stable) which would like to push new upstream versions even during the freeze – though personally I’m not convinced, at all, that this would be an improvement.
Rhonda, concerning the first question, I’m looking forward to a “culture shift”. A significant number of people are already ensuring that their packages are in a reasonably good state in testing but a non-negligible part also voluntarily ignores testing because it’s not supported, they believe that the only thing that counts is what ends up in stable (and thus fixing stuff during the freeze is enough). I want to change this. It will not fix the resources problem for sure, but it certainly can’t hurt either.
Concerning peer-review of changes during freeze, I would certainly be more inclined to do my share if I can help without being formerly part of the release team and if my work has some direct consequences on the process: say that 2 positive peer reviews by a random DD unblocks the package immediately (i.e. each positive reviews shortens the testing delay by 5 days), a negative peer review blocks the package until an official RM reviews it, and lack of peer review means that the standard testing delay gets used.
I’d suggest adding it to http://wiki.debian.org/ReleaseProposals in the appropriate place.
Specifically, this proposal would cause problems for team overloads (translation, security, release and FTP), Not Using Unstable, Experimental Hard To Use
There is also the possibility that CUT would increase enthusiasm and participation, since Debian would be appealing to a much bigger user base. Chicken and egg problem, perhaps.
In the existing way or working, why can’t the scope of the freeze be reduced to main, or the freeze on non-main be much shorter?
As most DDs run unstable machines, it’s not helpful to have unstable and testing diverge. Currently, testing gets a lot of testing through unstable during the freeze, thus improving the overall quality. Having a non-frozen unstable leads to less tests for testing or twice as many tests for everyone.