CI Requirements - Lessons Not Learnt?

[Eike Hein]

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
identify:

* We want to have a working CI that gives us useful results

* We want to have developer flexibility in terms of using and catering
  latest dependencies

* We want the master branches to be realistically buildable by other
  devs

* 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
to procure.

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
their input
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.


Cheers,
Eike