On Mon, 2019-05-06 at 12:09 -0600, Chris Murphy wrote: > On Mon, May 6, 2019 at 7:25 AM Roberto Ragusa <mail@xxxxxxxxxxxxxxxx> wrote: > > On 5/6/19 1:40 PM, Julen Landa Alustiza wrote: > > > > > We found this bug before releasing, but it is not a release blocking bug (the upgrade criteria just cover clean n > > > and n-1 upgrading to n+1 and this bug just happens whith continously upgraded systems since fc21 or lower) > > > > Wait a moment, is n and n-1 defined to "installed from scratch n and n-1?". > > Correct. > > "For each one of the release-blocking package sets, it must be > possible to successfully complete a direct upgrade from a fully > updated, clean default installation of each of the last two stable > Fedora releases with that package set installed." > > https://fedoraproject.org/wiki/Fedora_30_Beta_Release_Criteria#Upgrade_requirements > > > Is this a precedent that n-installed is different than n-through-upgrades? > > It is completely impractical for QA to, every cycle, do a clean > install of each version of Fedora, and upgrade them in sequence to the > current pre-release version, and if any of those get stuck somewhere, > suggest it would be release blocking. It's totally untenable. As a manual test - indeed. But as a fully automated test running in a VM it could work IMHO. Grossly simplified description of such an automated test: - create a VM - install old fedora version N via kickstart - setup SSH keys for remote access in the kickstart - apply any other customizations needed - SSH to machine, run commands to upgrade to N+1, repeat until desired current version is reached Test considered successfull if it is possible to login to the upgraded system after final reboot. Test considered failed if a timeout is reached, with timeouts assigned to the individual parts (installation, prepare for upgrade, upgrade). More granular checks could be used, at the cost of more complicated test harness. This would presumably run for many hours, but if multiple runs could be done for different starting versions N in parallel, it should still be short enough to gate stuf like GO/NOGO decissions. > > And not least of which is the BIOS bootloader staleness issue, but > file systems are inherently non-deterministic data blobs. The older > they get, the more non-deterministic they become, and the more likely > problems are edge cases that require special handling. The older it > is, the less stable it is, and the more likely you'll run into > problems no one else has. It's just the way they are. > > > -- > Chris Murphy > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
