Debian rolling discussion on -devel@

Here is my attempt at a summary of the rolling discussion currently happening on debian-devel@. It might not be complete, it’s probably a bit biased, but I hope that it’s still better than nothing. It was also posted on debian-devel@.

If you are involved in Debian development, please discuss it on debian-devel@, rather than in the comments of this blog.

If you want to provide feedback about the Debian rolling idea, use this Doodle poll and/or the comments of this blog.
Update : Someone had the good idea to vandalize the poll, and remove all the votes from people in favor of rolling. Before the vadalism (log), the results were:
37 votes: I am a Debian user, I use testing or unstable, and I would like rolling to happen.
6 votes: I am a Debian user, I use testing or unstable, and I DON’T want rolling to happen.
17 votes:  I am a Debian user, I use stable, and I would like rolling to happen.
3 votes: I am a Debian user, I use stable, and I DON’T want rolling to happen.
7 votes: I am NOT a Debian user, but I would probably use it if rolling happened.
1 vote: I am NOT a Debian user, and I don’t care about rolling.

Motivations

There’s some user demand for rolling releases. For evidence, one can look at the usage of Debian testing or unstable which clearly goes further than the Debian development community. Or at the quickly growing market share of ArchLinux. Or at the interest in LinuxMint and Aptosid. Or at the DPL’s report of his interactions with the press.

Debian’s only official product is its stable releases. While it’s a clearly great and useful product, many users and developers don’t recognize themselves in it: it contains software that is too old for their needs. The success of Ubuntu is related to this problem: Ubuntu proposes a different compromise between stability and up-to-date-ness.

While concurrencing Ubuntu with more frequent stable releases (released every 6-months, for example) doesn’t look like the right thing to do, Debian is in a perfect position to provide a rolling release with marginal additional work, since Debian already has testing (and unstable) to build on.

The rolling discussion investigates how we could endorse the concept of a rolling release, provided as a product in addition to stable releases. This rolling release would be based on the current testing branch.

Benefits for Debian:

  • Attract users who think that testing is only a development branch, and want newer software than what one finds in stable. Those users are likely to be rather advanced users (free software developers and contributors), thus interesting to work with (able to submit good-quality bug reports, etc). Some of them could also become Debian contributors. And even if they don’t, more users of testing/rolling means more testers of the next stable release [remember how the bug reporting rate of Ubuntu is higher than Debian’s — some areas of Debian could use more testers].
  • Give back to the free software world by providing a platform where new upstream releases would quickly be available to users. Since users would be able to test new upstream releases earlier, they would be able to provide feedback to upstream devs earlier, contributing to a shorter feedback loop. Debian is often identified by upstream developers as the platform with releases from two years ago. I would love to see Debian in a position to contribute more to improviing the quality of the Free Software world.
  • Get back some attention that is currently taken away from Debian by derivatives. This is important to carry our political or technical messages, which are not necessarily carried out by our derivatives.

Current proposed plan for rolling

(Disclaimer: this is mostly my view. It is shared by others, but some details might not be)

rolling is mostly about (external) communication. It is not expected to change our development processes fundamentally.
It would be a statement by the project (through a GR, for example). A very preliminary draft was proposed by Raphael Hertzog:

Title: Debian endorses usage of testing by end-users, and renames it to rolling

The Debian project recognizes that the Debian testing distribution—initially created to make it easier to prepare and test the next stable release—has become a useful product of its own. It satisfies the needs of users who are looking for the latest stable versions of software and who can cope (or even appreciate) a system that’s constantly evolving.

The Debian project decides to endorse this usage and will strive to provide a good experience to users of “testing”. To better communicate this policy change to our users, “testing” will be renamed “rolling”.

Yes, it’s mostly “PR bullshit”, and I don’t expect it to significantly change Debian development processes. However, communication is necessary if we want to attract new users. What would change is more attention from developers to what happens in testing/rolling, which is a good thing since a better testing/rolling makes it easier to create stable releases from it.

