CI Requirements - Lessons Not Learnt?

[Martin Gräßlin]

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