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: >> 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. -- desktop mailing list desktop@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/desktop
