Talk:Desktop/Whiteboards/UpdateExperience

• bruno: Regarding: "System updates may only be deferred for a short time after which they will be installed automatically", this admin needs to be able to defer some updates indefinitely. I have had a period where it took over a year for a kernel bug affecting my hardware (causing a lock up) to get fixed. During that time kernel updates broke my system.
• bruno: For the boot testing (particularly in rawhide), you may want to add upstart to the list. A recent upstart change caused some surprises for me. After an update the reboot command didn't work until I had rebooted the system. A custom event in /etc/event.d stopped working and it seems that whole directory got depreciated.
• oget: I know this part is sketchy but... "gnome-session: * since nothing starts without it" : I have many systems here which don't have gnome-session but everything that I and all my users need seems to start without it.
• ffesti: Having a user's view on updates makes perfect sense. Mixing updating and testing policy with usability issues of the updating tools is probably not helping. Both require very different considerations and affect very different people and pieces of software. I would suggest splitting things up and just link to one another.
• ffesti: Grouping updates by application and putting everything else into a "system software" bucket is a usable interface. Nevertheless it does not address the actual flaw of the updater UI: It does not provide the information needed by the user to make the decision he has to make: "Update now or later?" (or do something complicated). To make this decision the user needs to know how important the update is (the current levels are just fine but are not displayed in the overall summary) and how expensive it is in term of system resources and interruption. Download size is probably a good enough estimate for the system resources used. But telling the user he has to reboot after he has installed the updates is much too late. Requiring reboot or logout are the major interruptions - just followed by applications that needs to be restarted. This should be stated at the very beginning. With this information in place the informations about updates - grouped cleverly or not - can just be hidden by a "Details" button that shows the list of applications or packages to be updated.
• ffesti: Update on shut down is a nice feature. Nevertheless there are quite some systems that are not shut down often enough to rely on that for installing all updates. Laptops are often just suspended/hibernated instead of shut down. Even many desktop machines are run 24/7.
• ffesti: "Users should be able to detect whether updates are available from within the app they are using." I guess we are talking about updates for the app currently used. I strongly disagree with this idea. Teaching all kind of applications about all kind of different update mechanism out there is just not possible. Even if there was only one way to update applications this is just a waste of time. I doubt that much upstream project will even consider integrating this.