Re: [vote/discuss]Override stressNewTest for Pull Request #4250?

It finished after 4 hour 51 minutes. It looks like we do need to increase the timeout for stressNewTest. On Thu, Oct 31, 2019 at 4:45 PM Darrel Schneider wrote: > +1 > > On Thu, Oct 31, 2019 at 4:16 PM Jinmei Liao wrote: > > > +1 > > > > On Thu, Oct 31, 2019, 3:30 PM Xiaojian Zhou wrote: > > >

Re: Re: unable to push

It is how Github branch protection is designed. This is my explanation from the information provided by you : - The Pull Request you mentioned had 11 commits and when you tried to merged it, I assume you tried to squash it to a single commit. It generates a new SHA. - When you are pushing that SH

Fwd: Re: unable to push

I just want to know why my PR that passed the tests and was approved couldn't be pushed from the command line Naba On 10/31/19 5:11 PM, Nabarun Nag wrote: Hi Bruce, This was what was discussed in multiple email chains last week. GitHub branch protection was enabled on the develop branch. Comm

Re: unable to push

I just want to know why my PR that passed the tests and was approved couldn't be pushed from the command line Nab On 10/31/19 5:11 PM, Nabarun Nag wrote: Hi Bruce, This was what was discussed in multiple email chains last week. GitHub branch protection was enabled on the develop branch. Comma

Re: unable to push

Hi Bruce, This was what was discussed in multiple email chains last week. GitHub branch protection was enabled on the develop branch. Command-line and the merge button on the website have the same effect. This has now being implemented in a lot of Apache projects and we are implementing it as the

Re: [DISCUSS] is overriding a PR check ever justified?

Because the precheckins didn't run the tests in jkd8, they only run certain tests with jdk11. That's why the test passed all PR checks but failed in the pipe. On Thu, Oct 31, 2019, 3:12 PM Nabarun Nag wrote: > Jinmei, it's answered in the third email in this chain. Aaron asked the > same questio

Re: unable to push

Was there a pull request for this SHA? On Thu, Oct 31, 2019, 16:36 Bruce Schuchardt wrote: > I just completed GEODE-7358 and was prevented from pushing from the > command-line. The Merge button on github worked, but why can't I have > command-line control of the process? I don't like giving co

Re: [vote/discuss]Override stressNewTest for Pull Request #4250?

+1 On Thu, Oct 31, 2019 at 4:16 PM Jinmei Liao wrote: > +1 > > On Thu, Oct 31, 2019, 3:30 PM Xiaojian Zhou wrote: > > > I'm curious to see the new stressNew test result too. > > > > On Thu, Oct 31, 2019 at 3:26 PM Owen Nichols > wrote: > > > > > I’ve retriggered StressNew < > > > > > > https:/

unable to push

I just completed GEODE-7358 and was prevented from pushing from the command-line.  The Merge button on github worked, but why can't I have command-line control of the process?  I don't like giving control of my merge to a web-site button.  We should revert this change! geode> git push --no-ve

Re: [vote/discuss]Override stressNewTest for Pull Request #4250?

+1 On Thu, Oct 31, 2019, 3:30 PM Xiaojian Zhou wrote: > I'm curious to see the new stressNew test result too. > > On Thu, Oct 31, 2019 at 3:26 PM Owen Nichols wrote: > > > I’ve retriggered StressNew < > > > https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-pr/jobs/Stress

Re: [vote/discuss]Override stressNewTest for Pull Request #4250?

I'm curious to see the new stressNew test result too. On Thu, Oct 31, 2019 at 3:26 PM Owen Nichols wrote: > I’ve retriggered StressNew < > https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-pr/jobs/StressNewTestOpenJDK11/builds/4758> > with a temporarily-increased timeout

Re: [vote/discuss]Override stressNewTest for Pull Request #4250?

I’ve retriggered StressNew with a temporarily-increased timeout of 12 hours so we can see how long it would actually take, to have some data point whether to propose a permanent

Re: [DISCUSS] is overriding a PR check ever justified?

Jinmei, it's answered in the third email in this chain. Aaron asked the same question. [the process won't take more than 30 min, also its good to confirm that the revert won't turn the pipeline red] I am more worried that how a commit that made the pipeline red made it into the codebase. Regards N

Re: [vote/discuss]Override stressNewTest for Pull Request #4250?

