> I believe a failure to upgrade from N-2 to N should not block the N > release. The reason is limited resources, both for tests and for changes > to fix problems. These resources are more valuable applied to the N > release than to something two releases in the past. > > If someone wants to test a release-skipping upgrade, fine. Report > problems? Sure. If someone wants to fix these problems, OK; if not, the > policy should be "Upgrade one release at a time. Release-skipping > upgrades may work, but are not guaranteed." That's exactly what I'm trying to improve here. Either make it a reliable feature, or warn the users against it very visibly, because this is an operation that can easily break their system heavily. We don't currently warn the users much, especially the system-upgrade tool doesn't contain any warnings like that. If we decide we're not going to support release skipping officially, users should always do a conscious and informed decision about this and be aware of the risks. > > If "upgrade N-2 -> N-1" works, and "upgrade N-1 -> N" works, then "upgrade > N-2 -> N" also works, right? Maybe not, and I think it profligate to > insist we fix a broken two-release upgrade when two single-release > upgrades successfully reach the desired target. Document, do not block. > > I may hold a minority opinion, but this seems like another call for QA to > do somebody else's job. Who should decide that release-skip upgrade is a > Fedora imperative? That would be FESCo. If more people hold your opinion, we should probably file a ticket and ask them. It's definitely a valid opinion. And it would definitely be easier for QA. But in this case, I believe the work is worth it, because I personally know many people who don't want to upgrade twice a year. And offering people a way to upgrade just once a year (easily, i.e. not going through consecutive upgrades) is something I consider essential for an operating system. -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: http://lists.fedoraproject.org/admin/lists/test@xxxxxxxxxxxxxxxxxxxxxxx
