>It's not like dnf-system-upgrade would magically stop working when N-2 >reaches EOL, so honestly, overall, I just don't really see the problem >you're describing Like most of Fedora, dnf-system-upgrade gets limited testing before release. When N is released, a large number of users who did not install N-1 will think it is time to upgrade before their current N-2 reaches End-of-Life in four weeks. These users will try system-upgrade from a much larger set of initial states than could be tested before release. This is the time the greatest number of (N-2 to N) problems will be found. It is also the time when problems in the brand-new release N are most likely, as users of N-1 eagerly try N. With an abundance of bug reports in the just-released N, and some new reports of problems with N-2 that will be closed by EOL in a handful of days, where do you think maintenance should focus? I admit this view is based on what is probable, not on actual fact. My point is not do this or avoid that, I want the Fedora user to have an accurate understanding of upgrade choices. My reading of the EOL policy says "If it isn't fixed before EOL, it is unlikely to be fixed." If I encounter a problem with release-skipping system-upgrade, too bad. There is probably no time to fix it before EOL. In effect, release-skipping system-upgrade is not supported. Either I upgrade every release (when system-upgrade is supported and bug fixes are likely), I plan to do a new install, or I hope to be lucky with EOL code. That is not a bad set of choices. Bad is a user in trouble because he reasonably thought they were different. "Release-skipping system-upgrade is a release-blocking requirement" sounds likely to obscure the support risks that attend its use. Fedora is certainly better for a robust system-upgrade facility. No point is filing bugs now for my 21-23 failure, though. 21 is EOL, and the failure did not occur with 22. -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: http://lists.fedoraproject.org/admin/lists/test@xxxxxxxxxxxxxxxxxxxxxxx