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.