[Pulp-dev] Github Required Checks

[David Davis]

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 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
> 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 at redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20180205/3436ddce/attachment.htm>