On Fri, 2019-10-18 at 21:19 +0200, Kevin Kofler wrote:
Miro Hrončok wrote:
> Actually:
>
https://github.com/rpm-software-management/dnf-plugins-extras/pull/166
Ewww! This kind of hacks should NEVER be accepted in a production
distribution!
Eh. I don't think it's a particularly bad hack at all. It's simple,
labelled, we know what it does, and it's inherently limited (it'll
never do anything outside of an upgrade to F31).
This hack will also NOT fix the issue for users like me who use dnf
directly
rather than the system-upgrade plugin.
That's not one of our official recommended upgrade methods. You don't
use those, you get to workaround the bugs they fix. We will still
document this in CommonBugs for people who do that, of course. Note
that the unofficial script updater msuchy maintains for folks like you
already has a similar workaround:
https://github.com/xsuchy/fedora-upgrade/commit/35baf9d60fbd57c18da48ce06...
The right thing to do would be to delay the release until we have a
real
fix, as long as it takes. Even if it takes weeks. And of course to unfreeze
the contents in the meantime because it could take weeks and there is no
telling how long.
And you know what my preferred fix would be. :-) But of course it takes time
to fix the demodularization upgrade path in DNF and to demodularize at least
the modules that are causing the errors here.
Sadly, Fedora has always preferred rushing out a release with this type of
crude hacks instead of fixing things properly, without introducing such
technical debt. And this does not seem to have changed. Sad. :-(
This is an official part of Fedora's approach, it's documented in
several places, where we talk about having a hybrid approach where
neither time nor quality completely determines the release date - it's
a combination of the two. e.g.:
https://fedoraproject.org/wiki/Fedora_Release_Criteria#Release_Constraints
https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle#Development_Sche...
it's a choice we make. There are advantages and disadvantages to
releasing exclusively based on quality, or exclusively based on time,
or something between the two. This is the choice we picked. There isn't
really a "right" one and a "wrong" one.
And yeah, I don't see this as a very bad hack in terms of 'tech debt'
at all. We've done a lot worse in the past!
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net