Please review PR #4188

Hi, could somone review PR https://github.com/apache/geode/pull/4188 for flaky test. Thanks, Mario

Re: [DISCUSS] Blocking merge button in PR

I'd still like to see the PR rerun tool or an equivalent available to everyone.  Sure you can push an empty commit but that reruns everything, but the PR tool lets you rerun only the checks that failed. On 10/21/19 3:04 PM, Ernest Burghardt wrote: +1 @Naba thanks for seeing this through! On M

Re: [DISCUSS] Blocking merge button in PR

+1 @Naba thanks for seeing this through! On Mon, Oct 21, 2019 at 1:51 PM Nabarun Nag wrote: > Thank you all for all the valuable feedback. Robert was kind enough to > check the technical feasibility of the integration of Github Branch > Protection Rules and its compatibility with our concourse C

Re: [DISCUSS] Blocking merge button in PR

Thank you all for all the valuable feedback. Robert was kind enough to check the technical feasibility of the integration of Github Branch Protection Rules and its compatibility with our concourse CI checks and we are satisfied with the settings provided and the initial tests that Robert did with a

Please review PR #4190

ServerLauncherTest is failing in CI because port 40404 is in use on the machine. The tests that are failing are unit tests and do not require starting a CacheServer on port 40404. Please review PR #4190 which disables the default server in these unit tests. https://github.com/apache/geode/pull/419

Re: Time to starting thinking about cutting the 1.11 release branch?

Yes, 11/4 should work okay for this job.  10/25 is too soon. On 10/21/19 12:18 PM, Alexander Murmann wrote: Bruce, that sounds like some great work to get in. Given this is a discussion about getting our release cut and shipped on our quarterly release train. How does this fit in with the two p

Re: [DISCUSS] Blocking merge button in PR

