Re: criterion proposal: upgrading across 2 releases

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 2015-11-24 at 21:57 -0500, Richard Ryniker wrote:
> On Tue, 24 Nov 2015 10:46:55 -0800, Adam Williamson wrote:
> 
> > We have never really gone to any lengths to test or support N-1 upgrades
> > with 3rd party repositories or non-repo software either.  That's a
> > different question.
> 
> From a user's perspective, the value of system-upgrade depends on its
> ability to move his system "as configured" to a new release.  All of his
> personalization, including any non-fedora software, remains in place.
> 
> You are certainly right to except non-Fedora software from QA tests.  The
> problem I perceive is the vast number of possible combinations of
> packages from just the Fedora repositories.  There may be no need to test
> exhaustively, but any heuristic is likely to miss problems from time to
> time.  It is likely only enough cases can be tested to distinguish "some
> system-upgrades work" from "system-upgrade is often impossible."
> 
> This is valuable to know, and I have no quibble with a QA criterion that
> says "system-upgrade is never possible" will block a release.  I suspect
> there is no precise, useful definition that will tell a user whether his
> particular system will succeed with system-upgrade.

Yes, this is basically the situation. We can only do so much by
literally testing actual upgrades, by hand or automated. Things like
the daily dependency checks and the taskotron depcheck test can help
more. But ultimately, there are so many permutations that we can never
really offer a guaranteed smooth upgrade path (and in fact, AFAIK, no
OS vendor - even those with far more resources than us - does this).

> "dnf system-upgrade" is rather new.  Maybe the Fedora organization should
> observe user experience for another release or two before it decides this
> is a critical, and therefore release-blocking, part of Fedora.  I
> understand enthusiasm for the new, offline upgrade mechanism.  More
> history will yield a better understanding of what problems can occur, and
> what costs must be borne to fix them.

dnf-system-upgrade itself is new, but Fedora has always had a
theoretically 'official supported' upgrade mechanism; it was anaconda,
then fedup, now it's dnf-system-upgrade. dnf-system-upgrade was
introduced specifically with the understanding that it replaced fedup
at the same level of support.

I don't think this is enthusiasm for dnf-system-upgrade per se, just a
kind of recognition of a gap in coverage that's been around for a
while. We could probably have plausibly supported N+2 upgrades with
fedup; certainly in practice we put effort into fixing them.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

--
test mailing list
test@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe:
http://lists.fedoraproject.org/admin/lists/test@xxxxxxxxxxxxxxxxxxxxxxx




[Index of Archives]     [Fedora Desktop]     [Fedora SELinux]     [Photo Sharing]     [Yosemite Forum]     [KDE Users]

  Powered by Linux