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

[Drake Diedrich]

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

Here's a start on snapshotting.  http://debmarshal.debian.net/debian/
(be gentle, it's on the wrong side of a cable modem)

Snapshots are being taken of sid and squeeze.  "latest" is a symlink
to the latest successful debmirror pull.
One piece of automated testing is set up: edos-debcheck.  if it comes
back clean, the "best" symlink is updated to the latest snapshot.
"better" just looks for no new errors, so should (slowly) converge
towards zero errors.

There are lots of opportunities to test for other things - only
evaluate for EDOS on standard+ packages, build an install test, build
an upgrade test from one snapshot to another, etc.

snapshots could also get permanent names when we're happy enough with
them.  The current user interface is ln -sf.

There are working tools to remove numbered dists that don't have
symbolic names, but the associated pool cleaning tools are working too
aggressively at the moment.  I'll be working on those, particularly
when I get back home and can plug in a spare USB drive to hold
repository backups.  (apologies for the recent pulls from the
mirrors).

The config files/scripts for debmarshal.debian.net are in
http://code.google.com/p/debmarshal (as well as lots of other code),
while the patch to debmirror has been living in bug # 550007 for the
past year.


>
> And it catches both users who just want a way to install testing and users who
> want to run something newish but don't want changes daily.
>
>> 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.)

Even without automated testing, if the snapshots are available and
labeled, and we have some way to collect the upgrade reports, the
snapshots will make it pretty easy to just update sources.list and see
if it works.