Debian Rolling Release 计划讨论进展

acidls

转自：http://wowubuntu.com/debian-rolling.html

首先我们说一下，关于 Debian Rolling Release 的这个灵感最先是来源于 2007 年 Joey Hess 的提议，他观察到大量的用户并不满意当前 Stable 版本中软件包的发布周期，过于老旧，许多用户都会选择使用 Debian Testing 版本，所以他建议发布一个 constantly-usable testing (CUT - 持续可用的 testing) 版本，即保持软件包的可用性及稳定性又能跟上时代。

而在 2010 年 8 月的 Debconf10 （2010年的 Debain 开发者会议）上，这个概念又再次被提及。此后，在 debian-devel@ 邮件列表中，大量的 Debian 开发者就这一问题进行了详细的讨论，其中包括是否要推出 Debian Rolling Release (滚动发布行版），许多人也给予了支持。另外，还涉及到是否要把 Debian testing 改名为 rolling 、为 testing 定期创建一个 snapshot release 或彻底改变发布进程（包括冻结进程，甚至于unstable, testing 和 stable 三者之间的关系）等等。

现在， Debain 的开发者之一 Lucas Nussbaum 对这些讨论做了一次总结，从中我们可以看出当前 Debian Rolling 计划方面的一些讨论进展。当然目前只限于讨论阶段，正式的工作还没有实质性的展开。
讨论概括：

像之前所说的，想要发行 Rolling release 的主要动机是因为 Debain Stable 版本中的软件包过于老旧。而 Ubuntu 则是采用折中的方案让软件包即具有稳定性又保持最新( 这也就是 Ubuntu 为什么要每６个月频繁发布一个版本的原因之一），虽然大家比较赞同 ubuntu 采用这种频繁发布稳定版本的做法，但感觉还是做得不够好。所以 Debain 最好的方向是提供一个 Rolling Release 版本，并且会基于当前的 testing 分支。

这样带来的好处有：

    吸引更多的用户使用 Debian ，这样可以能让更多的用户参与到 Debian 的开发或软件测试中去。
    给自由软件提供一个能让用户用到最新版本的平台。
    让 Debian 重新获取更多注意力，因为很多的注意力都被大量的 Debian 衍生版给夺走了。

同时表示不会改变当前的 Debain 开发进程，也就是不会把 tesing 改名为 rolling 。目前讨论中碰到的最大问题是“如果一旦发行 rolling 版本的话，在代码冻结期间该怎么办？“，并给出了设想中的解决方案。

另外，他们还没讨论了其它一些有趣的事情，比如建造 Debian 的 PPA 平台、使用 unstable 代替 testing 作为 rolling 的基础等等。

更多详细情况请查看 Lucas Nussbaum 的原文：http://www.lucas-nussbaum.net/blog/?p=659

adam8157

用unstable做基础吧...testing还是作为冻结用比较好...毕竟stable的用户丢不得

CHII

看来滚动发行是个潮流，至于能不能成为一种趋势，还难说

poet

目前的 testing 很好用，也很多人用。

unstable，也有它的支持群体。

其实没有太大动力去搞 rolling 的。个人觉得吧 unstable 做成 rolling 的可能性最大。

AutoXBC

debian 有三万个包，rolling 意味着随便升级一个什么 libpng，就要把这三万个都测试下是否正常，实际可能不会牵涉这么多，几千个差不多；或者升级 libpng，然后正不正常根本不测试，第二天发个通告，谁崩了吱个声。

第一种会累死，第二种会被骂死。除了 arch 和 gentoo 那种系统崩于前，面不改色的用户，其他发行根本扛不住。

acidls

转一个debian-devel邮件列表上一个挺不错的方案：

Josselin Mouette wrote：

Hi,

during the recent discussions about rolling, a proposal was made in a
blog comment, and after giving it some quick thoughts, most people I’ve
talked with seem to think it is a good idea, so it’s time for it to be
discussed at large.

It starts from the following fact: if you want a testing system that
works correctly, you usually have to add APT lines for unstable, while
pinning them to only install specific packages you need to unbreak
what’s broken in unstable.

The idea is to make this process automatic. Let me elaborate.

  The new “rolling” suite
  -----------------------
This would be a pseudo-suite, like experimental. Except that while
experimental is built on top of unstable and filled manually by
maintainers, rolling would be built on top of testing and filled
semi-automatically. A rolling system would have typically 2 APT lines:
one for testing and one for rolling.

The rolling suite would only exist for a subset of architectures (we
could start with powerpc, i386 and amd64), generated by picking up
packages from unstable. Typically it would be generated from an override
file that looks like:
source-package version
xserver-xorg-video-ati 1.2.3-4
...
The rolling suite would try to have a package that has *at least* this
version. If it is found in testing, the package is removed from rolling.
If otherwise it is found in unstable, the package is picked from
unstable.

This way, when something is broken in testing and cannot be unbroken
quickly, a maintainer who notices it could add (or make the people in
charge add) the necessary packages to the override file. If, for a
reason or another, an important bug fix or a security update doesn’t
propagate to testing quickly enough, you can now just add it and the
necessary dependencies to rolling, and people using it aren’t affected.
Whenever the affected packages finally migrate to testing, the
discrepancy between rolling and testing automatically disappears.

The reason for the “at least” version rule is that new uploads to
unstable are supposed to fix the situation in testing anyway. I don’t
think we should keep in rolling packages that are no longer in unstable.

  A concrete example
  ------------------
Let’s imagine something that might happen soon (although of course we
will try hard for it not to happen): a new version of nautilus migrates
to testing, but it was missing a Breaks - it doesn’t work with the
version of gnome-settings-daemon in testing. The new
gnome-settings-daemon in unstable works, but it won’t migrate because
there is a libgnomekbd transition in progress, and gnome-screensaver
which is part of the transition doesn’t build on s390.

In this case, we can just add libgnomekbd and gnome-settings-daemon to
the override file. Users of the rolling suite will have the two versions
of libgnomekbd available, and they can update their systems to a working
state.

  Why I like it
  -------------
First of all, this idea doesn’t affect *at all* the current release
process. It just takes people willing to maintain the override file -
and we could even choose to let any DD modify it. And it’s much faster
to modify such a file than telling every user from testing that they
have to upgrade to the unstable version.

And just as importantly, I think it should just work. There’s very
little chance that people get completely hosed systems like it happens
sometimes for unstable. There are all chances that something broken in
testing can be fixed by pulling a handful of packages from unstable.

  What to do during freezes
  -------------------------
I’m not sure we really need to do something different in times of
freeze. Our time would be better spent by reducing the freeze time and
making it more predictable; squeeze has been an awesome step in this
direction.

If we want to do something different though, there is a simple recipe:
allow packages to be picked up from unstable, but also from
experimental. Again, no disruption: people can keep on breaking some
pieces of experimental, but if they want some other pieces to be useful
for rolling users, they just need to be committed to more carefulness
and to add them to the override file.


What do you think?

--
Joss