Re: [Pulp-dev] Github Required Checks

[Brian Bouterse]

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  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  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 
>> 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 
>>> 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  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 
> 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 
>> 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 
>>> 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 un

Re: [Pulp-dev] Github Required Checks

[Daniel Alley]

+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  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 
> 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 
>> 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  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 
 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 
> 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 
>> 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 >> > 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

Re: [Pulp-dev] Github Required Checks

[Dennis Kliban]

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  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 
> 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  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 
>>> 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 
 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 
> 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 
>> 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 o

Re: [Pulp-dev] Github Required Checks

[David Davis]

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 
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  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 
>> 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  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 
 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 
> 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 
>> 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

Re: [Pulp-dev] Github Required Checks

[Austin Macdonald]

+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  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 
> 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  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 
>>> 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 
 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 
> 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 

Re: [Pulp-dev] Github Required Checks

[Jeff Ortel]

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 > 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 mailto: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
mailto: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
mailto: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
mailto: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 migh

Re: [Pulp-dev] Github Required Checks

[Robin Chan]

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  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 
> 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  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 
>>> 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 
 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 
> 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 
>> wrote:
>>
>>> Jeremy, I

Re: [Pulp-dev] Github Required Checks

[Brian Bouterse]

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  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  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 
>> 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 
>>> 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 
 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 
> 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

Re: [Pulp-dev] Github Required Checks

[Brian Bouterse]

+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  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 
> 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 
>> 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 
>>> 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  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 
> wrote:
>

Re: [Pulp-dev] Github Required Checks

[Daniel Alley]

+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  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 
> 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 
>> 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  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 
 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 paych

Re: [Pulp-dev] Github Required Checks

[David Davis]

+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  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 
> 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  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  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
>
>
__

Re: [Pulp-dev] Github Required Checks

[Brian Bouterse]

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  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  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  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

Re: [Pulp-dev] Github Required Checks

[Milan Kovacik]

> 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  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  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

Re: [Pulp-dev] Github Required Checks

[Daniel Alley]

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  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

Re: [Pulp-dev] Github Required Checks

[Jeremy Audet]

> 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

Re: [Pulp-dev] Github Required Checks

[David Davis]

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?


David

On Mon, Feb 5, 2018 at 11:37 AM, Jeremy Audet  wrote:

> > I _do_ think we need to formalize a set of rules about merging, though,
> and decide how strict we want to be about it.  There are a few
> possibilities:
>
> I'm only indirectly affected by this decision, so take my opinion with a
> grain of salt.
>
>1. I dislike option 1, because it unnecessarily ties us to a
>particular policy implementation. Yes, it's *nice* to always have green
>Travis reports. But Travis and other service providers break, and their
>screw-ups shouldn't stop us from doing productive work.
>2. I like option 2, because it lets us assert that QA process failures
>must be fixed, without tying oursevles too closely to an unreliable third
>party.
>3. I dislike option 3, because it trains devs to think that QA process
>failures is OK and normal. It's not. Technical debt that affects QA
>processes should always be paid off.
>
> Distinguishing between policy and implementation is tricky. Ask ICANN
> about that. But I still think it's a valuable goal to aim for. Here's a
> sample policy statement that might apply to this team:
>
> Every PR must pass the checks defined by the `all` make target, for all of
>> the interpreters listed in `setup.py`.
>>
>
> This policy statement doesn't include implementation details such as:
>
>- Are these checks automatically executed or manually executed?
>- If automatically executed, which service provider is used? Travis?
>CircleCI? Or perhaps a custom Jenkins or Buildbot application that rents
>VMs from an IaaS provider?
>- Are builds performed on RHEL 7, or in Docker containers based on
>Ubuntu 16.04, or in systemd-nspawn containers based on Arch, or something
>else?
>
> Notably, these implementation details can change, while the policy stays
> the same.
>
> ___
> 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

Re: [Pulp-dev] Github Required Checks

[Jeremy Audet]

