[cut-team] CUT thoughts

[Anthony Towns]

On Mon, Aug 16, 2010 at 03:15, Lucas Nussbaum <lucas at lucas-nussbaum.net> wrote:
> On 14/08/10 at 11:28 -0400, Anthony Towns wrote:
>> For me, the proposals that I think will make this better for me are
>> regular/frequent snapshots of testing and security support for them.
>> That way I can directly install the most recent snapshot, set it up to
>> automatically install security updates, and plan for functionality
>> changes when the next CUT snapshot happens.
> How would this differentiate from other distributions doing 6-month
> release cycles, and in particular Ubuntu, which can already be seen as
> Debian snapshots (+ added value)?

It'd have support for more architectures than Ubuntu for one
(including kfreebsd* even I guess?), would be easily upgradable to
testing/unstable, and users of testing snapshots would be helping to
test the next stable release of Debian.

> Doing "snapshot testing for installation, with only minimal security
> support, then tell users to use rolling", we provide something quite
> unique in the Free Software world, with a constant flux of new upstream
> releases.

testing and unstable already provide a constant flux of new upstream
releases already, though... How will rolling be different from these?

> This only adds minimal (but interesting) work for the project,

I'm not sure that's true; managing transitions and doing rebuilds
isn't really that interesting, or that easy, and as far as I can tell
that's going to be needed.

> with huge benefits for the "relevance" of Debian in the Free Software
> world, since rolling will constantly be one of the places where
> freshly-released software will get real users.

"Freshly released" and "constantly usable" are often in competition
though -- that's why we don't have the latest upstream kernel or X in
unstable right now, eg, and why we have versions encoded into package
names (antlr v antlr3, samba v samba4, various versions of python,
squid v squid3, etc) so that users can make that choice.

That's not a problem -- it's just a matter of choosing how much you
focus on fresh and how much you focus on usable; I'm just not seeing
much opportunity for rolling to get much fresher than testing already
is. At the moment, the unfreshness I see is mostly due to either
difficult problems to resolve (gnash is blocked by a "crippling memory
bug", eg) or by a deliberate decision (wesnoth is blocked by a
maintainer filed RC bug).

> I agree with your concern about security support for testing/rolling,
> and the fact that "please just dist-upgrade" is not really a solution.
> But this could be solved by other means, for example by having a tool
> (similar to apt-listchanges) that would scan changelogs for CVEs and
> warn the user when upgradable packages provide security fixes. The user
> would then be able to upgrade only those packages.

That can't be done well with testing though, because pulling in one
new package for security updates can either (a) pull in a bunch of
other packages due to transitions and versioned dependencies, or (b)
pull in a bunch of major changes due to a new upstream version having
migrated to testing since the last snapshot was taken.

That said, it sounds like an easy approach to start with, and if we
can use debsecan to monitor just how much of a problem it turns out to
be, that's pretty cool...

Cheers,
aj

-- 
Anthony Towns <aj at erisian.com.au>