Am 2017-01-05 22:32, schrieb Adriaan de Groot:
So what's the impact?
Twofold: for CI it causes failing builds. We should consider that
red-flag
property of CI to be a *good* thing -- because it indicates something
changed
in our assumptions or in the code, and the source is no longer good
(green),
for some suitable definition of "good".
And for distro's, there's an upcoming problem, as indicated by Kevin
Kofler.
I'd flag the same thing: it's unpleasant when packaging <X> turns into
packaging <X>, <X'>, <X''> .. because of dependencies the packagers
didn't
know about beforehand.
On Thursday 05 January 2017 21:49:52 Martin Gräßlin wrote:
.. I think that this dependency is way more important to overall
KWin than a few people having to manually build xkbcommon. Which is
fairly trivial as David showed in his reply to the thread ..
The impact is mostly because the automated systems don't know all that
much
about dependency bumps, and also really aren't ready for
manually-building-
stuff. As Martin has pointed out, there *is* now a release to build
against, so
this concrete case is not in the realm of random-GitHub-commit.
To specify even better, it's the case:
Package foo depends on a newer version of the already existing
dependency bar
which does not introduce any new dependency itself.
It is, however, a burden to CI and packagers. CI -- or rather the
people
behind CI, which I guess are largely Ben and Scarlett -- does its
darnedest to
give us an accurate picture of the state of KDE software. Packagers are
the
people who get the software in the hands of users.
For packagers it should not matter at all. This is the most common
situation for
distribution. And in the release of e.g. Plasma they have to handle this
for
hundreds of updated dependencies.
It's also not unexpected, because we have a dependency freeze in place
prior to
the release, thus the dependencies are announced way ahead.
It's only a "problem" for distros if they want to backport to an older
release as
in the case of Fedora. Honestly I consider this unreasonably. If you
don't have a
problem with backporting hundreds of packages I don't think that the one
additional
package is a problem.
Socially, we can try to keep CI (through sysadmin-tickets) and
packagers
(through the distributions@ list) informed of changes in dependencies,
so that
those groups can respond in a timely fashion.
Honestly I would consider it spaming the distribution mailing list if I
announce a
new dependency which most distributions have already integrated at the
time of the
increase of the dependency. (In this specific case it was already part
of e.g.
Opensuse tumbleweed, Debian Testing, Ubuntu 17.04, Arch, ... - yes I did
my lesson
before increasing the dependency).
The problem in my opinion lies somewhere else. We are used to ensure
that distros
can package our software. That is we check that the next release will
have the
dependency. We are targeting a newer stack. But CI is on an older stack.
I don't really see a good solution to this problem. This is a problem
which will come
up again and we have had quite often in the past. KWin requires overall
a way more
modern stack than our CI system provides. In most cases that's handled
by a PPA.
Cheers
Martin