> I _do_ think we need to formalize a set of rules about merging, though,
and decide how strict we want to be about it.  There are a few
possibilities:

I'm only indirectly affected by this decision, so take my opinion with a
grain of salt.

   1. I dislike option 1, because it unnecessarily ties us to a particular
   policy implementation. Yes, it's *nice* to always have green Travis
   reports. But Travis and other service providers break, and their screw-ups
   shouldn't stop us from doing productive work.
   2. I like option 2, because it lets us assert that QA process failures
   must be fixed, without tying oursevles too closely to an unreliable third
   party.
   3. I dislike option 3, because it trains devs to think that QA process
   failures is OK and normal. It's not. Technical debt that affects QA
   processes should always be paid off.

Distinguishing between policy and implementation is tricky. Ask ICANN about
that. But I still think it's a valuable goal to aim for. Here's a sample
policy statement that might apply to this team:

Every PR must pass the checks defined by the `all` make target, for all of
> the interpreters listed in `setup.py`.
>

This policy statement doesn't include implementation details such as:

   - Are these checks automatically executed or manually executed?
   - If automatically executed, which service provider is used? Travis?
   CircleCI? Or perhaps a custom Jenkins or Buildbot application that rents
   VMs from an IaaS provider?
   - Are builds performed on RHEL 7, or in Docker containers based on
   Ubuntu 16.04, or in systemd-nspawn containers based on Arch, or something
   else?

Notably, these implementation details can change, while the policy stays
the same.
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] Github Required Checks

[Daniel Alley]

I don't think we should make it a hard *physical* block on PR merging.
Setting aside the occasional infrastructure issues, we also have some unit
tests (in pulp core, at least) that rely on e.g. non-expired certificates,
and fixing those once they break would require circumventing the process or
disabling the checks.  Maybe that scenario is infrequent enough that we
don't care, though - I can see that being the case.

I _do_ think we need to formalize a set of rules about merging, though, and
decide how strict we want to be about it.  There are a few possibilities:


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.

Option 2:  Every PR must pass all the unit tests, have a clean docs build
and no PEP8 errors, but if the automated runners are not working correctly
it is fine to just run those tests offline and merge if they pass.

Option 3:  Every PR must pass all the unit tests, but if something is wrong
with the automated docs or PEP8 runners, we disregard them until they are
functional again and fix anything that got through in the interim.

(etc.)

I think using a PEP for this would be reasonable.


As an aside, you mentioned that we already have the required checks enabled
on the 3.0-dev branch, but I'm pretty sure we don't.  See this [0] PR where
the automated docs builder failed to run properly (not a docs issue) but
was merged.

[0] https://github.com/pulp/pulp/pull/3280

On Fri, Feb 2, 2018 at 12:34 PM, Brian Bouterse  wrote:

> A week or two ago on irc, @misa identified that unit tests which run on
> travis with crane prs had been failing for a long time. These unit tests
> are run on each PR that is submitted, but broken and ignored. We were
> interested in finding a better way to ensure that our required checks all
> must pass before a PR can be merged.
>
> I want to get feedback on an idea to resolve this. Github has settings
> which restricts merging until the required checks are met. It allows you to:
>
> - required review before merging
> - reviewed status checks passing before merging. For us this would include
> unit test runs and docs builder runs
>
> What if we enable ^ on the 'master' branch of all the dev maintained repos
> including:
>
> devel, pulp-ci, pulp, pulp_file, pulp_puppet, pulp_rpm, pulp_docker,
> crane, ansible-pulp3, pulp_template, pulp_example, pulpproject.org,
> pulp_python, pulp_deb, ansible-pulp3_systemd, pulp_ostree, ansible-pulp3_db
>
> We have already enabled this on the 3.0-dev branch in the pulp repo maybe
> 6 months ago, so this would be more of the same.
>
> What do you all think about this idea? What questions or alternatives are
> there? Should this be done via a pup?
>
> Any feedback or ideas are welcome.
>
> -Brian
>
> ___
> 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