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
