On Thu, Nov 5, 2020 at 2:07 PM Michal Schorm <msch...@redhat.com> wrote: > > On Thu, Nov 5, 2020 at 12:21 AM Fabio Valentini <decatho...@gmail.com> wrote: > > On Mon, Oct 26, 2020 at 5:21 PM Ben Cotton <bcot...@redhat.com> 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.
Yes, this sounds like a good compromise. Thanks! Fabio _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
