On Thu, Nov 5, 2020 at 12:21 AM Fabio Valentini <decathorpe@xxxxxxxxx> wrote: > On Mon, Oct 26, 2020 at 5:21 PM Ben Cotton <bcotton@xxxxxxxxxx> wrote: > > == Contingency Plan == > > > > Modules will provide the functional version of MariaDB 10.4, available to all users. > > * Contingency mechanism: Fedora Modules for 10.4 available > > This is not a sufficient contingency plan. Leaving broken 10.5 > non-modular packages in f34 is a non-starter. > > Is there a realistic path to back out of the 10.5 update in rawhide / > F34 if there are problems? > It looks like the 10.4 -> 10.5 update requires database upgrades as > well, so would MariaDB 10.4 have problems with accessing databases > that have been migrated to 10.5? In the worst case scenario, I would be forced to revert the change, bump MariaDB 10.4 package epoch and release F34 with MariaDB 10.4 instead. Database upgrades in general (this is not just about MariaDB or MySQL) are very problematic. Every sane DB upgrade *ever* should have a data backup prior and I don't want, nor have any means to, solve the cases of corrupted DB data which haven't got a backup. What would be an issue however, if a significant number of users would report the upgrade is problematic and they can't use the DB with the new version. The best thing both they and I can do is to file a BZ ticket (so we are informed about it in the first place). I will search the upstream JIRA ticket system for workarounds as a part of the problem solving. If any are found, I'd try to apply them or at least provide them to the users. If the issues would be in place but no solution in sight, the revert to MariaDB 10.4 in Rawhide (and F34 if already branched) is the way to go. If you will agree to this contingency mechanism, I will add it to the Self-Contained Change wiki page. Otherwise I'd ask you for a suggestion of what you picture as sufficient contingency mechanism. Michal -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-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/devel@xxxxxxxxxxxxxxxxxxxxxxx
