Re: Roadmap for 4.0

+1 On 4/4/18, 5:48 PM, "Jeff Jirsa" wrote: Earlier than I’d have personally picked, but I’m +1 too -- Jeff Jirsa > On Apr 4, 2018, at 5:06 PM, Nate McCall wrote: > > Top-posting as I think this summary is

Re: Roadmap for 4.0

+1 and seriously hoping stuff marked "Patch available" will at least get a chance of cutting in. On Thu, 5 Apr 2018 at 12:43 kurt greaves wrote: > > > > Earlier than I’d have personally picked, but I’m +1 too > > This but +1. > > On 5 April 2018 at 03:04, J. D. Jordan

Re: Roadmap for 4.0

> > Earlier than I’d have personally picked, but I’m +1 too This but +1. On 5 April 2018 at 03:04, J. D. Jordan wrote: > +1 > > > On Apr 4, 2018, at 5:06 PM, Nate McCall wrote: > > > > Top-posting as I think this summary is on point - thanks,

Re: Roadmap for 4.0

+1 > On Apr 4, 2018, at 5:06 PM, Nate McCall wrote: > > Top-posting as I think this summary is on point - thanks, Scott! (And > great to have you back, btw). > > It feels to me like we are coalescing on two points: > 1. June 1 as a freeze for alpha > 2. "Stable" is the new

Re: Roadmap for 4.0

