On Fri, Oct 03, 2014 at 05:10:24PM -0400, Josh Boyer wrote: > On Fri, Oct 3, 2014 at 4:46 PM, Florian Müllner <fmuellner@xxxxxxxxx> wrote: > > On Fri, Oct 3, 2014 at 8:59 PM, Stephen Gallagher <sgallagh@xxxxxxxxxx> wrote: > >> On Fri, 2014-10-03 at 13:50 -0400, Owen Taylor wrote: > >>> * In general, packages that were originally installed by default on the > >>> system, but no longer installed by default in F<n> should be removed. > >>> This may not always be practical, but after the upgrade: > >> > >> No, absolutely not. I disagree vehemently. See above. Upgrades must > >> *never* remove a user's chosen applications. > > > > I don't think it is entirely fair to consider applications that are > > not installed explicitly by the user a choice - we picked it, not the > > user. We don't even know if the user has used her "chosen application" > > at least a single time - and if the user does not agree with the new > > default, the previous one is just a simple reinstall away (in which > > case the application's presence does become user configuration that > > must be preserved on future updates). > > Right. It's the "we don't know" part that makes it unacceptable. If > we've done a good job at picking defaults, then we're going to assume > the users are actually using them. If they aren't we have no way of > telling so it's not safe to just remove the application. > > If we did have a way to track how many times an application has been > opened while we upgrade, that might make things easier to deal with. The score from ~/.local/share/gnome-shell/application_state would be useful there, if someone figured out a way to sum over the various $HOME for multi-user. > > There's probably some point in here in favor of keeping the list of > > default applications small to encourage users to customize the set of > > installed applications, rather than trying to cover as many use cases > > as possible out of the box ... > > Yes, agreed. And if we switch applications for a particular task, it > should be done with great care and planning to minimize any impact on > a user's workflow. Sometimes you have to break things, but that > should be very very seldom. -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ The open source story continues to grow: http://opensource.com -- desktop mailing list desktop@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/desktop
