<div dir="ltr">Regarding the plugin repos, last year we talked about plugins being completely autonomous (aside from abiding by our Code of Conduct). Wouldn’t setting the required checks for projects like pulp_file, pulp_python, pulp_deb, etc violate this autonomy? In other words, shouldn’t we let plugin teams decide their own policy and what checks to enable?<div><br></div><div><div class="gmail_extra"><div><div class="m_6471934715282076850gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><br></div><div>David<br></div></div></div></div></div></div></div></div>
<br><div class="gmail_quote">On Mon, Feb 5, 2018 at 11:37 AM, Jeremy Audet <span dir="ltr"><<a href="mailto:jaudet@redhat.com" target="_blank">jaudet@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><span><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></span>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>
<br>______________________________<wbr>_________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailman<wbr>/listinfo/pulp-dev</a><br>
<br></blockquote></div><br></div></div></div>