[cut-team] Rethinking CUT

[Michael Gilbert]

On Fri, 10 Sep 2010 09:49:53 +0200, Raphael Hertzog wrote:
> Hi,
> 
> On Thu, 09 Sep 2010, Michael Gilbert wrote:
> > 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".
> 
> 4. No timely security fixes and in general no official support from Debian.

That's part of the public's misperception of testing, which I think
is covered already under #3. Testing actually does receive fairly
timely security fixes; it gets unstable uploads with a 2-day delay,
except for uploads depending on other transitions and when the
maintainer doesn't set high. In the former case, the maintainer (or
security uploader) should be doing a TPU update, which hasn't been
happening much, and could be fixed by better communication. Testing has
already been declared "officially supported" by the security team.  The
difference between testing and unstable is not very large anyway [0].
In the latter case, someone should be hinting the security upload into
testing faster.

> > 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
> 
> Hu, no. I don't expect the usual end-user to go look for packages
> elsewhere than his currently installed distribution. He should not have
> to manually install packages grabbed over HTTP or add any other
> repository in his source.list.

Like I said, some simple scripts could be written to hide the
complexity of this process from the user.

> > 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).
> 
> I would call this "papering over the root problem" instead of "fixing the
> root problem" as you say it.

What are your ideas to fix this?  That's just one idea that I had, and
my intent was to hopefully generate further conversation/ideas to
address COAV from others.  The benefit of this one is that the
infrastructure is already completely in place.

Another approach that I can think of is what people are
currently calling "rolling".  That would involve an additional
distribution that keeps around removed packages (and their
dependencies).  That sounds like a lot of additional manual work, but
it may be feasible if enough people are interested.  However, I think
that should be named using an broadly-used existing meme such as "beta".

Best wishes,
Mike

[0] http://security-tracker.debian.org/tracker/status/release/testing