+1 pulpcore +0 pulp_file -1 Other plugins. I'm thinking about the situation where we need to fix a bug with a PR to pulpcore and to a plugin. How is the version of pulpcore determined for runnning the plugin tests? In the past, we used nightly builds, so plugins would have to wait 24 hours after pulpcore merge just to run the tests correctly. Even if the test runner checks out HEAD and runs against that, each plugin should choose to add this check at their own pace.
On Mon, Mar 5, 2018 at 12:45 PM, Jeff Ortel <jor...@redhat.com> wrote: > > > On 03/02/2018 03:20 PM, Brian Bouterse 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? > > > +1 > > > > 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 > listPulp-dev@redhat.comhttps://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
