[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Debian rolling: tentative summary


Since I already sent too many mails in the 'rolling' discussion, I
decided to send one more.  Here is an attempt at a summary of what was
said so far. It might not be complete, it's probably a bit biased, but I
hope that it's still better than nothing.  When replying, please try to
focus on specific points, and change the subject accordingly.

There's some user demand for rolling releases[1]. 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[2].

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

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

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

  * 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

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[3]:

  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
       * "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
       * 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"
       * 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:
       * 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[4]
  * 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.

[1] http://en.wikipedia.org/wiki/Rolling_release
[2] http://article.gmane.org/gmane.linux.debian.devel.general/161527
[3] http://raphaelhertzog.com/2011/04/29/do-we-need-project-wide-support-for-debian-rolling/
[4] http://article.gmane.org/gmane.linux.debian.devel.general/161517

- Lucas

Reply to: