Cool for pulp and pulp_file this (and the docs updates) are slated to be added to the sprint tomorrow maybe: https://pulp.plan.io/issues/3379
On Thu, Mar 8, 2018 at 2:14 PM, Daniel Alley <dal...@redhat.com> wrote: > +1, that sounds great. It would alleviate a lot of issues with respect to > breakages. > > On Thu, Mar 8, 2018 at 2:03 PM, Dennis Kliban <dkli...@redhat.com> wrote: > >> I want to introduce an ability to specify in the commit message for >> pulpcore a PR for pulp_file and a PR for pulp-smash. Travis would then >> checkout pulp_file from that PR and pulp-smash from that PR and test the >> pulpcore PR in combination with the 2 other PRs. This way we can test >> changes that require changes in multiple repositories. How does that sound? >> >> On Thu, Mar 8, 2018 at 11:48 AM, David Davis <davidda...@redhat.com> >> wrote: >> >>> I set up the pulp_file tests to install pulp 3.0-dev (although we could >>> change this to nightly builds once those are being built): >>> >>> https://github.com/pulp/pulp_file/blob/master/.travis/install.sh#L6 >>> >>> In the situation you mentioned, we’d merge the PR to pulp and then rerun >>> the PR tests against the corresponding pulp_file PR. I’d like to make the >>> PR tests required in pulp_file (unless anyone objects). >>> >>> >>> David >>> >>> On Thu, Mar 8, 2018 at 11:22 AM, Austin Macdonald <amacd...@redhat.com> >>> wrote: >>> >>>> +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 >>>> >>>> >>> >>> _______________________________________________ >>> 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
