[cut-team] Rethinking CUT

[Michael Gilbert]

Apologies again.  One more try:

> I've been thinking for a while now about the CUT ideas currently
> floating around.  The problem I see is that there are a lot of ideas
> for solutions but no concrete (root cause) list of problems those
> solutions are meant to address.  Without this all-important first step
> (often used by engineers in problem-solving), I think the results will
> miss the mark, and in the process compound the work for many teams
> without a whole lot of benefit.
>
> From my reading, I've identified the following three problems as the
> 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
>