[cut-team] CUT thoughts

Anthony Towns aj at erisian.com.au
Tue Aug 17 03:20:05 UTC 2010


On Mon, Aug 16, 2010 at 20:29, Joey Hess <joeyh at debian.org> wrote:
> 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've had limited time for CUT this week, but FWIW, aj and I seem to be
> almost entirely on the same page about CUT.

And from discussion, taking snapshots of testing every 3-6 months and
"releasing" them to users seems fairly uncontroversial. So sounds like
we can move forward with that while still discussing "rolling" and
whatnot.

>> 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.
> I'm afraid it's a lot of work to get a snapshot to even stable's level
> of security support.

I'm presuming "stable's level of security support" is roughly
synonymous with "the highest level of security support achievable in
the distribution industry". That that's evidently less than perfect is
slightly disappointing, but if CUT can even get into the same ballpark
that's pretty great.

> Suppose we did manage it.. If a new CUT snapshot is taken every 3 to 6
> months, and presumably support for the old snapshot is dropped, users
> would need to upgrade to the new snapshot (or on testing), every 3 to 6
> months to continue to get security support. So there's still a
> semi-frequent upgrade requirement.

Well, even 3 month upgrades are only 1/90th = 1.1% of the frequency of
daily upgrades (or 8% compared to weekly upgrades). Six monthly is
0.55% (4% vs weekly). That's a pretty huge win by my count.

Cheers,
aj

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



More information about the cut-team mailing list