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

[Joey Hess]

*taptap* is this list on? Alioth may be being slow. I've CC'd 7 people
who have not subscribed to the list yet. There are currently 9 people
subscribed to the list.

Quoting Asheesh in full for those who did not see it before, replies inline.

Asheesh Laroia wrote:
> Hi all! We are the people who worte we'd be interested in being on a
> "CUT" team at the end of Joey's Birds of a Feather Session.
> 
> This is a little long, but it deserves your attention.
> 
> Lucas and I chatted a little bit after the BoF, and we had the
> following thoughts.
> 
> Possible implementations
> ------------------------
> 
> Which of the following would you want to help with?
> 
> There seem to be two different implementations we're talking about.
> In one, we would snapshot the entire testing suite every N months (N
> == 6, probably). 
> 
> Then users can install from our snapshotted CD
> images, which we could generate, and they'd set sources.list to
> point at CUT-1 or CUT-2 or so forth. Users would be able to add
> testing to their sources.list if they liked, and if not, they could
> just stay on the particular snapshot CUT. (As far as we can tell,
> this is what Joey meant when he talked about CUT in the BoF.)
> 
> There is another lighter-weight thing we can do that Lucas and I
> call "Debian rolling." In this proposal, we ask users to run
> testing, or something very similar. (To be precise, we'd probably
> create a new suite with slightly different rules for how packages
> migrate from unstable to the rolling suite. Packages would still get
> uploaded to "unstable.") Every N months, we'd snapshot just enough
> of the archive to create installation media. During the install, we
> point users' sources.list to testing; the installer would
> automatically choose fresher packages.
> 
> First question: Dear people on this thread, which of "CUT",
> "rolling", "neither", or "both" would you be interested in helping
> out with? Personally, I am only excited about "rolling", and Lucas
> told me he feels the same way.
> 
> What's next?
> ------------
> 
> Lucas and Asheesh want clarity as to which of the proposals you guys
> are interested in working on. Snapshotting the whole archive? Or
> just getting more users onto testing or something similar (e.g.,
> what we've called "rolling").
> 
> Once you've read this email, reply saying which approach you like!

I am interested in both. In particular, I want there to be snapshots
because they are needed to ensure installation always works and provide
a firm base, and I want users to be able to easily upgrade to testing
or similar, and have that also work well.

I don't think these ideas are in opposition, indeed doing each makes
doing the other easier. Just, I think that snapshotting is the best way to
get started, because it's an incremental step up from the current d-i
releases, and wih testing frozen, this is the easiest point in the
release cycle to make one or more snapshot releases.

So I want to take advantage of the freeze:

0. Assemble a team.
1. Assemble a snapshot release.
2. Publicise that this is available, get users.
3. Deal with upgrades. (Someone suggested makign a "weather report" 
   that detects trouble in testing.)

That all seems straightforward, and it lays the groundwork for whatever
we decide to do later.

> Once we decide which approach we're working on, we'll begin the work
> of identifying all the relevant issues and address them.
> 
> The rest of this email describes how Debian rolling would work.
> 
> Implementation problems for Debian rolling
> ------------------------------------------
> 
> If we snapshot just enough of testing to do an install, then we
> could offer installation media. But testing isn't perfect. It's used
> to prepare stable releases, and not intended for general use. ("RT"
> below refers to the release team.) Some problems:
> 
> * RT removes packages not suitable for stable release. but maybe
> they are still suitable for general use (e.g clamav)
> * RT sometimes need to break testing (transitions)
> * RT sometimes FREEZES testing!
> 
> One action we can take to determine how real these problems are:
> 
>     ACT: Find real cases of testing breakages. Talk to the release
> team about the secnarios and possible compromises. Perhaps through
> that discussion we'll learn that we don't need a separate suite at
> all.
> 
> So we propose that a separate suite, "rolling," be created. rolling
> is in sync with testing except when it's a good idea to diverge.
> (For example, rolling would not freeze; rolling could keep packages
> unsuitable for a stable release.)

The release team necessarily has to yank packages sometimes for transitions.
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.

> Another problem with telling users to use testing (or anything
> similar, like rolling): The security situation is unclear.
> 
> ACT: Talk to security team to figure out what's the current level of
> security support for testing, and how it could be improved if
> needed. (Find out if the Testing Security Team is still active.)
> 
> Maybe we simply will tell people that the only way to get security
> updates is through a dist-upgrade.
> 
> ACT: Decide if that's enough. (It's fine with Lucas and Asheesh.)

I covered this in my talk. 

* Testing still tends to have fewer security holes than stable,
  and more than unstable. http://security-tracker.debian.org/tracker/
  has some great lists for comparing the security holes in the 3 suites.
* Stable always has a relatively large backlog of security holes. It is
  not unusual for many of them to be high impact either.
* Stable gets fixes for very serious security holes faster than testing.
* Transitions can block security fixes from reaching testing sometimes.
* The Testing Security Team has only used the testing-security queue 5
  times since the last stable release, but all the infrastructure is there,
  and could be used more by the CUT team to backport fixes from unstable
  if a transition was blocking them from reaching testing.
* No accouncements are done for fixes that propigate from unstable, 
  leaving users needing to dist-upgrade. This is something the CUT team
  should address.
* There is still a perception problem around testing's security that
  does not match well with reality, and from a publicity POV, that is
  one of the problems CUT can address.

> Installation:
>     possible solutions:
>         - only provide snapshots of the installation media itself
> (CD images)
>         PB: cannot support netboot / business card CD
>         PB: we cannot update the installation media
> 
>     ACT: figure out when/if the installer updates all packages to
> current testing

I think that d-i and CD team members will all agree that making d-i
media that targets a snapshot of testing will result in it all working
much better for much longer than the current status of targeting testing.

>     ACT: decide what about security support for the installation
> media/snapshot?
>         what are the scenarios that need to be addressed, since we
> are upgrading at the end of installation anyway?

Mostly not a problem. d-i upgrades, so there are no security issues from
using old media, assuming d-i itself, and apt are secure.

Case in point: All stable release media is full of packages with security
holes; many vendors don't bother to update to stable point releases
until they run out of existing stock, and this does not cause problems.

> Social/communication issues
> ---------------------------
> 
> Naming:
> 
> 'cut' is opaque if we don't do snapshots.
> 
> 'testing' is sub-optimal. Possible options: 'next', ...
> 
> For implementing a snapshot-based system, "cut" is okay. Other
> choices: fresh, current.
> 
> For a new suite that updates similarly to how testing updates, Lucas
> and Asheesh like the name "rolling". Do you?

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.
 
> Other downstreams:
> 
> ACT: investigate sidux, mepis and other derivatives and see if they
> do similar things/want to join the fun
> 
> That's all
> ----------
> 
> "rolling" is a pretty simple proposal. Now reply and say what you think.
> 
> -- Asheesh (and Lucas, since he's basing this email on Lucas's
> typewritten notes).
> 
> -- 
> You can bear anything if it isn't your own fault.
>                 -- Katharine Fullerton Gerould
> 

-- 
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/20100809/ffa170d5/attachment.pgp>