[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Pulp-dev] Github Required Checks



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?


David

On Mon, Feb 5, 2018 at 11:37 AM, Jeremy Audet <jaudet 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 possibilities:

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 party.
  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 else?

Notably, these implementation details can change, while the policy stays the same.


_______________________________________________
Pulp-dev mailing list
Pulp-dev redhat com
https://www.redhat.com/mailman/listinfo/pulp-dev



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]