As you might know, I’m of one the people who promote the idea of having a Constantly Usable Testing (CUT). I will post a set of articles on this topic to help me clarify my ideas and to get some early feedback of other Debian contributors. I plan to use the result of this process to kickstart a broader discussion on debian-devel (where I hope to get the release team involved).
Let’s start by defining my own objectives with Debian CUT. I won’t speak of the part of Debian CUT that plans to make regular snapshots of testing with installable media because that’s not where I will invest my time. I do hope other people will do it though. Instead I will concentrate on changes that would improve Debian testing for end-users. I consider that testing (in its current form) is largely usable already but there are two main obstacles to overcome.
Testing without freezes = rolling
The first one is that testing is no longer testing during freezes. The regular flow of new upstream versions—that makes testing so interesting for many users—is stalled because we’re using testing to finalize the next stable version. That’s why I’d like to introduce a new suite called “rolling” that would work like the current testing except that it never freezes. Testing would no longer be a permanent suite, it would only exist during the freeze and it would be branched off from rolling.
Rolling should be a supported distribution
The second obstacle is not really technical. We must advertise rolling as a distribution that ordinary people can use but we should make it clear that it’s never going to have the same level of polish that a stable release can have. And to back up this assertion, we must empower Debian developers to be able to provide good support of their software in rolling, this probably means using “rolling-proposed-updates” more often to push fixes and security updates when the natural flow of updates is blocked by transitions or other problems. Some maintainers won’t have the time required to provide the same level of support as they currently do for a stable release and that’s okay, it’s not worse than the current testing. The goal is to treat it on a best-effort basis and to try to gradually improve the situation.
My goal for wheezy
This is the the minimal implementation of CUT that I would like to target in the wheezy timeframe. Having testing as a temporary branch of rolling is not a strict requirement, although I’d argue that it’s important to not waste resources towards maintaining two separate yet very similar distributions.
Should Debian embrace those goals?
Ignoring all possible problems that will surface while trying to implement those goals, can we agree that Debian should embrace those goals because it means providing a better service to a class of users that is not satisfied by the current stable release?
I will come back to the expected problems in a subsequent post and we will have the opportunity to discuss them. Here I just want to see whether we can have broad buy-in on the principles behind Debian rolling and CUT.
I suggest calling this new suite “current”. It has some marketing advantages: a good connotation of “the latest and greatest”, plus “Debian current” is a meaningful phrase itself and indicates something dynamic.
I disagree. I associate “current” rather with unstable than testing/rolling.
I think you know this, but I think that the rolling idea is pretty great.
I like “current”, maybe also known as “shark”?
I don’t think the name matters much as long as it’s not testing because testing gives the wrong message out.
But current is a too-common word IMO, I like rolling because it would be much less ambiguous when used in a Debian context.
I’m fairly concerned that CUT is trying to avoid a problem, rather than solve it. How short a release period would be necessary to please people who find stable out of date too soon? 18, 12, 6 months? What is achievable?
[ PS: the tab-ordering on your site is a little unexpected – the element after this TEXTAREA is your header, not the submit button! ]
I don’t understand your comment Jon, there would be no release with rolling. There might be snapshot to make it easier to install it but rolling is constantly evolving so there’s no release period short enough to match what rolling would offer.
What I mean is, the audience of CUT is people who find stable too old, and sid too unstable. But if we had a shorter/fixed/predictable release cycle, would stable not then be more attractive to these people? How short would it need to be?
Having said that, similarly I thought that debian-maintainers were a bad idea because it was a hack rather than fix the NM process. However, I took advantage and benefited from it at the time.
Jon, if we shorten the time between two stable release we make stable unsuitable for corporate usage where a long term support (LTS) period is required. We could do like Ubuntu (have LTS release and other frequent non-LTS releases) but IMO we don’t have the required man-power to maintain so many releases in parallel.
IMO the combination stable (which is LTS) + rolling would satisfy a lot more users than many short releases.
I’ve been running Testing on my home computer for maybe five years now (Stable on my server). Yeah, it’s a bit of a pain that during the freeze updates are so slow; but would freezes work at all if there were a parallel distribution being developed at the same time? I’m afraid that many DDs would stop fixing RC bugs in the packages of others, and would focus on uploading new stuff to the Rolling distribution. I like to run Testing, but rock-solid Stable is Debian’s greatest achievement.
Honestly, Testing is fine to run, and updates frequently enough, just so long as packages build on all architectures and massive transitions from Unstable are avoided. I think the focus of CUT should be on improving Testing by making sure that it is readily installable.
MG, I will discuss this objection (“stop fixing RC bugs”) in another article that is due out today.
I don’t know why you believe that rolling would be massively different from testing, I made it clear that it’s testing with no freeze at least at the start. Once we agreed on that, we can discuss improvements to make it even more suitable for end-users. I have a couple of ideas and this will make a third or fourth article on the topic. But one thing at a time. 🙂
I enjoy use testing with updated software, this make my debian (sometimes) one step ahead over ubuntu stable release in term of updated software. I love debian but i’m also love new software version, so “testing” (and “sid”) is my solution on my desktop.
I have use testing since squeeze in testing branch, i’m agree that in “frozen” state there’s not a lot of “excitement” compared to “normal” state, just a boring updated bugs fix until next normal state begin after new debian released.
In my opinion, there would be unneccesery to create a new “rolling” brach. What we need iis something like “testing-backports” to get new software updates before new release.
b7, thanks for your comment but it’s clear that you express the point of view of an end-user here. Anything labeled “backports” is supplementary work for the maintainer that does not directly benefit to the preparation of a future stable version. It presupposes the existence of something newer already packaged.
The problem with the freeze is that we can only package new stuff in experimental where it’s not exposed to a large set of users and any transition done in experimental will need to be redone in unstable (because packages cannot migrate from experimental to unstable, we need to reupload the source packages).
A simple solution to make testing more current is to allow leaf packages to migrate faster possibly with just a 2-day instead of 10-day delay. This would also help in pushing security updates faster. Other than that, if people can upload to t-p-u, then I guess that would be good enough for 75% of time (1.5 years rolling release, 0.5 years freeze).
One thing I’m not entirely clear about yet, is how this is different from unstable. As requested, I won’t mention the problems with this approach yet, but it may be more fruitful improving unstable uploads (possibly by greater use of / improvements to experimental) than Yet-Another-Suite
Neil, how rolling is different from unstable you mean? Exactly like testing is different from unstable right now: fewer brown-paper-bag/RC bugs, availability on a coherent set of architectures, some decent testing and no broken dependencies.
That said officially supporting rolling means that we should strive to not break unstable too much and use more extensively experimental (or any other means to prepare problematic transitions outside of unstable). I would like to investigate ways to make transitions more “atomic” even in unstable.
Indeed. And once you’ve done that, can’t you use unstable instead of ‘rolling’? I’ll leave my comments about supportability of rolling for your next post 🙂
Unstablewill always risk breakage due to its nature — because we upload directly there. We do need a small safety net for people who are not able to recover from brown paper bag bug that make udev / X / apt broken.
> Testing would no longer be a permanent suite, it would only exist during the freeze and it would be
> branched off from rolling.
So, basically you propose a return of frozen suite (excepts it’s a copy, not a symlink)?
Personally I prefer the idea of can’t-remeber-who, to make a new rolling suite without freezes and with only mainstream architectures (i386, amd64 and perhaps arm for embedded platforms; hm, what about kfreebsd-*?), so problems on $SOME_STRANGE_ARCH wouldn’t affect it and packages could flow to this suite faster.
However I’m aware that this means more work in maintaining Debian suites.
(Posted info about this article in our local media, will try to post any interesting comments here.)
Frozen on top of rolling is not the same as frozen on top of unstable (which was what we had in the nineties). I don’t think it counts as a step backwards but rather as a supplementary layer.
I’m still interested to investigate if we can do better by supporting only a subset of architectures but I don’t want to have two conflicting distributions just because of this. So I want to start first with the same rules than the current testing and then discuss possible improvements one by one.
Rename the current “testing” as “rolling” and fork the testing from the rolling when the freeze starts.
I think Debian CUT/rolling deserves a new name, I know a quite a lot of people, and some of them are prominent users of other distros that are chased away by “testing” and “unstable”. Whether by using some of the Toy Stories character names or something else, but I strongly believe this name should be changed.
In case we have it “rolling” in Wheeze time frame … Debian is on the roll 🙂
I’ve been following the mailing list discussion, and have an idea that maybe was raised already.
Right now you have (experimental) -> (unstable) -> (testing) | (stable) | old-stable, with DDs and DMs uploading to either experimental or unstable, migrating down the line. What about having (rolling) right underneath (unstable). During non-freeze periods (rolling) behave’s pretty much like sidux, a copy of sid with packages either pulled in from experimental or removed when major bugs occur. During freeze however, DM’s/DD’s can choose to upload directly to (rolling), and (sid) only with RT’s permission, or however it currently works. When release happens, (unstable) is synced from (rolling), and packages migrate to testing as per usual.
I think this is a very good proposal. It would help those users who feel that stable is too old and testing too unstable.
I’m a former Mandriva volunteer packager. I have been running Ubuntu for some years now and due to Unity and long standing bugs that don’t get fixed I’m looking for something else. That way I came across this rolling distro concept, had never heard of it before… I maintain several boxes for friends which are currently on LTS 10.04. Reinstalling Ubuntu every 2 years on those boxes is a pain and therefore I would be very happy if a rolling release with reasonable stability would happen. I like the snapshot idea because that way I can first test a snapshot on my own box and then ‘approve’ the snapshot for the other boxes. Currently Linux Mint DE works like that. Another feature I would like is a rollback function, in case a certain snapshot breaks the system.