Avoiding fragmentation with a rolling release
cjwatson at ubuntu.com
Fri Mar 1 17:40:26 UTC 2013
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
Colin Watson [cjwatson at ubuntu.com]
More information about the ubuntu-devel