CI Requirements - Lessons Not Learnt?

[Martin Gräßlin]

Am 2017-01-11 11:10, schrieb 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).

I like this proposal except for the veto power. I value "working bug 
free software" higher than "working CI". That's what just have with the 
xkbcommon issue in KWin. To me the bug fix we have is way, way, way more 
important than a running CI. And I'm saying that as one of the devs 
working very intensively with the CI.

I want the CI to work, don't get me wrong. But if I have to decide of 
releasing known broken software and all the bug reports related to it, 
well...

The problem here is that it's not a black/white thing. Sometimes we just 
need the new dep and it's as important part of our quality story as the 
CI is.

Cheers
Martin