[Pulp-dev] Github Required Checks

Jeremy Audet jaudet at redhat.com
Mon Feb 5 16:37:30 UTC 2018

> 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.

   1. 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.
   2. 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
   3. 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?
   - 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?
   - 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

Notably, these implementation details can change, while the policy stays
the same.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20180205/fbb16790/attachment.htm>

More information about the Pulp-dev mailing list