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
