[cut-team] CUT discussion summary for -project@

Lucas Nussbaum lucas at lucas-nussbaum.net
Tue Aug 31 12:24:27 UTC 2010 

Hi,

I tried to summarize below the various proposals made on the list in a
form suitable for a mail to -project at . I did my best to represently the
different views, but I'm obviously a bit biased. Please review. I plan
to send this to -project@ on friday unless it is obvious by then that it
needs more work.

--------------
To: debian-project at lists.debian.org
Subject: Constantly Usable Testing: summary of the discussions so far

Hi,

After the CUT BOF at Debconf[1], discussions on CUT continued on the
cut-team mailing list[2].

There seem to be a consensus on providing something usable by end users
that includes software newer than in stable releases. One can agree
that, while stable releases suit the needs of many of our users, there
is also a number of users that consider that stable doesn't suit their
needs, and would prefer to use something with newer software and more
frequent updates.

However, there are several different proposals on what we would actually
want to do. The goal of this mail is to summarize those proposals to
bring everyone up to speed, and discuss them together.  One way to move
forward, once we have discussed the various proposals on -project@,
would be to have a poll to decide where the project wants to go. A draft
ballot is proposed at the end of this mail.

4 implementations are being described, mostly in order of appearance on
the cut-team list. This list of questions to keep in mind while reading
the following is:
- What tradeoff do we want to make between usability and up-to-dateness?
- How does it position in the Free Software distributions "market"?
- Which level of security support do we want to provide?
- What are the implications on core teams (ftpmasters, release team,
  security team, mirrors)?
- What are the implications on the Debian development processes?
- Marketing/communication issues: how will we advertise it?

[1] http://cut.debian.net/ (video + notes available)
[2] http://lists.alioth.debian.org/mailman/listinfo/cut-team

General overview
================
While there is consensus on the fact that snapshots of testing are
needed to build and provide installation media, there are several
proposals on what users would actually use. In proposal A, users would
use "frozen" snapshots of testing made every 3 to 6 months. In proposal
B, users would use testing itself. In Proposal C, users would use a
suite that is very similar to testing most of the time, but is kept
separate to increase flexibility. Propsals D and E are combinations of A
and (respectively) B and C.

Proposals
=========
Proposal A: Users install and use snapshots of testing made every 3-to-6 months
-------------------------------------------------------------------------------
This is the original proposal from Joey Hess.

- The testing suite would be snapshotted every 3 to 6 months into a
  separate suite (squeeze-cut-201009, for example).
- Installation media would be created to install this suite.
- Users would install Debian using that installation media, and then use
  the snapshot suite (possibly pinning packages from testing/unstable).
- It would be possible to upgrade from snapshot 'n' to snapshot 'n+1'
  (needs testing), or from snapshot 'n' to testing (needs testing too).
- Security support would be provided for this suite. 

Cons:
- Ubuntu already provides snapshots of unstable done every 6 months, and
  does it quite well. How will we differentiate from it? It would have
  more architectures, but that doesn't sound like a strong selling
  argument.
- Main advantage of testing: constant flux of software updates (always
  close to latest upstream release). Lost with that (6-month delay)
- Security support needs a lot of work (no updates received
  automatically from unstable). How long are snapshots supported?
  Supporting multiple snapshots at the same time looks insane.

Proposal B: Users install from snapshot, and then update to and use testing
---------------------------------------------------------------------------
- a subset of testing (what is required for installation) is snapshotted
  every 6 months to build installation media and allow to install this
  suite over the network

- users install from this installation media, and upgrade to testing
  during the installation process
- security support is limited to extremely serious issues that can
  affect installation (d-i + apt)

Cons:
- testing is used to prepare stable releases => conflicting goals
  + packages not suitable for stable releases might be removed from testing
    (because of long-term support concerns, for example), though this
    is not very frequent [B.1]
  + when testing is frozen, much less updates to testing
  + complex migrations blocked by some architectures might delay updates
    to testing
