CI Requirements - Lessons Not Learnt?

[Martin Gräßlin]

Sorry picked wrong from address

Am 2017-01-05 10:28, schrieb 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