[cut-team] CUT thoughts

[Michael Gilbert]

On Mon, 16 Aug 2010 10:15:06 +0200, Lucas Nussbaum 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.
> > 
> > I would like to see more uploads to unstable (newer kernels, newer X,
> > etc) and more propogation to testing (Lucas mentioned wesnoth, which
> > is blocked by the maintainer's request because squeeze is targetting
> > 1.8, which is released upstream but hasn't been uploaded afaics, not
> > 1.6 which is in unstable). I think it'd be great if CUT somehow helped
> > with that, but I don't see how it will.
> > 
> > To me, that means starting by choosing a day to snapshot testing every
> > 3-6 months, including an installer for the snapshot, and doing
> > security support for the snapshot until (at least) the next snapshot
> > is released.
> 
> 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)?
> 
> 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. This only adds minimal (but interesting) work for the project,
> 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.
> 
> 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.

debsecan already exists to provide such information.  One could easily
write an apt-listsecchanges wrapper around that to achieve what you
want.

mike