Avoiding fragmentation with a rolling release

[Colin Watson]

On Thu, Feb 28, 2013 at 09:55:31PM +0000, Matthew Paul Thomas wrote:
> Rick Spencer wrote on 28/02/13 20:41:
> > On Thu, Feb 28, 2013 at 12:14 PM, Matthew Paul Thomas
> >> I don't understand why you are proposing monthly snapshots at 
> >> all. Can you elaborate?
> > 
> > The monthly snapshots would be for users who want the fresh 
> > software, but don't want to manage the daily grind of updating to 
> > ensure that their system is secure. The way I think of it is that 
> > we "support" 2 cadences for updates, daily and monthly.
> 
> As above, that seems like something we'd want to discourage. Even so,
> it is already possible in R, without snapshots. It takes two clicks:
> 
> 1. When Software Updater appears, expand "Details of updates".
> 
> 2. Uncheck the checkbox next to "Other updates", leaving "Security
> updates" checked. (These groupings appear only if any of the updates
> are security updates.)

This is a good point.  (It has no real-world testing, because we have
never had a release where we applied changes both in the release pocket
and in -security; we have only had releases where we applied changes
only in the release pocket, and releases where we applied changes in
both -security and -updates.  That said, I agree that this argument
holds up theoretically, and thus we could do this without the complexity
of staging everything in -updates.)

Another possibility that AFAIK has not been discussed is to use the new
phased updates facility; we could set the Phased-Update-Percentage to 0
until we want to roll something out.

I share your scepticism about the value of monthly snapshots for
upgraders, though (as opposed to snapshot images, marketing checkpoints,
or what-have-you).  It seems to me to be the worst of both worlds.

> > I think that crash reports is a useful and valid measure of 
> > robustness, and your measures do point to the fact that Quality is 
> > journey, not a destination. We should certainly continue to focus 
> > on decreasing crashes, increasing performance, increasing security,
> > etc... all the things that make software robust for users.
> > 
> > ...
> 
> Certainly robustness is much more than just crashes, but
> errors.ubuntu.com already records more than just crashes. (And yes, we
> take that into account when comparing releases.) If there are other
> measurable grounds for claiming one release is more robust than
> another, then let's measure them.

Do we measure how often parts of upgrades are held back?  That's been
the largest single infrastructural improvement in raring, but I don't
think it's reflected on errors.u.c because it doesn't count as an
upgrade failure.

-- 
Colin Watson                                       [cjwatson at ubuntu.com]