[cut-team] Rethinking CUT

[Michael Gilbert]

On Fri, 10 Sep 2010 18:25:41 -0400 Joey Hess wrote:

> Michael Gilbert wrote:
> > So, your manifesto identifies these items as the root causes
> 
> Not as I understand the term "root causes". Those are implementation
> details.

I very much disagree.  Those are certainly the problems that you've
identified in that manifesto, and like I said before they're not
really the root problems, but they are real problems that you want to
fix. #5 is the only item that discusses an implementation, and that just
declares that CUT is the solution.

So the other statement of interest in your manifesto is that "All of
these erode the idea that the goal of Debian is to produce a succession
of static releases."  That, I think, is ultimately the genesis of
your manifesto, but it is not a cause it is a destination.  And
that destination is already here since testing is a reasonably
up to date rolling release.

> > The existing testing suite already provides a set of constantly
> > evolving software releases, how does CUT address this need any
> > better?
> 
> Not in a form that is constantly usable.

Agreed.  That is certainly true today.  In the same vain, I would say
that CUT itself isn't constantly usable today either (since it doesn't
exist). However, with some work, I think both could get there, but by
focusing on testing itself, we would be improving an existing
well-established/important part of the Debian ecosystem; rather than
diverting resources to something new and leaving the existing
infrastructure with problems that could be fixed.

So, I don't disagree with CUT itself.  I just think that the fixes
should be applied to the core infrastructure (testing).  Once those
fixes are in place, one could easily take a snapshot.debian.org
snapshot and call that a CUT without much of any effort except to put
the snapshot apt sources into the constantly working testing
installer.  At that point, doing a CUT is just when someone decides
they want to generate installer images for snapshot.debian.org.

> > Since this is new jargon to me, I looked it up in the jargon file [0].
> > Since I'm saying that the name should be changed "by fiat" by those in
> > authority, I don't see how this fits at all.  There is no other problem
> > to fix after the name changes, so there is no recursive nature.  If
> > anything, this would be the last step in a yak shaving, not the first.
> 
> My estimate for the amount of work required to change the name of
> testing, all references to it, etc, is 2 years to infinite. What's yours? :P

I have no idea.  So you're saying that its hard-coded in a lot of
places, and it would take a really long time, and require a lot of
springboarding off of previous changes. OK, I see your point.  What
about using aliases, beta=testing?  The most important changes there
would be for user facing stuff, like on the website. Anyway the name of
the suite isn't really that interesting of a problem (since it is a
marketing issue, and Debian is a technical conglomeration), but it could
have a very large impact on users' mentality and willingness to use
testing.

Best wishes,
Mike