17:13:24 <notting> #startmeeting Designing the Update Experience
17:13:24 <zodbot> Meeting started Sat Dec  5 17:13:24 2009 UTC.  The chair is notting. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:13:24 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:13:39 <notting> #topic Designing the Update Experience - http://fedoraproject.org/wiki/Desktop/Whiteboards/UpdateExperience
17:14:29 <notting> Problems: we have too many updates, at too low a level for most users. (wget? what's wget, and why am I running it?)
17:15:08 <mizmo> is meeting bot recording this
17:15:10 <notting> uncoordinated: automake was upgraded in an older stable release, which affected the build process for other packages, including other security updates
17:16:09 <notting> coordination mechanism is just a mailing list
17:17:04 <mizmo> zodbot start meeting
17:17:14 <mizmo> zodbot help
17:17:14 <zodbot> mizmo: (help [<plugin>] [<command>]) -- This command gives a useful description of what <command> does. <plugin> is only necessary if the command is in more than one plugin.
17:17:23 <mizmo> zodbot meeting help
17:17:40 <mizmo> jesse signs everything that is built for updates-testing
17:17:59 <mizmo> then he starts a push process which creates new updates repos for updates-testing, updates-release for f10, f11, f12... long and time-consuming that takes about a day to do everything
17:18:04 <mizmo> pushes to repos, pushes to near master...
17:18:10 <mizmo> syncs out and updates all the bug flags in bodhi
17:18:18 <mizmo> pkg kit checks by default one time a day
17:19:17 <mizmo> zodbot #startmeeting
17:19:22 <mizmo> updates are done ad-hoc
17:20:10 <notting> updates aren't really tested as a unit, even though they're pushed as a unit
17:20:56 <mizmo> notting: do you know if zodbot is recording?
17:21:13 <notting> mizmo: it should be, it said it was.
17:21:16 <mizmo> oh okay
17:21:56 <ianweller> mizmo: (meeting's already started, yes)
17:23:04 <notting> other OSes: MacOS X has 'system updates' (could be X, libc, kernel, cocoa), and 'application updates' (itunes, safari, firefox, etc.)
17:23:41 <notting> #idea walters - we know, as a desktop, what apps people run. we can do categorization with that data
17:25:27 <notting> (we start to go through the suggestions on the wiki page now)
17:28:00 <notting> for all releases:
17:28:18 <notting> - system updates should be tested as a single unit, and presented to the user as such
17:28:39 <notting> - system updates must not break any application we define as critical (firefox), or any application as all
17:28:50 <notting> note: application here is 'user-visible application'
17:30:45 <notting> - application updates should appear as a single update 'firefox update' (which includes the varous dependent things)
17:31:20 <notting> - by batching these, we can use it as a form of versioning. 'Fedora 12.1' or similar
17:33:21 <notting> - apps should not do their own updates (such as firefox does on windows)
17:34:49 <notting> - why do i have to do updates while I'm using the system?
17:37:52 <notting> stickster: what about security updates?
17:38:08 <notting> they can still be handled separately; they are normally still scheduled, etc.
17:40:10 <notting> more discussion on why apps doing their own updates is bad, and why we should use the system mechanism
17:40:23 <notting> - limiting number of reboots & restarts
17:40:31 <notting> - offers the user a way to opt out of certain app updates
17:41:01 <notting> - can better test combinations
17:41:02 <notting> etc.
17:42:15 <notting> We want to be able to queue/defer updates to currently running software
17:42:52 <notting> should download updates in the background
17:43:32 <notting> mizmo - should define some portion of the data reserved for update data, cleaned when done
17:43:45 <notting> lmacken - should be able to define how we want to do updates at install/firstboot time
17:44:17 <mizmo> also special mode for updates to occur in -like on the PS3hehe
17:45:08 <notting> want to be able to install updates that require restarting at shutdown time
17:46:49 <notting> walters - one issue with that is shutdown/etc. is the time when you're likely to run out of battery
17:47:17 <notting> ... further refinement of these ideas for stable releases ...
17:47:50 <notting> - batched updates should just occur once a week at most. perhaps once a month?
17:48:00 <notting> - 'new release tuesday'
17:48:39 <notting> - system updates should a) fix critical bugs b) security vulnerabilities c) hardware enablement
17:51:08 <notting> stickster - we may have another class of packages that aren't system tools, but aren't full end-user apps.
17:52:17 <notting> system updates should be able to run autonomously, and not deferred except for a very short time
17:52:25 <notting> app updates may be deferred or ignored
17:54:20 <notting> ... some discussion of apps that bring in large library sets that nothing else uses. how do we handle this?
17:55:49 <notting> app updates can add new features, etc. if firefox breaks firefox, well, that's on firefox
17:57:28 <notting> need to do more testing of zero-day updates - how is a stable release relevant if it gets 100 updates after install?
17:58:34 <notting> lmacken - "we will always push more updates than people want, and we will always break things. how do we minimize this?"
17:59:53 <notting> stickster - how do we get people to test?
18:00:00 <notting> caillon - we don't have any 'thing' for them to test
18:00:47 <notting> no defined test starting point, no test cases, no incentive for them to test (or to create this content)
18:02:51 <notting> this isn't even clear for groups like releng or QA doing testing of critical path updates
18:03:53 <notting> also, for people contributing bugs in bugzilla, how do they test updates? packages from koji?
18:04:13 <notting> ... time is running out ..
18:04:22 <notting> will try and discuss more at the hackfests tomorrow
18:15:29 <ianweller> notting: #endmeeting plz
18:35:15 <ricky> #endmeeting