[cut-team] Rethinking CUT

[Michael Gilbert]

On Fri, 10 Sep 2010 15:12:04 -0400 Joey Hess wrote:

> Michael Gilbert wrote:
> > 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.
> 
> My original CUT manifesto does discuss the core problem that CUT would
> solve. http://kitenet.net/~joey/code/debian/cut/

So, your manifesto identifies these items as the root causes that
prompted you to spawn the CUT meme:

  1.  Testing should be installable at all times.
  2.  >= serious bugs should be fixed in a timely fashion, or buggy
      software dropped from testing. 
  3.  Security issues in testing should be either fixed ASAP or tracked
      so that users can deal with them. 
  4.  Upgrades from older versions of testing should always work.
  5.  Snapshots should be made available regularly, so that users who
      need a firm foundation for deployment have one. They'd be
      numbered, so we could call them cut 4, cut 5, etc. Each would be a
      snapshot of testing at a point when it was in especially good
      shape.

I completely concur with #1 since that's also one of my identified root
issues.  #2 and #3 are already solved by existing testing
processes/teams, and neither of those are addressed any better by
releasing CUT snapshots.  Actually, I think CUT may make those two
problems worse.  I'm not sure how often #4 crops up in the existing
testing suite, but I can see how it is a real problem.  I think that
could be addressed via automated piuparts upgrade testing from all
older versions (as retrieved from snapshot.debian.org) and blocking new
unstable versions from entering testing when there is a failure.

The root issue in #5 appears to be "users need a firm foundation for
deployment," which would also be addressed if #1 were solved, so #1
and #5 are one in the same. 

Hence, I think the only root causes identified by your manifesto are #1
and #4, and #4 has a potentially straightforward solution that could
be implemented in testing today.

> The essential problem is that modern computer users no longer only get
> software from pre-packaged releases on CD; rolling streams of constant
> updates are the new norm, at least outside of server farms. (And server
> farms themselves serve up constantly evolving software; CF google.)
> Everything else is follow-through from that problem, which I think
> testing allows Debian to put a unique spin on.

The existing testing suite already provides a set of constantly
evolving software releases, how does CUT address this need any
better?

> >         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.
> 
> FWIW, that is already the case, but it doesn't help when you have outdated
> installation media that is broken by the current state of the archive it
> installs from.

OK, so one of my other CIT options (a or b, or future ideas from
others) would be needed to address issue #1.

> > Issue #3 is a problem of marketing.
> 
> Yep, and marketing is a big part of CUT. Thus the idea of presenting to
> the user something like "Debian cut 1". The term "testing" then becomes
> more like a developer/power user code word. Actually renaming testing is
> yak shaving.

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.

The name of the suite is the least of my concerns, but it does play a
huge part in the 

> > 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.)
> 
> I have not seen any indication by anyone that anything we're planning
> will involve significant extra work for any team. Certianly not the
> release team.

If you want users to use it, you need the security team to provide
updates, and that is at least one point of reference for the additional
burden.  If you're not worried about keeping users up to date with
security patches, then that's not a problem.

Since the point of that paragraph was missed I'll reiterate it: I don't
see how additional quasi-stable n-month "CUT" releases actually address
any of the root causes of the problems at hand.  I think you're trying
to use a hammer to drive a screw.

Best wishes,
Mike

[0] http://catb.org/jargon/html/Y/yak-shaving.html