Release criterion proposal: upgrade methods

[drago01]

On Wed, Sep 26, 2012 at 5:20 AM, Adam Williamson <awilliam at redhat.com> wrote:
> On Tue, 2012-09-25 at 23:01 -0400, Richard Ryniker wrote:
>
>> Maybe someone with more fortitude (intellectual honesty? discipline?)
>> than I will kill upgrade, and make the world a better place.  Or at least
>> document that "upgrade" is offered only on a "good effort" basis, with no
>> guarantee or support.
>
> That's more or less my take on it, and why I'd like to use the word
> 'recommended' rather than 'supported'. I agree that it's very difficult
> to convincingly suggest that upgrades are in any reasonable definition
> 'supported'.
>
> (As a sidebar, it's worth noting that major version upgrades are
> unsupported for RHEL, and Microsoft rarely offers true 'upgrades'
> between Windows builds any more, and I think never recommended them for
> enterprise use: vastly better funded and more conservative operating
> system projects than Fedora nevertheless have the same problems. It all
> rather indicates to me that 'supporting' major version upgrades of
> operating systems is rather close to being an impossibility.)

I have been always upgrading my systems, I do never reinstall (I never
tried to skip a release but from N-1 to N always has been fine for me;
the only time I did that was to move from i386 to x86_64 years ago).
Also Vista -> 7 upgrade worked just fine for me. Same for OSX
upgrades. Other linux distributions manage to support that as well.

> To bring this back to practicalities: I'd say this discussion represents
> a rather strong consensus that we don't see much value in
> *strengthening* the release criteria and validation testing as concerns
> upgrades. We are left with the option of preserving the existing status
> quo, wherein we effectively guarantee that precisely two fairly
> artificial cases will work, or of simply dropping the release criterion
> relating to upgrading and demoting the test cases to 'optional' status.

I don't see a reason why we should change anything. The status quo has
been fine and making it optional would just result into broken
upgrades (i.e not blocking for upgrade bugs etc).

> I can kind of see arguments both ways; on the one hand, the burden of
> testing upgrades to the strictly limited extent we currently do is not a
> terribly harsh one, and it at least gives us some confidence that the
> basic upgrade mechanism is not irretrievably broken. On the other hand,
> the practical benefits of the testing are fairly marginal: that 'we know
> it's not completely impossible' is pretty much all we get out of it.

I don't understand what you mean by "impossible"  ... we can test
specific cases like the usrmove migration pretty well (upgrade from
F16 to 17); we can test anaconda/preugrade/whatever ... everything
else is more or less the same as a regular update with just more
packages.

Sure we cannot test every single package whether it upgrades properly
but I don't see any reason why we should just say "it is impossible
lets just stop testing anything".