Re: [DISCUSS] enable GitHub PR blocking on API breaking changes

2020-05-18 Thread Robert Houghton
INFRA has added the status to the required list for merging PRs to geode/develop. Thanks everyone. On Fri, May 15, 2020 at 3:03 PM Robert Houghton wrote: > Please refer to https://issues.apache.org/jira/browse/INFRA-20270 > > On Fri, May 15, 2020 at 2:58 PM Robert Houghton > wrote: > >>

Re: [DISCUSS] enable GitHub PR blocking on API breaking changes

2020-05-15 Thread Robert Houghton
Please refer to https://issues.apache.org/jira/browse/INFRA-20270 On Fri, May 15, 2020 at 2:58 PM Robert Houghton wrote: > Support seems to be unanimously good, and folks voted in this thread. I'm > going to make the ASF-INFRA request. > > On Fri, May 15, 2020 at 11:47 AM Anthony Baker wrote:

Re: [DISCUSS] enable GitHub PR blocking on API breaking changes

2020-05-15 Thread Robert Houghton
Support seems to be unanimously good, and folks voted in this thread. I'm going to make the ASF-INFRA request. On Fri, May 15, 2020 at 11:47 AM Anthony Baker wrote: > Barry and I tossed up a draft PR to fix a problem in session state > replication with Tomcat. If we can get this completed I’d

Re: [DISCUSS] enable GitHub PR blocking on API breaking changes

2020-05-15 Thread Anthony Baker
Barry and I tossed up a draft PR to fix a problem in session state replication with Tomcat. If we can get this completed I’d like to include it with v1.13.0. I believe our tests will fail with any version of Tomcat after 9.0.21. Anthony > On May 15, 2020, at 1:27 AM, Ju@N wrote: > > +1 >

Re: [DISCUSS] enable GitHub PR blocking on API breaking changes

2020-05-15 Thread Ju@N
+1 On Thu, 14 May 2020 at 22:19, Mark Hanson wrote: > +1. The more we can automate this types of checks the better. > > Thanks, > Mark > > -- Ju@N

Re: [DISCUSS] enable GitHub PR blocking on API breaking changes

2020-05-14 Thread Mark Hanson
+1. The more we can automate this types of checks the better. Thanks, Mark

Re: [DISCUSS] enable GitHub PR blocking on API breaking changes

2020-05-14 Thread Nabarun Nag
+1 On Thu, May 14, 2020 at 8:54 AM Donal Evans wrote: > Thanks for the explanation, Robert. Also, I realised I never explicitly > said it in my earlier post, but this is a +1 from me > > On Thu, May 14, 2020 at 8:05 AM Joris Melchior > wrote: > > > This seems like a good thing to have. > > > >

Re: [DISCUSS] enable GitHub PR blocking on API breaking changes

2020-05-14 Thread Donal Evans
Thanks for the explanation, Robert. Also, I realised I never explicitly said it in my earlier post, but this is a +1 from me On Thu, May 14, 2020 at 8:05 AM Joris Melchior wrote: > This seems like a good thing to have. > > +1 > > From: Robert Houghton > Sent:

Re: [DISCUSS] enable GitHub PR blocking on API breaking changes

2020-05-14 Thread Joris Melchior
This seems like a good thing to have. +1 From: Robert Houghton Sent: May 13, 2020 17:32 To: dev@geode.apache.org ; Mario Ivanac Subject: [DISCUSS] enable GitHub PR blocking on API breaking changes We have enabled this job on the develop and support 1.13

Re: [DISCUSS] enable GitHub PR blocking on API breaking changes

2020-05-14 Thread Robert Houghton
@donal There is a violation filter in place for major version changes that would currently allow any change. That can be narrowed down to only allow deletion of already-deprecated signatures. On Wed, May 13, 2020 at 5:18 PM Owen Nichols wrote: > If ApiChecker fails on your PR, and you merge

Re: [DISCUSS] enable GitHub PR blocking on API breaking changes

2020-05-13 Thread Owen Nichols
If ApiChecker fails on your PR, and you merge anyway, it will fail on develop, so there’s no question it should be a required PR check. We left some checks optional to avoid blocking merges on unrelated flaky failures. ApiChecker should never be flaky. If/when Geode decides it’s time for a

Re: [DISCUSS] enable GitHub PR blocking on API breaking changes

2020-05-13 Thread Donal Evans
Given that this job takes less than 10 minutes to run, pass or fail, I don't see it adding any additional friction to the PR process in terms of having to wait for things to finish. I am curious if there are any circumstances we could envisage where skipping or bypassing this check would be