Changing the Default Updates Model Tom Callaway Fedora Engineering/Infrastructure Manager spot@fedoraproject.org

Current Updates Model CC-BY - Official US Navy Imagery Fire hose model Updates coming all the time Constantly telling you that you need to update I suspect the average user ignores this Combined with PackageKit Getting sprayed in the face with updates you probably don't understand or care about CC-BY - Official US Navy Imagery

Testing of Current Updates Per package testing Sometimes, groups of packages, but usually, just one. If it happens at all Most updates don't get karma unless they have to.

Summary of Problems with the Current Model Too many updates Too often Too confusing Poorly tested Smells like fish

An Alternate Proposal Minimize the number of times the user has to think about updates Improve the user experience Make updates easier to consume Improve the Testing

Minimize the amount “Monthly update bundles” Take all the package updates that make it to “updates-stable” with one week left in the month Roll them into a Monthly Bundle “Fedora 19 August Update” Send them to the user - “The Fedora 19 August Update is available”

What about Security Updates Updates tagged as security go out asynchronously (when they hit stable) Because, well, SECURITY. I think we should weight security issues over user annoyance. Maybe we can make those issues look more ominous/serious?

Improve the User Experience Focus on Applications Joe User doesn't care about libxyz or perl-what-the- flock Joe cares about Firefox, Totem, LibreOffice When the bundle arrives, and I want the info on it, show me the apps. This ties into the GNOME Software Center replacement for PackageKit But most people don't care. Just want bugs fixed.

Make updates easier to consume The process should be as few clicks as possible. Run as much in the background as it can. Don't show the package list to the user But don't make it too hard for them to figure out if they want it. Summarize the core changes in the bundle Translate the summary

Improve the Testing That extra week in the month? Testing. Not going to tell QA how to test But they should test the packages as a block Possibly reuse some of the release testing Automated? Please? Not a replacement for karma (a step beyond that)

Things this does not do It does not require core changes to bodhi Does need additional tooling to make “monthly bundles” It does not change the testing->stable karma flow Just adds a third step beyond it

Things it does need Client support System needs to know when a bundle is ready and how to handle it Infrastructure Support Tooling to make bundles Tooling to tell clients that a bundle is ready QA Support We could do it without the testing aspect... but nah.

The New Default When we've got this built, we make it the default for users If people want the firehose model, it still exists. This new monthly model is just new repos. We should make it simple for the “power” user to have the firehose.

Tweaking User may want some applications to be treated like security model Support a whitelist for asynchronous immediate updates from “stable” repo. Possibly also auto-installed as option in whitelist Possibly also let user put packages in list (that aren't “applications”)

Additional Ideas for the Future CC-BY - http://www.flickr.com/photos/666_is_money/8683998256

Application Specific Features Treat applications asynchronously on launch Firefox has an update in stable (but not yet in the monthly bundle (or user hasn't applied bundle yet)) User opens Firefox and is prompted to upgrade it Test applications on launch Gimp has an update in testing User opens gimp and is prompted to help us test it If they agree, update it, restart it, then at a later point, ask for karma. Offer to roll-back.

Questions? Thanks.