Re: criterion proposal: upgrading across 2 releases
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