CI Requirements - Lessons Not Learnt?
privat at martin-graesslin.com
Thu Jan 5 09:28:52 UTC 2017
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
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
More information about the release-team