CI Requirements - Lessons Not Learnt?

Kai-Uwe ku.b-list at
Sat Jan 14 10:42:32 GMT 2017

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>:
>> 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.


More information about the kde-core-devel mailing list