[Pulp-dev] Github Required Checks
daviddavis at redhat.com
Mon Feb 5 17:16:07 UTC 2018
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?
On Mon, Feb 5, 2018 at 11:37 AM, Jeremy Audet <jaudet at redhat.com> wrote:
> > 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.
> Pulp-dev mailing list
> Pulp-dev at redhat.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pulp-dev