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