Open questions

Most of the discussion is about the influence of the introduction of ‘rolling’ on Debian development processes, and in particular, on the painful process resulting in stable releases. Many fear that, with ‘rolling’, it will be harder to get stable releases out.

The root question is: if we do rolling, what do we do during freezes? Several options have been mentioned in the thread:

  1. We could decide not to do anything special: just freeze rolling for ~6 months, as we used to freeze testing. That might bore people who like the constant flux of new upstream releases, but if we decide that it’s the only way to ensure high-quality stable releases, so be it.
  2. We could decide to fork a frozen branch when we freeze, and continue to manage rolling using migrations from unstable.
  3. We could mix both solutions: freeze rolling for 3 months, so that most of the stabilization work occurs with a single active branch, and then, for the final release preparation, fork frozen off rolling, and unfreeze rolling.

Two kinds of objections have been raised:

  • Those against the rolling concept:
    • “It’s only about PR, Debian isn’t about PR.” Answer: PR does matter sometimes, especially if we want to attract users.
    • “There’s usually no installer for it, other than installing the latest stable release and dist-upgrading, which doesn’t always work.” Answer: True; but it sounds like an acceptable problem. And if upgrades from the latest stable fail, it’s an RC bug, so we would like to know. And if we do get d-i betas, it’s a great way to get user testing for them.
    • It will split the developers base between supporting ‘rolling’ and supporting stable releases (which also need to be supported after they have been released). Answer: already the case today.
    • Testing is not targeted at end users, but is a tool for the release team to create stable releases. It needs to stay that way. Answer: really, can’t we do both?
    • Renaming testing to rolling will require changes in many parts of Debian infrastructure. Answer: some problems can be mitigated by keeping a testing symlink. The remaining impact needs to be evaluated.
  • Those against the two development branches during freezes problem:
    • It splits the users and developers base between two branches (less users means less bug reports ; less developers means less bug fixing). Answer: true.
    • It requires the use of two different entry points for packages (unstable for packages targeted at rolling, frozen-proposed-updates for packages targeted at frozen). Answer: true.
    • All in all, huge overhead for the release team. Answer: true.
    • Overhead for developers, who need to support two targets. Answer: true.
    • Just after a stable release, we would start the next release from rolling, instead of stable. So we would start from a “less clean” base. Answer: true.
    • It’s even worse if you consider staged freezes (freezing base packages earlier than the rest of the distribution, for example). Answer: true; but is it really a problem if some base packages are frozen in rolling for a few months?

Other things that were discussed:

  • possible changes to processes around testing to make it more usable (reduce the set of architectures required for migration to testing ; allow/encourage usage of t-p-u to rebuild unstable packages that are ready to transition except for the fact that they are entangled in a transition ; have different level of RC bugs: there are RC bugs that are acceptable in rolling that are not acceptable in stable)
  • PPAs for Debian
  • Developer activity during freeze (developer temporarily stopping to work on Debian during freezes)
  • Let’s improve our packaging process or reduce the duration of our freezes before introducing rolling. Answer: but then, shouldn’t we also stop doing stable releases for a while? ;)
  • Setting up an official “rolling instance”. Answer: that can’t work. detailed answer
  • Using unstable instead of testing as the basis for rolling. Answer: there seems to be more demand for something similar to testing, than for something similar to unstable.

Tentative personal conclusion

I have the impression that advertising testing as a rolling release usable by end-users is generally considered a good thing.
The renaming of testing to rolling is not as consensual, but most opponents have a “whatever ; if you want” position.

How we deal with freezes is the hard point in this discussion. I’m personnally in favor of the “freeze rolling for 3 months, then fork frozen and unfreeze rolling” plan, though it has some problems too (it is not clear whether the required manpower really decreases at the end of freezes).

Where do we go from there? After another round of discussion, we might postpone the “how to deal with freezes” question to later, and proceed with a GR to measure the support for the “testing for end-users + s/testing/rolling/” proposal.

