+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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> >> 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 <[email protected]> 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 <[email protected]> >>>> 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 <[email protected]> >>>>> 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 <[email protected]> >>>>>> 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 <[email protected] >>>>>>> > 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 <[email protected] >>>>>>>> > 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 <[email protected]> >>>>>>>>> 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 <[email protected]> >>>>>>>>>> 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 >>>>>>>>>> [email protected] >>>>>>>>>> https://www.redhat.com/mailman/listinfo/pulp-dev >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Pulp-dev mailing list >>>>>>>>> [email protected] >>>>>>>>> https://www.redhat.com/mailman/listinfo/pulp-dev >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Pulp-dev mailing list >>>>>>>> [email protected] >>>>>>>> https://www.redhat.com/mailman/listinfo/pulp-dev >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Pulp-dev mailing list >>>>>>> [email protected] >>>>>>> https://www.redhat.com/mailman/listinfo/pulp-dev >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Pulp-dev mailing >>>> [email protected]https://www.redhat.com/mailman/listinfo/pulp-dev >>>> >>>> >>>> >>>> _______________________________________________ >>>> Pulp-dev mailing list >>>> [email protected] >>>> https://www.redhat.com/mailman/listinfo/pulp-dev >>>> >>>> >>> >>> _______________________________________________ >>> Pulp-dev mailing list >>> [email protected] >>> https://www.redhat.com/mailman/listinfo/pulp-dev >>> >>> >> >> _______________________________________________ >> Pulp-dev mailing list >> [email protected] >> https://www.redhat.com/mailman/listinfo/pulp-dev >> >> > > _______________________________________________ > Pulp-dev mailing list > [email protected] > https://www.redhat.com/mailman/listinfo/pulp-dev > >
_______________________________________________ Pulp-dev mailing list [email protected] https://www.redhat.com/mailman/listinfo/pulp-dev
