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 [[email protected]] -- ubuntu-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
