[cut-team] Rethinking CUT

[Michael Gilbert]

On Fri, 17 Sep 2010 21:37:47 +1000, Anthony Towns wrote:
> On Mon, Sep 13, 2010 at 08:43, Joey Hess wrote:
> > It gets the ball rolling, and make no mistake, there is considerable
> > inertia to overcome.
> 
> Speaking of intertia...
> 
> Where are we at on the snapshots implementation? AFAIK there are at
> least two unsettled "objections" to the current plan on the wiki --
> (1) what frequency it should be, one month, three, six, other? (2) are
> official snapshots needed, given Michael's script -- what benefits
> over that are official snapshots trying to achieve?

First of all, thank you very much for the thoughtful list below. I
think this kind of discussion is really needed to help steer CUT in the
right direction.

Personally, I don't really have an opinion with respect to question
(1). If snapshot.debian.org were used, snapshots can be of any frequency
since everything is captured down to the four times a day update.

For question (2), I think the only two benefits are support for newer
hardware, and support for newer features.  However, my approach
requires virtually no manpower; whereas stabilizing the testing
installer for a release requires much many people (and a lot of effort
from what I've read).  Advanced users will find a way to get access to
those missing installer features anyway if they really want that.
Hence, it isn't really a necessity for the installer; its just
something nice to have.  As for hardware support, I think presenting a
list of what is/isn't supported is the best solution for that.
Ultimately its a trade off between feature richness vs. human effort.
Personally, I prefer simplicity/automation.

> I'm a bit concerned that we're not really on the same page, and I
> guess to some extent I think we haven't really established a clear
> idea on who we're trying to help. As far as I can see, CUT's maybe
> possibly going to help some/all of the following groups of people who
> are being under-served by Debian at the moment:
> 
>     (1) people who could be running testing right now, but aren't
> because of non-technical issues (misplaced concern about security,
> fear from the name, insufficient publicity, negative reactions from
> DDs)
> 
>     (2) people who want to run testing right now, but find it
> technically difficult because of the installation and upgrade path
> (both the initial install stable, upgrade to testing; and the daily
> upgrades of testing forever after)

I would add that one of the biggest problems is that its hard for
average users to figure out where to get the testing installation
media itself. Something clean like Ubuntu's front page would really help
in this area. Provide two big links on the debian.org front page:
"Download Debian stable" and "Download Debian testing", and on those
pages include only the most common media (again similar to Ubuntu's
media download pages) with a link to something like "advanced/other
media".

>     (3) people who already run testing, but find their systems aren't
> usable in the way they need it to be (from a quality perspective, ie
> packages are there but don't install/work at an acceptable standard)
> 
>     (4) people who already run testing and want newer software from
> unstable (that would be fine on their machine, but is blocked by
> britney for other reasons -- eg transitions, issues on other
> architectures, etc)
> 
>     (5) people who already run testing/unstable/experimental and want
> newer software from upstream (that is unavailable to them because of
> release concerns rather than stability concerns)
> 
>     (6) the installer team, who find it overly difficult to do beta
> releases against testing and get useful feedback (because it takes too
> long to update the beta to fix bugs due to britney delays; because
> betas get rendered obsolete automatically by testing updates)
> 
>     (7) the release team, who have to worry simultaneously about
> people using testing/unstable wanting new software (cases 4 and 5), at
> the same time they're trying to stabilise the collection of packages
> for a stable release
> 
> I think official snapshots would help with (2) and (6), and possibly
> (1) since if more people beat the technical problems and enjoy the
> experience, they'll pass on good recommendations.

I really don't think snapshots are necessary at all to address (1), (2),
and (6).  A constantly working installer solves all of those; not
snapshots.

I do think snapshots may address another set of people:

   (8) people who want a faster moving operating system than stable, but
don't want the breakage that comes during the daily testing upgrade
treadmill.

However, I think that some stronger policies in the existing testing
support scripts could also address this in a simpler fashion. One of
which would be to use piuparts to check upgrades between testing
versions (and from stable to testing), and to block transitions when
that fails.  Of course, this only verifies packaging issues.  It
doesn't address lost or changed features between testing packages.  But
users can always submit bug reports for that and hopefully get an
update in a couple weeks depending on whether the maintainer is
responsive.

Also, the now official nature of backports can help (8) a lot as well.

> My feeling is that the point of "rolling" is to address (4), (5) and
> (7) (and maybe (3)), and I think that's a much more challenging set of
> problems.
 
Just curious, how do you see "rolling" addressing (7)?  Is it that
users making use of a "rolling" won't file bugs that the release team
then has to take the time to ignore?

Personally, I think that CUT should be limited to addressing (1), (2),
(6), and (8) in the existing testing framework; rather than snapshots.
Also, I think a separate rolling team should be started to address (3),
(4), (5), and (7). Finally, if there are enough people interested in
the snapshot solution for (8), then a separate testing-snapshots team
can be formed, and snapshot media provided in an unofficial manner to
gauge usefulness/interest, which could be assimilated later into an
official status.

Best wishes,
Mike