Do we need project-wide support for Debian rolling?

The discussion about Debian rolling started sooner than expected on debian-devel (see the thread here). I initially wanted to iron out the biggest problems through discussions on my blog and try to submit a somewhat polished proposal… instead we ended up discussing the same things both on -devel and on my blog.

That said it’s not that bad (except for the time I lost to have similar conversations in both places) because the debian-devel discussions included members of the release team and it looks like they are not fundamentally opposed to the idea.

Despite this, the introduction of a “frozen” suite branched off from “testing/rolling” is not really consensual (yet?). But the idea of officially supporting testing on a best-effort basis appears to have almost no opposition.

While some will undoubtedly believe that this is a useless exercise, I believe it would help if the project stated this in a somewhat official manner. My answer to the question in the title is thus:


I am thus considering to submit a general resolution to that effect. My current draft is below.

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”.

While we believe that this is a good move, we would like to remind our users that Debian is a volunteer project and that our resources are not infinite. Package maintainers are contributing to Debian on a best-effort basis. This means that they might not be able to properly support their package(s) in all distributions. In that case, the project recommends that maintainers apply the following priorities:

  1. Support in stable (security updates, release critical bugs)
  2. Preparation of the next stable release
  3. Support in rolling

Note that this general resolution could have amendments with s/rolling/current/ and that would solve the bikeshedding over the name that started several times already.

I deliberately separated “Preparation of the next stable release” and “Support in rolling” so that priorities are clear even if we decide to not freeze “rolling” and to introduce a “frozen” distribution to finalize the next stable release.

I also did not go into too much details on the implications that it might have, it’s best to leave that up to each contributor/team/etc.

I hesitated to add a paragraph stating that we want to try to gradually improve the usability of testing but in the end I think it would be somewhat redundant. We’re always trying to do our best when we decide to take on something.

All comments welcome (even if you just agree and would be willing to second such a GR).

Update: I will tweak the draft included in this article when I get good suggestions. Thanks to Lucas Nussbaum for the first one.


  1. says

    FYI I replaced “In that case, the following priorities should apply:” by “In that case, the project recommends that maintainers apply the following priorities:”. Thanks to a suggestion of Lucas Nussbaum.

    It conveys better that those are the recommended priorities but that maintainers have some latitude in defining their own priorities.

  2. muchan says

    I’m following the discussion on debian-devel.

    If the implementation of “CUT” is actually separating current “testing” into “rolling” and ‘frozon”
    at the starting of freeze, then I think you can actually achieve the same thing by just
    1) renaming the “unstable” to “rolling”
    (or not renaming, but just start supporting users of “unstable” repository as rolling users)
    2) do not (actually) freeze the “unstable” when “testing” is frozen.
    That is CUS, Continually Usable Sid

    The problem of cherry picking from “unstable” to “frozen/testing” need to be solved with “p-t-u” repository.
    The only difference I see with “unstable/rolling” from your “testing/rolling” is that you have some days in unstable to fix problems before the packages entering “testing/rolling”. 8)

  3. Arthur says

    “this is a good move”, seems a bit vague. Also, how will it be understood when translated; Maybe more like “we believe this will bring benefits to Debian and its users”, or “we believe this will provide a benefit Debian users who currently use testing”.


  4. Greg says

    Thanks a lot for actually stepping up and doing this.
    I like the direction this is going to, as CUT for me doesn’t mean testing snapshots as Joey Hess had proposed initially, and the video from DebConf was discouraging at the very least, but that may to some degree be normal since it was some very early discussions with no clear plan to follow.
    I agree with the rolling concept as its layed out on your blog posts. It might make Debian much more of an option for many desktop users who are now using derivatives like Sidux, Crunchbang or Mint to name some. Its a very interesting project i will keep an eye on. It might actually make Debian usable for me as well.

  5. Ste says

    We need to consider also all the work maintainers do on different upstream release that go throught in experimental->unstable->testing when we are not in freeze. There is some work on packages that is not common on different upstream version released and this kind of work is not be used by all the users that are on stable because generally only one specific or two upstream version go into stable.
    I very like this rolling proposal that i fell very like this old rought 2005 idea:

  6. Michael says

    LMDE, which you would know is based on Debian Testing, is already “marketed” as a rolling release so you may find there is a feeling out there that Debian Testing is already a rolling release and this may create confusion for some people.

    I personally feel a rolling release is better based on Sid and that still enables Testing to be frozen without causing more work for devs etc.

    • says

      Supporting package in rolling and in testing is twice the work. So what you suggest is causing more work for devs. There’s a reason why I prefer to try to improve testing so that it becomes a better rolling.

  7. Biswarup says

    For an “officially” supported rolling distribution (which many layman or “ordinary” desktop users will use), provision for two safety nets (experimental+ unstable) is kind of expected.

    But those having bleeding edge hardware will be more interested in “unstable-rolling” rather than “testing-rolling”.

  8. Ralph Ulrich says

    I followed your blog, but I don’t understand. Perhaps my german dEnglish. But I suspect you mixing words: testing – rolling – unstable
    If you really want Debian fitting better for users who like to use Debian as a Rolling Release, why don’t you ask them in the forums:

    1. We, users of Debian as rolling release, tried to break the big freeze using varying experimental repos. We mostly ended up breaking not only the freeze but our systems.

    2. The second most annoying thing for us is unstable udev making our systems unbootable once a year.

  9. Debianero says

    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.