CI Requirements - Lessons Not Learnt?

[Kevin Kofler]

Jan Kundrát wrote:
> do you have some examples of distribution maintainers actually doing such
> a stupid thing?

I've done it more than once. If the dependency that the latest upstream
version wants is not available and will not be made available for whatever
reason, reverting the dependency bump is really the only way. And the users
will be no worse off than if we had stuck to the old version that did not
have the changes I am reverting to begin with.

I have already given an example, from when I was still maintaining the core
Qt 5 packages in Fedora:
http://pkgs.fedoraproject.org/cgit/rpms/qt5-qtbase.git/tree/qtbase-opensource-src-5.3.2-old_xkbcommon.patch?id=e26fd4ffda851bfe13d975547e218e16f72ce556
(for Fedora 19, and for Fedora 20 until xkbcommon got updated there).

I am not a maintainer of Qt 5 nor KWin in Fedora anymore, but I would still
be happy to give assistance with coming up with such a patch IF the
maintainers ask me. (I find producing such patches very easy.)

But to be clear, all this is hypothetical planning for future releases, and
the maintainers may decide to do something different (e.g., to upgrade
Plasma/KWin only in a Copr also offering a newer xkbcommon), or xkbcommon
might get updated anyway (there is already a build for Fedora 25, it was
just not submitted in Bodhi, so I don't know what the plans are there).

So, to make it clear, Fedora at this time DOES NOT REVERT any dependency
bump in KWin!

> In my professional epxerience, the distro maintainers that I have worked
> with were reasonable people who invest time into doing valuable QA and
> packaging duties. Surely there's no place for "hey, let's go break this
> code" as your proposal suggests.

What you call "break", I call "make work". It is that or not have the code
at all. And the existing old version was already "broken" in the same way.

        Kevin Kofler