CI Requirements - Lessons Not Learnt?

Ben Cooksley bcooksley at kde.org
Sat Jan 14 20:05:09 GMT 2017


On Sat, Jan 14, 2017 at 11:42 PM, Kai-Uwe <ku.b-list at gmx.de> wrote:
> 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
>>> 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.

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




More information about the kde-core-devel mailing list