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

List:       kde-core-devel
Subject:    Re: CI Requirements - Lessons Not Learnt?
From:       Ben Cooksley <bcooksley () kde ! org>
Date:       2017-01-14 20:05:09
Message-ID: CA+XidOHZhZcUmcDWGiHE_u4Ap=0N_J90mpVwqzTHaj8Vx9sVLw () mail ! gmail ! com
[Download RAW message or body]

On Sat, Jan 14, 2017 at 11:42 PM, Kai-Uwe <ku.b-list@gmx.de> wrote:
> Am 14.01.2017 um 08:29 schrieb Martin Gr=C3=A4=C3=9Flin:
>> Am 14. Januar 2017 00:58:55 MEZ schrieb Kevin Kofler <kevin.kofler@chell=
o.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 u=
p changes depend on it?
>>
>> Then you know more than I do! Over the last week's the input code got re=
factored and is still being refactored. Good luck getting this reverted wit=
hout breaking other things.
>>
>> That's the point where I do heavily disagree with your thinking. You hav=
e 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 codi=
ng.

Please split that off into a separate thread, it's totally separate to
this matter and is dragging it very quickly in totally-off-topic
territory.

>
> Kai-Uwe

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