CI Requirements - Lessons Not Learnt?
hein at kde.org
Wed Jan 11 10:10:41 GMT 2017
So my view of the situation is that we have a bunch of desires and
needs, and we need to sort them. Here's a couple I can reasily
* We want to have a working CI that gives us useful results
* We want to have developer flexibility in terms of using and catering
* We want the master branches to be realistically buildable by other
* We want to keep quality of HEAD high
These desires/needs are in conflict with each other, so it's not an
entirely simple sorting process. For example, "keep quality of HEAD
high" can require dragging in very recenty dependencies when our
and the other code need to act in concern to address a problem. On
the other hand, "want to have a working CI" and "realistically
buildable" means avoiding silly-recent dependencies that are hard
I submit that one of the guidelines of our dev process it that
regression-type defects take priority over newly-identified defect
Breaking CI or breaking developer builds is a regression. Changes
that require new deps (usually) aren't related to regressions, un-
less the external software update is about fixing a regression. I
think local (our) regressions outweigh external regressions.
If you accept this sorting, then my proposal is:
1. Make it mandatory to file a review request for dependency changes
2. Make it mandatory to subscribe sysadmin to those reviews and get
3. Sysadmin commits to providing that input in a reasonable time frame
4. Sysadmin tries to procure the new dependency in a reasonable time frame
This puts veto power into the sysadmin's hands, which is what we
want under the proposed sorting (we want a working CI and this is
how we get it).
Note that alternatives to this are practically difficult, unless
developers are willig to become sysadmins and/or packagers.
More information about the kde-core-devel