CI Requirements - Lessons Not Learnt?
mgraesslin at kde.org
Fri Jan 6 08:28:48 GMT 2017
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
> property of CI to be a *good* thing -- because it indicates something
> in our assumptions or in the code, and the source is no longer good
> for some suitable definition of "good".
> And for distro's, there's an upcoming problem, as indicated by Kevin
> I'd flag the same thing: it's unpleasant when packaging <X> turns into
> packaging <X>, <X'>, <X''> .. because of dependencies the packagers
> 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
> about dependency bumps, and also really aren't ready for
> 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
which does not introduce any new dependency itself.
> It is, however, a burden to CI and packagers. CI -- or rather the
> 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
> people who get the software in the hands of users.
For packagers it should not matter at all. This is the most common
distribution. And in the release of e.g. Plasma they have to handle this
hundreds of updated dependencies.
It's also not unexpected, because we have a dependency freeze in place
the release, thus the dependencies are announced way ahead.
It's only a "problem" for distros if they want to backport to an older
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
package is a problem.
> Socially, we can try to keep CI (through sysadmin-tickets) and
> (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
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
Opensuse tumbleweed, Debian Testing, Ubuntu 17.04, Arch, ... - yes I did
before increasing the dependency).
The problem in my opinion lies somewhere else. We are used to ensure
can package our software. That is we check that the next release will
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.
More information about the kde-core-devel