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

+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)

> 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)

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)

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)

>> 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)

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

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

Jason has asked for review and feedback many times. Maybe be constructive and review his code instead of just complaining (once again)? Sent from my iPhone > On Nov 19, 2016, at 1:49 PM, Edward Capriolo wrote: > > I would say start with a mindset like 'people will run

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

I would say start with a mindset like 'people will run this in production' not like 'why would you expect this to work'. Now how does this logic effect feature develement? Maybe use gossip 2.0 as an example. I will play my given debby downer role. I could imagine 1 or 2 dtests and the logic of

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

Any proposal to solve the problem you describe? -- Jeff Jirsa > On Nov 19, 2016, at 8:50 AM, Edward Capriolo wrote: > > This is especially relevant if people wish to focus on removing things. > > For example, gossip 2.0 sounds great, but seems geared toward huge

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

Honest question: are you *ever* positive Ed? Maybe give it a shot once in a while. It will be good for your mental health. Sent from my iPhone > On Nov 19, 2016, at 11:50 AM, Edward Capriolo wrote: > > This is especially relevant if people wish to focus on removing

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

This is especially relevant if people wish to focus on removing things. For example, gossip 2.0 sounds great, but seems geared toward huge clusters which is not likely a majority of users. For those with a 20 node cluster are the indirect benefits woth it? Also there seems to be a first push to

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

On Friday, November 18, 2016, Jeff Jirsa wrote: > We should assume that we’re ditching tick/tock. I’ll post a thread on > 4.0-and-beyond here in a few minutes. > > The advantage of a prod release every 6 months is fewer incentive to push > unfinished work into a

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

We should assume that we’re ditching tick/tock. I’ll post a thread on 4.0-and-beyond here in a few minutes. The advantage of a prod release every 6 months is fewer incentive to push unfinished work into a release. The disadvantage of a prod release every 6 months is then we either have a very

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

> While stability is important if we push back large "core" changes until later > we're just setting ourselves up to face the same issues later on In theory, yes. In practice, when incomplete features are earmarked for a certain release, those features are often rushed out, and not always fully

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

On 18 November 2016 at 18:25, Jason Brown wrote: > #11559 (enhanced node representation) - decided it's *not* something we > need wrt #7544 storage port configurable per node, so we are punting on > #12344 - Forward writes to replacement node with same address during

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

Introducing all of these in a single release seems pretty risky. I think it would be safer to spread these out over a few 4.x releases (as they’re finished) and give them time to stabilize before including them in an LTS release. The downside would be having to maintain backwards compatibility

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

Hi Nate, Most of the JIRAs in the middle are being rebased or being reviewed and code is already out there. These will make 4.0 a very solid release. Thanks, Sankalp On Thu, Nov 17, 2016 at 5:10 PM, Ben Bromhead wrote: > We are happy to start testing against

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

We are happy to start testing against completed features. Ideally once everything is ready for an RC (to catch interaction bugs), but we can do sooner for features where it make sense and are finished earlier. On Thu, 17 Nov 2016 at 16:47 Nate McCall wrote: > To sum up that