[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: CI Requirements - Lessons Not Learnt?
From:       Martin_Gräßlin <mgraesslin () kde ! org>
Date:       2017-01-15 13:52:30
Message-ID: 8fa97b4db190a3a3992700c73c9df69f () kde ! org
[Download RAW message or body]

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@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
[prev in list] [next in list] [prev in thread] [next in thread]