CI Requirements - Lessons Not Learnt?
mgraesslin at kde.org
Sun Jan 15 13:52:30 GMT 2017
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.kofler at chello.at>:
>>> The common case is that the new library version is used for an API
>>> and that reverting the dependency bump in the application will
>>> also revert the application code using the new library API (because
>>> otherwise it won't build) and restore the known state from the
>>> release of the application. (This can reintroduce bugs, but only ones
>>> were already in the previous release.) As I understand it, this is
>>> 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
> 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
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.
More information about the kde-core-devel