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 <jau...@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 > >
_______________________________________________ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev