+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 on point - thanks, Scott! (And
> g
+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 wrote:
>
> > +1
> >
> > >
>
> 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, Scott! (And
> > great to have you back, btw).
> >
>
+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 "Exciting" (and the t
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
> > implied by such before a GA
+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
> > implied by such before a
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
:)
Michael
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 two points:
> 1. Jun
+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 like we are coalescing on two points:
>
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 "Exciting" (and the testing a
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 r
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 feel
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 prop
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-rais
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 bike-
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: Road
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
> can be ready for a release on a d
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.
+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
+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:
> Implementation details aside, I’
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 should
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 both approaches. In working with o
>
> 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 "
>
> 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 pre
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 st
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 oth
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 release
27 matches
Mail list logo