Will breaking this PR into parts help. Put the tests in separate PRs? +1 if it is inconvenient On Thu, Oct 31, 2019 at 2:52 PM Donal Evans wrote: > +1 to allowing this PR to be merged, although I'd lean strongly toward > facilitating this by temporarily increasing the timeout on the job to allo

Re: [vote/discuss]Override stressNewTest for Pull Request #4250?

+1 to allowing this PR to be merged, although I'd lean strongly toward facilitating this by temporarily increasing the timeout on the job to allow it to actually pass rather than a manual override of the StressNewTest. The fact that it's passed over 7000 times without failing is pretty strong evid

Re: [DISCUSS] is overriding a PR check ever justified?

I am not sure whether this is related to this topic or not, but recently I had to revert one of my commit, before I could just do a revert and push to develop, but now that is blocked. I had to file a PR to revert a change that's causing the pipeline to be red. My question is: do we still need to f

[vote/discuss]Override stressNewTest for Pull Request #4250?

Greetings, We have a pull request (https://github.com/apache/geode/pull/4250) that is running into a problem with stressNewTest. Mostly the tests that are being run are RollingUpgrade tests that take quite a bit of time to run the full suite. Because these tests are added/modified, the stressNew

Re: Jira permission to assign myself

Thank you so much On Thu, Oct 31, 2019 at 2:19 PM Dan Smith wrote: > Hi Szu-Yu Lo, > > You should have access now. Thanks for being interested in contributing to > Geode! If you haven't already, you might want to check out our How to > Contribute >

Re: [DISCUSS] Tweak to branch protection rules

Seems like the consensus is to make this change. I'll follow up with infra. -Dan On Wed, Oct 30, 2019 at 11:06 AM Jason Huynh wrote: > +1, thanks Dan! > > On Wed, Oct 30, 2019 at 10:07 AM Aaron Lindsey > wrote: > > > +1 > > > > - Aaron > > > > > > On Wed, Oct 30, 2019 at 8:02 AM Ju@N wrote: >

Re: Jira permission to assign myself

Hi Szu-Yu Lo, You should have access now. Thanks for being interested in contributing to Geode! If you haven't already, you might want to check out our How to Contribute page. Thanks again! -Dan On Thu, Oct 31, 2019 at 11:13 A

Re: Jira permission to assign myself

Hi Dan, My username is sylo. Thanks On Thu, Oct 31, 2019 at 2:12 PM Dan Smith wrote: > Hi Szu-Yu Lo, > > What is your JIRA username? If you don't already have an account, you can > create one. > > -Dan > > On Thu, Oct 31, 2019 at 10:09 AM Szu-Yu Lo wrote: > > > Hi, > > > > I am new to geode a

Re: Jira permission to assign myself

Hi Szu-Yu Lo, What is your JIRA username? If you don't already have an account, you can create one. -Dan On Thu, Oct 31, 2019 at 10:09 AM Szu-Yu Lo wrote: > Hi, > > I am new to geode and would love to contributed to geode. I am not able to > assigned myself. It would be greatly appreciated, i

Re: [DISCUSS] is overriding a PR check ever justified?

You are correct... Break glass is a sign that whatever needed to be done, was not going to work using the prescribed approach.. I see this "break glass" as a special handshake or someone with more "authority" needs to be agree with this... but given there is not "someone with more authority" i

Jira permission to assign myself

Hi, I am new to geode and would love to contributed to geode. I am not able to assigned myself. It would be greatly appreciated, if I could have permission to assign an issue to myself. Regards, Szu-Yu Lo

Re: [DISCUSS] is overriding a PR check ever justified?

-1 for "Break glass" approach. Needing a break glass approach is a sign. I wonder how hard that would be to make exist. I think our break glass approach is that we have someone with the power disable the restrictions in Github for the window that we must and then we put it back. Thanks, Mark >

Re: [DISCUSS] is overriding a PR check ever justified?

I would agree with udo, +1 to having an emergency 'break glass' override but -1 to having the ability to do it routinely or for convenience. The main use case in my mind is for infrastructure related issues that block a PR behind unrelated changes which can be really frustrating and inconvenient (

Re: [DISCUSS] is overriding a PR check ever justified?

-1 for allowing overrides. If there's an edge case on which it's required, then we could use it at the very last resources *if and only if* it's been discussed and approved through the dev list for that particular case. Cheers. On Wed, Oct 30, 2019 at 11:35 PM Robert Houghton wrote: > Any commi