Re: Testing 4.0 Post-Freeze

2018-07-09 Thread Benedict Elliott Smith
+1. > On 9 Jul 2018, at 20:17, Mick Semb Wever wrote: > > >> We have done all this for previous releases and we know it has not worked >> well. So how giving it one more try is going to help here. Can someone >> outline what will change for 4.0 which will make it more successful? > > > I

Re: Testing 4.0 Post-Freeze

2018-07-09 Thread Mick Semb Wever
> We have done all this for previous releases and we know it has not worked > well. So how giving it one more try is going to help here. Can someone > outline what will change for 4.0 which will make it more successful? I (again) agree with you Sankalp :-) Why not try something new? It's

Re: Testing 4.0 Post-Freeze

2018-07-09 Thread sankalp kohli
Sure...thats an addition to the 3 states I was thinking(-1,+/-0 and +1) :) On Mon, Jul 9, 2018 at 12:49 PM Josh McKenzie wrote: > > > > I did not see a -1 but all +0s and a few +1s. > > It's more accurate to say you have quite a few -0's, some +0's, and a few > +1's, probably some -0.5's if

Re: Testing 4.0 Post-Freeze

2018-07-09 Thread Josh McKenzie
> > I did not see a -1 but all +0s and a few +1s. It's more accurate to say you have quite a few -0's, some +0's, and a few +1's, probably some -0.5's if you're into that. On Mon, Jul 9, 2018 at 2:53 PM Jeremy Hanna wrote: > What I’m saying is that for new contributors, not branching has a

Re: Testing 4.0 Post-Freeze

2018-07-09 Thread Jonathan Haddad
The most impactful change that I can see is the people that are involved with development who are willing to -1 a release. Those of us with votes are TLP have a big incentive for 4.0 to be stable - we want people to upgrade. I assume folks at Netflix, Apple are also very incentivized to see a

Re: Testing 4.0 Post-Freeze

2018-07-09 Thread Jeremy Hanna
What I’m saying is that for new contributors, not branching has a cost and I think there are other ways to organize efforts. One of the suggestions was for each organization to test their own use cases in the stabilization process. I don’t think that’s been done very effectively previously.

Re: Testing 4.0 Post-Freeze

2018-07-09 Thread sankalp kohli
We have done all this for previous releases and we know it has not worked well. So how giving it one more try is going to help here. Can someone outline what will change for 4.0 which will make it more successful? Not branching is one idea but we should discuss what will change now than iterating

Re: Testing 4.0 Post-Freeze

2018-07-09 Thread Jeremy Hanna
I wholeheartedly agree with efforts to make releases more stable and the more contributors that add tests or test within the context of their own use cases, the better. +1 non-binding to the idea of better, more complete testing for releases. When it comes to how to do this, I think that’s

Re: Testing 4.0 Post-Freeze

2018-07-09 Thread Jonathan Haddad
My proposal is that we implement everything you're suggesting, except we branch off as we have in the past rather than locking down trunk. I'd encourage everyone to work to improve 4.0 in some way or another, whether it be fixing bugs, testing in a staging environment (feedback), writing tooling

Re: Testing 4.0 Post-Freeze

2018-07-09 Thread sankalp kohli
If some committers want to bring in features without a path forward for releasing(as tests are broken), is that an acceptable state for you? How do we get out of this state. Like I said in my original email, this is a "proposal" and I am trying to see how we can improve things here. So if you are

Re: Testing 4.0 Post-Freeze

2018-07-09 Thread Jonathan Haddad
Not everyone wants to work and collaborate the way you do. It seems absurd to me to force everyone to hold off on merging into a single branch just because a lot of us want to prioritize testing 4.0. I think most committers are going to want to contribute to the 4.0 testing process more than

Re: Testing 4.0 Post-Freeze

2018-07-09 Thread sankalp kohli
How is this preventing someone from working and collaborating on an Apache Project? You can still collaborate on making 4.0 more stable. Why will these committers not work on making 4.0 more stable and fix broken tests? Considering we cannot release without test passing, how will these features

Re: Testing 4.0 Post-Freeze

2018-07-09 Thread Jonathan Haddad
I don't see how changing the process and banning feature commits is going to be any help to the project. There may be a couple committers who are interested in committing new features. I'm a -1 on changing the branching strategy in a way that prevents people from working and collaborating on an

Re: Testing 4.0 Post-Freeze

2018-07-09 Thread sankalp kohli
I did not see a -1 but all +0s and a few +1s. On Mon, Jul 9, 2018 at 5:49 AM Josh McKenzie wrote: > What did we land on? Sounds like we're pretty split without consensus on > "change the old branching strategy and reject new things on trunk during > stabilization" vs. "keep doing things the way

Register now for ApacheCon and save $250

2018-07-09 Thread Rich Bowen
Greetings, Apache software enthusiasts! (You’re getting this because you’re on one or more dev@ or users@ lists for some Apache Software Foundation project.) ApacheCon North America, in Montreal, is now just 80 days away, and early bird prices end in just two weeks - on July 21. Prices will

[VOTE FAILED - VETO] Release Apache Cassandra 2.2.13

2018-07-09 Thread Michael Shuler
This sha fails to build JDK7. If built on JDK8, which is what I did erroneously, the release fails with JDK7 runtime in AntiCompactionTest. In going through a round of test builds, it appears we have a problem with the CASSANDRA-14423 commit calling a JDK8-only String.join(). I'm vetoing this

[VOTE FAILED] Release Apache Cassandra 3.0.17

2018-07-09 Thread Michael Shuler
Based on the CASSANDRA-14555 notes and revert of the CASSANDRA-14252 from the cassandra-3.0/3.11 branches, I'm also a -1 for release. Kind regards, Michael On 07/03/2018 02:14 AM, Sam Tunnicliffe wrote: > -1 I think CASSANDRA-14252 should be reverted from 3.0 & 3.11, at least the > effect on

[VOTE FAILED] Release Apache Cassandra 3.11.3

2018-07-09 Thread Michael Shuler
Based on the CASSANDRA-14555 notes and revert of the CASSANDRA-14252 from the cassandra-3.0/3.11 branches, I'm also a -1 for release. Kind regards, Michael On 07/03/2018 02:14 AM, Sam Tunnicliffe wrote: > -1 I think CASSANDRA-14252 should be reverted from 3.0 & 3.11, at least the > effect on

Re: Testing 4.0 Post-Freeze

2018-07-09 Thread Josh McKenzie
What did we land on? Sounds like we're pretty split without consensus on "change the old branching strategy and reject new things on trunk during stabilization" vs. "keep doing things the way we did but message strongly that we won't be reviewing new things until 4.0 is stable". On Sat, Jul 7,