+1 - Aaron On Mon, Oct 21, 2019 at 11:53 AM Udo Kohlmeyer wrote: > BIG +1 (Yes, I'm changing my -1) > > @Naba, thank you for the offline chat. It seems that the proposal of > Github enforcing our good practices is a great option. > > 2 merged PR's without a full green pipeline, since 18 Oct 20

Re: Time to starting thinking about cutting the 1.11 release branch?

Bruce, that sounds like some great work to get in. Given this is a discussion about getting our release cut and shipped on our quarterly release train. How does this fit in with the two proposed dates of cutting 11/4 or 10/25? Are you suggesting to keep 11/4 as Owen original proposed? On Mon, Oct

Re: [DISCUSS] Blocking merge button in PR

+1 On Mon, Oct 21, 2019 at 11:53 AM Udo Kohlmeyer wrote: > BIG +1 (Yes, I'm changing my -1) > > @Naba, thank you for the offline chat. It seems that the proposal of > Github enforcing our good practices is a great option. > > 2 merged PR's without a full green pipeline, since 18 Oct 2019, shocki

Re: Time to starting thinking about cutting the 1.11 release branch?

I have some backward compatibility work in membership that I want to complete for 1.11.  Doing so will remove the need to keep a bunch of other backward-compatibility code around and simplify things in the membership packages. On 10/18/19 5:08 PM, Owen Nichols wrote: Knowing on what day the r

Re: [VOTE] Apache Geode 1.9.2.RC1

+1, Checked that WAR's are generated for geode-web and geode-web-api. Also ran set of examples and tests from Spring Data Geode (Moore), to confirm that it has not broken functionality. --Udo On 10/21/19 8:20 AM, Jens Deppe wrote: Since the deadline has expired without enough votes, I am go

Re: [DISCUSS] Blocking merge button in PR

BIG +1 (Yes, I'm changing my -1) @Naba, thank you for the offline chat. It seems that the proposal of Github enforcing our good practices is a great option. 2 merged PR's without a full green pipeline, since 18 Oct 2019, shocking and disgusting!! I would just like to reiterate to ALL commit

Re: [DISCUSS] Blocking merge button in PR

+1, very well said Anthony > On Oct 21, 2019, at 11:05 AM, Nabarun Nag wrote: > > > > *Reiterating the proposal:* > Github branch protection rule for : > - at least one review > - Passing build, unit and stress test. > > > In our opinion, no committer would want to check-in code with failin

Re: [DISCUSS] Blocking merge button in PR

@Karen Thank you so much for the feedback. I understand that committers must trust each other and I agree entirely with that. This proposal is just preventing us from making mistakes. Its just guard rails. As you can see in the email chain that this mistake was made multiple times and this has let

Re: [DISCUSS] Blocking merge button in PR

All committers have to right to commit and all committers have the right to revert. It is ALL for the good of the project. Now, of course, I imagine we won't apply scorched earth policies, but every committers should feel empowered to be able to revert a bad merge, if it hindering the progress

Re: [DISCUSS] Blocking merge button in PR

@Robert Houghton, Tbh honest, if we find that we have committers that are NOT following procedure/protocol, then there is a PMC that this needs to be escalated to. IF said committer is willfully acting in a negative manner towards the project, I am fully supportive of removing the rights and

Re: [DISCUSS] Blocking merge button in PR

One perspective to consider is, should anyone be able to revert a bad commit, or only the original committer? If we feel individual ownership of commits, we might hesitate to revert someone else’s commit, even if it broke the build. However if we feel a strong sense of community, we might be o

Re: [DISCUSS] Blocking merge button in PR

I *really* like the idea of requiring all PR checks to have *completed* before merge. Does anyone know if this GitHub offers a knob for this? > On Oct 21, 2019, at 4:53 AM, Ju@N wrote: > > +10 to Naba's proposal, it seems the right thing to do and will help us to > prevent accidentally breakin

Re: [DISCUSS] Blocking merge button in PR

@Udo Kohlmeyer What, if anything, do you propose we do to help keep our project building and running cleanly that does not force punitive or coercive behavior on our developers? "Naming names" or "shaming" are not popular choices, and everyone on the comitters list *should* follow procedure, but d

Re: [DISCUSS] Blocking merge button in PR

Udo, I think you are making a great point! I am fully bought into trusting our committers to know how many reviews are needed for their PRs. We should be able to have the same trust into knowing when it's OK to merge. If a committer wants to they can after all, always merge and push without a PR. T

Re: [DISCUSS] Blocking merge button in PR

I must agree with @Karen here.. All committers are trusted to do the right thing. One of those things is to commit (or not commit) PR's. Now we are discussing disabling the button when tests are failing. Why stop there? Why not, that the submitter of the said commit does not get to merge the

Re: [DISCUSS] Blocking merge button in PR

"Apache asserts that a healthy community is a higher priority than good code. Strong communities can always rectify problems with their code, whereas an unhealthy community will likely struggle to maintain a codebase in a sustainable manner.” —apache.org/theapacheway

Re: [DISCUSS] Blocking merge button in PR

+1 to enacting this immediately... just this weekend a PR was merged with failures on all of the following: * concourse-ci/DistributedTestOpenJDK11 * Concourse CI build failure * concourse-ci/UnitTestOpenJDK11 * Concourse CI build failure * concourse-ci/UnitTestOpenJDK8 * Concourse CI build failure

Re: [DISCUSS] Blocking merge button in PR

I have (more than once) committed docs changes for typo fixes without review. I generally label the commits with a bold "Commit then Review" message. But, I am bringing this up as I have purposely not followed what looks to be a positively-received proposed policy, since I have not gotten reviews

Re: [VOTE] Apache Geode 1.9.2.RC1

Since the deadline has expired without enough votes, I am going to extend it for another 48(ish) hours until 8am PST, Wednesday , 23rd October. Thanks --Jens On Tue, Oct 15, 2019 at 10:47 AM Jens Deppe wrote: > Hello Geode Dev Community, > > This is a release candidate for Apache Geode version

Re: [DISCUSS] Blocking merge button in PR

+1 to the revised approach. I think requiring at least one review is important. More eyes make for better code. Cheers, Joris. On Mon, Oct 21, 2019 at 8:11 AM Ju@N wrote: > +10 to Naba's proposal, it seems the right thing to do and will help us to > prevent accidentally breaking *develop* while

Re: [DISCUSS] Blocking merge button in PR

+10 to Naba's proposal, it seems the right thing to do and will help us to prevent accidentally breaking *develop* while keeping focus on people instead of processes. I'd add, however, that the *Merge Pull Request* button should remain disabled until *all CIs have finished*, and only enable it once