Re: [VOTE] Release Apache Cassandra 3.10 (Take 3)

2016-11-20 Thread Oleksandr Petrov
>From just a quick glance, I can say at least some of the tests are either PA or are getting there: For example: http://cassci.datastax.com/job/cassandra-3.X_novnode_dtest/lastCompletedBuild/testReport/paging_test/TestPagingData/test_paging_with_filtering_on_partition_key/ Should be fixed by

Re: Proposals for releases - 4.0 and beyond

2016-11-20 Thread Mick Semb Wever
On 19 November 2016 at 10:49, Jeff Jirsa wrote: > Option #3: Sylvain proposed [3] feature / testing / stable branches, Y > cadence for releases, X month rotation from feature -> testing -> stable -> > EOL (X to be determined). This is similar to an Ubuntu/Debian like

Re: [VOTE] Release Apache Cassandra 3.10 (Take 3)

2016-11-20 Thread sankalp kohli
Hi, I see the following test runs are failing. Are they for this release? http://cassci.datastax.com/job/cassandra-3.X_utest_cdc/ http://cassci.datastax.com/job/cassandra-3.X_testall/ http://cassci.datastax.com/job/cassandra-3.X_offheap_dtest/

Re: [VOTE] Release Apache Cassandra 3.10 (Take 3)

2016-11-20 Thread Nate McCall
+1 On Sat, Nov 19, 2016 at 7:08 AM, Michael Shuler wrote: > I propose the following artifacts for release as 3.10. > > sha1: 96d67b109a2ef858c2753bbb9853d01460cb8f8e > Git: > http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.10-tentative >

Re: Summary of 4.0 Large Features/Breaking Changes (Was: Rough roadmap for 4.0)

2016-11-20 Thread Jason Brown
+1 to everything Blake said. Bonus points for property-based state testing (a la ScalaCheck/QuickCheck). This being said, are we drifting from the original topic of this thread? Should we decide features for 4.0? It seems to me testing concerns might be for another thread? Is it worthwhile voting

Re: Summary of 4.0 Large Features/Breaking Changes (Was: Rough roadmap for 4.0)

2016-11-20 Thread Blake Eggleston
> I'm not sure how the apache team does this. Perhaps individual engineers  can run some modern version at a company of theirs, altho that seems  unlikely, but as an Apache org, i just don't see how that happens.  > To me it seems like the Apache Cassandra infrastructure itself needs to  stand up

Re: Summary of 4.0 Large Features/Breaking Changes (Was: Rough roadmap for 4.0)

2016-11-20 Thread Sankalp Kohli
This was not for the Dev list :) > On Nov 20, 2016, at 09:06, Sankalp Kohli wrote: > > I have asked him to calm down as these things are never constructive for the > community. Making personal comments put him in bad light more than anytime > else. > I will speak with

Re: Summary of 4.0 Large Features/Breaking Changes (Was: Rough roadmap for 4.0)

2016-11-20 Thread Sankalp Kohli
I have asked him to calm down as these things are never constructive for the community. Making personal comments put him in bad light more than anytime else. I will speak with him in person when we are in office. Thanks for keeping an eye on these things for us. I will setup another meeting

Re: Summary of 4.0 Large Features/Breaking Changes (Was: Rough roadmap for 4.0)

2016-11-20 Thread Dave Brosius
>> We fully intend to "engineer and test the snot out of" the changes we are working on as the whole point of us working on them is so we *can* run them in production, at our scale. I'm not sure how the apache team does this. Perhaps individual engineers can run some modern version at a

Re: Summary of 4.0 Large Features/Breaking Changes (Was: Rough roadmap for 4.0)

2016-11-20 Thread Jason Brown
Hey all, One of the goals on my team, when working on large patches, is to get community feedback on these initiatives before throwing them into prod. This gets us a wider net of feedback (see Sylvain's continuing excellent rounds of feedback to my work on CASSANDRA-8457), as well as making sure