47 thoughts on “Debian rolling discussion on -devel@

  1. PPA is a big mess, just keep it to Ubuntu.

    We’ve managed to get servers/desktops/laptops running perfectly fine just by adding non-free, contrib and Christian Marillat’s multimedia.

    No other distro maintains such a clean source list and able to get all the things done (flash, java, nvidia, etc.)

    SO DON’T EVER MESS UP DEBIAN’S CLEAN SOURCE.LIST.

  2. I’d rather have argued that Marillat’s multimedia’s the big mess. That’d also match my experience.

  3. I hack on my Ubuntu enough that I have to do a fresh install every time a 6-month release comes out. I’m patient enough to wait 6 months for the latest packages, but reinstalling everything is a pain in the ass. On server systems it’s unacceptable downtime, which is why I still don’t run Ubuntu on my servers. So for me, the big advantage to rolling would be never having to reinstall. For most people, the big advantage would be that bugs get fixed quicker, features get added quicker, features aren’t rushed into the latest “release”, and developers waste less time backporting things. On the flipside, it would take a lot more quality assurance than I think Canonical is capable of right now to ensure that new major packages releases in rolling aren’t constantly breaking my system. We would need buy-in from the developers and package maintainers themselves for rolling to really work.

  4. I’m strongly in favour of a rolling release. However, I feel that molding/arguing testing into a rolling release is a suboptimal solution. Ideally, I’d want to see a proper rolling release happen within the confines of the current Debian ecosystem, but without sacrificing the purpose of testing.

    In my view, rolling is not a superset of testing, and you can’t just freeze a rolling distribution to branch off a stable distribution. Rolling and testing are tightly coupled but independent siblings, each possibly with their own rules wrt stability/security. From the infrastructure point of view, we’d need management tools that can handle the plurality of patches from different branches, and make sharing/migrating between them as easy as possible. From that point of view, Debian Rolling would simply be a first-class citizen of DEX. Maybe even become a reference implementation.

    Then again, I’m not a DD (yet) so I don’t pretend to have any standing in these matters.

  5. about the poll.. can u block the poll or something? because anyone can edit the data of the voters (name and vote)

  6. I’m in favor of rolling release. It’s just a comment from a Debian user who works & develops on this great GNU/Linux distro. I’ve used testing for more than one year. Actually, I use it on a derivative Debian testing. The first time I used it, I said to my laptop: “Great, packages are quite recent ! And it’s highly stable for a testing distro.”.
    In case where Debian developers decide to freeze the rolling version — but I think that’s not very relevant — it’s better if the period is as short as possible. I understand that there is not THE solution, both for users and developers. It’s a good thing to allow people to discuss about it — see the dedicated Quick & Dirty poll on Doodle.
    By the way, I’m impatient to know what the community will do !

  7. “There’s usually no installer for it, other than installing the latest stable release and dist-upgrading, which doesn’t always work.” Answer: True; but it sounds like an acceptable problem.

    False, the businesscard ISOs offers a choice of installing stable, testing, or unstable, but “usually” is technically true.

    Unfreezing rolling after three months would be a good negotiation between those who want to keep freezing testing/rolling for six months and those who want to keep testing/rolling unfrozen.

    “features aren’t rushed into the latest “release”” This was a good point. “a proper rolling release … but without sacrificing the purpose of testing” This sounds like a good option but probably has the excess overhead drawbacks.

  8. Maybe it’s because I’m not a developer, I’m can’t quite wrap my head around the idea some seem to have that testing had to go through a certain amount of usage before it was made official and *.rolling.* can be set up without any kind of permission.

    It would be the frozen part of the equation that needs testing right. I could definitely see the need/desire to have frozen be set up outside of the normal chain to flesh out the implementation details but in the bigger picture I’m not seeing how the usefulness of the idea would be proven without actually doing it within the official chain during an actual release.

    Not sure I understand the ‘there’s no installer for it’ arguments either. If people want to follow a rolling release, it seems to me that a net install type of installation process would be good in the general case, as the preferred option, maybe with the option to install some some kind of basic desktop, if they have issues that prevent them from being able to connect to the net during installation.

    If the installer team is willing, getting an image with a more current installer together seems like a good smaller scale test case to see how the branching off of frozen might work on the larger scale.

    Later, Seeker

  9. I’m very sorry, but here comes the most terrible comment.

    Can we find a better name than rolling? Almost anything is better than that, for example pioneer.

  10. Debian Unstable user here. Rolling would be most welcome addition. I know lots of local Debian users and basically no one uses stable.

    Rolling is superb name. It captures nicely all the aspects of the planned distribution.

  11. Let me first say that i’am not a Debian developer and so my viewpoint is only that of an end-user who greatly enjoys Debian as an OS. So i do not really know what it means for all the devolper teams in the end to make this transition from a testing to a rolling system.

    I use Debian testing on my Laptop since Lenny has been released. My experiences are very postive and i often wondered how stable and “smoothly” it already works. I’am convinced that a rolling release is the right step in the right direction. It will make Debian more popular and attrack people who otherwise would make a choice in favour of another distribution because they want the newest software.I heard some people say that Debian shouldn’t become a “mass destribution” and that users who want a Debian Distri with all the latest software should use Ubuntu instead. My opinion is, the more popular a distribution becomes, the more user are getting “involved” in it, use it and give feedback, the more fertile will it be for the developement of the distribution. Processes like this we can observe in all areas and fields not only in software developement. I think it is something like a natural evolution.

    Only it should be taken care that the high quality standard doesn’t suffer under this process as it in my opinion happens in some other Linux distris which become so popular during the last years. It might be a difficult balancing act but for me it is important to preserve all that Debian stands for: A reliable,free and stable distribution. And if this could be complemented by a disrtibution for those who prefer newest software with the same or nearly the same standards it can only be an enrichment for Debian.

    As to the freeze time of the the new rolling distri i only can say that a three months freeze time looks as a good compromise. But i’am not a developer and so i can’t judge if this would sufficient time without too much suffering for the quality of the developement as a whole.

    Greetings Dirk

  12. I think rolling release is the way to go for Desktops, not sure about servers.

    I use arch linux as a desktop and have the least issues than any other system.

    Also when you hear about new exciting software / version of software you can usually get the package in arch in days/minutes rather than in Debian (sometimes 1/3 – 1/2 decade later… – how many years until Debian gets the latest stable KDE (4.6.2) or Firefox4 – by the time it does the packages will be out of date and semi useless…)

    If you think about it rolling release is in a way more true to the open source model working – if there is a bug it will be fixed in the application – that fix will be used in all distros – there are many cases where a fix for a package in 1 distro is not in another, etc.)

    With debian on the desktop I have had the most unstable experience ever – with intel + sis video chipsets constant random crashes – the thing is the same machines work with the latest ubuntu as the later driver / xorg had fixes in (for example) – what is the point in supporting an out of date version of a package (missing the upstream fixes)

    Ubuntu does also suffer from this to some degree (but you only ever have to wait 6 months for the next release rather than 2+ years)

    For the server though im not so sure a rolling release is a good idea…

  13. Since poll is closed: to me testing is already rolling, unless it freezes (then it is a “stucking” not “rolling”). So, to have proper rolling it must not freeze for a moment but evolve in natural process of receiving updates/transitions from unstable. So I am all for your “2.”

    As for comments about PPA — they are useful for various reasons to have. and one of them is to provide convenient media for a flow of contributions into Debian proper, so people could have their packaging built across releases, verified that it is working and clean, and then look for sponsorship

  14. Just make it rolling release altogether, without freezes. It would be easier to maintain.
    Steal some ideas from ArchLinux :) For example, Arch has a ‘testing’ repo but packages don’t stay there more than 1-2 weeks.

    Also, a rolling release model would help fix bugs faster in upstream.

  15. I have to think more about it for sure but right know I don’t see the point.

    Well, I understand the whole rolling thing but I love the current Debian cleanness.

    I’m a 100% Debian user. I don’t use another distro, just Debian for everything.

    In my servers I want stable and in my desktops and laptops it depends. Some are running stable, some testing and some sid.

    If we need to attract more users maybe is just a PR problem and I do believe ubuntuzing Debian is not the solution.

  16. My recommendation would be to raise the standards of experimental, make unstable the rolling, and fork it for six months to develop stable. Not that I have any particular experience, but just my idea.

  17. My only suggestion is to deal immediately with the question of what to do with freezes, before renaming “testing” to “rolling.”

    Testing currently is not a rolling release distribution. Unlike true rolling release distributions (such as Gentoo or Arch) testing goes into lengthy freezes while stable releases are finalized. That’s what makes testing what it currently is, which is a tool Debian uses to prepare the next stable release.

    Advertising “testing” as “rolling” without addressing this would be false advertising and will set users up for disappointment.

  18. I am not a developer nor am I familiar with Debian’s infrastructure but I would like to give a modest proposal. Why not add a rolling release branch atop of the testing branch?

    I don’t know the implications or burdens of this but I do know that packages can keep flowing into rolling even if testing freezes for a stable release. But once a major release is out, packages can flow from rolling into testing and hopefully those packages are already stable enough for immediate testing for stable release. Hell, if the majority of the developers want, this would even help release stable releases faster since rolling release packages will be tested while the testing branch is frozen.

    This idea will result in a lot of similar/same packages between testing and rolling between freezes but once testing unfreezes, it will at least have more stable packages pouring in from rolling right after stable releases. If developers don’t want two similar channels, why not branch testing off of rolling for the stabilization process?

    I borrowed/stole this idea from Google Chrome’s development model with its Canary, Dev, Beta and Stable channels. :)

  19. I’m all for a rolling release. stable for servers, rolling for desktops. :)

    If you do this you may even think about removing all the gnome, kde, X, … ballast from stable and make it a server only distribution. So stable will need noticeable lower ressources, which can be used for rolling then. ;)

    But I’m also only a (long-term) Debian user. Having used testing for several years on my deskop systems. But have stopped some years ago because of too many problems after the long freeze periods and the following rush of package updates. So I switched my desktop systems to a mix of stable, backports and volatile/updates with apt preference settings for floating upgrades between the branches. “rolling” can only become less complicated. ;)

    I can only agree to Omari. Suggesting a “rolling” distribution with long freezes will make rolling not better than testing is now, psychologically even worse. Either go with a really rolling release (without any freezes) or, when Debian cannot afford this, keep testing as it is. Having a renamed testing which only behaves slightly different than testing now, with still the same fundamental problems during/after the freeze period is not a win.

    Another aspect is the system maintenance:
    – stable: once in a year or 2 you need a lot of time to upgrade your systems, but between these dates you need only very little time for maintenance, good
    – rolling: you often need a bit of time for upgrades, but never a lot of time, also good
    – rolling with a freeze period: you often need a bit of time for upgrades, but also once in a year or 2 a lot of time to catch up after the freeze, bad

  20. One word for those who think that rolling is a good idea: fork. KDE4 making it to stable was bad enough already. Still want more mess? Suffer it yourselves.

  21. ST – Actually KDE4 is a prime example as to why a desktop distro should be rolling….

    Any distro that supported 4.0.x series was stupid … that series was unusable (to nvidia users especially ) – if a distro had that version that meant supporting a version of broken software – even when KDE released fixes the distro would still support the version with major bugs in(that would never be fixed in that version)

    It was KDE4 that made me love arch – almost the second KDE released a fix I was able to use it.

    Just my 2 pence (i’m British..)

  22. Please don’t do this.

    There are already distros that are suited for the “I <3 shiny new!" crowd. Debian is about producing consistent, ultra-stable, polished releases. Rolling release distros are the latest, greatest trend, sure, but they don't lend themselves to stability. Even if you do a split model (one rolling branch, one stable), you'll be taking away precious development resources from the development of a stable release.

    Debian didn't amass its userbase because people wanted the latest shiny toys. Please don't risk killing the very thing that makes it special just to win a popularity contest.

  23. I am a Debian user and run sid (unstable). I vote no for the following reasons,testing and unstable are both a basic rolling distribution with unstable getting the latest packages. The amount of resources needed to add another platform will add delays to the next stable release. I cannot see the value of straining a very good group of developers even further. If you want the latest, run sid it’s a lot of fun.

  24. What about using backports+stable to provide the popular new releases to people while still maintaining good “infrastructure” stability?

  25. I am all for the change..
    It is no longer a branch just for “testing” out, it is an actual branch that people use all day every day.. It is the branch most people use.. These people are not *testing* it out.. So it shouldn’t be called testing any more..
    Change it to “rolling” please!..

  26. I’m a longtime Linux user on desktop (I switched to 100% linux in 1999). I am a developer, not a sysadmin, although I’ve done some sysadmins tasks. I’m a distro-hopper, tried almost all and used most of the major ones.
    I really like the philosophy of Debian, I tried it often, but I never used it in “production”, since as a developer and desktop user it has often been too time consuming for me.
    I was a happy Ubuntu LTS user when it was a young project, but now I dislike their super-consumer orientation and their big effort and resource “wasting” just for mocking Windows and Mac.
    So I’m looking to the next distro to use. Debian rolling sounds like a very interesting idea, but I’m not sure if just a rename of testing would be enough for me. What people like me need is something that:

    1) doesn’t break (even occasionally like sidux did) – I mean, it’s ok if something breaks, but not the critical stuff like kernel, grub, essential drivers, X, KDE/GNOME, etc.

    2) since I don’t think 1) will really happen :-) it must provide a way for the users to easily “unroll” to the previous status IMMEDIATELY should something break (imagine I’m the speaker at the conference and my linux laptop breaks!)
    This is particularly true for the critical packages which make the system not usable (or hell, unbootable), but it must be possible with everything: “unrolling” to a known working status and delay to later the investigation of what went wrong.

    3) I would not bothered at all by a 6 months window every second year in which the rolling freezes, *PROVIDED* that:
    3a) the freeze does not make the system unusable or insecure (which means that there must be critical security updates, not really total freeze)
    3b) at the end of the freeze the number of updates is not dumped suddenly, but in slow, manageable way.

    HTH,
    Davide

  27. Testing is currently fine, as is. If it is only a name change (from testing to rolling), why waste the time? If somebody wants to have a different section that fundamentally is different than testing (like additional debugging, etc), then fine.

    @Philipp Kern nice to bring up your feud with Debian Multimedia out of context in this forum. Real mature, dude.

    PAS

  28. Meh, I replied to the first comment. Of course it’s the duty of the people writing comments on blog posts to define on-topic’ness. Or maybe not.

  29. Actually, Debian would have a large benefit of a rolling release if they
    really want to get a fair desktop share (i.e. directly, not by its
    derivatives).
    Even on hardware bought specifically with Linux needs in mind one is
    in need of the latest HW support and graphics environment, and this
    is more than just kernel and X. Those who say “you can do this easily”
    are just wrong.
    I am a professional Unix admin and this attitude is just annoying.
    And I really mean fresh, i.e. kernel 2.6.xx.1 is released would mean kernel
    and user space tools (fsck, fdisk, … – you name it) is up to date in a
    roughly tested form (i.e. not unstable) – i.e. more up-to-date than recent
    Ubuntu.
    If this would be provided, I would be using Debian again as I was for more
    than a decade (now I one of its derivatives)!
    It would be an additional branch on top of stable or testing – but with
    working stability in mind and focussing on desktop needs – so not based
    on unstable, but would also hold other nice desktop pearls like LibreOffice,
    Firefox, etc. in the latest stable releases without more than 3 day delay from its release … which should be easily provided (maybe also in alternate
    versions which can be switched easily by the user).
    That would be a distro !!!
    It would also be nice to have current development environment (latest libc,
    gcc) – but this is not important and may reasonably wait for the next stable
    release of Debian.
    The need really exists – but there doesn’t seem to be much support by
    developers. That’s OK.
    As long as I personally don’t step in and shout to do it, it would not be
    fair to blame others.
    I just want to ask involved people to reconsider.
    The need IS there !!!

  30. I agree with some of the comments above. If you call it “rolling”, rolling it should be. Calling the current testing “rolling” would be false marketing and a very bad move. I’m not against PR in general, but that kind of PR is what gives PR its bad name. It’s PR for PR’s sake.

    So I’m in favour of option 2: Create a rolling distribution, from which the frozen branch is forked. If the Debian developers don’t think they can do this, the current structure should remain. However, I think the Debian project would benefit from this move, because it would attract a lot of new people, including new developers and, ironically, new testers.

    Another thing: If “testing” were renamed as “rolling”, I’d also rename “unstable” as “testing”, because that seems a more appropriate name for a bleeding-edge distro. But maybe I’m biased, because I’m an Arch Linux user.

  31. A rolling and fresh Debian would be wonderful. For some time the Aptosid distribution has satisfied that need for me on my desktop, although SID does break in violent ways from time to time (like right now), and you have to be vigilant to retain a working system.

    For me, the ideal Debian desktop system would be:
    – Fresh packages, some non-critical bugs acceptable.
    – Not frozen at any point, i.e. _true_ rolling.
    – No architecture waiting for another.
    – No dependency breakage, i.e. _always_ installable/upgradable.

    This is currently not satisfied by SID or testing (especially during freeze). I do realize that it’s a tall order, but I also believe it’s within reach. Maybe best served by a repository between testing and unstable, with some added rules. So, something like:

    Experimental (as today) -> Unstable (as today but not slowing down in freezes) -> Rolling (no dep.breakage+no critical bugs) -> Testing (as today) -> Stable (as today)

    But I’m probably just naive….
    Anyway, as always, huge thanks to Debian and everyone involved!

  32. As someone who has run testing for years, I can tell you there is one big problem. Testing is unstable plus 10 days of no bugs. Which means if a bug is found on day 11 the earliest a fix can arrive is 10 days later. This is often the case where a bug comes to light after it hits the wider testing userbase, and now testing is broken. Unstable/Experimental usually get the fix right away. Which can make testing’s problem even worse because if some other bug gets fixed it resets the 10 day counter for the first fix to get down to testing. Stable gets around these issues by having a much longer test cycle and has things such as debian-security to allow fixes to bypass the normal wait.

    The way one running testing usually bypassed this is pulling in package piecemeal from unstable, when the bug get fixed there, but I don’t know if that is a good officially recommended policy. Unless Rolling is targeting only the most advanced user, who should just be using testing in that case.

    A good alternative might be to add a rolling-fixes archive that let’s in packages with important fixes from unstable faster. Or come up with a way to push backrev’s of versions so that if the new version in testing has serious bugs the old testing version can be easily restored. You could have rolling lag testing by 10 days, but that probably just divides the testing user base and pushes the same problem back 10 days.

  33. @Ted Kotz: There is already an urgency setting for package upgrades. I’m not sure if a package with urgency critical can pass in less than 10 days to testing, but I guess so. This mechanism could be further improved by a voting system. More experienced users can take the fixed package from unstable and vote for it, when it works. Then packages with more votes could be moved faster into rolling and the bug fix is earlier available for all other users.

    Debian stable is much worse. For less severe bugs you often have to live 2 years with a broken package only because the fixed upstream version does not pass into stable before the next release and the package from testing/unstable does not work in stable because of missing dependencies. ;(

Comments are closed.