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 <bbout...@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 <bbout...@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 <dal...@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 <davidda...@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 <bbout...@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 <mkova...@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 <dal...@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 <jau...@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@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 >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>>> >>>> >>> >> > > _______________________________________________ > 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