Goals for Fedora Workstation upgrades

[Owen Taylor]

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