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
<mailto: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
<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
<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
<davidda...@redhat.com <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
<bbout...@redhat.com <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
<mkova...@redhat.com <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 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 <mailto: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 <mailto: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 <mailto:Pulp-dev@redhat.com>
https://www.redhat.com/mailman/listinfo/pulp-dev
<https://www.redhat.com/mailman/listinfo/pulp-dev>
_______________________________________________
Pulp-dev mailing list
Pulp-dev@redhat.com <mailto:Pulp-dev@redhat.com>
https://www.redhat.com/mailman/listinfo/pulp-dev
<https://www.redhat.com/mailman/listinfo/pulp-dev>
_______________________________________________
Pulp-dev mailing list
Pulp-dev@redhat.com <mailto:Pulp-dev@redhat.com>
https://www.redhat.com/mailman/listinfo/pulp-dev
<https://www.redhat.com/mailman/listinfo/pulp-dev>
_______________________________________________
Pulp-dev mailing list
Pulp-dev@redhat.com <mailto:Pulp-dev@redhat.com>
https://www.redhat.com/mailman/listinfo/pulp-dev
<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
