[cut-team] Rethinking CUT

Joey Hess joeyh at debian.org
Fri Sep 10 19:12:04 UTC 2010


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/

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.

>         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.

> 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.

> 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.

-- 
see shy jo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 828 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/cut-team/attachments/20100910/cb39c9c1/attachment.pgp>


More information about the cut-team mailing list