The discussion about F20 to F21 upgrades has been largely focused on the technolaogy - what will happen if we make package X depend on package Y and obsolete package Z. I understand the motivation behind wanting upgrades to be encoded in the package set and to keep special casing to a minimum. But I think we can't just shrug and consider that the end - we need to know what we are trying to achieve to figure out when we need to special case and do ugly things to get there.
Before going too far into the practicalities of what we can achieve for Fedora 21, I decided try to write down what we'd want for F21 => F22 and beyond. I mean this to be Workstation specific - not apply to other products or non-productized installations of Fedora.
* The end result of an upgrade to F<n> must have all the packages that would have been installed for a fresh install of F<n>
* 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: - There must be no duplication of applications in system roles. For example, there must not be two character map applications - There should be no left over system services started at boot If a default application is removed without any replacement in the new default set (e.g. we stop installing an office suite), leaving the old application is acceptable.
* Normal user configuration of the pre-upgraded system via (non-tweak-tool) desktop configuration must not leave the system in a broken state after the upgrade.
* After the upgrade, the user should see the new defaults for things like backgrounds unless they have explicitly configured non-default settings.
* We test the following upgrades:
fresh install F<n-1> => f<n> fresh install F<n-2> => f<n> serial upgrade fresh install F<n0> => F<n0+1> => ... f<n> (n0 to be determined - f20 or f21 most likely)
On Fri, 2014-10-03 at 13:50 -0400, Owen Taylor wrote:
The discussion about F20 to F21 upgrades has been largely focused on the technolaogy - what will happen if we make package X depend on package Y and obsolete package Z. I understand the motivation behind wanting upgrades to be encoded in the package set and to keep special casing to a minimum. But I think we can't just shrug and consider that the end - we need to know what we are trying to achieve to figure out when we need to special case and do ugly things to get there.
Before going too far into the practicalities of what we can achieve for Fedora 21, I decided try to write down what we'd want for F21 => F22 and beyond. I mean this to be Workstation specific - not apply to other products or non-productized installations of Fedora.
- The end result of an upgrade to F<n> must have all the packages that
would have been installed for a fresh install of F<n>
Yes, with the obvious subtext that this should be additive-only. I.e. if Workstation 22 decides that Geary is the default email client, it should NOT remove Evolution or Thunderbird or Claws, etc. (This was probably understood already, but it's useful to have it be explicit.)
- 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.
- There must be no duplication of applications in system roles. For
example, there must not be two character map applications
System-level tools makes some sense.
- There should be no left over system services started at boot
I REALLY don't think this is acceptable. You're making decisions about what services the user wants to run. It's *arguable* about GNOME-internal services, but if for example we stopped shipping CUPS on the default install, it's REALLY not acceptable to disable and remove it from an installed system.
If a default application is removed without any replacement in the new default set (e.g. we stop installing an office suite), leaving the old application is acceptable.
I don't like that "don't take things away from the user" is kind of an afterthought here. I also REALLY don't like the idea of arbitrarily replacing important software like an office suite. If we suddenly decide that Koffice is better in the default set than LibreOffice, we shouldn't be forcing that on our users. I have no problem if they are coexisting after upgrade, but one should not replace the other unless they are fully backwards-compatible with what is being replaced (such as how LibreOffice replaced OpenOffice.org)
- Normal user configuration of the pre-upgraded system via
(non-tweak-tool) desktop configuration must not leave the system in a broken state after the upgrade.
Meaning knobs in the gnome-settings panel, I assume. I note that you make no claims at all about extensions, which I understand the technical reasons for, but it's still not ideal for a user.
Perhaps we can have the upgrade tool try to detect extensions and warn that they may not work after upgrading? (I realize this is difficult to do in the general case, but maybe just for extensions running in the active session?)
- After the upgrade, the user should see the new defaults for things
like backgrounds unless they have explicitly configured non-default settings.
Agreed.
We test the following upgrades:
fresh install F<n-1> => f<n> fresh install F<n-2> => f<n>
I don't think this has ever been a policy, and upgrading from F19->F21 productized adds more trouble to the process for dubious gains.
serial upgrade fresh install F<n0> => F<n0+1> => ... f<n> (n0 to be determined - f20 or f21 most likely)
I don't know what exactly that means. Could you rephrase it?
On Fri, Oct 3, 2014 at 8:59 PM, Stephen Gallagher sgallagh@redhat.com wrote:
On Fri, 2014-10-03 at 13:50 -0400, Owen Taylor wrote:
The discussion about F20 to F21 upgrades has been largely focused on the technolaogy - what will happen if we make package X depend on package Y and obsolete package Z. I understand the motivation behind wanting upgrades to be encoded in the package set and to keep special casing to a minimum. But I think we can't just shrug and consider that the end - we need to know what we are trying to achieve to figure out when we need to special case and do ugly things to get there.
Before going too far into the practicalities of what we can achieve for Fedora 21, I decided try to write down what we'd want for F21 => F22 and beyond. I mean this to be Workstation specific - not apply to other products or non-productized installations of Fedora.
- The end result of an upgrade to F<n> must have all the packages that
would have been installed for a fresh install of F<n>
Yes, with the obvious subtext that this should be additive-only. I.e. if Workstation 22 decides that Geary is the default email client, it should NOT remove Evolution or Thunderbird or Claws, etc. (This was probably understood already, but it's useful to have it be explicit.)
- 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.
- There must be no duplication of applications in system roles. For
example, there must not be two character map applications
System-level tools makes some sense.
- There should be no left over system services started at boot
I REALLY don't think this is acceptable. You're making decisions about what services the user wants to run. It's *arguable* about GNOME-internal services, but if for example we stopped shipping CUPS on the default install, it's REALLY not acceptable to disable and remove it from an installed system.
If a default application is removed without any replacement in the new default set (e.g. we stop installing an office suite), leaving the old application is acceptable.
I don't like that "don't take things away from the user" is kind of an afterthought here. I also REALLY don't like the idea of arbitrarily replacing important software like an office suite. If we suddenly decide that Koffice is better in the default set than LibreOffice, we shouldn't be forcing that on our users. I have no problem if they are coexisting after upgrade, but one should not replace the other unless they are fully backwards-compatible with what is being replaced (such as how LibreOffice replaced OpenOffice.org)
- Normal user configuration of the pre-upgraded system via
(non-tweak-tool) desktop configuration must not leave the system in a broken state after the upgrade.
Meaning knobs in the gnome-settings panel, I assume. I note that you make no claims at all about extensions, which I understand the technical reasons for, but it's still not ideal for a user.
Perhaps we can have the upgrade tool try to detect extensions and warn that they may not work after upgrading? (I realize this is difficult to do in the general case, but maybe just for extensions running in the active session?)
- After the upgrade, the user should see the new defaults for things
like backgrounds unless they have explicitly configured non-default settings.
Agreed.
We test the following upgrades:
fresh install F<n-1> => f<n> fresh install F<n-2> => f<n>
I don't think this has ever been a policy, and upgrading from F19->F21 productized adds more trouble to the process for dubious gains.
serial upgrade fresh install F<n0> => F<n0+1> => ... f<n> (n0 to be determined - f20 or f21 most likely)
Well I think that means you install "F20" and want to go to "FW26" you should be able to do F20->FW21->FW22->...->FW26 ... but given that F<n> => <Fn+1> is tested and supposed to work anyway this should "just work" without any additional effort.
On Fri, Oct 3, 2014 at 9:22 PM, drago01 drago01@gmail.com wrote:
but given that F<n> => <Fn+1> is tested and supposed to work anyway this should "just work" without any additional effort.
There is some room for breakage between
F<n> at the time F<n+1> is released => F<n+1> at the time F<n+1> is released and F<n> at the time F<n+4> is released => F<n+1> at the time F<n+4> is released,
but hopefully not too much
On Fri, Oct 3, 2014 at 8:59 PM, Stephen Gallagher sgallagh@redhat.com 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). 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 ...
On Fri, Oct 3, 2014 at 4:46 PM, Florian Müllner fmuellner@gnome.org wrote:
On Fri, Oct 3, 2014 at 8:59 PM, Stephen Gallagher sgallagh@redhat.com 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.
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.
josh
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@gnome.org wrote:
On Fri, Oct 3, 2014 at 8:59 PM, Stephen Gallagher sgallagh@redhat.com 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.
Hi
On Fri, Oct 3, 2014 at 5:25 PM, Paul W. Frields wrote:
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.
On a multi-user system, not all users necessarily have the same weight. If you are merely using such info as a advisory note, thats fine but if we are deciding to swap out applications based on this info, it is being way too clever and not in a good way.
Rahul
On Fri, Oct 3, 2014 at 11:10 PM, Josh Boyer jwboyer@fedoraproject.org wrote:
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.
Considering that removing an application does not affect any user data or configuration associated with said application, I don't agree that this is unacceptable or unsafe - users that don't like the new default can easily revert to the old one. When they use search to launch the application, it's actually little more than an extra click - instead of the application, they get its details page in Software which allows them to install it. There's obviously some disruption and inconvenience in the (one time) extra step, but it hardly classifies as breakage in my opinion - in particular as I would expect many (most?) users to follow the new default (after all there's a reason for changing the default - it is supposed to better than the old one, at least for most users). I also think we should not ignore the impact that piling up stuff the user never asked for over time has. Technically removing an unwanted applications is not any more effort than installing a wanted one, but there's a huge difference between cleaning up other people's mess and adding something you are looking forward to using.
Picking the default email client as example, assume we change it from Evolution to Thunderbird at some point, and to Geary some releases later. Following Owen's proposal, (1) users who are happy with the default (or don't use any email client) end up with one client (2) users who prefer one of the old defaults (either Evo or Thunderbird) end up with two clients (3) users who prefer some other email client (say KMail) end up with two clients as well (4) users who prefer to stick with Evo when we change the default to Thunderbird, but then adopt Thunderbird by the time we switch to Geary end up with three clients
I only see a somewhat reasonable justification for installing three email clients in case (4), I'd put all the other cases somewhere between "a bit dodgy" and "extremely messy" - in particular installing four clients for users that only ever used a single one (case (3)) is pretty crazy. If this was done to prevent irreparable damage to case (2) users, that'd be an unfortunate but necessary drawback. But to save some users a couple of minutes on updates?
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.
Very much agreed. Ideally the new default would pick up the most important configuration from the old one to make the transition as painless as possible (to stick with the email example: import existing accounts so users don't have to spend time repeating a boring setup they already did in the past). At the very least the change should be well documented, including how to get back to the old default if we end up removing it.
Hi
On Fri, Oct 3, 2014 at 8:24 PM, Florian Müllner wrote:
Considering that removing an application does not affect any user data or configuration associated with said application, I don't agree that this is unacceptable or unsafe
It may be safe but it is not expected at all. To continue with your example, if users were using Evolution in Fedora 20 and after the upgrade to Fedora 21, Evolution gets removed and users get Geany which they have no idea about and they have to go back and manually install Evolution again just to get their emails? That is just completely unacceptable especially if you don't even bother to ask them ahead of time.
I understand you want to control the experience to some extend but I think you are underestimating how extremely disruptive this is for users. Provide them the tools to get a "fresh install" style experience instead but don't remove applications they could be relying on just because they are no longer the default. One way of avoiding previous default applications cluttering up the system is to have a very high bar to doing that.
Rahul
On Fri, Oct 3, 2014 at 8:24 PM, Florian Müllner fmuellner@gnome.org wrote:
On Fri, Oct 3, 2014 at 11:10 PM, Josh Boyer jwboyer@fedoraproject.org wrote:
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.
Considering that removing an application does not affect any user data or configuration associated with said application, I don't agree that this is unacceptable or unsafe - users that don't like the new default can easily revert to the old one. When they use search to launch the
Um... except the cases where the new application keeps it's own directory of caches and such. Think of evolution vs. thunderbird. I'd be really upset if an upgrade resulted in me going to start my email and having to either a) redownload all the headers and messages into a new cache or b) dig around for an app in the software center that I was perfectly happy using.
application, it's actually little more than an extra click - instead of the application, they get its details page in Software which allows them to install it. There's obviously some disruption and
Not everyone user search to start apps. Many people use the favorites list and they'll be irritated it wasn't there.
inconvenience in the (one time) extra step, but it hardly classifies as breakage in my opinion - in particular as I would expect many
You've used Fedora before, right? It's not just "one click". It's more like:
1) look in favorites and notice it's gone 2) search for it while pissed off it's not in favorites 3) get even more irritated it was removed and you have to install it again 4) wait for all the metadata to download 5) have PK tell you there are 300M worth of other updates to apply 6) decided to ignore that and just install your app (and the update dependencies it has now) 7) wait for it to install 8) manually add it back to favorites 9) finally start your task
and then possibly
10) remove the new default app you didn't want in the first place
(most?) users to follow the new default (after all there's a reason for changing the default - it is supposed to better than the old one, at least for most users). I also think we should not ignore the impact that piling up stuff the user never asked for over time has. Technically removing an unwanted
Ok, but now you're back to arguing for swapping things out that were never used. Which is fine. That isn't the concern. If it isnt' used, and we can tell that, then there isn't really an issue with replacing it.
For the cases where we switch a default app, I think it might be possible to notify the user _before_ the upgrade via the upgrade tool. E.g. "Fedora 22 uses an amazing new IRC client that has built in emoji support as the default for IRC. Would you like to use this instead of the old default that has no cute picture of a steaming pile of poo?" We can migrate data, etc before hand as well. Then it's no longer a surprise, and people are less pissed off.
(Clearly my example is poor and sarcastic, but you get my point. It's Friday evening, allow me some fun.)
applications is not any more effort than installing a wanted one, but there's a huge difference between cleaning up other people's mess and adding something you are looking forward to using.
Picking the default email client as example, assume we change it from Evolution to Thunderbird at some point, and to Geary some releases later. Following Owen's proposal, (1) users who are happy with the default (or don't use any email client) end up with one client (2) users who prefer one of the old defaults (either Evo or Thunderbird) end up with two clients (3) users who prefer some other email client (say KMail) end up with two clients as well (4) users who prefer to stick with Evo when we change the default to Thunderbird, but then adopt Thunderbird by the time we switch to Geary end up with three clients
They've made choices to use those email clients. We don't get to unilaterally undo their choices just because we think we know they'll like the new thing better. (and in your cases 3/4 they could have easily removed Evo when they switched to Thunderbird or KMail).
I only see a somewhat reasonable justification for installing three email clients in case (4), I'd put all the other cases somewhere between "a bit dodgy" and "extremely messy" - in particular installing four clients for users that only ever used a single one (case (3)) is pretty crazy. If this was done to prevent irreparable damage to case (2) users, that'd be an unfortunate but necessary drawback. But to save some users a couple of minutes on updates?
No, see below. It's not just about the updates. It's about the fact that, however well intentioned, the distro made a choice that the user wasn't expecting it to make and removed something that was in use without telling them about it.
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.
Very much agreed. Ideally the new default would pick up the most important configuration from the old one to make the transition as painless as possible (to stick with the email example: import existing accounts so users don't have to spend time repeating a boring setup they already did in the past). At the very least the change should be well documented, including how to get back to the old default if we end up removing it.
It's not just accounts. It's metadata, it's keyboard shortcuts, it's menu layouts. It is the entire UX. Every time you change how someone does a task they were already doing, that person will either grumble about it and learn the new thing or they'll get irritated and use the old thing. Do that enough times though and those grumbles become more than just grumbles and they start using something else entirely.
Now, I think we probably mostly agree that if we switch a default app for another, those apps are (hopefully) likely to be very similar. The transition curve should be very small, and that's something we should be considering before we make the switch to begin with. These cases will probably be fairly limited as well. However, I really do not want to operate under the assumption that we can blindly switch applications out from under the users.
josh
On Fri, Oct 03, 2014 at 08:58:30PM -0400, Josh Boyer wrote:
Um... except the cases where the new application keeps it's own directory of caches and such. Think of evolution vs. thunderbird. I'd be really upset if an upgrade resulted in me going to start my email and having to either a) redownload all the headers and messages into a new cache or b) dig around for an app in the software center that I was perfectly happy using.
The example Owen gave was a character picker. Maybe there's a distinction to be made between apps which keep data and (meaningful) preferences, and ones that are just little utilities?
On Fri, 2014-10-03 at 21:10 -0400, Matthew Miller wrote:
The example Owen gave was a character picker. Maybe there's a distinction to be made between apps which keep data and (meaningful) preferences, and ones that are just little utilities?
I'd rather distinguish between uninstallable core ("system") apps, and other apps. Core apps are part of the operating system and we should feel free to add and remove them during major upgrades. If the user doesn't want his operating system to change, he shouldn't upgrade.
For non-core apps, like the aforementioned email clients, we may want to be more cautious. I don't think it'd be unacceptable to remove non-core apps if they were previously installed by default, but I'd rather leave them alone. By definition, these apps are not part of the operating system, so why should we bother changing them? They're just a starting point that we hope users will find useful, and messing with them is more likely to annoy than to relieve ("Oh I'm so glad that Evolution disappeared when I upgraded to F23" seems less likely than the opposite). (Another option would be to let users choose which apps to keep when upgrading, like Josh mentioned.)
I'm curious if anyone else thinks this distinction is valuable.
Note that this plan would work better if the line between core and non-core apps was less arbitrary. Firefox is a good default browser, but I'd rather it not be considered an unremovable core component of the operating system (those should not be branded!), so it shouldn't be removed if e.g. Epiphany were to become core and be installed during an upgrade. Removing Firefox is one of those changes that would be much more likely to annoy than not. But swapping one unremovable app (hypothetically, say gnome-system-log) for another (gnome-logs) would be fine. We'd just need to be more careful with what is removable (orca?) and what is not (gnome-dictionary?).
Michael
On 10/03/2014 09:10 PM, Matthew Miller wrote:
On Fri, Oct 03, 2014 at 08:58:30PM -0400, Josh Boyer wrote:
Um... except the cases where the new application keeps it's own directory of caches and such. Think of evolution vs. thunderbird. I'd be really upset if an upgrade resulted in me going to start my email and having to either a) redownload all the headers and messages into a new cache or b) dig around for an app in the software center that I was perfectly happy using.
The example Owen gave was a character picker. Maybe there's a distinction to be made between apps which keep data and (meaningful) preferences, and ones that are just little utilities?
As a long time Red Hat/Fedora user, my expectation is that an upgrade will bring in newer versions of things (and any of their dependencies that are *required* for their operation) but otherwise leave my system alone. Remember, my system already works the way I want. Please don't break that.
An argument could be made that certain system-level things may need to change, especially if the old one is going to be abandoned (like moving boot loaders or init systems) but even then, I always read the release notes, so as long as it is clearly noted and the user is given an upgrade path ("to switch to the new default X subsystem, uninstall Y and install Z and run this configuration migration script").
-Adam Batkin
On Sun, Oct 5, 2014 at 2:40 AM, Adam Batkin adam@batkin.net wrote:
[...] An argument could be made that certain system-level things may need to change, especially if the old one is going to be abandoned (like moving boot loaders or init systems) but even then, I always read the release notes, so as long as it is clearly noted and the user is given an upgrade path ("to switch to the new default X subsystem, uninstall Y and install Z and run this configuration migration script").
The point of the an upgrade is that it is an automated process. Asking the user to do "x and y" afterwards is not really an option. It's pushing the burden to the user.
On 10/05/2014 01:55 AM, drago01 wrote:
On Sun, Oct 5, 2014 at 2:40 AM, Adam Batkin adam@batkin.net wrote:
[...] An argument could be made that certain system-level things may need to change, especially if the old one is going to be abandoned (like moving boot loaders or init systems) but even then, I always read the release notes, so as long as it is clearly noted and the user is given an upgrade path ("to switch to the new default X subsystem, uninstall Y and install Z and run this configuration migration script").
The point of the an upgrade is that it is an automated process. Asking the user to do "x and y" afterwards is not really an option. It's pushing the burden to the user.
That's the argument for automatically upgrading "certain system-level things". My point is that an upgrade shouldn't touch anything at the application level. Don't touch text editors, web browsers, e-mail clients, compilers, scripting languages, etc... The only exception being if it's a requirement for something else in the platform (i.e. you didn't have ruby installed before, but it's a requirement for some system level script, so now it will be installed).
-Adam Batkin
On Fri, 2014-10-03 at 14:59 -0400, Stephen Gallagher 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 think there's a continuum of cases here. Factors include:
- Does the application have user-visible branding that will be familiar to the user and allow the application to be distinguished from other applications in the same role? - Will the user have accumulated data and settings in the application that can't be easily migrated to the new application? - Is the old application still supported upstream?
If all of these are no, we would probably just want a Obsoletes:; if all of these are yes, then leaving the old application installed is quite likely the right answer.
In the end, we want to avoid things that are going to look broken confuse the user.
- There must be no duplication of applications in system roles. For
example, there must not be two character map applications
System-level tools makes some sense.
- There should be no left over system services started at boot
I REALLY don't think this is acceptable. You're making decisions about what services the user wants to run. It's *arguable* about GNOME-internal services, but if for example we stopped shipping CUPS on the default install, it's REALLY not acceptable to disable and remove it from an installed system.
On a Workstation, system-level services running by default are internal details - not something that the user is configuring. I'm not thinking mysqld here; I'm thinking about iscsid or an input method daemon. I'm not sure how much we'll have problems here - systemd activation definitely helps. I do think it's worth in testing comparing the running list of processes between a fresh install and an upgrade and see if there are leftovers that are eating ram and slowing down the boot process.
If a default application is removed without any replacement in the new default set (e.g. we stop installing an office suite), leaving the old application is acceptable.
I don't like that "don't take things away from the user" is kind of an afterthought here. I also REALLY don't like the idea of arbitrarily replacing important software like an office suite. If we suddenly decide that Koffice is better in the default set than LibreOffice, we shouldn't be forcing that on our users. I have no problem if they are coexisting after upgrade, but one should not replace the other unless they are fully backwards-compatible with what is being replaced (such as how LibreOffice replaced OpenOffice.org)
Our best defense here, as was pointed out, is to keep preinstalls to a minimum - don't feature apps by putting them into the release, feature them in GNOME Software.
- Normal user configuration of the pre-upgraded system via
(non-tweak-tool) desktop configuration must not leave the system in a broken state after the upgrade.
Meaning knobs in the gnome-settings panel, I assume. I note that you make no claims at all about extensions, which I understand the technical reasons for, but it's still not ideal for a user
Since extensions aren't (in general) shipped by Fedora, we have only a limited ability to make requirements about them. The GNOME behavior (unless overridden by an hidden gsetting) is that extensions are assumed *NOT* to work with new versions of GNOME unless explicitly marked as such. So what happens, is that if you upgrade early to a new version of GNOME, all your extensions might vanish, but you won't end up with a broken desktop.
GNOME extensions should definitely be doing better in various ways on upgrades:
- Having a test image available to authors and easy ways to deploy extensions into that image running into a VM; the author shouldn't have to set up a devel environment inside the VM. - Mailing extension authors as soon as the next version of GNOME is frozen with instructions for testing. - Actively reach out to authors of the most popular extensions and try to make sure that we have them covered. - And actually have extension upgrade integration into the desktop
Unfortunately, right now, there's nobody working on any of this.
Perhaps we can have the upgrade tool try to detect extensions and warn that they may not work after upgrading? (I realize this is difficult to do in the general case, but maybe just for extensions running in the active session?)
Once the user has decided to upgrade, I don't know if we should derail them - we don't have any control on our end when or whether any particular extension becomes available. I think it would be useful to have a some page you could easily go to on extensions.gnome.org that showed which of your extensions will work on the next version of GNOME.
We test the following upgrades:
fresh install F<n-1> => f<n> fresh install F<n-2> => f<n>
I don't think this has ever been a policy, and upgrading from F19->F21 productized adds more trouble to the process for dubious gains.
This is a policy for F22 and beyond - so upgrading from F19 is not in the picture here. :-) My thought here was that if we continue the policy of supporting Fedora release N until N+2 is released, people who wait until their version is EOL shouldn't have to do two consecutive upgrades to get to the newest Fedora.
As developers and enthusiasts, it's quite easy to overestimate upgrade percentages - to think that *nobody* is still using F19 at this point.
If we could get stats for what percentage of Fedora systems are checking for updates on each version, we could get a better idea about whether making the upgrade-process non-awful for people who are lagging a version matters or not.
serial upgrade fresh install F<n0> => F<n0+1> => ... f<n> (n0 to be determined - f20 or f21 most likely)
I don't know what exactly that means. Could you rephrase it?
I mean simulating the process of installing Fedora 21 and upgrading as each new release comes out. Nothing in my proposal comes close to ensuring that an upgraded system is *identical* to a newly installed system, so there's definitely room for bugs where and F21 => F22 upgrade works, a F22 => F23 upgrade works, but F21 => F2 => F23 doesn't.
- Owen
On Mon, Oct 06, 2014 at 11:53:07AM -0400, Owen Taylor wrote:
Since extensions aren't (in general) shipped by Fedora, we have only a limited ability to make requirements about them. The GNOME behavior (unless overridden by an hidden gsetting) is that extensions are assumed *NOT* to work with new versions of GNOME unless explicitly marked as such. So what happens, is that if you upgrade early to a new version of GNOME, all your extensions might vanish, but you won't end up with a broken desktop.
I don't mean this in a high-drama way, but: there are several extensions which have become really ingrained in the way I use my GNOME desktop, and if they vanished, I would feel like my desktop were broken for me.
So....
GNOME extensions should definitely be doing better in various ways on upgrades:
- Having a test image available to authors and easy ways to deploy extensions into that image running into a VM; the author shouldn't have to set up a devel environment inside the VM.
- Mailing extension authors as soon as the next version of GNOME is frozen with instructions for testing.
- Actively reach out to authors of the most popular extensions and try to make sure that we have them covered.
- And actually have extension upgrade integration into the desktop
Unfortunately, right now, there's nobody working on any of this.
a huge vote for all of this. It's really important for a non-scary Fedora Workstatation upgrade experience. If we can find someone to work on this, I think it will pay off.
On Mon, Oct 06, 2014 at 11:53:07AM -0400, Owen Taylor wrote:
- Having a test image available to authors and easy ways to deploy extensions into that image running into a VM; the author shouldn't have to set up a devel environment inside the VM.
- Mailing extension authors as soon as the next version of GNOME is frozen with instructions for testing.
Does something like the LWN series for Linux in-kernel API changes(*) exist for Gnome Shell? If not, then that might be pretty useful for extension authors, especially those not already involved with core Gnome development.
On Fri, Oct 3, 2014 at 1:50 PM, Owen Taylor otaylor@redhat.com wrote:
The discussion about F20 to F21 upgrades has been largely focused on the technolaogy - what will happen if we make package X depend on package Y and obsolete package Z. I understand the motivation behind wanting upgrades to be encoded in the package set and to keep special casing to a minimum. But I think we can't just shrug and consider that the end - we need to know what we are trying to achieve to figure out when we need to special case and do ugly things to get there.
Before going too far into the practicalities of what we can achieve for Fedora 21, I decided try to write down what we'd want for F21 => F22 and beyond. I mean this to be Workstation specific - not apply to other products or non-productized installations of Fedora.
- The end result of an upgrade to F<n> must have all the packages that
would have been installed for a fresh install of F<n>
- 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:
- There must be no duplication of applications in system roles. For
example, there must not be two character map applications
- There should be no left over system services started at boot
If a default application is removed without any replacement in the new default set (e.g. we stop installing an office suite), leaving the old application is acceptable.
I agree with Stephan on these points. If we switch a default application in a newer version of Workstation, we cannot simply remove the old one during upgrades. It breaks all kinds of workflow, and there's really no point in forcing that on our users.
We can install the new application along side the old. If we wanted to be proactive about default changes, we could have firstboot (or whatever it's called) run on the first login for each user and highlight the new application changes and perhaps offer to switch the default to the new one.
josh
desktop@lists.stg.fedoraproject.org
-
Adam Batkin -
drago01 -
Florian Müllner -
Josh Boyer -
Lars Seipel -
Matthew Miller -
Michael Catanzaro -
Owen Taylor -
Paul W. Frields -
Rahul Sundaram -
Stephen Gallagher