CI Requirements - Lessons Not Learnt?

[Martin Gräßlin]

Am 2017-01-15 18:41, schrieb Kevin Kofler:
> Martin Gräßlin wrote:
>> 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.
> 
> Oh dear, no!
> 
> The good thing about KDE has always been that it has allowed downstream
> modifications in an unbureaucratic way, allowing full use of the KDE
> trademark and other related names even for modified versions. Switching 
> to a
> Firefox-style policy where every single modification has to be OKed by
> Mozilla (in your case, by KDE) would make your software a real pain to
> distribute, especially since you want to disallow modifications 
> absolutely
> necessary to make your software work on some distributions. (Sure, in 
> this
> particular case, xkbcommon can be updated, if distribution policies 
> allow
> it. But you are talking about dependency changes in general, which can 
> have
> bumped sonames or other incompatibilities.)

Of course this also requires a clear specification which explains when 
we consider it as a fork. Patching out changes which degrade the quality 
(as your wish for xkbcommon would do) is to me something which should 
clearly be separated from our products. Your and our users should be 
aware that they do not get the quality we as an upstream provide. And 
for us as upstreams this must also be clearly separated as otherwise we 
would get bug reports we cannot investigate and cannot understand. If a 
distribution patches out needed dependency (as you wish in the case of 
xkbcommon) things can get ugly on our side. Imagine how I would look 
when I get a bug report for exactly the issue I fixed. That you patched 
it out, wouldn't be the first thing that comes to my mind. That's why I 
wrote in another mail that I would consider every Fedora bug report in 
that case a direct RESOLVED DOWNSTREAM. Ideally I would not get any bug 
reports then, this can only be achieved by calling the forked version a 
different name and ensuring that the users are educated about the state 
that this got forked and that KDE is no longer responsible for any 
issues of the forked version.

Kevin, overall I think you have a rather naive approach to trying to 
bring newer versions to older distributions. Just reverting a change 
which introduces a new dependency can never work as you are no domain 
expert. There can be many, many changes building up on the change 
without you noticing as it's hidden through a facade (which is also the 
case with xkbcommon in KWin). Just think about this number: there are 
about 150 commits in KWin between 5.8 and 5.9. And 15 commits went in 
after the xkbcommon dependency change. Some of them directly basing on 
top of the dependency change. How do you want to check that? I as a 
maintainer are not able to tell you which changes would need to be 
backed out.

If such a change means you cannot provide it in an older distro: then 
don't do it. We have an LTS for that. Your users are better served with 
an LTS.

If on the other hand a new dependency would cause a problem for your 
next (!) distribution release, then speak up early in the process. But 
this is something I consider as rather unlikely. How should one be able 
to beat Rawhide in a dependency increase? And I just checked, rawhide of 
course has the xkbocmmon release we need since at least November 13th - 
more than a month prior to the include in KWin.

So maybe rethink your approach to bring the latest release to your older 
distros. Honestly I think you are creating more issues for your users 
than you want to solve. We have a maintained LTS version nowadays, use 
that!

Cheers
Martin