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

[Joey Hess]

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.

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

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

> - 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. :)

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.

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

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.

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

> All of those problems seem easily fixable by a small shift of
> priorities. If we decide (as a project) that rolling should be a usable
> (for users) and security-supported suite, then we could prioritize
> getting updates in more.

To me this priority realignment (in general, not only for security), plus
a corresponding shift in users' attitudes toward testing, is the main thing
that CUT needs in order to happen.

-- 
see shy jo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 828 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/cut-team/attachments/20100811/f3e488f1/attachment.pgp>