De: "Jakub Cajka"
I'm strongly against general unrestricted practice of compat
packages as proposed. If you need compat package you
need to work with usptreams on stabilizing the API/project, fork it, or just use COPR as
your projects(or its
dependencies) are not yet mature enough for Fedora.
I appreciate the sentiment, and I quite hate compat packages, but the restrictions you
want did not work in practice for Fedora.
Making compat package creation hard does not result in faster fixing to use new code. What
it actually does is to block the packaging of all the projects that need a more recent
package state, because packagers that need the old state for one of their packages, will
drag their feet on updating common dependencies till the code of their packages is fixed
upstream, or they have the time to fix it themselves.
And blocking packaging of new part means you do not get the new packagers that would join
because they're interested in the new parts, and would contribute to the maintenance
of common deps (not all of which need compat-ing), and would relieve part of the pressure
on the existing packagers, that prevents them from working as much a they'd like to on
updating their packages. It's a death spiral. It results in a massively obsolete Go
package baselines, full of holes, because all the energy is poured in making existing
stuff work, at the expense of onboarding new packages and packagers.