On Fri, Jan 21, 2022 at 3:54 PM Adam Williamson <adamwill@xxxxxxxxxxxxxxxxx> wrote: > > The release criteria aren't design documents. We're not defining the > intended behavior, exactly; we're defining a certain subset of known > expected behavior which we require to *work*. > > The situations you describe are, essentially, "disaster recovery" > scenarios. What our current package managers do in this scenario is > "leave things in a corrupted state". Yep. The (outdated, being updated) Workstation product requirements doc says "Upgrade should be a safe process that never leaves the system needing manual intervention." And that's not the case if there's a crash or power failure. It's definitely manual intervention time to recover. But how could Fedora QA enforce what amounts to an aspirational requirement? I think it's a good aspiration and should be in the next revision, but also needs recommitting to it. > That's been the case for years and > will likely continue to be so. I hope it won't continue much longer. On the one hand rpm-ostree is pretty much there, and on the other hand btrfs can make it trivially cheap to apply updates/upgrades on snapshots *instead* of the current running system. A crash or powerfail with either transactional model means you're booting the current unmodified root. So there is a way forward. > So, I'd say there isn't really anything useful we could do by writing > criteria around the scenario of interrupted updates. I think there's a "plug in your laptop" requirement by GNOME Software. If for some reason that check, and inhibitor, weren't working, i.e. a regression, I think it could be considered a blocker. It'd be a manifestly bad idea to let a laptop start doing an major version upgrade without power. If the system shuts down during package installation, manual intervention would be required to recover. > It's worth noting that we do have one rpm-ostree based release-blocking > edition at present - IoT - and we may have more (e.g. Silverblue and/or > CoreOS) in future. For rpm-ostree based installs, we can and do assert > in the release criteria that rollbacks and rebases work, for recovery > from broken update attempts: Yep, good > https://fedoraproject.org/wiki/Basic_Release_Criteria#rpm-ostree_requirements > > because that is how things are designed to work, and it's clearly > important enough that we should make it part of the release criteria > that things actually work that way. But for traditional RPM-based > installs, it doesn't really seem like something we can usefully address > in the criteria to me. Not yet. -- Chris Murphy _______________________________________________ test mailing list -- test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to test-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
