[cut-team] Ideas for the rolling release

[Drake Diedrich]

On Tue, Aug 17, 2010 at 12:31 AM, Lucas Nussbaum
<lucas at lucas-nussbaum.net> wrote:
> On 16/08/10 at 16:18 +0200, Raphael Hertzog wrote:
>> Hi,
>>
>> On Mon, 16 Aug 2010, Reinhard Tartler wrote:
>> > This depends on the implementation. If we want to snapshot testing
>> > (which I am actually in favor for), then packages would first need to
>> > migrate to testing anyway. But that would also mean no transition
>> > fast-tracking.
>>
>> Snapshots and a rolling distribution are not in opposition. One is needed
>> for the installation media anyway.
>
> The question is whether we want snapshots that are usable and supported
> for general use (aj's POV), or just for installation (my POV). In the
> second case, we could ignore most of the security support.
>
> - Lucas

   snapshots are pretty cheap (~100MB/day of binary changes, tens of
MB in Packages files/day IIRC, haven't been measuring lately), so
there's no reason not to use them for many purposes and keep lots of
them around.  I'm running two architectures on a 300MB partition (in a
VM) of both squeeze and sid, and can go about 3 months before I need
to clean out the pool.

  I'd suggest snapshots be staged.  First, we test each snapshot in an
automated fashion (EDOS+ any new tests we write) to identify the best
days from squeeze and sid.    Then we keep it around long enough to
get all the installation support in place for that snapshot.  At this
point we may hit a snag: something newer/older/extra is needed to make
the install of that snapshot work, and we have two options: quit and
try another snapshot that's better, backport in new code into an
add-on repository to fix it up, while still keepiong the base verbatim
snapshot of testing/unstable.  If we get working installation for a
snapshot, we'll keep it around as a candidate for further testing,
maturing, upgrade and install testing, and maybe call it a the next
CUT.  Production deployments can have their sacrificial machine try
out the exact thing that'll be the CUT a bit early and gain confidence
in it before we push the button to make it a release.  It won't be
brand new at that point, but it'll have been pretty well understood
and tested, and if it is an exact release of what was in testing at
some point, the majority of the security updates for testing itself
should just work on it (again, we'd want to verify).

   If it's a fork off sid rather than squeeze, and there's a critical
security update, that package can be pulled from sid if dependencies
allow and added to the extra repository.  Occaisionally we might have
to actually build a package specifically for rolling, but only when
there's an issue that forces our hand.

   I've been thinking that rolling/CUT should be based off unstable
during code freeze, since we hope code freeze will only last about the
length of a CUT release cycle anyway, and off of "testing" when there
isn't a code freeze (to get a bit more maturing and let the release
team get more information on the retrospective state of unfrozen
"testing").

-Drake