1. Changing the Default Updates Model
Tom Callaway
Fedora Engineering/Infrastructure Manager

2. 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

3. 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.

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

6. 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

7. 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”

8. 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?

9. 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.

10. 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

11. 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)

12. 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

13. 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.

14. 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.

15. 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”)

16. Additional Ideas for the Future
CC-BY -

17. 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.

18. Questions?
Thanks.