Goals for Fedora Workstation upgrades

[drago01]

On Fri, Oct 3, 2014 at 8:59 PM, Stephen Gallagher <sgallagh at 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.