No subject

root causes that spawned the CUT meme (there may be others, and
additional thoughts are very welcome):

    1.  The provided testing installation media is often broken, missing
        functionality, and at times unable to install testing itself.

    2.  Packages are sometimes temporarily unavailable in testing.

    3.  Public (mis)perception of the name "testing".

Issue #1 has various vectors for solutions that don't necessarily
invoke the need for the complexity of the current CUT proposals.  A few
approaches that I can think of are:

    a.  Use the "official" stable media (relabeled as testing) to
        install testing. This is how I install testing on my systems
        since I can't really tell the state of the devel
        debian-installer until I try it and run into a problem.
        Obviously this approach could be problematic since only hardware
        that's compatible with the previous installer will be supported.
        Perhaps a known incompatible hardware list could be downloaded
        and displayed to the user?  Also, bugs that break the testing
        installation functionality (such as [0]) would have to be
        treated with the utmost urgency.  This would be a stop-gap
        solution for most of testing's lifetime until new d-i reaches a
        release candidate state.

    b.  Provide a live cd copier like the one used on Ubuntu's live
        installation media or as Stefano pointed out Linux Mint's new
        live testing installer.

    c.  Keep the testing installer in a "constantly" supported/working
        state.  I'm not sure how feasible that is due to the flux that
        testing goes through during transitions, etc., but it would be
        the ideal solution.  Perhaps, and admittedly I'm not familiar
        with d-i's current development process, all installer
        development should happen in experimental instead of
        testing/unstable. This would free up testing to house only
        (mostly) stable d-i packages; thus providing a constantly
        working installer.  In order to preserve this state, all
        non-bugfix/non-planned uploads of packages with udebs to
        unstable would need to be blocked to preserve the stability of
        the installer due to the automatic unstable->testing transition
        process. This would have the added benefit of bringing d-i
        development more in line with the rest of debian.

In any case, there are many possible approaches for issue #1 that
don't involve inventing new releases.  Thus, I think the goal for #1
should be called Constantly Installable Testing (CIT), rather than CUT.

In terms of issue #2, I think that is already addressed somewhat by
snapshot.debian.org.  If a package goes missing from testing, all one
needs to do is find a snapshot from sufficiently far back.  Admittedly,
there is no user-friendly way to go about that currently.  Right now, to
pick up an old version, one would manually need to add a bunch of apt
sources, and eventually find one has a package that works.  However, it
should be fairly straightforward to write a few additional tools to make
that more automated.  Again, I don't see the need to invent new releases
to address this problem.  I would call the project to address #2
something like Constantly Available Old Versions (or CAOV).

Issue #3 is a problem of marketing.  No sane commercial software
development house would provide a "testing" version to all of its users.
They reserve that nomenclature for one-off test releases that fix
specific customer problems.  "beta" is the term that comes closest to
describing what testing actually is.  Consider commercial games.  They
have "beta" releases whereby lots of users exercise a rolling codebase,
which as an added benefit generates significant buzz about the
product.  A couple other bonuses are that even your average computer
user is familiar with the term, and they'll jump on it if they like the
latest thing, and they'll will avoid it if they fear change.  I think a
rename is really needed to change public perception.  It may also be
beneficial to use beta-like version numbers; i.e. wheezy could be
versioned something like 6.9.20100905-1 while it is in beta (with the
date-# denoting each snapshot). I wouldn't give this effort an acronym
due to the danger of bikeshedding. While CUT is a nice name, it doesn't
have the advantage of being a long-standing existing meme that most
users are already familiar with.  Anyway, for this to happen folks with
the authority to do so need to declare "testing is now going to be
called beta".

So, to sum up: I don't see how additional quasi-stable n-month "CUT"
releases (involving significant additional workload for many teams:
security, release, etc.) actually address any of the root causes of
the problems at hand.  I think the ideas are very interesting
and well thought out, but I think a lot more could be accomplished
instead by focusing on the root issues I've identified separately
using existing infrastructure.

Best wishes,
Mike

[0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=529475