On Wed, Apr 4, 2018 at 7:50 PM, Michael Shuler wrote: > On 04/04/2018 07:06 PM, Nate McCall wrote: > > > > It feels to me like we are coalescing on two points: > > 1. June 1 as a freeze for alpha > > 2. "Stable" is the new "Exciting" (and the testing and dogfooding > >

Re: Roadmap for 4.0

+1 On Wed, Apr 4, 2018 at 8:50 PM Michael Shuler wrote: > On 04/04/2018 07:06 PM, Nate McCall wrote: > > > > It feels to me like we are coalescing on two points: > > 1. June 1 as a freeze for alpha > > 2. "Stable" is the new "Exciting" (and the testing and dogfooding > >

Re: Roadmap for 4.0

On 04/04/2018 07:06 PM, Nate McCall wrote: > > It feels to me like we are coalescing on two points: > 1. June 1 as a freeze for alpha > 2. "Stable" is the new "Exciting" (and the testing and dogfooding > implied by such before a GA) > > How do folks feel about the above points? +1 +1 :)

Re: Roadmap for 4.0

Earlier than I’d have personally picked, but I’m +1 too -- Jeff Jirsa > On Apr 4, 2018, at 5:06 PM, Nate McCall wrote: > > Top-posting as I think this summary is on point - thanks, Scott! (And > great to have you back, btw). > > It feels to me like we are coalescing on

Re: Roadmap for 4.0

+1, well said Scott. > On Apr 4, 2018, at 5:13 PM, Jonathan Ellis wrote: > > On Wed, Apr 4, 2018, 7:06 PM Nate McCall wrote: > >> Top-posting as I think this summary is on point - thanks, Scott! (And >> great to have you back, btw). >> >> It feels to me

Re: Roadmap for 4.0

On Wed, Apr 4, 2018, 7:06 PM Nate McCall wrote: > Top-posting as I think this summary is on point - thanks, Scott! (And > great to have you back, btw). > > It feels to me like we are coalescing on two points: > 1. June 1 as a freeze for alpha > 2. "Stable" is the new

RE: Roadmap for 4.0

So in a vibrant community like ours, each year it is reasonable to expect that some new features will be ready. We probably can't predict far in advance which ones. So each year whatever is ready, is included in that year's major release (using a 12 month cycle as an example) and then no one is

Re: Roadmap for 4.0

Top-posting as I think this summary is on point - thanks, Scott! (And great to have you back, btw). It feels to me like we are coalescing on two points: 1. June 1 as a freeze for alpha 2. "Stable" is the new "Exciting" (and the testing and dogfooding implied by such before a GA) How do folks

RE: Roadmap for 4.0

The group seems to be trying to find a set of features that will define version 4.0. I'm saying that makes things way too complicated. You'll drift, time will go by, no release because of this or that. I'm saying instead, accept that you can't know the time frame really that it will take to

RE: Roadmap for 4.0

I wouldn't want to add anything to a release that isn't ready. Whatever isn't ready can go in a future release. -Original Message- From: Scott Andreas [mailto:sc...@paradoxica.net] Sent: Wednesday, April 04, 2018 4:18 PM To: dev@cassandra.apache.org Subject: Re: Roadmap for 4.0

Re: Roadmap for 4.0

Re-raising a point made earlier in the thread by Jeff and affirmed by Josh: ––– Jeff: >> A hard date for a feature freeze makes sense, a hard date for a release >> does not. Josh: > Strongly agree. We should also collectively define what "Done" looks like > post freeze so we don't end up in

RE: Roadmap for 4.0

Focusing on 4.0 release then, lets agree on a date next year. Whatever is ready for release by that date is what will be in that release. Kenneth Brotman -Original Message- From: Nate McCall [mailto:zznat...@gmail.com] Sent: Wednesday, April 04, 2018 12:59 PM To: dev Subject: Re:

Re: Roadmap for 4.0

On Thu, Apr 5, 2018 at 3:26 AM, Kenneth Brotman wrote: > Can I suggest a way of defining the next few progressions as a way of > approaching this? > > How about something like this: > Version 4.0: A major release of as many improvements to the code as >

RE: Roadmap for 4.0

Can I suggest a way of defining the next few progressions as a way of approaching this? How about something like this: Version 4.0: A major release of as many improvements to the code as can be ready for a release on a date sometime next year ;to be decided on by us this month.

Re: Roadmap for 4.0

+1 to what Jon and Josh said. At this point in time, an "exciting" 4.0 release to me is one that is stable and usable with no perf regressions on day 1 and includes some of the big internal changes mentioned previously. This will set the community up well for some awesome and exciting stuff that

Re: Repair scheduling tools

+1 to including the implementation in Cassandra itself. Makes managed repair a first-class citizen, it nicely rounds out Cassandra's consistency story and makes it 1000x more likely that repairs will get run. On Wed, Apr 4, 2018 at 10:45 AM Jon Haddad wrote: >

Re: Roadmap for 4.0

Agreed with Josh. There’s nothing set in stone after we release 4.0, trying to extrapolate what we do here for the rest of humanity’s timeline isn’t going to be a useful exercise. Regarding building a big list - it’s of no value. In fact, if we’re already talking about releasing 4.0 we

Re: Repair scheduling tools

Implementation details aside, I’m firmly in the “it would be nice of C* could take care of it” camp. Reaper is pretty damn easy to use and people *still* don’t put it in prod. > On Apr 4, 2018, at 4:16 AM, Rahul Singh wrote: > > I understand the merits of

Re: Roadmap for 4.0

> > This discussion was always about the release strategy. There is no > separation between the release strategy for 4.0 and the release strategy > for the project, they are the same thing and what is intended to be > discussed here. Not trying to be pedantic here, but the email thread is titled

Re: Roadmap for 4.0

> > I'm also a bit sad that we seem to be getting back to our old demons of > trying > to shove as much as we possibly can in the next major as if having a > feature > miss it means it will never happen. That wasn't the intention of this thread, but that's the response I got. Thought I made it

RE: Roadmap for 4.0

Having https://issues.apache.org/jira/browse/CASSANDRA-12269 in mind, 3.0 was a noticeable step back regarding write throughput compared to what we have been used with 2.1 on the same infrastructure, thus for us, 3.0.x is a no-go, thus planning more towards the 3.11.x series in pre-production

Re: Repair scheduling tools

I understand the merits of both approaches. In working with other DBs In the “old country” of SQL, we often had to write indexing sequences manually for important tables. It was “built into the product” but in order to leverage the maximum benefits of indices we had to have different indices

Re: Roadmap for 4.0

3.0 will be the most popular release for probably at least another couple years - I see no good reason to cap its support window. We aren’t Oracle. — AY On 3 April 2018 at 22:29:29, Michael Shuler (mich...@pbandjelly.org) wrote: Apache Cassandra 3.0 is supported until 6 months after 4.0

Re: Repair scheduling tools

We at Scylla, implemented repair in a similar way to the Cassandra reaper. We do that using an external application, written in go that manages repair for multiple clusters and saves the data in an external Scylla cluster. The logic resembles the reaper one with some specific internal sharding

Re: Repair scheduling tools

Simon, You could still do load aware repair outside of the main process by reading Cassandra's metrics. In general, I don't think the maintenance tasks necessarily need to live in the main process. They could negatively impact the read / write path. Unless strictly required by the serving path,