> I _do_ think we need to formalize a set of rules about merging, though,
and decide how strict we want to be about it. There are a few
I'm only indirectly affected by this decision, so take my opinion with a grain of salt.
I dislike option 1, because it unnecessarily ties us to a particular policy implementation. Yes, it's *nice* to always have green Travis reports. But Travis and other service providers break, and their screw-ups shouldn't stop us from doing productive work.
I like option 2, because it lets us assert that QA process failures
must be fixed, without tying oursevles too closely to an unreliable
I dislike option 3, because it trains devs to think that QA process failures is OK and normal. It's not. Technical debt that affects QA processes should always be paid off.
Distinguishing between policy and implementation is tricky. Ask ICANN about that. But I still think it's a valuable goal to aim for. Here's a sample policy statement that might apply to this team:
Every PR must pass the checks defined by the `all` make target, for all of the interpreters listed in `setup.py`.
This policy statement doesn't include implementation details such as:
Are these checks automatically executed or manually executed?
automatically executed, which service provider is used? Travis?
CircleCI? Or perhaps a custom Jenkins or Buildbot application that rents
VMs from an IaaS provider?
Are builds performed on RHEL 7,
or in Docker containers based on Ubuntu 16.04, or in systemd-nspawn
containers based on Arch, or something else?
Notably, these implementation details can change, while the policy stays the same.