Am 2017-01-14 11:42, schrieb Kai-Uwe:
Am 14.01.2017 um 08:29 schrieb Martin Gräßlin:
Am 14. Januar 2017 00:58:55 MEZ schrieb Kevin Kofler
<kevin.kof...@chello.at>:
The common case is that the new library version is used for an API
addition,
and that reverting the dependency bump in the application will
necessarily
also revert the application code using the new library API (because
otherwise it won't build) and restore the known state from the
previous
release of the application. (This can reintroduce bugs, but only ones
which
were already in the previous release.) As I understand it, this is
exactly
the situation we are in with KWin and xkbcommon now
And you understand KWin? You know why it was added and how many follow
up changes depend on it?
Then you know more than I do! Over the last week's the input code got
refactored and is still being refactored. Good luck getting this
reverted without breaking other things.
That's the point where I do heavily disagree with your thinking. You
have no idea about the software in question. And you cannot have it.
So trust the people knowing it!
Modifications of distributors can be seen for various projects in the
past and today. You both appear to have reached a point beyond
consensus. I think this is respectable. The actual thread shows how
much
at least one party is strongly distracted from feeling well with the
situation. At least I read it from your emails.
The perhaps simplest thing for the upstream maintainer, would be to
request the distributor to call his version of the software a __fork__.
That should typically cover slightly renaming, to make the fork
distinguishable for end users, take over responsibility for bug reports
and do separate maintenance. That constellation might help, to not be
bound and in conflict around the issue until it is resolved. (A later
reunification can be requested any time one party wishes. A parallel
reasonably minor modified version of the original can still be shipped
with a suitable distribution version and cooperation can easier happen
with that.)
Just an idea to concentrate on more productive things for the joy of
coding.
I think that is a reasonable suggestion. If distros patch our
dependencies we need to consider this as a fork. And a fork should be
called a fork. It needs to be clear that KDE is not responsible for any
issues caused by the fork and thus the complete product must be renamed.
Also if a component like KWin gets forked this means that the complete
product Plasma has to be considered as forked.
Cheers
Martin
