CI Requirements - Lessons Not Learnt?

[Martin Gräßlin]

Am 2017-01-05 09:44, schrieb Ben Cooksley:
> Hi all,
> 
> It seems that my previous vocal complaints about system level /
> serious impact dependency bumps on the CI system have gone completely
> unnoticed by (some) members of our Community.
> 
> This was demonstrated earlier this week when components of Plasma
> bumped their version requirements for XKBCommon and Appstream-Qt -
> without even a thought about notifying Sysadmin or checking which
> version the CI had, until their builds broke.
> 
> Neither of these is easy to fix at this stage, as the system base is
> now too old to receive updates such as these. Base upgrades require a
> full rebuild of everything on the CI system, and usually involve
> significant additional churn and is a process that must be done
> roughly twice a year, depending on dependency bump demands.
> 
> Does anyone have any suggestions as to how we may avoid this in the 
> future?

I have a few questions here:

1) Where is this requirement to check with sysadmins codified? So far I 
was only aware of dependency freeze.
2) How can we easily check what build.kde.org has? Looking at cmake 
output is not a sufficient way as it gives me wrong information
3) What should we do when build.kde.org does not have the requirement?

It should be rather obvious that we don't introduce new dependencies 
because we like to. There is a very important software reason to it.
That's the case for the xkbcommon dependency increase. Should I have let 
the code broken as it was, expecting half a year of bug reports till 
build.kde.org has the base upgraded to Ubuntu 16.04?

If I have to degrade the quality of the product for serving the CI, I 
and all users have a problem. And this is currently the only 
alternative. The quality of our product is highly at risk as our changes 
are no longer compile tested. This is a huge problem for the release of 
Plasma 5.9. On the other hand I cannot revert the dependency change as 
that would break tests or introduce the broken code again. So actually 
we are caught between a hard and a rock place.

When I increased the dependency I had the dependency freeze of Plasma 
5.9 in mind. That's the one target I have to hit from release process 
currently. Also I had to consider a social aspect here. I asked 
xkbcommon devs to do the release. I would have feeled ashamed if we 
asked for the release and then don't use it. For me it was from a social 
point of view a very high requirement to ship with the dependency in the 
next release after xkbcommon release.

If we have to wait an arbitrary time till build.kde.org has upgraded the 
base, maybe the choice of the base is not sufficient. E.g. I asked 
openSUSE about this dependency weeks ago. Actually a few days after 
xkbcommon had the release and it was already shipped in tumbleweed. 
Similar for Mesa 13 which I'm also eagerly waiting for build.kde.org to 
fetch it.

Cheers
Martin