[Pulp-dev] Github Required Checks

Fri Mar 2 21:41:11 UTC 2018

lgtm.
Thanks for explaining the process and where it will be documented for
future reference, good update to the issue.

On Fri, Mar 2, 2018 at 4:20 PM, Brian Bouterse <bbouters at redhat.com> wrote:

> I had neglected to write up the temporary enable/disable part of the
> issue, so I just updated it here:  https://pulp.plan.io/issues/3379
>
> In short, one of the pulp org owners (ipanova, ttereshc, rchan, jortel,
> bmbouter) can temporarily enable/disable required checks. This issue would
> also add this process to both the pulp2 and pulp3 docs.
>
> What do you all think about an idea like this?
>
> On Fri, Feb 16, 2018 at 1:33 PM, Brian Bouterse <bbouters at redhat.com>
> wrote:
>
>> +1 to enabling checks for the 'pulp' and 'pulp_file' repos in Github with
>> the ability to temporarily disable them. I wrote up this issue here to do
>> that:  https://pulp.plan.io/issues/3379
>>
>> I think we should enable these because we have a human-enforced policy
>> that expects failed checks to not be merged, but in practice code that is
>> merged breaks things that quality checks also identified. I think Pulp
>> would benefit from a stronger pre-merge enforcement of our existing checks.
>> In the case where our quality checks are failing, I'm hoping we can focus
>> on fixing them before continuing on with the merge in all but exceptional
>> cases.
>>
>> On Thu, Feb 15, 2018 at 8:55 PM, Daniel Alley <dalley at redhat.com> wrote:
>>
>>> +0 on required github-enforcement, +1 to a strict human-enforced policy
>>> about tests passing for PR merges
>>>
>>> Reason being, an issue has occurred which would block valid PRs twice
>>> within the last month.  The first being the test certs expiring on January
>>> 25th, the second being when we switched the PR unittest runners over to new
>>> versions of Fedora this morning.
>>>
>>> I'm not against the idea by any means, I'm just not entirely convinced
>>> that the exceptions requiring intervention will be very infrequent, and I
>>> can imagine it leading to a fair amount of frustration.
>>>
>>> On Thu, Feb 15, 2018 at 7:34 PM, David Davis <daviddavis at redhat.com>
>>> wrote:
>>>
>>>> +1 to enabling the checks for the core pulp repos in Github. The only
>>>> concern I have is that perhaps something happens outside of our control
>>>> (e.g. Travis goes down) and we can’t merge PRs. In those cases though, we
>>>> can temporarily disable checks.
>>>>
>>>>
>>>> David
>>>>
>>>> On Thu, Feb 15, 2018 at 4:38 PM, Brian Bouterse <bbouters at redhat.com>
>>>> wrote:
>>>>
>>>>> I want to adjust my proposal to only be for core, and not a
>>>>> requirement for any plugin. I think the plugin policy is something the
>>>>> committers should decide along with their users. I overall believe enabling
>>>>> these kinds of checks is a good idea so I encourage plugins do it. We
>>>>> should make sure each team has a github admin in place who could make such
>>>>> a change.
>>>>>
>>>>> I like option 1, which to retell my understanding means that we'll
>>>>> enable github to require the checks to pass and you can't merge or push
>>>>> without them passing. Is that good, would there be any -1's for a change on
>>>>> core like this?
>>>>>
>>>>> To share my perspective about plugins being in the Pulp organization,
>>>>> they are there only for a clear association with Pulp on github. Any open
>>>>> source plugin that creates value with Pulp and does it with a debatable
>>>>> level of responsibility towards its users I think is probably ok to
>>>>> include. I don't expect them to give up any control or autonomy if they do
>>>>> that. The benefit of bringing these different plugin communities closer
>>>>> together through the organization is hopefully towards common services like
>>>>> automated testing and such over time.
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Feb 13, 2018 at 8:28 AM, Milan Kovacik <mkovacik at redhat.com>
>>>>> wrote:
>>>>>
>>>>>> > Option 1:  Nothing merges without passing PR runner tests, ever,
>>>>>> even if the issue is rooted in the configuration or infrastructure of the
>>>>>> test runners or an expired certificate etc.  This would light a fire to get
>>>>>> these issues resolved ASAP because nothing can happen without them.
>>>>>> I like this option for the same reasons Daniel mentioned; it also
>>>>>> implies an up-to-date infrastructure and better reliability: both false
>>>>>> negative and false positive (test/build) failures will still happen in all
>>>>>> the three options regardless, but at least false negatives won't be ignored.
>>>>>> This might also help catching environment issues sooner in the
>>>>>> process (such as a third-party library update causing a legitimate failure
>>>>>> because of e.g backwards incompatibility).
>>>>>> When it comes to plugin independence, we could state that only
>>>>>> plugins conforming with these (core) PR criteria can be "adopted" and
>>>>>> tagged as Pulp-approved/compatible and kept under the Pulp project.
>>>>>>
>>>>>> --
>>>>>> milan
>>>>>>
>>>>>> On Mon, Feb 5, 2018 at 7:21 PM, Daniel Alley <dalley at redhat.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Jeremy, I don't think David was continuing our line of discussion on
>>>>>>> policy, but rather rebutting the original idea that Github's "required
>>>>>>> checks" be enforced for all plugins.  That goes back to the whole
>>>>>>> difference between having a policy that requires green tests and making it
>>>>>>> physically impossible to merge PRs without them.  Maybe some plugins want a
>>>>>>> policy and some plugins are fine with hard required checks on Github, but
>>>>>>> the latter shouldn't be enforced on everyone - is what I think David was
>>>>>>> saying.
>>>>>>>
>>>>>>> Also, my understanding is that pulp_deb is not strictly under our
>>>>>>> control, but that we're hosting it specifically to let misa use our QA
>>>>>>> infrastructure, and because we might want to productise it at some point in
>>>>>>> the future.
>>>>>>>
>>>>>>> On Mon, Feb 5, 2018 at 12:55 PM, Jeremy Audet <jaudet at redhat.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> > 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?
>>>>>>>>
>>>>>>>> Are pulp_file, pulp_python, pulp_deb, and so on autonomous
>>>>>>>> projects? The fact that they're hosted on GitHub under the pulp
>>>>>>>> organization [1] indicates that they're under our control. Since they're
>>>>>>>> under our control, we get to set the rules. If any of these projects really
>>>>>>>> are autonomous, then somebody please kick them out of the pulp organization.
>>>>>>>>
>>>>>>>> If I was writing paychecks to a team of devs, and they refused to
>>>>>>>> adopt basic QA processes for their projects, I'd happily fire the entire
>>>>>>>> dev team. I can't be the only one who's had this thought.
>>>>>>>>
>>>>>>>> [1] https://github.com/pulp
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Pulp-dev mailing list
>>>>>>> Pulp-dev at redhat.com
>>>>>>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Pulp-dev mailing list
>>>>>> Pulp-dev at redhat.com
>>>>>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Pulp-dev mailing list
>>>>> Pulp-dev at redhat.com
>>>>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> Pulp-dev mailing list
>>>> Pulp-dev at redhat.com
>>>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>>>
>>>>
>>>
>>
>
> _______________________________________________
> 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/20180302/ff6b438a/attachment.htm>