Goals for Fedora Workstation upgrades

[Stephen Gallagher]

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?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://lists.fedoraproject.org/pipermail/desktop/attachments/20141003/d16043a6/attachment.sig>