- security support provided only by full system upgrades => might
  introduce breakages. This can be mitigated by using tools like
  debsecan to list pending security updates.
- While proposal A aims at being perfectly usable for most
  not-very-technical users, this one clearly limits the target user base
  to more experienced users that would be able to get out of occasional
  breakages (but maybe that's a Pro rather than a Con)?
- the "testing" name is suboptimal for marketing purposes

[B.1] http://udd.debian.org/cgi-bin/attic/sources_in_unstable_but_not_in_testing_by_popcon_max.cgi

Proposal C: new suite: "rolling". Users install from snapshot then upgrade to rolling
-------------------------------------------------------------------------------------

To mitigate the problems of Proposal B, a new suite named "rolling" is
created.  For most of the time and for most packages, rolling == testing
(and packages land in rolling like they do for testing, through
migration from unstable).
The tradeoff between up-to-dateness and usability is similar to the one
currently provided by testing (when not frozen).
Exceptions about migrations, and differences with testing:
- when testing is frozen, rolling continues to receive updates from unstable
- some packages removed from testing might stay in rolling (if suitable
  for rolling release, but not for stable release)

- the rolling release team might choose (with the maintainer) different
  trade-offs (break less popular architectures, for example) to push
  important new versions of packages (or new packages) to rolling
  (example: get chromium earlier in rolling)
- some packages that are blocked in unstable due to library transitions
  might be backported to rolling through rolling-proposed-updates (built
  against the packages in rolling)
- security support would be very similar to testing-security work

Cons:
  [ the Cons of proposal B about security support and target user base
  also apply ]
- Overhead due to creation of a new suite. Not clear how much of the
  work on testing will be re-used (for transitions management, for
  example)
- Will reduce number of testing users during freeze (not a problem for
  the rest of the cycle because rolling would be very similar to
  testing) (Long term idea: make testing a branch of rolling that starts
  at freeze time)
- During freeze, unstable is currently used to upload packages targeted
  at testing. It can't be used to upload packages targeted at rolling at
  the same time.

Proposal D: A + B -- Users use either snapshots or testing
----------------------------------------------------------

We give the choice to users: they can either use a frozen snapshot of
testing (that would be security-supported as in proposal A), or testing
itself.

Cons:
- requires more work and more manpower (security support for both, etc)
- Harder to explain to users than a single alternative

Proposal E: A + C -- Users use either snapshots or rolling
----------------------------------------------------------

We give the choice to users: they can either use a frozen snapshot of
testing (that would be security-supported as in proposal A), or the
rolling suite (see Proposal C).

Cons:
- requires more work and more manpower (security support for both, etc)
- Harder to explain to users than a single alternative

Proposed ballot for a poll
==========================
The goal of this poll is to determine whether, as a project, we want to
endorse the idea and want to work in that direction. If widely accepted,
we would then expect DDs to work toward achieving the proposal (or at
least not work against it), similarly to what we already do for
migrations to testing or stable releases.
I chose to formulate this as a poll (question to developers) rather than
a GR.
The poll would be conducted using the Condorcet method. I hope to
convince Stefano Zacchiroli to organize the details, as he worked on an
unofficial devotee installation during Debconf9.
I've explicitely added both "NOTA" and "Further Discussion" options. I
hope the distinction is clear enough.

<-------
As a DD, which of the following proposals would you like the Debian
project to adopt?

A: Users install and use snapshots of testing made every 3-to-6 months
B: Users install from snapshot, and then update to and use testing
C: new suite: "rolling". Users install from snapshot then upgrade to rolling
D: A + B -- Users use either snapshots or testing
E: A + C -- Users use either snapshots or rolling
F: NOTA -- I don't think that the project should go in any of those directions
G: Further discussion
------->

Orthogonal stuff that was also discussed in the discussion
==========================================================
- QA (using edos-debcheck)
- live images (mostly requires *-desktop tasks to be installable, no big issues)
- versioning for snapshots (consensus on date-based?)


- Lucas

More information about the cut-team mailing list