[cut-team] Contantly Usable Testing, and Debian "rolling"

Thu Aug 12 09:59:47 UTC 2010

On 11/08/10 at 17:51 -0400, Joey Hess wrote:
> Lucas Nussbaum wrote:
> > I'm fine with doing both:
> > - snapshotting of testing
> > - making testing more usable, possibly with a new very-close-to-testing
> >   suite
> > 
> > The question about snapshotting of testing is how much manpower we want
> > to put on this. Do we want to do security support of those snapshots?
> > For all issues, or just the very-critical ones? If those snapshots are
> > only used to install a system that users have to upgrade as soon as the
> > installation is finished, we don't need to put as much effort to support
> > them security-wise as if the snapshots were targetted for general use.
> > I'd prefer that those snapshots would only be used for installation, and
> > are explicitely not security-supported.
> 
> I don't want to cause the security team more work.
> One way to handle security for the snapshots would be to require at
> least partial upgrades to testing to get security fixes. Or full upgrades
> as you say.

OK

> > > The release team necessarily has to yank packages sometimes for transitions.
> > 
> > After discussing that with the release team, it is not clear if such
> > removals are as frequent as you seem to think. Also, when asked during
> > the BOF, nobody was able to come up with a good case of an important
> > package being removed for a transition.
> 
> You can get a pretty good idea of the current scope of removals from
> testing with this rune. (Remove the perl command to see all past
> removals too.)
> 
> (for a in aba adsb faw he jcristau luk madcoder mehdi neilm pkern vorlon zobel; do curl -s http://release.debian.org/britney/hints/$a | perl -pe 'exit if /^finished/'; done) |grep remove
> 
> Remove the perl and grep for 'force-hint' instead to see transitions
> that were pushed in despite dependency breakage before.

I think that the question is whether those removals make testing less
usable: are the removed packages removed because they are not suitable
for a stable release, or because they are completely broken? 

Looking at it differently, this UDD CGI gives the list of source
packages in unstable but not in testing:
http://udd.debian.org/cgi-bin/attic/sources_in_unstable_but_not_in_testing_by_popcon_max.cgi

While there are some that we would definitely want in a "rolling" suite
(gnash, chromium-browser, wesnoth, wine-unstable), there are also many
packages that are simply superseded by new versions that are in testing
(autofs, emacs22, dhcp3, db4.8).

> > > A suite without such oversight would tend to always lag what is available
> > > in testing. Especially desktop environments would tend to fall behind
> > > due to their complex dependency graphs. That is one of the problems I
> > > have with the idea of adding another testing-like suite, rather than 
> > > finding ways to improve testing.
> > 
> > Can you elaborate on that? I'm not sure I understand why this "rolling"
> > suite would lag much behind testing.
> 
> Without manual hinting, it's all too easy for britney to tie one
> transition to another and end up with a mess that is unlikely to
> get into testing on its own until the freeze.
> 
> I'm not sure that the release team's hints could be used, in filtered
> form, against another suite. Seems likely that the more a rolling suite
> got out of sync with testing, the less testing's hints would apply to
> it, and so it would get increasingly out of sync. 
> 
> (Also, during a testing freeze, someone else would have to provide hints
> to keep rolling going.)

I agree that constant work would be needed here. But I wonder if we could
simply do:
- when not in freeze: rolling = testing + manually-done list of packages
  removed from testing because they are not suitable for a stable
  release. Since what ftpmaster needs is a list of packages to include
  in rolling, that could be easily done by "stealing" testing's list of
  packages and adding the additional ones we want. But maybe there are
  other, less hackish ways to do that.
- when in freeze: more work needed to manually hint packages from
  unstable

> > - testing is used to prepare the next stable release. The release team
> >   removes packages that are not suitable for a stable release, but could
> >   perfectly be suitable for a rolling release. Good examples are packages
> >   that rely on an online service to achieve functionality (anti-virus,
> >   get-video-from-youtube stuff, etc).
> 
> Note that flashplugin-nonfree and youtube-dl and clamav are currently
> available in testing. If they were not, volatile seems the solution.
> 
> It's hard to argue that the lack of this sort of thing in testing makes
> testing unusable -- without also concluding that stable is unusable,
> anyway. :)

Sure. I have the impression that the whole "use volatile for this
package" vs "allow package in stable" discussion has never really
reached consensus, or that the consensus is constantly challenged.

Anyway, if testing is perfect as the "constantly usable suite", we can
make rolling = testing for most of the time, and only diverge during
freezes. But I think that keeping (by design) the possibility to make
different compromises for testing and rolling is very important.

> Packages like chromium-browser not having yet gotten into testing make
> it much less appealing than it could be. But that's not being kept out
> by RC bugs, but just by normal propigation delays, and I think, by an
> libicu44 transition. Not things that a separate rolling suite would
> handle better.

Right. In case of important packages (by user demand), we could consider
avoiding transition delays by uploading to rolling-proposed-updates or
something, building against the libs currently in rolling.

> > - testing is sometimes frozen. During the freeze, it would be great if
> >   we could find a way for users of the rolling release to continue to
> >   receive updated packages (new upstream releases), which wouldn't be
> >   the case if they used testing.
> 
> Bdale also had some thoughts about ways that having a suite in between
> unstable and testing could make unstable more "unstable" (a good thing).
> 
> > Can't we target installing a snapshot, and upgrading to rolling at the
> > end of the installation process? Wouldn't that solve the problems with
> > trying to get an installer that can be tested?
> 
> The failure mode if d-i fails to upgrade during the installation
> process is not particularly user friendly to recover from. You get a red
> screen and it will happily, and probably fruitlessly, try again. You
> don't have a running system to continue using until the upgrade problem
> is resolved. This is mostly not seen with stable since d-i upgrades to
> well-tested security updates, and only upgrades packages installed before
> apt is configured. (Ie, it upgrades *before* the tasks are installed.)

How do you define "fails to upgrade"? If "dist-upgrade" works, but
doesn't upgrade all the packages that have a newer version available,
does it count as "fails to upgrade"?

> This is one of the places that automated testing could help, we could
> use it to detect upgrade problems during the install from a CUT
> snapshot.

Right.

> > > I don't dislike it at all, but "cut" is supposed to be at least usable as
> > > a way to describe both a snapshot and as an acronym to describe a rolling,
> > > constantly usable testing release.
> > 
> > I think that "cut" is a great acronym to describe the snapshots, but
> > that "rolling" is much better to describe the rolling release itself.
> > We should aim for users saying: "I installed Debian using CUT-3, and am
> > now running Debian rolling."
> 
> Or they could say "I installed Squeeze+1 CUT 1 and since they're doing
> Constantly Usable Testing now, I keep getting new stuff in Squeeze+1
> whenever I want to upgrade."

But that sounds much more complex and thus less appealing. Also, really,
"testing" sucks as a name for something we want to advertise, and users
to use.

Another question is wether CUT versioning should be done relatively to
stable releases, or in an absolute way. From a user point of view, I
don't really see the point of versioning them relatively to stable
releases (after all, what the user wants is use the constantly usable
suite, they don't care about the stable release in that use case).

We could adopt date-based versioning for CUTs. That works well for other
projects ;)
-- 
| Lucas Nussbaum
| lucas at lucas-nussbaum.net   http://www.lucas-nussbaum.net/ |
| jabber: lucas at nussbaum.fr             GPG: 1024D/023B3F4F |