<div dir="ltr"><div><div><div><div>> 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 
possibilities:<br><br></div>I'm only indirectly affected by this decision, so take my opinion with a grain of salt.<br></div><ol><li>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.</li><li>I like option 2, because it lets us assert that QA process failures 
must be fixed, without tying oursevles too closely to an unreliable 
third party.</li><li>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.</li></ol></div></div><div><div>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:<br><br></div></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Every PR must pass the checks defined by the `all` make target, for all of the interpreters listed in `setup.py`.<br></blockquote><br></div><div>This policy statement doesn't include implementation details such as:<br><ul><li>Are these checks automatically executed or manually executed?</li><li>If
 automatically executed, which service provider is used? Travis? 
CircleCI? Or perhaps a custom Jenkins or Buildbot application that rents
 VMs from an IaaS provider?<br></li><li>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?</li></ul><p>Notably, these implementation details can change, while the policy stays the same.<br></p></div></div>