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

Any committer has the 'status' permission on apache/geode.git. Some API tokens have it as well. Its curl + github API reasoning to do this. On Wed, Oct 30, 2019 at 2:02 PM Jason Huynh wrote: > If we are going to allow overrides, then maybe what Owen is describing > should occur. Make a request

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

If we are going to allow overrides, then maybe what Owen is describing should occur. Make a request on the dev list and explain the reasoning. I don't think this has been done and a few have already been overridden. Also who has the capability to override and knows how. How is that determined?

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

+1 to override in extreme circumstances -1 to have an override flag with simple access for the common man. I think we need a "break glass" override.. but not something that is easily accessible. The 99.9% case has to go through the current process and constraints... BUT I think we ne

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

> How do you override a check, anyway? Much like asking for jira permissions, wiki permissions, etc, just ask on the dev list ;) Presumably this type of request would be made as a “last resort” following a dev list discussion wherein all other reasonable options had been exhausted (reworking o

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

+1 for allowing overrides. I think we should avoid backing ourselves into a corner where we can't get anything into develop without talking to apache infra. Some infrastructure things we can't even fix without pushing a change develop! How do you override a check, anyway? -Dan On Wed, Oct 30, 20

Re: [DISCUSS] - Upgrading from Spring 4 to Spring 5

Sorry, To clarify... When we change the Spring version we would be looking at looking to use the latest version and it's associated BOM. That might be inclusive of other Spring project upgrades. --Udo On 10/30/19 1:35 PM, Nabarun Nag wrote: Hi Udo, Maven has the latest as 5.2.0.RELEASE as t

Re: [DISCUSS] - Upgrading from Spring 4 to Spring 5

Hi Udo, Maven has the latest as 5.2.0.RELEASE as the latest version. In the Dependency.groovy file, we have been putting the full version number. Hence I am guessing you are suggesting we put 5.2.0.RELEASE? What about the status of the following dependencies? 'org.springframework.hateoas', name:

Re: [DISCUSS] - Upgrading from Spring 4 to Spring 5

@Naba, At this point 5.2.x is the weapon of choice. Might be 5.3.x, depending on when we get to doing this. --Udo On 10/30/19 12:02 PM, Nabarun Nag wrote: Hi Udo +1, 5.2.0.RELEASE to be specific? On Wed, Oct 30, 2019 at 11:04 AM Ju@N wrote: Hello Udo, Big +1 for the proposal!. That sai

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

-1 to overriding from me. The question I have here is what's the rush? Is anything ever so time-sensitive that you can't even wait the 15 minutes it takes for it to build and run unit tests? If some infrastructure problem is preventing builds or tests from completing then that should be fixed befo

Re: [DISCUSS] - Upgrading from Spring 4 to Spring 5

Hi Udo +1, 5.2.0.RELEASE to be specific? On Wed, Oct 30, 2019 at 11:04 AM Ju@N wrote: > Hello Udo, > > Big +1 for the proposal!. > That said, I believe it was agreed a couple of months ago in the > *Lightweight > RFC Process [1] *that the whole discussion should be done in the [DISCUSS] > email

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

@Aaron It's okay to wait for at least the build, and unit tests to complete, to cover all the bases. [There may have been commits in between which may result in failure because of the revert] And it's not hard to get a PR approval. -1 on overriding. If the infrastructure is down, which is the tes

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

One case when it might be acceptable to overrule a PR check is reverting a commit. Before the branch protection was enabled, a committer could revert a commit without a PR. Now that PRs are mandatory, we have to wait for the checks to run in order to revert a commit. Usually we are reverting a comm

Re: Deprecate SystemFailure Class

Hearing no objections or concerns, I will begin the deprecation process[1] for SystemFailure. After that I'll remove the dependencies [2] on SystemFailure in the membership subsystem. [1] https://issues.apache.org/jira/browse/GEODE-7369 [2] https://issues.apache.org/jira/browse/GEODE-7354

[DISCUSS] is overriding a PR check ever justified?

Our new branch-protection rules can sometimes lead to unexpected obstacles when infrastructure issues impede the intended process. Should we discuss such cases as they come up, and should overruling the result of a PR check ever be an option on the table? -Owen

Re: [DISCUSS] Tweak to branch protection rules

+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: > > > Perfect Naba, thanks for answering this. > > My vote is +1 then. > > > > On Wed, Oct 30, 2019 at 2:37 PM Nabarun Nag wrote: > > > > > The check box Dan

Re: [DISCUSS] - Upgrading from Spring 4 to Spring 5

Hello Udo, Big +1 for the proposal!. That said, I believe it was agreed a couple of months ago in the *Lightweight RFC Process [1] *that the whole discussion should be done in the [DISCUSS] email thread directly and not as comments within the proposal itself, you might want to double check that an

[DISCUSS] - Upgrading from Spring 4 to Spring 5

Hi there fellow Apache Geode Devs, We would like to propose the upgrade of the Spring libraries within Geode Project. Currently the project is using Spring 4, which is EOL Q1 2020. The link the proposal can be found here

Re: [DISCUSS] Tweak to branch protection rules

+1 - Aaron On Wed, Oct 30, 2019 at 8:02 AM Ju@N wrote: > Perfect Naba, thanks for answering this. > My vote is +1 then. > > On Wed, Oct 30, 2019 at 2:37 PM Nabarun Nag wrote: > > > The check box Dan is mentioning will just not invalidate any approved > > review if the code is changed. > > If

Re: [DISCUSS] Tweak to branch protection rules

Perfect Naba, thanks for answering this. My vote is +1 then. On Wed, Oct 30, 2019 at 2:37 PM Nabarun Nag wrote: > The check box Dan is mentioning will just not invalidate any approved > review if the code is changed. > If a change is requested, the button will remain disabled. > > Regards > Naba

Re: [DISCUSS] Tweak to branch protection rules

The check box Dan is mentioning will just not invalidate any approved review if the code is changed. If a change is requested, the button will remain disabled. Regards Naba On Wed, Oct 30, 2019 at 6:27 AM Joris Melchior wrote: > +1 > > On Wed, Oct 30, 2019 at 5:27 AM Ju@N wrote: > > > Questio

Re: [DISCUSS] Tweak to branch protection rules

+1 On Wed, Oct 30, 2019 at 5:27 AM Ju@N wrote: > Question: this only applies for *approvals*, not for *refusals*, right?; I > mean, the *merge pull request* button will remain blocked if there were > some changes requested by reviewers and the author of the PR adds new > commits (either addressi

Re: [DISCUSS] Tweak to branch protection rules

Question: this only applies for *approvals*, not for *refusals*, right?; I mean, the *merge pull request* button will remain blocked if there were some changes requested by reviewers and the author of the PR adds new commits (either addressing those requested changes or not)?. If the answer to the