Re: Roadmap for 4.0

[Nate McCall]

To close the loop on this thread: I don't think we need to do an
official vote here, but let's just put it on our calendars that we are
aiming to branch off 4.0 and freeze the first week of Sept.

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Roadmap for 4.0

[kurt greaves]

Seems to me we should put September first to an official vote so we can
finish up with this mess.

On 13 April 2018 at 02:27, Rahul Singh  wrote:

> I can commit some resources on my team - especially as we onboard some of
> our summer apprentices.
>
> I have some proprietary stress tools geared for Cassandra read / writes
> that are a little better and creates a little more realistic data than
> Cassandra stress.
>
> --
> Rahul Singh
> rahul.si...@anant.us
>
> Anant Corporation
>
> On Apr 12, 2018, 3:41 PM -0400, Nate McCall , wrote:
> > Ok. So who's willing to test 4.0 on June 2nd? Let's start a sign up.
> >
> > We (tlp) will put some resources on this via going through some canned
> > scenarios we have internally. We aren't in a position to test data
> validity
> > (yet) but we can do a lot around cluster behavior.
> >
> > Who else has specific stuff they are willing to do? Even if it's just
> > tee'ing prod traffic, that would be hugely valuable.
> >
> > On Fri, Apr 13, 2018, 6:15 AM Jeff Jirsa  wrote:
> >
> > > On Thu, Apr 12, 2018 at 9:41 AM, Jonathan Haddad  > > wrote:
> > >
> > > > It sounds to me (please correct me if I'm wrong) like Jeff is arguing
> > > that
> > > > releasing 4.0 in 2 months isn't worth the effort of evaluating it,
> > > because
> > > > it's a big task and there's not enough stuff in 4.0 to make it
> > > worthwhile.
> > > >
> > > >
> > > More like "not enough stuff in 4.0 to make it worthwhile for the
> people I
> > > personally know to be willing and able to find the weird bugs".
> > >
> > >
> > > > If that is the case, I'm not quite sure how increasing the surface
> area
> > > of
> > > > changed code which needs to be vetted is going to make the process
> any
> > > > easier.
> > >
> > >
> > > It changes the interest level of at least some of the people able to
> > > properly test it from "not willing" to "willing".
> > >
> > > Totally possible that there exist people who are willing and able to
> find
> > > and fix those bugs, who just haven't committed to it in this thread.
> That's
> > > probably why Sankalp keeps asking who's actually willing to do the
> testing
> > > on June 2 - if nobody's going to commit to doing real testing on June
> 2,
> > > all we're doing is adding inconvenience to those of us who'd be
> willing to
> > > do it later in the year.
> > >
>

Re: Roadmap for 4.0

[Rahul Singh]

I can commit some resources on my team - especially as we onboard some of our 
summer apprentices.

I have some proprietary stress tools geared for Cassandra read / writes that 
are a little better and creates a little more realistic data than Cassandra 
stress.

--
Rahul Singh
rahul.si...@anant.us

Anant Corporation

On Apr 12, 2018, 3:41 PM -0400, Nate McCall , wrote:
> Ok. So who's willing to test 4.0 on June 2nd? Let's start a sign up.
>
> We (tlp) will put some resources on this via going through some canned
> scenarios we have internally. We aren't in a position to test data validity
> (yet) but we can do a lot around cluster behavior.
>
> Who else has specific stuff they are willing to do? Even if it's just
> tee'ing prod traffic, that would be hugely valuable.
>
> On Fri, Apr 13, 2018, 6:15 AM Jeff Jirsa  wrote:
>
> > On Thu, Apr 12, 2018 at 9:41 AM, Jonathan Haddad  > wrote:
> >
> > > It sounds to me (please correct me if I'm wrong) like Jeff is arguing
> > that
> > > releasing 4.0 in 2 months isn't worth the effort of evaluating it,
> > because
> > > it's a big task and there's not enough stuff in 4.0 to make it
> > worthwhile.
> > >
> > >
> > More like "not enough stuff in 4.0 to make it worthwhile for the people I
> > personally know to be willing and able to find the weird bugs".
> >
> >
> > > If that is the case, I'm not quite sure how increasing the surface area
> > of
> > > changed code which needs to be vetted is going to make the process any
> > > easier.
> >
> >
> > It changes the interest level of at least some of the people able to
> > properly test it from "not willing" to "willing".
> >
> > Totally possible that there exist people who are willing and able to find
> > and fix those bugs, who just haven't committed to it in this thread. That's
> > probably why Sankalp keeps asking who's actually willing to do the testing
> > on June 2 - if nobody's going to commit to doing real testing on June 2,
> > all we're doing is adding inconvenience to those of us who'd be willing to
> > do it later in the year.
> >

Re: Roadmap for 4.0

[Dave Brosius]

I think the reason there's such a kerfuffle around a 'close-to-now' 
freeze date is more of a concern as to when cassandra 5.0 is going to be 
released. I'm assuming if people thought 5.0 was going to be released in 
early 2019 no one would have a problem with setting the freeze date of 
4.0 to _right now_. But most likely people are thinking 5.0~sun explode 
time, and want to jam anything remotely protocol-breaking into 4 that 
they can now. I realize people are reticent about having a quick 
pipeline of .0 releases, which causes multiple release branches to 
support, but it seems that's the only way to actually get them out.



On 04/12/2018 06:45 PM, Jonathan Ellis wrote:

The thing is, good intentions are cheap. And they get cheaper the further
out in the future the point of action gets.

Realistically, the main difference between June and September is we ship
three months later. More, if we manage to land large, destabilizing patches
in the meantime.  I’m very skeptical it will actually result in additional
testing.  In my experience, people start testing once you actually have an
alpha or beta released. And even then they prefer to wait for a dot zero.

We only have about nine years of project history showing this, though.
I’m sure this time  will be different.

On Thu, Apr 12, 2018 at 3:59 PM Ben Bromhead  wrote:


While I would prefer earlier, if Sept 1 gets better buy-in and we can have
broader commitment to testing. I'm super happy with that. As Nate said,
having a solid line to work towards is going to help massively.

On Thu, Apr 12, 2018 at 4:07 PM Nate McCall  wrote:


If we push it to Sept 1 freeze, I'll personally spend a lot of time

testing.

What can I do to help convince the Jun1 folks that Sept1 is acceptable?

I can come around to that. At this point, I really just want us to
have a date we can start talking to/planning around.

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

--

Ben Bromhead
CTO | Instaclustr 
+1 650 284 9692
Reliability at Scale
Cassandra, Spark, Elasticsearch on AWS, Azure, GCP and Softlayer




-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Roadmap for 4.0

[kurt greaves]

September also works for Instaclustr.

On Fri., 13 Apr. 2018, 08:27 Jon Haddad,  wrote:

> Sept works for me too.  I’ll be involved in the validation process before
> the cutoff date.
>
>
> > On Apr 12, 2018, at 3:17 PM, Carlos Rolo  wrote:
> >
> > I will commit time to test (not a full validation, but at least go
> through
> > operations) regardless of the date. Both seems fine to me.
> >
> > Regards,
> >
> > Carlos Juzarte Rolo
> > Cassandra Consultant / Datastax Certified Architect / Cassandra MVP
> >
> > Pythian - Love your data
> >
> > rolo@pythian | Twitter: @cjrolo | Skype: cjr2k3 | Linkedin:
> > *linkedin.com/in/carlosjuzarterolo
> > *
> > Mobile: +351 918 918 100
> > www.pythian.com
> >
> > On Thu, Apr 12, 2018 at 11:00 PM, Joseph Lynch 
> > wrote:
> >
> >> The Netflix team prefers September as well. We don't have time before
> that
> >> to do a full certification (e2e and performance testing), but can
> probably
> >> work it into end of Q3 / start of Q4.
> >>
> >> I personally hope that the extra time gives us as a community a chance
> to
> >> come up with a compelling user story for why users would want to
> upgrade. I
> >> don't feel we have one right now.
> >>
> >> -Joey
> >>
> >>
> >> On Thu, Apr 12, 2018 at 2:51 PM, Ariel Weisberg 
> wrote:
> >>
> >>> Hi,
> >>>
> >>> +1 to September 1st. I know I will have much better availability then.
> >>>
> >>> Ariel
> >>> On Thu, Apr 12, 2018, at 5:15 PM, Sankalp Kohli wrote:
>  +1 with Sept 1st as I am seeing willingness for people to test it
> after
> >>> it
> 
> > On Apr 12, 2018, at 13:59, Ben Bromhead  wrote:
> >
> > While I would prefer earlier, if Sept 1 gets better buy-in and we can
> >>> have
> > broader commitment to testing. I'm super happy with that. As Nate
> >> said,
> > having a solid line to work towards is going to help massively.
> >
> > On Thu, Apr 12, 2018 at 4:07 PM Nate McCall 
> >>> wrote:
> >
> >>> If we push it to Sept 1 freeze, I'll personally spend a lot of time
> >> testing.
> >>>
> >>> What can I do to help convince the Jun1 folks that Sept1 is
> >>> acceptable?
> >>
> >> I can come around to that. At this point, I really just want us to
> >> have a date we can start talking to/planning around.
> >>
> >> 
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> >> For additional commands, e-mail: dev-h...@cassandra.apache.org
> >>
> >> --
> > Ben Bromhead
> > CTO | Instaclustr 
> > +1 650 284 9692
> > Reliability at Scale
> > Cassandra, Spark, Elasticsearch on AWS, Azure, GCP and Softlayer
> 
>  -
>  To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>  For additional commands, e-mail: dev-h...@cassandra.apache.org
> 
> >>>
> >>> -
> >>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> >>> For additional commands, e-mail: dev-h...@cassandra.apache.org
> >>>
> >>>
> >>
> >
> > --
> >
> >
> > --
> >
> >
> >
> >
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: Roadmap for 4.0

[Jonathan Ellis]

The thing is, good intentions are cheap. And they get cheaper the further
out in the future the point of action gets.

Realistically, the main difference between June and September is we ship
three months later. More, if we manage to land large, destabilizing patches
in the meantime.  I’m very skeptical it will actually result in additional
testing.  In my experience, people start testing once you actually have an
alpha or beta released. And even then they prefer to wait for a dot zero.

We only have about nine years of project history showing this, though.
I’m sure this time  will be different.

On Thu, Apr 12, 2018 at 3:59 PM Ben Bromhead  wrote:

> While I would prefer earlier, if Sept 1 gets better buy-in and we can have
> broader commitment to testing. I'm super happy with that. As Nate said,
> having a solid line to work towards is going to help massively.
>
> On Thu, Apr 12, 2018 at 4:07 PM Nate McCall  wrote:
>
> > > If we push it to Sept 1 freeze, I'll personally spend a lot of time
> > testing.
> > >
> > > What can I do to help convince the Jun1 folks that Sept1 is acceptable?
> >
> > I can come around to that. At this point, I really just want us to
> > have a date we can start talking to/planning around.
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> > --
> Ben Bromhead
> CTO | Instaclustr 
> +1 650 284 9692
> Reliability at Scale
> Cassandra, Spark, Elasticsearch on AWS, Azure, GCP and Softlayer
>
-- 
Jonathan Ellis
co-founder, http://www.datastax.com
@spyced

Re: Roadmap for 4.0

[Jon Haddad]

Sept works for me too.  I’ll be involved in the validation process before the 
cutoff date.  


> On Apr 12, 2018, at 3:17 PM, Carlos Rolo  wrote:
> 
> I will commit time to test (not a full validation, but at least go through
> operations) regardless of the date. Both seems fine to me.
> 
> Regards,
> 
> Carlos Juzarte Rolo
> Cassandra Consultant / Datastax Certified Architect / Cassandra MVP
> 
> Pythian - Love your data
> 
> rolo@pythian | Twitter: @cjrolo | Skype: cjr2k3 | Linkedin:
> *linkedin.com/in/carlosjuzarterolo
> *
> Mobile: +351 918 918 100
> www.pythian.com
> 
> On Thu, Apr 12, 2018 at 11:00 PM, Joseph Lynch 
> wrote:
> 
>> The Netflix team prefers September as well. We don't have time before that
>> to do a full certification (e2e and performance testing), but can probably
>> work it into end of Q3 / start of Q4.
>> 
>> I personally hope that the extra time gives us as a community a chance to
>> come up with a compelling user story for why users would want to upgrade. I
>> don't feel we have one right now.
>> 
>> -Joey
>> 
>> 
>> On Thu, Apr 12, 2018 at 2:51 PM, Ariel Weisberg  wrote:
>> 
>>> Hi,
>>> 
>>> +1 to September 1st. I know I will have much better availability then.
>>> 
>>> Ariel
>>> On Thu, Apr 12, 2018, at 5:15 PM, Sankalp Kohli wrote:
 +1 with Sept 1st as I am seeing willingness for people to test it after
>>> it
 
> On Apr 12, 2018, at 13:59, Ben Bromhead  wrote:
> 
> While I would prefer earlier, if Sept 1 gets better buy-in and we can
>>> have
> broader commitment to testing. I'm super happy with that. As Nate
>> said,
> having a solid line to work towards is going to help massively.
> 
> On Thu, Apr 12, 2018 at 4:07 PM Nate McCall 
>>> wrote:
> 
>>> If we push it to Sept 1 freeze, I'll personally spend a lot of time
>> testing.
>>> 
>>> What can I do to help convince the Jun1 folks that Sept1 is
>>> acceptable?
>> 
>> I can come around to that. At this point, I really just want us to
>> have a date we can start talking to/planning around.
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>> For additional commands, e-mail: dev-h...@cassandra.apache.org
>> 
>> --
> Ben Bromhead
> CTO | Instaclustr 
> +1 650 284 9692
> Reliability at Scale
> Cassandra, Spark, Elasticsearch on AWS, Azure, GCP and Softlayer
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
 For additional commands, e-mail: dev-h...@cassandra.apache.org
 
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>>> For additional commands, e-mail: dev-h...@cassandra.apache.org
>>> 
>>> 
>> 
> 
> -- 
> 
> 
> --
> 
> 
> 
> 
> 


-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Roadmap for 4.0

[Carlos Rolo]

I will commit time to test (not a full validation, but at least go through
operations) regardless of the date. Both seems fine to me.

Regards,

Carlos Juzarte Rolo
Cassandra Consultant / Datastax Certified Architect / Cassandra MVP

Pythian - Love your data

rolo@pythian | Twitter: @cjrolo | Skype: cjr2k3 | Linkedin:
*linkedin.com/in/carlosjuzarterolo
*
Mobile: +351 918 918 100
www.pythian.com

On Thu, Apr 12, 2018 at 11:00 PM, Joseph Lynch 
wrote:

> The Netflix team prefers September as well. We don't have time before that
> to do a full certification (e2e and performance testing), but can probably
> work it into end of Q3 / start of Q4.
>
> I personally hope that the extra time gives us as a community a chance to
> come up with a compelling user story for why users would want to upgrade. I
> don't feel we have one right now.
>
> -Joey
>
>
> On Thu, Apr 12, 2018 at 2:51 PM, Ariel Weisberg  wrote:
>
> > Hi,
> >
> > +1 to September 1st. I know I will have much better availability then.
> >
> > Ariel
> > On Thu, Apr 12, 2018, at 5:15 PM, Sankalp Kohli wrote:
> > > +1 with Sept 1st as I am seeing willingness for people to test it after
> > it
> > >
> > > > On Apr 12, 2018, at 13:59, Ben Bromhead  wrote:
> > > >
> > > > While I would prefer earlier, if Sept 1 gets better buy-in and we can
> > have
> > > > broader commitment to testing. I'm super happy with that. As Nate
> said,
> > > > having a solid line to work towards is going to help massively.
> > > >
> > > > On Thu, Apr 12, 2018 at 4:07 PM Nate McCall 
> > wrote:
> > > >
> > > >>> If we push it to Sept 1 freeze, I'll personally spend a lot of time
> > > >> testing.
> > > >>>
> > > >>> What can I do to help convince the Jun1 folks that Sept1 is
> > acceptable?
> > > >>
> > > >> I can come around to that. At this point, I really just want us to
> > > >> have a date we can start talking to/planning around.
> > > >>
> > > >> 
> -
> > > >> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > > >> For additional commands, e-mail: dev-h...@cassandra.apache.org
> > > >>
> > > >> --
> > > > Ben Bromhead
> > > > CTO | Instaclustr 
> > > > +1 650 284 9692
> > > > Reliability at Scale
> > > > Cassandra, Spark, Elasticsearch on AWS, Azure, GCP and Softlayer
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > > For additional commands, e-mail: dev-h...@cassandra.apache.org
> > >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> >
>

-- 


--

Re: Roadmap for 4.0

[Joseph Lynch]

The Netflix team prefers September as well. We don't have time before that
to do a full certification (e2e and performance testing), but can probably
work it into end of Q3 / start of Q4.

I personally hope that the extra time gives us as a community a chance to
come up with a compelling user story for why users would want to upgrade. I
don't feel we have one right now.

-Joey


On Thu, Apr 12, 2018 at 2:51 PM, Ariel Weisberg  wrote:

> Hi,
>
> +1 to September 1st. I know I will have much better availability then.
>
> Ariel
> On Thu, Apr 12, 2018, at 5:15 PM, Sankalp Kohli wrote:
> > +1 with Sept 1st as I am seeing willingness for people to test it after
> it
> >
> > > On Apr 12, 2018, at 13:59, Ben Bromhead  wrote:
> > >
> > > While I would prefer earlier, if Sept 1 gets better buy-in and we can
> have
> > > broader commitment to testing. I'm super happy with that. As Nate said,
> > > having a solid line to work towards is going to help massively.
> > >
> > > On Thu, Apr 12, 2018 at 4:07 PM Nate McCall 
> wrote:
> > >
> > >>> If we push it to Sept 1 freeze, I'll personally spend a lot of time
> > >> testing.
> > >>>
> > >>> What can I do to help convince the Jun1 folks that Sept1 is
> acceptable?
> > >>
> > >> I can come around to that. At this point, I really just want us to
> > >> have a date we can start talking to/planning around.
> > >>
> > >> -
> > >> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > >> For additional commands, e-mail: dev-h...@cassandra.apache.org
> > >>
> > >> --
> > > Ben Bromhead
> > > CTO | Instaclustr 
> > > +1 650 284 9692
> > > Reliability at Scale
> > > Cassandra, Spark, Elasticsearch on AWS, Azure, GCP and Softlayer
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: Roadmap for 4.0

[Ariel Weisberg]

Hi,

+1 to September 1st. I know I will have much better availability then.

Ariel
On Thu, Apr 12, 2018, at 5:15 PM, Sankalp Kohli wrote:
> +1 with Sept 1st as I am seeing willingness for people to test it after it
> 
> > On Apr 12, 2018, at 13:59, Ben Bromhead  wrote:
> > 
> > While I would prefer earlier, if Sept 1 gets better buy-in and we can have
> > broader commitment to testing. I'm super happy with that. As Nate said,
> > having a solid line to work towards is going to help massively.
> > 
> > On Thu, Apr 12, 2018 at 4:07 PM Nate McCall  wrote:
> > 
> >>> If we push it to Sept 1 freeze, I'll personally spend a lot of time
> >> testing.
> >>> 
> >>> What can I do to help convince the Jun1 folks that Sept1 is acceptable?
> >> 
> >> I can come around to that. At this point, I really just want us to
> >> have a date we can start talking to/planning around.
> >> 
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> >> For additional commands, e-mail: dev-h...@cassandra.apache.org
> >> 
> >> --
> > Ben Bromhead
> > CTO | Instaclustr 
> > +1 650 284 9692
> > Reliability at Scale
> > Cassandra, Spark, Elasticsearch on AWS, Azure, GCP and Softlayer
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
> 

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Roadmap for 4.0

[Sankalp Kohli]

+1 with Sept 1st as I am seeing willingness for people to test it after it

> On Apr 12, 2018, at 13:59, Ben Bromhead  wrote:
> 
> While I would prefer earlier, if Sept 1 gets better buy-in and we can have
> broader commitment to testing. I'm super happy with that. As Nate said,
> having a solid line to work towards is going to help massively.
> 
> On Thu, Apr 12, 2018 at 4:07 PM Nate McCall  wrote:
> 
>>> If we push it to Sept 1 freeze, I'll personally spend a lot of time
>> testing.
>>> 
>>> What can I do to help convince the Jun1 folks that Sept1 is acceptable?
>> 
>> I can come around to that. At this point, I really just want us to
>> have a date we can start talking to/planning around.
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>> For additional commands, e-mail: dev-h...@cassandra.apache.org
>> 
>> --
> Ben Bromhead
> CTO | Instaclustr 
> +1 650 284 9692
> Reliability at Scale
> Cassandra, Spark, Elasticsearch on AWS, Azure, GCP and Softlayer

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Roadmap for 4.0

[Nate McCall]

> If we push it to Sept 1 freeze, I'll personally spend a lot of time testing.
>
> What can I do to help convince the Jun1 folks that Sept1 is acceptable?

I can come around to that. At this point, I really just want us to
have a date we can start talking to/planning around.

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Roadmap for 4.0

[Jeff Jirsa]

If we push it to Sept 1 freeze, I'll personally spend a lot of time testing.

What can I do to help convince the Jun1 folks that Sept1 is acceptable?



On Thu, Apr 12, 2018 at 12:57 PM, Ben Bromhead  wrote:

> I would also suggest if you can't commit to June 2 due to timing or feature
> set. If you could provide the absolute minimum date / features that would
> let you commit to testing, that would be useful.
>
> On Thu, Apr 12, 2018 at 3:49 PM Ben Bromhead  wrote:
>
> > We (Instaclustr) are also happy to get started testing. Including
> > (internal to Instaclustr) production workloads.
> >
> > On Thu, Apr 12, 2018 at 3:45 PM Nate McCall  wrote:
> >
> >> To be clear, more who is willing to commit to testing should we go this
> >> route.
> >>
> >> On Fri, Apr 13, 2018, 7:41 AM Nate McCall  wrote:
> >>
> >> > Ok. So who's willing to test 4.0 on June 2nd? Let's start a sign up.
> >> >
> >> > We (tlp) will put some resources on this via going through some canned
> >> > scenarios we have internally. We aren't in a position to test data
> >> validity
> >> > (yet) but we can do a lot around cluster behavior.
> >> >
> >> > Who else has specific stuff they are willing to do? Even if it's just
> >> > tee'ing prod traffic, that would be hugely valuable.
> >> >
> >> > On Fri, Apr 13, 2018, 6:15 AM Jeff Jirsa  wrote:
> >> >
> >> >> On Thu, Apr 12, 2018 at 9:41 AM, Jonathan Haddad 
> >> >> wrote:
> >> >>
> >> >> > It sounds to me (please correct me if I'm wrong) like Jeff is
> arguing
> >> >> that
> >> >> > releasing 4.0 in 2 months isn't worth the effort of evaluating it,
> >> >> because
> >> >> > it's a big task and there's not enough stuff in 4.0 to make it
> >> >> worthwhile.
> >> >> >
> >> >> >
> >> >> More like "not enough stuff in 4.0 to make it worthwhile for the
> >> people I
> >> >> personally know to be willing and able to find the weird bugs".
> >> >>
> >> >>
> >> >> > If that is the case, I'm not quite sure how increasing the surface
> >> area
> >> >> of
> >> >> > changed code which needs to be vetted is going to make the process
> >> any
> >> >> > easier.
> >> >>
> >> >>
> >> >> It changes the interest level of at least some of the people able to
> >> >> properly test it from "not willing" to "willing".
> >> >>
> >> >> Totally possible that there exist people who are willing and able to
> >> find
> >> >> and fix those bugs, who just haven't committed to it in this thread.
> >> >> That's
> >> >> probably why Sankalp keeps asking who's actually willing to do the
> >> testing
> >> >> on June 2 - if nobody's going to commit to doing real testing on June
> >> 2,
> >> >> all we're doing is adding inconvenience to those of us who'd be
> >> willing to
> >> >> do it later in the year.
> >> >>
> >> >
> >>
> > --
> > Ben Bromhead
> > CTO | Instaclustr 
> > +1 650 284 9692
> > Reliability at Scale
> > Cassandra, Spark, Elasticsearch on AWS, Azure, GCP and Softlayer
> >
> --
> Ben Bromhead
> CTO | Instaclustr 
> +1 650 284 9692
> Reliability at Scale
> Cassandra, Spark, Elasticsearch on AWS, Azure, GCP and Softlayer
>

Re: Roadmap for 4.0

[Ben Bromhead]

I would also suggest if you can't commit to June 2 due to timing or feature
set. If you could provide the absolute minimum date / features that would
let you commit to testing, that would be useful.

On Thu, Apr 12, 2018 at 3:49 PM Ben Bromhead  wrote:

> We (Instaclustr) are also happy to get started testing. Including
> (internal to Instaclustr) production workloads.
>
> On Thu, Apr 12, 2018 at 3:45 PM Nate McCall  wrote:
>
>> To be clear, more who is willing to commit to testing should we go this
>> route.
>>
>> On Fri, Apr 13, 2018, 7:41 AM Nate McCall  wrote:
>>
>> > Ok. So who's willing to test 4.0 on June 2nd? Let's start a sign up.
>> >
>> > We (tlp) will put some resources on this via going through some canned
>> > scenarios we have internally. We aren't in a position to test data
>> validity
>> > (yet) but we can do a lot around cluster behavior.
>> >
>> > Who else has specific stuff they are willing to do? Even if it's just
>> > tee'ing prod traffic, that would be hugely valuable.
>> >
>> > On Fri, Apr 13, 2018, 6:15 AM Jeff Jirsa  wrote:
>> >
>> >> On Thu, Apr 12, 2018 at 9:41 AM, Jonathan Haddad 
>> >> wrote:
>> >>
>> >> > It sounds to me (please correct me if I'm wrong) like Jeff is arguing
>> >> that
>> >> > releasing 4.0 in 2 months isn't worth the effort of evaluating it,
>> >> because
>> >> > it's a big task and there's not enough stuff in 4.0 to make it
>> >> worthwhile.
>> >> >
>> >> >
>> >> More like "not enough stuff in 4.0 to make it worthwhile for the
>> people I
>> >> personally know to be willing and able to find the weird bugs".
>> >>
>> >>
>> >> > If that is the case, I'm not quite sure how increasing the surface
>> area
>> >> of
>> >> > changed code which needs to be vetted is going to make the process
>> any
>> >> > easier.
>> >>
>> >>
>> >> It changes the interest level of at least some of the people able to
>> >> properly test it from "not willing" to "willing".
>> >>
>> >> Totally possible that there exist people who are willing and able to
>> find
>> >> and fix those bugs, who just haven't committed to it in this thread.
>> >> That's
>> >> probably why Sankalp keeps asking who's actually willing to do the
>> testing
>> >> on June 2 - if nobody's going to commit to doing real testing on June
>> 2,
>> >> all we're doing is adding inconvenience to those of us who'd be
>> willing to
>> >> do it later in the year.
>> >>
>> >
>>
> --
> Ben Bromhead
> CTO | Instaclustr 
> +1 650 284 9692
> Reliability at Scale
> Cassandra, Spark, Elasticsearch on AWS, Azure, GCP and Softlayer
>
-- 
Ben Bromhead
CTO | Instaclustr 
+1 650 284 9692
Reliability at Scale
Cassandra, Spark, Elasticsearch on AWS, Azure, GCP and Softlayer

Re: Roadmap for 4.0

[Ben Bromhead]

We (Instaclustr) are also happy to get started testing. Including (internal
to Instaclustr) production workloads.

On Thu, Apr 12, 2018 at 3:45 PM Nate McCall  wrote:

> To be clear, more who is willing to commit to testing should we go this
> route.
>
> On Fri, Apr 13, 2018, 7:41 AM Nate McCall  wrote:
>
> > Ok. So who's willing to test 4.0 on June 2nd? Let's start a sign up.
> >
> > We (tlp) will put some resources on this via going through some canned
> > scenarios we have internally. We aren't in a position to test data
> validity
> > (yet) but we can do a lot around cluster behavior.
> >
> > Who else has specific stuff they are willing to do? Even if it's just
> > tee'ing prod traffic, that would be hugely valuable.
> >
> > On Fri, Apr 13, 2018, 6:15 AM Jeff Jirsa  wrote:
> >
> >> On Thu, Apr 12, 2018 at 9:41 AM, Jonathan Haddad 
> >> wrote:
> >>
> >> > It sounds to me (please correct me if I'm wrong) like Jeff is arguing
> >> that
> >> > releasing 4.0 in 2 months isn't worth the effort of evaluating it,
> >> because
> >> > it's a big task and there's not enough stuff in 4.0 to make it
> >> worthwhile.
> >> >
> >> >
> >> More like "not enough stuff in 4.0 to make it worthwhile for the people
> I
> >> personally know to be willing and able to find the weird bugs".
> >>
> >>
> >> > If that is the case, I'm not quite sure how increasing the surface
> area
> >> of
> >> > changed code which needs to be vetted is going to make the process any
> >> > easier.
> >>
> >>
> >> It changes the interest level of at least some of the people able to
> >> properly test it from "not willing" to "willing".
> >>
> >> Totally possible that there exist people who are willing and able to
> find
> >> and fix those bugs, who just haven't committed to it in this thread.
> >> That's
> >> probably why Sankalp keeps asking who's actually willing to do the
> testing
> >> on June 2 - if nobody's going to commit to doing real testing on June 2,
> >> all we're doing is adding inconvenience to those of us who'd be willing
> to
> >> do it later in the year.
> >>
> >
>
-- 
Ben Bromhead
CTO | Instaclustr 
+1 650 284 9692
Reliability at Scale
Cassandra, Spark, Elasticsearch on AWS, Azure, GCP and Softlayer

Re: Roadmap for 4.0

[Nate McCall]

To be clear, more who is willing to commit to testing should we go this
route.

On Fri, Apr 13, 2018, 7:41 AM Nate McCall  wrote:

> Ok. So who's willing to test 4.0 on June 2nd? Let's start a sign up.
>
> We (tlp) will put some resources on this via going through some canned
> scenarios we have internally. We aren't in a position to test data validity
> (yet) but we can do a lot around cluster behavior.
>
> Who else has specific stuff they are willing to do? Even if it's just
> tee'ing prod traffic, that would be hugely valuable.
>
> On Fri, Apr 13, 2018, 6:15 AM Jeff Jirsa  wrote:
>
>> On Thu, Apr 12, 2018 at 9:41 AM, Jonathan Haddad 
>> wrote:
>>
>> > It sounds to me (please correct me if I'm wrong) like Jeff is arguing
>> that
>> > releasing 4.0 in 2 months isn't worth the effort of evaluating it,
>> because
>> > it's a big task and there's not enough stuff in 4.0 to make it
>> worthwhile.
>> >
>> >
>> More like "not enough stuff in 4.0 to make it worthwhile for the people I
>> personally know to be willing and able to find the weird bugs".
>>
>>
>> > If that is the case, I'm not quite sure how increasing the surface area
>> of
>> > changed code which needs to be vetted is going to make the process any
>> > easier.
>>
>>
>> It changes the interest level of at least some of the people able to
>> properly test it from "not willing" to "willing".
>>
>> Totally possible that there exist people who are willing and able to find
>> and fix those bugs, who just haven't committed to it in this thread.
>> That's
>> probably why Sankalp keeps asking who's actually willing to do the testing
>> on June 2 - if nobody's going to commit to doing real testing on June 2,
>> all we're doing is adding inconvenience to those of us who'd be willing to
>> do it later in the year.
>>
>

Re: Roadmap for 4.0

[Nate McCall]

Ok. So who's willing to test 4.0 on June 2nd? Let's start a sign up.

We (tlp) will put some resources on this via going through some canned
scenarios we have internally. We aren't in a position to test data validity
(yet) but we can do a lot around cluster behavior.

Who else has specific stuff they are willing to do? Even if it's just
tee'ing prod traffic, that would be hugely valuable.

On Fri, Apr 13, 2018, 6:15 AM Jeff Jirsa  wrote:

> On Thu, Apr 12, 2018 at 9:41 AM, Jonathan Haddad 
> wrote:
>
> > It sounds to me (please correct me if I'm wrong) like Jeff is arguing
> that
> > releasing 4.0 in 2 months isn't worth the effort of evaluating it,
> because
> > it's a big task and there's not enough stuff in 4.0 to make it
> worthwhile.
> >
> >
> More like "not enough stuff in 4.0 to make it worthwhile for the people I
> personally know to be willing and able to find the weird bugs".
>
>
> > If that is the case, I'm not quite sure how increasing the surface area
> of
> > changed code which needs to be vetted is going to make the process any
> > easier.
>
>
> It changes the interest level of at least some of the people able to
> properly test it from "not willing" to "willing".
>
> Totally possible that there exist people who are willing and able to find
> and fix those bugs, who just haven't committed to it in this thread. That's
> probably why Sankalp keeps asking who's actually willing to do the testing
> on June 2 - if nobody's going to commit to doing real testing on June 2,
> all we're doing is adding inconvenience to those of us who'd be willing to
> do it later in the year.
>

Re: Roadmap for 4.0

[Michael Shuler]

On 04/12/2018 10:57 AM, Michael Shuler wrote:
> Our current internal trunk test summary is attached. We're actually in a
> pretty good state on the baseline test suites, thanks to
> committers/reviewers.
> 
> Due to compute resource limitations and error noise on py2->py3 update,
> the following test suites are not being run internally on our CI system,
> so these should probably get first effort in the larger "fix all the
> tests" theme:
> 
> novnode-dtest (repetitive, so disabled atm)
> large-dtest (big instances, disabled on resources)
> upgrade-dtest (error noise and long test, disabled on resources)
> cqlsh-tests (py2->py3 work needed)
> 
> Just wanted to throw this out there for some context. There is certainly
> some work to be done, but I don't think we're in such dire straights as
> may be assumed from the conversation.

http://12.am/tmp/apache-trunk_test-summary_2018-04-12.png

It looks like attachments may get stripped from the list.

-- 
Michael

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Roadmap for 4.0

[Michael Shuler]

Our current internal trunk test summary is attached. We're actually in a
pretty good state on the baseline test suites, thanks to
committers/reviewers.

Due to compute resource limitations and error noise on py2->py3 update,
the following test suites are not being run internally on our CI system,
so these should probably get first effort in the larger "fix all the
tests" theme:

novnode-dtest (repetitive, so disabled atm)
large-dtest (big instances, disabled on resources)
upgrade-dtest (error noise and long test, disabled on resources)
cqlsh-tests (py2->py3 work needed)

Just wanted to throw this out there for some context. There is certainly
some work to be done, but I don't think we're in such dire straights as
may be assumed from the conversation.

-- 
Kind regards,
Michael


-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Roadmap for 4.0

[Eric Evans]

On Thu, Apr 12, 2018 at 4:07 AM, Sylvain Lebresne  wrote:
> I feel this discussion is starting to go in every directions and getting
> farther away from any decision/progress so I'll attempt to summarize what I
> hear, where I stand and *more importantly*, why.
>
> So as far as "what do we do for 4.0", I hear it boil down to 3 options:
> 1) we freeze June 1. It says nothing on when we do release but starting
> testing early, which also by extension limit the scope of what needs to be
> tested, give believability in an earlier and more stable release. Everyone
> seems to agree stability is good, and having no major release for too long
> run the risk of everyone outside our own bubble thinking the project is
> dead.
> 2) we decide on a freeze date now, but later than June 1 (the question is
> then "when?"). I'm listing this because there has been some explicit "+1 to
> freezing but not June 1" but I'll admit I'm not entirely sure of the
> reasoning behind this, and if there has been explicit argument for this,
> I've missed them.
> 3) we don't decide on a freeze date, 4.0 freeze is feature related. So we
> build a list of features that needs to be in to freeze (which can have some
> color for sure, some may be harder requirements than others). The best
> argument I've heard for this is Blake's one, which is that people won't
> truly test the release unless it is sexy (implying trunk isn't at all right
> now) and that it would therefore yield more stability.

Personally, a sexy Cassandra release is one that doesn't cost me an
inordinate amount of work and imperil my production clusters.  A sexy
Cassandra release is one with as few surprises as possible.  I can't
remember the last major release I thought was sexy.  Additionally, I'm
more likely to be able to spend time testing a new release, the more
that work can be shown to move us closer to implementing it (which
becomes more difficult as the delta increases).

> As should be clear, I'm a proponent of 1 for the reasoning I expressed on
> that point. I don't deny there is some logic behind the "it needs to be
> sexy to be tested" argument for 3, but it's simply imo more risky, and too
> much so. And this because:
> 1) I'm convinced it will delay the release *a lot* in practice compared to
> option 1 and I think we're underestimating the damage not releasing a major
> for years will do to the project.
> 2) it's all predicated on people doing unprecedented level of testing that
> they wouldn't do if we go with option 1, but there is no historical
> evidence to support the notion that it is a safe bet. If this doesn't
> happen, which we *have* to consider, then the project will be in a *much*
> worst state than with option 1. We'll have taken forever to release a less
> stable release.

+1

I think the way we address all those "sexy features" people want to
get out, is by working to increase the release cadence (without
increasing the burden on operators).  Release early, release often.


-- 
Eric Evans
john.eric.ev...@gmail.com

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Roadmap for 4.0

[Stefan Podkowinski]

Maybe people would have preferred to know early about potential
deadlines, before investing a lot of time into "pet ticket"
contributions? It's hard enough to make assumptions about if and when
contributions make it into a release, but with feature freeze deadlines
falling from the sky any time, it's getting a pure gamble and I wouldn't
be surprised to see especially companies becoming more reluctant to
sponsor work on larger contributions.

But I do agree with your statement to "make it clear what kind of
contributions are "preferred" at any given time". But really "any given
time", not just when it's convenient for us to have people help fix
testing, before they "may continue working on their pet tickets" again.


On 12.04.2018 11:37, Sylvain Lebresne wrote:
> On Thu, Apr 12, 2018 at 11:21 AM Sankalp Kohli 
> wrote:
> 
>> We can fix test after freezing if there are resources people are willing
>> to put. We need to gather support to see who can help with the 3 points I
>> have mentioned and when.
>>
> 
> Again though, without disagreeing with your points, those don't play into
> when we freeze. If we freeze tomorrow, even if it take 3 months to gather
> sufficient support for testing, there will still be less to test than if we
> push the freeze in 3 months and more things are committed in that
> time-frame. And in fact, the sooner we freeze, the sooner the project is
> making the statement that people that are willing to contribute to the
> project should now do so helping testing rather than continuing working on
> their pet ticket. And don't get me wrong, it's an open source project, we
> can't force anyone to do anything, so people may continue working on there
> pet ticket even after freeze. But we can at least, as a project, make it
> clear what kind of contributions are "preferred" at any given time.
> 
> 
>>
>> On Apr 12, 2018, at 02:13, Sylvain Lebresne  wrote:
>>

 I agree there's little point freezing if we can't even test the system
 properly.

>>>
>>> I'll mention that I really don't follow the logic of such claim. Why
>> can't
>>> we
>>> fix the testing of the system after freezing? In fact, isn't the whole
>>> point of freezing agreeing that it's high time to fix that? Isn't it
>> easier
>>> to fix tests (and focus on the testing environment if needs be) when
>>> things are frozen and code isn't changing from under you?
>>>
>>> PS: all the questions of this email are rhetorical.
>>>
>>> --
>>> Sylvain
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>> For additional commands, e-mail: dev-h...@cassandra.apache.org
>>
>>
> 

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Roadmap for 4.0

[Sankalp Kohli]

Here is what I think will happen if we don’t decide whether it will be 3 months 
or more to gather support. 

1. We freeze the features
2. No one works on testing it for months but I hope I am wrong 
3. Features get merged in trunk.
4. We now need to cut 4.1 or whatever is next as this has more features in this
4. Support comes for 4.1 due to features 
5. 4.0 loses its purpose 

Why not gather support nowsee when people can help and then decide on 
freeze. 
Also ask features which will motivate people to test. We cannot do all this 
after freeze. Let’s work on quantifying the date for freeze with these inputs.

I agree your point that with more features it will be harder to test but may be 
without those features no one will test it.

Just my opinion :) 



> On Apr 12, 2018, at 02:37, Sylvain Lebresne  wrote:
> 
> On Thu, Apr 12, 2018 at 11:21 AM Sankalp Kohli 
> wrote:
> 
>> We can fix test after freezing if there are resources people are willing
>> to put. We need to gather support to see who can help with the 3 points I
>> have mentioned and when.
>> 
> 
> Again though, without disagreeing with your points, those don't play into
> when we freeze. If we freeze tomorrow, even if it take 3 months to gather
> sufficient support for testing, there will still be less to test than if we
> push the freeze in 3 months and more things are committed in that
> time-frame. And in fact, the sooner we freeze, the sooner the project is
> making the statement that people that are willing to contribute to the
> project should now do so helping testing rather than continuing working on
> their pet ticket. And don't get me wrong, it's an open source project, we
> can't force anyone to do anything, so people may continue working on there
> pet ticket even after freeze. But we can at least, as a project, make it
> clear what kind of contributions are "preferred" at any given time.
> 
> 
>> 
>> On Apr 12, 2018, at 02:13, Sylvain Lebresne  wrote:
>> 
 
 I agree there's little point freezing if we can't even test the system
 properly.
 
>>> 
>>> I'll mention that I really don't follow the logic of such claim. Why
>> can't
>>> we
>>> fix the testing of the system after freezing? In fact, isn't the whole
>>> point of freezing agreeing that it's high time to fix that? Isn't it
>> easier
>>> to fix tests (and focus on the testing environment if needs be) when
>>> things are frozen and code isn't changing from under you?
>>> 
>>> PS: all the questions of this email are rhetorical.
>>> 
>>> --
>>> Sylvain
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>> For additional commands, e-mail: dev-h...@cassandra.apache.org
>> 
>> 

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Roadmap for 4.0

[Sylvain Lebresne]

On Thu, Apr 12, 2018 at 11:21 AM Sankalp Kohli 
wrote:

> We can fix test after freezing if there are resources people are willing
> to put. We need to gather support to see who can help with the 3 points I
> have mentioned and when.
>

Again though, without disagreeing with your points, those don't play into
when we freeze. If we freeze tomorrow, even if it take 3 months to gather
sufficient support for testing, there will still be less to test than if we
push the freeze in 3 months and more things are committed in that
time-frame. And in fact, the sooner we freeze, the sooner the project is
making the statement that people that are willing to contribute to the
project should now do so helping testing rather than continuing working on
their pet ticket. And don't get me wrong, it's an open source project, we
can't force anyone to do anything, so people may continue working on there
pet ticket even after freeze. But we can at least, as a project, make it
clear what kind of contributions are "preferred" at any given time.


>
> On Apr 12, 2018, at 02:13, Sylvain Lebresne  wrote:
>
> >>
> >> I agree there's little point freezing if we can't even test the system
> >> properly.
> >>
> >
> > I'll mention that I really don't follow the logic of such claim. Why
> can't
> > we
> > fix the testing of the system after freezing? In fact, isn't the whole
> > point of freezing agreeing that it's high time to fix that? Isn't it
> easier
> > to fix tests (and focus on the testing environment if needs be) when
> > things are frozen and code isn't changing from under you?
> >
> > PS: all the questions of this email are rhetorical.
> >
> > --
> > Sylvain
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: Roadmap for 4.0

[Sankalp Kohli]

Also I am +1 freezing anytime even today if someone can show what the plan is 
post freeze. May be I should start another thread to gather support for these 
items 

> On Apr 12, 2018, at 02:21, Sankalp Kohli  wrote:
> 
> We can fix test after freezing if there are resources people are willing to 
> put. We need to gather support to see who can help with the 3 points I have 
> mentioned and when. 
> 
> On Apr 12, 2018, at 02:13, Sylvain Lebresne  wrote:
> 
>>> 
>>> I agree there's little point freezing if we can't even test the system
>>> properly.
>>> 
>> 
>> I'll mention that I really don't follow the logic of such claim. Why can't
>> we
>> fix the testing of the system after freezing? In fact, isn't the whole
>> point of freezing agreeing that it's high time to fix that? Isn't it easier
>> to fix tests (and focus on the testing environment if needs be) when
>> things are frozen and code isn't changing from under you?
>> 
>> PS: all the questions of this email are rhetorical.
>> 
>> --
>> Sylvain

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Roadmap for 4.0

[Sankalp Kohli]

We can fix test after freezing if there are resources people are willing to 
put. We need to gather support to see who can help with the 3 points I have 
mentioned and when. 

On Apr 12, 2018, at 02:13, Sylvain Lebresne  wrote:

>> 
>> I agree there's little point freezing if we can't even test the system
>> properly.
>> 
> 
> I'll mention that I really don't follow the logic of such claim. Why can't
> we
> fix the testing of the system after freezing? In fact, isn't the whole
> point of freezing agreeing that it's high time to fix that? Isn't it easier
> to fix tests (and focus on the testing environment if needs be) when
> things are frozen and code isn't changing from under you?
> 
> PS: all the questions of this email are rhetorical.
> 
> --
> Sylvain

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Roadmap for 4.0

[Sylvain Lebresne]

>
>  I agree there's little point freezing if we can't even test the system
> properly.
>

I'll mention that I really don't follow the logic of such claim. Why can't
we
fix the testing of the system after freezing? In fact, isn't the whole
point of freezing agreeing that it's high time to fix that? Isn't it easier
to fix tests (and focus on the testing environment if needs be) when
things are frozen and code isn't changing from under you?

PS: all the questions of this email are rhetorical.

--
Sylvain

Re: Roadmap for 4.0

[Sylvain Lebresne]

I feel this discussion is starting to go in every directions and getting
farther away from any decision/progress so I'll attempt to summarize what I
hear, where I stand and *more importantly*, why.

So as far as "what do we do for 4.0", I hear it boil down to 3 options:
1) we freeze June 1. It says nothing on when we do release but starting
testing early, which also by extension limit the scope of what needs to be
tested, give believability in an earlier and more stable release. Everyone
seems to agree stability is good, and having no major release for too long
run the risk of everyone outside our own bubble thinking the project is
dead.
2) we decide on a freeze date now, but later than June 1 (the question is
then "when?"). I'm listing this because there has been some explicit "+1 to
freezing but not June 1" but I'll admit I'm not entirely sure of the
reasoning behind this, and if there has been explicit argument for this,
I've missed them.
3) we don't decide on a freeze date, 4.0 freeze is feature related. So we
build a list of features that needs to be in to freeze (which can have some
color for sure, some may be harder requirements than others). The best
argument I've heard for this is Blake's one, which is that people won't
truly test the release unless it is sexy (implying trunk isn't at all right
now) and that it would therefore yield more stability.

I'll acknowledge that some have expresses a preference for a freeze earlier
than June 1, but I think those are fine with June 1 as well so I think we
can fold this into option 1 to simplify. I also suspect option 2 was really
meant as option 3, but with some deadline to avoid slipping too much (but
without really changing the main intent), so maybe the initial question is
really just option 1 versus option 3 (and we decide the details of option 3
if we can agree this is what we want).

As should be clear, I'm a proponent of 1 for the reasoning I expressed on
that point. I don't deny there is some logic behind the "it needs to be
sexy to be tested" argument for 3, but it's simply imo more risky, and too
much so. And this because:
1) I'm convinced it will delay the release *a lot* in practice compared to
option 1 and I think we're underestimating the damage not releasing a major
for years will do to the project.
2) it's all predicated on people doing unprecedented level of testing that
they wouldn't do if we go with option 1, but there is no historical
evidence to support the notion that it is a safe bet. If this doesn't
happen, which we *have* to consider, then the project will be in a *much*
worst state than with option 1. We'll have taken forever to release a less
stable release.



--
Sylvain


On Thu, Apr 12, 2018 at 3:58 AM kurt greaves  wrote:

> >
> > I also don't see a place for minor releases as they exist today. It seems
> > like they are almost all the overhead of a major release with unnecessary
> > restrictions on what is possible.
>
> Yeah this, I've never heard of anything that we don't do in "minors", and
> it seems to me that everyone treats the minors as majors (hell, we're doing
> that here re 4.1). It seems to me that we should just have .
> versioning based on the way we treat minors.
>
> Who can sign up for testing the alpha1. I know Ben has shown interest.
>
> We can certainly do it, and we plan to do a lot of testing of 4.0, but I
> doubt we'll have anything ready to properly test it by June 1st.
> Another thing worth noting is dtests currently only partially run on
> CircleCI and it seems to me that Apple is the only one that actually runs
> them even there. It's going to take us a while to get the testing
> environment in a state that covers all bases post-freeze, and it's a good
> idea to have some commitment to doing that before we go ahead and freeze. I
> agree there's little point freezing if we can't even test the system
> properly.
>
> Not to mention the total lack of any kind of standard performance testing
> environment...
> ​
>

Re: Roadmap for 4.0

[kurt greaves]

>
> I also don't see a place for minor releases as they exist today. It seems
> like they are almost all the overhead of a major release with unnecessary
> restrictions on what is possible.

Yeah this, I've never heard of anything that we don't do in "minors", and
it seems to me that everyone treats the minors as majors (hell, we're doing
that here re 4.1). It seems to me that we should just have .
versioning based on the way we treat minors.

Who can sign up for testing the alpha1. I know Ben has shown interest.

We can certainly do it, and we plan to do a lot of testing of 4.0, but I
doubt we'll have anything ready to properly test it by June 1st.
Another thing worth noting is dtests currently only partially run on
CircleCI and it seems to me that Apple is the only one that actually runs
them even there. It's going to take us a while to get the testing
environment in a state that covers all bases post-freeze, and it's a good
idea to have some commitment to doing that before we go ahead and freeze. I
agree there's little point freezing if we can't even test the system
properly.

Not to mention the total lack of any kind of standard performance testing
environment...
​

Re: Roadmap for 4.0

[sankalp kohli]

If we have to decide on the date, we need to get confirmation on the
following which I mentioned earlier. We dont want to freeze things and no
one to make progress on

1. Who can sign up for fixing the tests(including upgrade tests). I don't
think we can release without tests passing. We can still cut alpa
2. Who can sign up for testing the alpha1. I know Ben has shown interest.
Who else can do it and when? We need to know this so we dont cut a release
and wait for people to start testing it.
3. Who has cycles to  fix the bugs which will come out of testing.

When to freeze should be decided when we know what timeline the
contributors come up with for the above three points.


Thanks,
Sankalp

On Wed, Apr 11, 2018 at 10:07 AM, Ariel Weisberg  wrote:

> Hi,
>
> What is the role of minor releases in Cassandra? I know that we have
> guarantees we make about minor releases that we don't make about major
> releases (is this summarized anywhere?), but is there anyone who actually
> thinks those guarantees are worth it vs having major releases on a shorter
> schedule?
>
> If we had major releases on a shorter schedule they would be smaller and
> stabilize faster and I think that has already been brought up.
>
> We don't do calendar based releases and I think that's a mistake. Maybe we
> don't cut the final version of a release based on the calendar, but I think
> we should release branch on a fixed cadence and release when ready.
>
> I also don't see a place for minor releases as they exist today. It seems
> like they are almost all the overhead of a major release with unnecessary
> restrictions on what is possible.
>
> Ariel
>
> On Wed, Apr 11, 2018, at 12:42 PM, Ben Bromhead wrote:
> > I'm on the side of freezing/branching earlier so we can really start the
> QA
> > process, but I do understand the concerns.
> >
> > As Kurt alluded to previously, given our current release velocity,
> 4.1/5.0
> > will likely be some time away after 4.0. If we manage to release two high
> > quality stable major versions back to back in a span of say 12 months,
> that
> > would actually be pretty awesome. The upgrade cycle will be a minor
> > complaint for just those major versions as the community settles on a
> > better cadence as we learn and go through it.
> >
> > Both Kurt and Jeff have advocated for key features that should be part of
> > the next major update which seems to be a major part of the desire to
> push
> > back against an early feature freeze. Interestingly most of these
> > contribute to the theme of the release (stability) even though they are
> > large changes. Particularly:
> >
> > https://issues.apache.org/jira/browse/CASSANDRA-9754  - "Birch" (changes
> > file format)
> > https://issues.apache.org/jira/browse/CASSANDRA-10540 -
> RangeAwareCompaction
> > https://issues.apache.org/jira/browse/CASSANDRA-13426 - Idemponent
> schema
> > changes
> >
> > We haven't seen any actual binding -1s yet on June 1, despite obvious
> > concerns and plenty of +1s
> >
> > Having said that, the above issues are the only ones people have
> identified
> > as:
> >
> >- the issues is a desired feature,
> >- the issue has clear progress on the tickets,
> >- the issues fits the theme of the release, and
> >- there is some concern about the issue making the June 1 deadline.
> >
> > I would invite those working on / reviewing these tickets to comment
> (Michael
> > Kjellman, Marcus Eriksson, Aleksey Yeschenko) specifically about
> inclusion
> > into 4.0 and June 1.
> >
> > If we want to delay the feature freeze for these, either a June 1 freeze
> > with a carve-out/exception for those three (they can get committed after
> > June 1 to 4.0) or a moderate push back of the freeze date (e.g. July 1)
> may
> > be an appropriate compromise.
> >
> > The carve-out/exception however is messy and opens a can of worms on the
> > proposed testing process for a 4.0 branch, but it is an option.
> >
> > I know this list doesn't include changes like transient replicas and
> > strongly consistent schema changes (previously mentioned), but the state
> of
> > the tickets is still in an architectural discussion, so I don't think its
> > worth making them blockers. Pluggable storage was also raised as
> something
> > worth including for 4.0, if someone working on those (Dikang, Blake?) had
> > an opinion on it regarding 4.0, impact on stability and a June 1
> deadline?
> >
> > Ben
> >
> >
> > On Wed, Apr 11, 2018 at 11:15 AM Blake Eggleston 
> > wrote:
> >
> > > I agree that not releasing semi-regularly is not good for the project.
> I
> > > think our habit of releasing half working software is much worse
> though.
> > > Our testing/stability story is not iron clad. I really think the bar
> for
> > > releasing 4.0 should be that the people in this thread are running the
> code
> > > in production, recommending their customers run it in production, or
> > > offering and supporting it as part of 

Re: Roadmap for 4.0

[Ariel Weisberg]

Hi,

What is the role of minor releases in Cassandra? I know that we have guarantees 
we make about minor releases that we don't make about major releases (is this 
summarized anywhere?), but is there anyone who actually thinks those guarantees 
are worth it vs having major releases on a shorter schedule?

If we had major releases on a shorter schedule they would be smaller and 
stabilize faster and I think that has already been brought up.

We don't do calendar based releases and I think that's a mistake. Maybe we 
don't cut the final version of a release based on the calendar, but I think we 
should release branch on a fixed cadence and release when ready.

I also don't see a place for minor releases as they exist today. It seems like 
they are almost all the overhead of a major release with unnecessary 
restrictions on what is possible.

Ariel

On Wed, Apr 11, 2018, at 12:42 PM, Ben Bromhead wrote:
> I'm on the side of freezing/branching earlier so we can really start the QA
> process, but I do understand the concerns.
> 
> As Kurt alluded to previously, given our current release velocity, 4.1/5.0
> will likely be some time away after 4.0. If we manage to release two high
> quality stable major versions back to back in a span of say 12 months, that
> would actually be pretty awesome. The upgrade cycle will be a minor
> complaint for just those major versions as the community settles on a
> better cadence as we learn and go through it.
> 
> Both Kurt and Jeff have advocated for key features that should be part of
> the next major update which seems to be a major part of the desire to push
> back against an early feature freeze. Interestingly most of these
> contribute to the theme of the release (stability) even though they are
> large changes. Particularly:
> 
> https://issues.apache.org/jira/browse/CASSANDRA-9754  - "Birch" (changes
> file format)
> https://issues.apache.org/jira/browse/CASSANDRA-10540 - RangeAwareCompaction
> https://issues.apache.org/jira/browse/CASSANDRA-13426 - Idemponent schema
> changes
> 
> We haven't seen any actual binding -1s yet on June 1, despite obvious
> concerns and plenty of +1s
> 
> Having said that, the above issues are the only ones people have identified
> as:
> 
>- the issues is a desired feature,
>- the issue has clear progress on the tickets,
>- the issues fits the theme of the release, and
>- there is some concern about the issue making the June 1 deadline.
> 
> I would invite those working on / reviewing these tickets to comment (Michael
> Kjellman, Marcus Eriksson, Aleksey Yeschenko) specifically about inclusion
> into 4.0 and June 1.
> 
> If we want to delay the feature freeze for these, either a June 1 freeze
> with a carve-out/exception for those three (they can get committed after
> June 1 to 4.0) or a moderate push back of the freeze date (e.g. July 1) may
> be an appropriate compromise.
> 
> The carve-out/exception however is messy and opens a can of worms on the
> proposed testing process for a 4.0 branch, but it is an option.
> 
> I know this list doesn't include changes like transient replicas and
> strongly consistent schema changes (previously mentioned), but the state of
> the tickets is still in an architectural discussion, so I don't think its
> worth making them blockers. Pluggable storage was also raised as something
> worth including for 4.0, if someone working on those (Dikang, Blake?) had
> an opinion on it regarding 4.0, impact on stability and a June 1 deadline?
> 
> Ben
> 
> 
> On Wed, Apr 11, 2018 at 11:15 AM Blake Eggleston 
> wrote:
> 
> > I agree that not releasing semi-regularly is not good for the project. I
> > think our habit of releasing half working software is much worse though.
> > Our testing/stability story is not iron clad. I really think the bar for
> > releasing 4.0 should be that the people in this thread are running the code
> > in production, recommending their customers run it in production, or
> > offering and supporting it as part of their cloud service.
> >
> > In that context, the argument for waiting for some features is less about
> > trying to do all the things and more about making 4.0 something worth the
> > time and expense of validating for production.
> >
> > On 4/11/18, 1:06 AM, "Sylvain Lebresne"  wrote:
> >
> > On Wed, Apr 11, 2018 at 12:35 AM Jeff Jirsa  wrote:
> >
> > > Seriously, what's the rush to branch? Do we all love merging so much
> > we
> > > want to do a few more times just for the sake of merging? If nothing
> > > diverges, there's nothing gained from the branch, and if it did
> > diverge, we
> > > add work for no real gain.
> > >
> >
> > Again, to me, the "rush" is that 1) there is tons of changes sitting in
> > trunk
> > that some user (_not all_, granted)[1], especially new ones, would
> > likely
> > benefits, and sooner for those is better than later, 2) we want to
> > 

Re: Roadmap for 4.0

[Jeff Jirsa]

One clarifying point, potentially trivia, but:

On Wed, Apr 11, 2018 at 9:42 AM, Ben Bromhead  wrote:

>
> We haven't seen any actual binding -1s yet on June 1, despite obvious
> concerns and plenty of +1s
>
>
Just to be clear: binding -1 votes are vetos for code changes, but they are
not vetos for procedural issues (
https://www.apache.org/foundation/voting.html ) .

(And at this point, I think it's clear that I'd be changing to -1 on the
June 1 date, but again, that's not a veto)

Re: Roadmap for 4.0

[Blake Eggleston]

I agree that not releasing semi-regularly is not good for the project. I think 
our habit of releasing half working software is much worse though. Our 
testing/stability story is not iron clad. I really think the bar for releasing 
4.0 should be that the people in this thread are running the code in 
production, recommending their customers run it in production, or offering and 
supporting it as part of their cloud service.

In that context, the argument for waiting for some features is less about 
trying to do all the things and more about making 4.0 something worth the time 
and expense of validating for production.

On 4/11/18, 1:06 AM, "Sylvain Lebresne"  wrote:

On Wed, Apr 11, 2018 at 12:35 AM Jeff Jirsa  wrote:

> Seriously, what's the rush to branch? Do we all love merging so much we
> want to do a few more times just for the sake of merging? If nothing
> diverges, there's nothing gained from the branch, and if it did diverge, 
we
> add work for no real gain.
>

Again, to me, the "rush" is that 1) there is tons of changes sitting in
trunk
that some user (_not all_, granted)[1], especially new ones, would likely
benefits, and sooner for those is better than later, 2) we want to favor
release stability and we *know* from years of experience (and frankly,
common
sense) that the bigger the release is, the harder it is to test it/ensuring
overall stability[2] and 3) not having major releases for years[3] is
impacting at least the perceived dynamism/liveness of the project to
external
actors (prospective new user come in mind here, but not only) and that's
simply bad for the project.

And having listed arguments for a soon freeze/not accumulating much more
before release, I'd like to reverse the question to you: what are the big
downsides of not doing that? Are we really that hung up on our own
developers
comfort that the annoyance of a bit more merging trumps the arguments above?

Anyway, the reasons above make me thing that it's better _for the project_
to freeze 4.0 soon, which doesn't exclude a "short" cycle for the following
major (where my definition of short here is something like 6-8 months), and
I'm happy to decide to make 4.0 a non-mandatory upgrade to whatever
comes next so that folks that prefer upgrading rarely can simply skip it and
go to the next one. Likely nobody will die if we wait more though, and it's
clear it will make a few people here more happy if we do, but I believe the
project as a whole will be a bit worst off, that's all.

--
Sylvain


[1]: I'll note that I don't deny upgrading is huge deal for some users, but
let's not skew arguments too much based on any one user interest. For many
users, upgrading even every year to get improvements is still considered as
a
good deal, and that's not counting new users for which it's super
frustrating
to miss out on improvements because we release major only every 2+ years.
[2]: I'll be clear: I will simply not buy anyone argument that "we'll do
so much better testing this time" on face value. Not anymore. If you want to
use that argument to sell having bigger releases, then prove it first. Let's
do reasonably sized 4.0 and 4.1/5.0 and prove that our testing/stability
story
is iron clad now, and then for 4.2/6.0 I'll be willing to agree that making
bigger release may not impact stability too much.
[3]: Conservative estimate, if we do care about stable releases as we all
seem
to, even if we were to freeze June 1, we will almost surely not release
before
October/November, which will be ~1.3 year since the last major release
(again,
that's the conservative estimate). If we push a few months to get some big
complex feature in, not only this push the freeze of those few months, but
will also require more testing, so we're looking at 2+ years, with a
possibly
large '+'.




>
> Beyond that, I still don't like June 1. Validating releases is hard. It
> sounds easy to drop a 4.1 and ask people to validate again, but it's a 
hell
> of a lot harder than it sounds. I'm not saying I'm a hard -1, but I really
> think it's too soon. 50'ish days is too short to draw a line in the sand,
> especially as people balance work obligations with Cassandra feature
> development.
>
>
>
>
> On Tue, Apr 10, 2018 at 3:18 PM, Nate McCall  wrote:
>
> > A lot of good points and everyone's input is really appreciated.
> >
> > So it sounds like we are building consensus towards June 1 for 4.0
> > branch point/feature freeze and the goal is stability. (No one has
> > come with a hard NO anyway).
> >
> > I want to reiterate Sylvain's point that we can do whatever we 

Re: Roadmap for 4.0

[Sylvain Lebresne]

On Wed, Apr 11, 2018 at 12:35 AM Jeff Jirsa  wrote:

> Seriously, what's the rush to branch? Do we all love merging so much we
> want to do a few more times just for the sake of merging? If nothing
> diverges, there's nothing gained from the branch, and if it did diverge, we
> add work for no real gain.
>

Again, to me, the "rush" is that 1) there is tons of changes sitting in
trunk
that some user (_not all_, granted)[1], especially new ones, would likely
benefits, and sooner for those is better than later, 2) we want to favor
release stability and we *know* from years of experience (and frankly,
common
sense) that the bigger the release is, the harder it is to test it/ensuring
overall stability[2] and 3) not having major releases for years[3] is
impacting at least the perceived dynamism/liveness of the project to
external
actors (prospective new user come in mind here, but not only) and that's
simply bad for the project.

And having listed arguments for a soon freeze/not accumulating much more
before release, I'd like to reverse the question to you: what are the big
downsides of not doing that? Are we really that hung up on our own
developers
comfort that the annoyance of a bit more merging trumps the arguments above?

Anyway, the reasons above make me thing that it's better _for the project_
to freeze 4.0 soon, which doesn't exclude a "short" cycle for the following
major (where my definition of short here is something like 6-8 months), and
I'm happy to decide to make 4.0 a non-mandatory upgrade to whatever
comes next so that folks that prefer upgrading rarely can simply skip it and
go to the next one. Likely nobody will die if we wait more though, and it's
clear it will make a few people here more happy if we do, but I believe the
project as a whole will be a bit worst off, that's all.

--
Sylvain


[1]: I'll note that I don't deny upgrading is huge deal for some users, but
let's not skew arguments too much based on any one user interest. For many
users, upgrading even every year to get improvements is still considered as
a
good deal, and that's not counting new users for which it's super
frustrating
to miss out on improvements because we release major only every 2+ years.
[2]: I'll be clear: I will simply not buy anyone argument that "we'll do
so much better testing this time" on face value. Not anymore. If you want to
use that argument to sell having bigger releases, then prove it first. Let's
do reasonably sized 4.0 and 4.1/5.0 and prove that our testing/stability
story
is iron clad now, and then for 4.2/6.0 I'll be willing to agree that making
bigger release may not impact stability too much.
[3]: Conservative estimate, if we do care about stable releases as we all
seem
to, even if we were to freeze June 1, we will almost surely not release
before
October/November, which will be ~1.3 year since the last major release
(again,
that's the conservative estimate). If we push a few months to get some big
complex feature in, not only this push the freeze of those few months, but
will also require more testing, so we're looking at 2+ years, with a
possibly
large '+'.




>
> Beyond that, I still don't like June 1. Validating releases is hard. It
> sounds easy to drop a 4.1 and ask people to validate again, but it's a hell
> of a lot harder than it sounds. I'm not saying I'm a hard -1, but I really
> think it's too soon. 50'ish days is too short to draw a line in the sand,
> especially as people balance work obligations with Cassandra feature
> development.
>
>
>
>
> On Tue, Apr 10, 2018 at 3:18 PM, Nate McCall  wrote:
>
> > A lot of good points and everyone's input is really appreciated.
> >
> > So it sounds like we are building consensus towards June 1 for 4.0
> > branch point/feature freeze and the goal is stability. (No one has
> > come with a hard NO anyway).
> >
> > I want to reiterate Sylvain's point that we can do whatever we want in
> > terms of dropping a new feature 4.1/5.0 (or whatev.) whenever we want.
> >
> > In thinking about this, what is stopping us from branching 4.0 a lot
> > sooner? Like now-ish? This will let folks start hacking on trunk with
> > new stuff, and things we've gotten close on can still go in 4.0
> > (Virtual tables). I guess I'm asking here if we want to disambiguate
> > "feature freeze" from "branch point?" I feel like this makes sense.
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> >
>

Re: Roadmap for 4.0

[kurt greaves]

Huh, I was writing my response for quite a while and getting distracted so
didn't see this, but yeah if I had a vote, this would obviously have it.

On 11 April 2018 at 03:03, Jeff Jirsa  wrote:

>
>
> --
> Jeff Jirsa
>
>
> On Apr 10, 2018, at 5:24 PM, Josh McKenzie  wrote:
>
> >>
> >> 50'ish days is too short to draw a line in the sand,
> >> especially as people balance work obligations with Cassandra feature
> >> development.
> >
> > What's a reasonable alternative / compromise for this? And what
> > non-disruptive-but-still-large patches are in flight that we would want
> to
> > delay the line in the sand for?
>
> I don’t care about non disruptive patches to be really honest. Nobody’s
> running trunk now, so it doesn’t matter to me if the patch landed 6 months
> ago or Jun 29, unless you can show me one person who’s ran a nontrivial
> multi-dc test cluster under real load that included correctness validation.
> Short of that, it’s untested, and the duration a patch has been in an
> untested repo is entirely irrelevant.
>
> If there’s really someone already testing trunk in a meaningful way (real
> workloads, and verifying correctness), and that person is really able to
> find and fix bugs, then tell me who it is and I’ll change my opinion (and
> I’m not even talking about thousand node clusters, just someone who’s
> actually using real data, like something upgraded from 2.1/3.0, and is
> checking to prove it matches expectations).
>
> Otherwise, when the time comes for real users to plan real upgrades to a
> hypothetical 4.1, they’ll have to do two sets of real, expensive, annoying
> testing - one for the stuff in 4.0 (chunk cache, file format changes,
> internode changes, etc), and a second for 4.0-4.1 changes for the invasive
> stuff I care about and you don’t want to wait for.
>
> I’d rather see us get all this stuff in and then spend real time testing
> and fixing in a 4-6 month alpha/beta phase (where real users can help,
> because its one real dedicated validation phase) than push this into two
> (probably inadequately tested) releases.
>
> But that’s just my opinion, and I’ll support it with my one vote, and I
> may get outvoted, but that’s what I’d rather see happen.
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: Roadmap for 4.0

[kurt greaves]

>
> In thinking about this, what is stopping us from branching 4.0 a lot
> sooner? Like now-ish? This will let folks start hacking on trunk with
> new stuff, and things we've gotten close on can still go in 4.0

Agree with Jeff here that this is not necessary. The branch point should be
the feature freeze point.

What's a reasonable alternative / compromise for this? And what
> non-disruptive-but-still-large patches are in flight that we would want to
> delay the line in the sand for?

Seeing as we are now back to where we started (because this was inevitable)
I'll start listing issues again. If we got this worked up over the release
back when I started this thread, June 1 probably would have been enough
warning for everyone to be happy. I started it the way I did so that we
avoided all the needless debate, but we went there anywhere.

Let's also not pretend that "we can drop 4.1 anytime", it will be exactly
as controversial as 4.0 and require as much time, discussion, validation,
and testing to get it out the window. I'd be expecting *at the earliest* that
4.1 landed in Q4 2019.
I also find the whole "only drop large features at the start of a branch"
curious. It's not like trunk has been verified in the meantime (ccm doesn't
count), and anything new that's been introduced should have tests
associated with it. As far as I'm aware, trunk is incredibly broken if you
consider the current testing environment, and we'll have to fix that prior
to releasing anything real. The point of a feature freeze is that you then
spend a lot of time validating, testing, and fixing after the freeze but
before you do the release. You're not in some great rush to release after
the freeze. The point of a feature freeze isn't to have all your features
in months/years before the freeze, it's just meant to stop you from
implementing more features while you fix existing issues.

I do understand the reluctance though, based on the history of the project.
Tick-tock consisted of almost no follow up testing and validation, and 3.0
wasn't much better - but I think it's still reasonable to give a proper
validation/testing strategy a chance, testing in our own environments and
actually making all the utests+dtests work.

Anyway, back to things which I think should land in 4.0 but have been in
the works for a long time:

RangeAwareCompaction - CASSANDRA-10540

We've seen *many* use cases that could benefit from this, and it's also
good for fixing some of the serious problems with vnodes, repairs, and
streaming.
Despite the lack of action I don't think it's far from being finished, but
with a June 1 deadline it's probably unlikely.

Large partition improvements - CASSANDRA-9754

I know this is a much awaited feature for a fair few users, but mostly it
will make operator life a lot easier. I look forward to the day where a
user can't kill their cluster by reading a few large partitions.

Idempotent DDL - CASSANDRA-13426

This will be handy but is really more important for CASSANDRA-10699
 (which probably
won't make it into 4.0).

More importantly, as I already noted, there's a large backlog of patches to
review that we simply won't get to before June 1st (this includes some
fairly large patches as well, like the pluggable storage refactors).


Side note June 1st puts us almost 2 years from our last feature release
(3.10, Oct 2016) - not "almost a year"/a year/around a year.

On 10 April 2018 at 22:34, Jeff Jirsa  wrote:

> Seriously, what's the rush to branch? Do we all love merging so much we
> want to do a few more times just for the sake of merging? If nothing
> diverges, there's nothing gained from the branch, and if it did diverge, we
> add work for no real gain.
>
> Beyond that, I still don't like June 1. Validating releases is hard. It
> sounds easy to drop a 4.1 and ask people to validate again, but it's a hell
> of a lot harder than it sounds. I'm not saying I'm a hard -1, but I really
> think it's too soon. 50'ish days is too short to draw a line in the sand,
> especially as people balance work obligations with Cassandra feature
> development.
>
>
>
>
> On Tue, Apr 10, 2018 at 3:18 PM, Nate McCall  wrote:
>
> > A lot of good points and everyone's input is really appreciated.
> >
> > So it sounds like we are building consensus towards June 1 for 4.0
> > branch point/feature freeze and the goal is stability. (No one has
> > come with a hard NO anyway).
> >
> > I want to reiterate Sylvain's point that we can do whatever we want in
> > terms of dropping a new feature 4.1/5.0 (or whatev.) whenever we want.
> >
> > In thinking about this, what is stopping us from branching 4.0 a lot
> > sooner? Like now-ish? This will let folks start hacking on trunk with
> > new stuff, and things 

Re: Roadmap for 4.0

[Jeff Jirsa]

-- 
Jeff Jirsa


On Apr 10, 2018, at 5:24 PM, Josh McKenzie  wrote:

>> 
>> 50'ish days is too short to draw a line in the sand,
>> especially as people balance work obligations with Cassandra feature
>> development.
> 
> What's a reasonable alternative / compromise for this? And what
> non-disruptive-but-still-large patches are in flight that we would want to
> delay the line in the sand for?

I don’t care about non disruptive patches to be really honest. Nobody’s running 
trunk now, so it doesn’t matter to me if the patch landed 6 months ago or Jun 
29, unless you can show me one person who’s ran a nontrivial multi-dc test 
cluster under real load that included correctness validation. Short of that, 
it’s untested, and the duration a patch has been in an untested repo is 
entirely irrelevant.

If there’s really someone already testing trunk in a meaningful way (real 
workloads, and verifying correctness), and that person is really able to find 
and fix bugs, then tell me who it is and I’ll change my opinion (and  I’m not 
even talking about thousand node clusters, just someone who’s actually using 
real data, like something upgraded from 2.1/3.0, and is checking to prove it 
matches expectations). 

Otherwise, when the time comes for real users to plan real upgrades to a 
hypothetical 4.1, they’ll have to do two sets of real, expensive, annoying 
testing - one for the stuff in 4.0 (chunk cache, file format changes, internode 
changes, etc), and a second for 4.0-4.1 changes for the invasive stuff I care 
about and you don’t want to wait for.

I’d rather see us get all this stuff in and then spend real time testing and 
fixing in a 4-6 month alpha/beta phase (where real users can help, because its 
one real dedicated validation phase) than push this into two (probably 
inadequately tested) releases.

But that’s just my opinion, and I’ll support it with my one vote, and I may get 
outvoted, but that’s what I’d rather see happen.


-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Roadmap for 4.0

[Sankalp Kohli]

Also in this time we should try to see who can do 3 things I mentioned in my 
earlier email 

> On Apr 10, 2018, at 17:50, Sankalp Kohli  wrote:
> 
> I think moving it to August/Sept will be better 
> 
> On Apr 10, 2018, at 17:24, Josh McKenzie  wrote:
> 
>>> 
>>> 50'ish days is too short to draw a line in the sand,
>>> especially as people balance work obligations with Cassandra feature
>>> development.
>> 
>> What's a reasonable alternative / compromise for this? And what
>> non-disruptive-but-still-large patches are in flight that we would want to
>> delay the line in the sand for?
>> 
>>> On Tue, Apr 10, 2018 at 6:34 PM, Jeff Jirsa  wrote:
>>> 
>>> Seriously, what's the rush to branch? Do we all love merging so much we
>>> want to do a few more times just for the sake of merging? If nothing
>>> diverges, there's nothing gained from the branch, and if it did diverge, we
>>> add work for no real gain.
>>> 
>>> Beyond that, I still don't like June 1. Validating releases is hard. It
>>> sounds easy to drop a 4.1 and ask people to validate again, but it's a hell
>>> of a lot harder than it sounds. I'm not saying I'm a hard -1, but I really
>>> think it's too soon. 50'ish days is too short to draw a line in the sand,
>>> especially as people balance work obligations with Cassandra feature
>>> development.
>>> 
>>> 
>>> 
>>> 
 On Tue, Apr 10, 2018 at 3:18 PM, Nate McCall  wrote:
 
 A lot of good points and everyone's input is really appreciated.
 
 So it sounds like we are building consensus towards June 1 for 4.0
 branch point/feature freeze and the goal is stability. (No one has
 come with a hard NO anyway).
 
 I want to reiterate Sylvain's point that we can do whatever we want in
 terms of dropping a new feature 4.1/5.0 (or whatev.) whenever we want.
 
 In thinking about this, what is stopping us from branching 4.0 a lot
 sooner? Like now-ish? This will let folks start hacking on trunk with
 new stuff, and things we've gotten close on can still go in 4.0
 (Virtual tables). I guess I'm asking here if we want to disambiguate
 "feature freeze" from "branch point?" I feel like this makes sense.
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
 For additional commands, e-mail: dev-h...@cassandra.apache.org
 
 
>>> 

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Roadmap for 4.0

[Sankalp Kohli]

I think moving it to August/Sept will be better 

On Apr 10, 2018, at 17:24, Josh McKenzie  wrote:

>> 
>> 50'ish days is too short to draw a line in the sand,
>> especially as people balance work obligations with Cassandra feature
>> development.
> 
> What's a reasonable alternative / compromise for this? And what
> non-disruptive-but-still-large patches are in flight that we would want to
> delay the line in the sand for?
> 
>> On Tue, Apr 10, 2018 at 6:34 PM, Jeff Jirsa  wrote:
>> 
>> Seriously, what's the rush to branch? Do we all love merging so much we
>> want to do a few more times just for the sake of merging? If nothing
>> diverges, there's nothing gained from the branch, and if it did diverge, we
>> add work for no real gain.
>> 
>> Beyond that, I still don't like June 1. Validating releases is hard. It
>> sounds easy to drop a 4.1 and ask people to validate again, but it's a hell
>> of a lot harder than it sounds. I'm not saying I'm a hard -1, but I really
>> think it's too soon. 50'ish days is too short to draw a line in the sand,
>> especially as people balance work obligations with Cassandra feature
>> development.
>> 
>> 
>> 
>> 
>>> On Tue, Apr 10, 2018 at 3:18 PM, Nate McCall  wrote:
>>> 
>>> A lot of good points and everyone's input is really appreciated.
>>> 
>>> So it sounds like we are building consensus towards June 1 for 4.0
>>> branch point/feature freeze and the goal is stability. (No one has
>>> come with a hard NO anyway).
>>> 
>>> I want to reiterate Sylvain's point that we can do whatever we want in
>>> terms of dropping a new feature 4.1/5.0 (or whatev.) whenever we want.
>>> 
>>> In thinking about this, what is stopping us from branching 4.0 a lot
>>> sooner? Like now-ish? This will let folks start hacking on trunk with
>>> new stuff, and things we've gotten close on can still go in 4.0
>>> (Virtual tables). I guess I'm asking here if we want to disambiguate
>>> "feature freeze" from "branch point?" I feel like this makes sense.
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>>> For additional commands, e-mail: dev-h...@cassandra.apache.org
>>> 
>>> 
>> 

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Roadmap for 4.0

[Jeff Jirsa]

Seriously, what's the rush to branch? Do we all love merging so much we
want to do a few more times just for the sake of merging? If nothing
diverges, there's nothing gained from the branch, and if it did diverge, we
add work for no real gain.

Beyond that, I still don't like June 1. Validating releases is hard. It
sounds easy to drop a 4.1 and ask people to validate again, but it's a hell
of a lot harder than it sounds. I'm not saying I'm a hard -1, but I really
think it's too soon. 50'ish days is too short to draw a line in the sand,
especially as people balance work obligations with Cassandra feature
development.




On Tue, Apr 10, 2018 at 3:18 PM, Nate McCall  wrote:

> A lot of good points and everyone's input is really appreciated.
>
> So it sounds like we are building consensus towards June 1 for 4.0
> branch point/feature freeze and the goal is stability. (No one has
> come with a hard NO anyway).
>
> I want to reiterate Sylvain's point that we can do whatever we want in
> terms of dropping a new feature 4.1/5.0 (or whatev.) whenever we want.
>
> In thinking about this, what is stopping us from branching 4.0 a lot
> sooner? Like now-ish? This will let folks start hacking on trunk with
> new stuff, and things we've gotten close on can still go in 4.0
> (Virtual tables). I guess I'm asking here if we want to disambiguate
> "feature freeze" from "branch point?" I feel like this makes sense.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: Roadmap for 4.0

[Nate McCall]

A lot of good points and everyone's input is really appreciated.

So it sounds like we are building consensus towards June 1 for 4.0
branch point/feature freeze and the goal is stability. (No one has
come with a hard NO anyway).

I want to reiterate Sylvain's point that we can do whatever we want in
terms of dropping a new feature 4.1/5.0 (or whatev.) whenever we want.

In thinking about this, what is stopping us from branching 4.0 a lot
sooner? Like now-ish? This will let folks start hacking on trunk with
new stuff, and things we've gotten close on can still go in 4.0
(Virtual tables). I guess I'm asking here if we want to disambiguate
"feature freeze" from "branch point?" I feel like this makes sense.

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Roadmap for 4.0

[sankalp kohli]

Hi,
I am +1 on freezing features at some point.

Here are my thoughts
1. The reason it took 1.5 years b/w 3.0 and 4.0 is because 3.0 was
released(not cut) too early. There were so many critical bugs in it for
months after the release. Most people have just finished or about to
upgrade to 3.0. (Please correct me if my understanding is wrong)
2. We should cut(not release) the branch when some of it is true. I am not
sure which ones are must in this list and we should discuss.
 a. Huge change log(This is true). The change log is also not growing very
quickly which is bad for project but beneficial for this.
 b. Which people are willing to start testing the next day it is cut.
 c. Do we have resources to fix the critical bugs. What if we find bugs and
no one is available to fix/review them. Can someone sign up for this.
 d. Do we have resources to fix all Dtest including upgrade tests.


Thanks,
Sankalp

On Tue, Apr 10, 2018 at 9:55 AM, Eric Evans 
wrote:

> On Mon, Apr 9, 2018 at 3:56 PM, Jonathan Haddad  wrote:
>
> [ ... ]
>
> > If they're not close to finished now why even consider them for
> > the 4.0 release?  They're so core they should be merged into trunk at the
> > beginning of the cycle for the follow up release in order to get as much
> > exposure as possible.
>
> This sounds right to me.  Bigger, destabilizing changes should land at
> the beginning of the cycle; Setting up a mad rush at the end of a
> release cycle does not yield favorable results (we've done this, we
> know).
>
> > On Mon, Apr 9, 2018 at 1:46 PM Nate McCall  wrote:
> >
> >> > I'd like to see pluggable storage and transient replica tickets land,
> for
> >> > starters.
> >>
> >> I think both those features are, frankly, necessary for our future. On
> >> the other hand, they both have the following risks:
> >> 1. core behavioral changes
> >> 2. require changing a (relatively) large surface area of code
> >>
> >> We can aim to de-risk 4.0 by focusing on what we have now which is
> >> solid repair and NIO internode (maybe we move the 4.0 branch timeline
> >> up?), aiming for a 4.1 following soon-ish.
> >>
> >> Or we can go in eyes open and agree on a larger footprint 4.0.
> >>
> >> I'm on the fence, tbh (can't emphasize enough how big both those
> >> features will be). I just want everyone to know what we are getting
> >> into and that we are potentially impacting our goals of "stable" ==
> >> "exciting."
>
> Unfortunately, when stability suffers things get "exciting" for all
> sorts of unintended reasons.  I'm personally not umm, excited, by that
> prospect.
>
>
> --
> Eric Evans
> john.eric.ev...@gmail.com
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: Roadmap for 4.0

[Eric Evans]

On Mon, Apr 9, 2018 at 3:56 PM, Jonathan Haddad  wrote:

[ ... ]

> If they're not close to finished now why even consider them for
> the 4.0 release?  They're so core they should be merged into trunk at the
> beginning of the cycle for the follow up release in order to get as much
> exposure as possible.

This sounds right to me.  Bigger, destabilizing changes should land at
the beginning of the cycle; Setting up a mad rush at the end of a
release cycle does not yield favorable results (we've done this, we
know).

> On Mon, Apr 9, 2018 at 1:46 PM Nate McCall  wrote:
>
>> > I'd like to see pluggable storage and transient replica tickets land, for
>> > starters.
>>
>> I think both those features are, frankly, necessary for our future. On
>> the other hand, they both have the following risks:
>> 1. core behavioral changes
>> 2. require changing a (relatively) large surface area of code
>>
>> We can aim to de-risk 4.0 by focusing on what we have now which is
>> solid repair and NIO internode (maybe we move the 4.0 branch timeline
>> up?), aiming for a 4.1 following soon-ish.
>>
>> Or we can go in eyes open and agree on a larger footprint 4.0.
>>
>> I'm on the fence, tbh (can't emphasize enough how big both those
>> features will be). I just want everyone to know what we are getting
>> into and that we are potentially impacting our goals of "stable" ==
>> "exciting."

Unfortunately, when stability suffers things get "exciting" for all
sorts of unintended reasons.  I'm personally not umm, excited, by that
prospect.


-- 
Eric Evans
john.eric.ev...@gmail.com

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Roadmap for 4.0

[DuyHai Doan]

> I'd like to see pluggable storage and transient replica tickets land, for
> starters.

So after all the fuss and scandal about incremental repair and MV not
stable and being downgraded to experimental, I would like to suggest that
those new features are also flagged as experimental for some time for the
community to use them extensively before being promoted as first class
features

Thoughts ?

On Mon, Apr 9, 2018 at 11:36 PM, Jeff Beck  wrote:

> If you are going to make 4 bigger as long as we call out that 3.11.x (or
> whatever) will keep getting patches for stability only that's all that's
> needed. We haven't gone to 3.x releases many places yet as we wait for a
> release that will be stable longer. Knowing 4 is going to be bigger I
> wouldn't want to see more feature releases in 3.x
>
> I wouldn't want to greatly slow features down if they require a major
> release and 5 is too far off.
>
> Jeff
>
> On Mon, Apr 9, 2018, 4:05 PM Josh McKenzie  wrote:
>
> > >
> > > If they're not close to finished now why even consider them for the 4.0
> > > release?
> >
> > Merging in major features at the end of a release cycle is not the path
> to
> > stability, imo.
> >
> > On Mon, Apr 9, 2018 at 4:56 PM, Jonathan Haddad 
> wrote:
> >
> > > There's always more stuff to try to shoehorn in.  We've done big
> releases
> > > with all the things, it never was stable.  We tried the opposite end of
> > the
> > > spectrum, release every month, that really wasn't great either.
> > Personally
> > > I'd be OK with stopping new features by the end of this month and
> aiming
> > to
> > > release a stable 4.0 when we agree we would be comfortable dogfooding
> it
> > in
> > > production at our own companies (in a few months), and aim for 4.1 (or
> > 5.0
> > > I don't want to bikeshed the version) for pluggable storage and
> transient
> > > replicas.  If they're not close to finished now why even consider them
> > for
> > > the 4.0 release?  They're so core they should be merged into trunk at
> the
> > > beginning of the cycle for the follow up release in order to get as
> much
> > > exposure as possible.
> > >
> > > Jon
> > >
> > > On Mon, Apr 9, 2018 at 1:46 PM Nate McCall  wrote:
> > >
> > > > > I'd like to see pluggable storage and transient replica tickets
> land,
> > > for
> > > > > starters.
> > > >
> > > > I think both those features are, frankly, necessary for our future.
> On
> > > > the other hand, they both have the following risks:
> > > > 1. core behavioral changes
> > > > 2. require changing a (relatively) large surface area of code
> > > >
> > > > We can aim to de-risk 4.0 by focusing on what we have now which is
> > > > solid repair and NIO internode (maybe we move the 4.0 branch timeline
> > > > up?), aiming for a 4.1 following soon-ish.
> > > >
> > > > Or we can go in eyes open and agree on a larger footprint 4.0.
> > > >
> > > > I'm on the fence, tbh (can't emphasize enough how big both those
> > > > features will be). I just want everyone to know what we are getting
> > > > into and that we are potentially impacting our goals of "stable" ==
> > > > "exciting."
> > > >
> > > > 
> -
> > > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > > > For additional commands, e-mail: dev-h...@cassandra.apache.org
> > > >
> > > >
> > >
> >
>

Re: Roadmap for 4.0

[Jeff Beck]

If you are going to make 4 bigger as long as we call out that 3.11.x (or
whatever) will keep getting patches for stability only that's all that's
needed. We haven't gone to 3.x releases many places yet as we wait for a
release that will be stable longer. Knowing 4 is going to be bigger I
wouldn't want to see more feature releases in 3.x

I wouldn't want to greatly slow features down if they require a major
release and 5 is too far off.

Jeff

On Mon, Apr 9, 2018, 4:05 PM Josh McKenzie  wrote:

> >
> > If they're not close to finished now why even consider them for the 4.0
> > release?
>
> Merging in major features at the end of a release cycle is not the path to
> stability, imo.
>
> On Mon, Apr 9, 2018 at 4:56 PM, Jonathan Haddad  wrote:
>
> > There's always more stuff to try to shoehorn in.  We've done big releases
> > with all the things, it never was stable.  We tried the opposite end of
> the
> > spectrum, release every month, that really wasn't great either.
> Personally
> > I'd be OK with stopping new features by the end of this month and aiming
> to
> > release a stable 4.0 when we agree we would be comfortable dogfooding it
> in
> > production at our own companies (in a few months), and aim for 4.1 (or
> 5.0
> > I don't want to bikeshed the version) for pluggable storage and transient
> > replicas.  If they're not close to finished now why even consider them
> for
> > the 4.0 release?  They're so core they should be merged into trunk at the
> > beginning of the cycle for the follow up release in order to get as much
> > exposure as possible.
> >
> > Jon
> >
> > On Mon, Apr 9, 2018 at 1:46 PM Nate McCall  wrote:
> >
> > > > I'd like to see pluggable storage and transient replica tickets land,
> > for
> > > > starters.
> > >
> > > I think both those features are, frankly, necessary for our future. On
> > > the other hand, they both have the following risks:
> > > 1. core behavioral changes
> > > 2. require changing a (relatively) large surface area of code
> > >
> > > We can aim to de-risk 4.0 by focusing on what we have now which is
> > > solid repair and NIO internode (maybe we move the 4.0 branch timeline
> > > up?), aiming for a 4.1 following soon-ish.
> > >
> > > Or we can go in eyes open and agree on a larger footprint 4.0.
> > >
> > > I'm on the fence, tbh (can't emphasize enough how big both those
> > > features will be). I just want everyone to know what we are getting
> > > into and that we are potentially impacting our goals of "stable" ==
> > > "exciting."
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > > For additional commands, e-mail: dev-h...@cassandra.apache.org
> > >
> > >
> >
>

Re: Roadmap for 4.0

[Josh McKenzie]

>
> If they're not close to finished now why even consider them for the 4.0
> release?

Merging in major features at the end of a release cycle is not the path to
stability, imo.

On Mon, Apr 9, 2018 at 4:56 PM, Jonathan Haddad  wrote:

> There's always more stuff to try to shoehorn in.  We've done big releases
> with all the things, it never was stable.  We tried the opposite end of the
> spectrum, release every month, that really wasn't great either.  Personally
> I'd be OK with stopping new features by the end of this month and aiming to
> release a stable 4.0 when we agree we would be comfortable dogfooding it in
> production at our own companies (in a few months), and aim for 4.1 (or 5.0
> I don't want to bikeshed the version) for pluggable storage and transient
> replicas.  If they're not close to finished now why even consider them for
> the 4.0 release?  They're so core they should be merged into trunk at the
> beginning of the cycle for the follow up release in order to get as much
> exposure as possible.
>
> Jon
>
> On Mon, Apr 9, 2018 at 1:46 PM Nate McCall  wrote:
>
> > > I'd like to see pluggable storage and transient replica tickets land,
> for
> > > starters.
> >
> > I think both those features are, frankly, necessary for our future. On
> > the other hand, they both have the following risks:
> > 1. core behavioral changes
> > 2. require changing a (relatively) large surface area of code
> >
> > We can aim to de-risk 4.0 by focusing on what we have now which is
> > solid repair and NIO internode (maybe we move the 4.0 branch timeline
> > up?), aiming for a 4.1 following soon-ish.
> >
> > Or we can go in eyes open and agree on a larger footprint 4.0.
> >
> > I'm on the fence, tbh (can't emphasize enough how big both those
> > features will be). I just want everyone to know what we are getting
> > into and that we are potentially impacting our goals of "stable" ==
> > "exciting."
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> >
>

Re: Roadmap for 4.0

[J. D. Jordan]

Myself I would put my non-binding vote for the stable side. I think those are 
both important, but maybe they are best as some of the first things to go into 
“release after 4.0”, not the last things to go into 4.0.
Maybe they would also prove as some incentive to get the next release out the 
door a little quicker than 4.0 will end up being ;).

-Jeremiah

On Apr 9, 2018, at 4:46 PM, Nate McCall  wrote:

>> I'd like to see pluggable storage and transient replica tickets land, for
>> starters.
> 
> I think both those features are, frankly, necessary for our future. On
> the other hand, they both have the following risks:
> 1. core behavioral changes
> 2. require changing a (relatively) large surface area of code
> 
> We can aim to de-risk 4.0 by focusing on what we have now which is
> solid repair and NIO internode (maybe we move the 4.0 branch timeline
> up?), aiming for a 4.1 following soon-ish.
> 
> Or we can go in eyes open and agree on a larger footprint 4.0.
> 
> I'm on the fence, tbh (can't emphasize enough how big both those
> features will be). I just want everyone to know what we are getting
> into and that we are potentially impacting our goals of "stable" ==
> "exciting."
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
> 

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Roadmap for 4.0

[Nate McCall]

> I'd like to see pluggable storage and transient replica tickets land, for
> starters.

I think both those features are, frankly, necessary for our future. On
the other hand, they both have the following risks:
1. core behavioral changes
2. require changing a (relatively) large surface area of code

We can aim to de-risk 4.0 by focusing on what we have now which is
solid repair and NIO internode (maybe we move the 4.0 branch timeline
up?), aiming for a 4.1 following soon-ish.

Or we can go in eyes open and agree on a larger footprint 4.0.

I'm on the fence, tbh (can't emphasize enough how big both those
features will be). I just want everyone to know what we are getting
into and that we are potentially impacting our goals of "stable" ==
"exciting."

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Roadmap for 4.0

[Jeff Jirsa]

I'd like to see pluggable storage and transient replica tickets land, for
starters.

On Mon, Apr 9, 2018 at 10:17 AM, Ben Bromhead  wrote:

> >
> > For those wanting to delay, are we just dancing around inclusion of
> > some pet features? This is fine, I just think we need to communicate
> > what we are after if so.
> >
>
> +1 Some solid examples of tickets that won't make it with the proposed
> timeline and a proposed alternative would help.
>
> Otherwise if no one chimes in I would propose sticking with June 1.
>
>
>
>
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> > --
> Ben Bromhead
> CTO | Instaclustr 
> +1 650 284 9692
> Reliability at Scale
> Cassandra, Spark, Elasticsearch on AWS, Azure, GCP and Softlayer
>

Re: Roadmap for 4.0

[Ben Bromhead]

>
> For those wanting to delay, are we just dancing around inclusion of
> some pet features? This is fine, I just think we need to communicate
> what we are after if so.
>

+1 Some solid examples of tickets that won't make it with the proposed
timeline and a proposed alternative would help.

Otherwise if no one chimes in I would propose sticking with June 1.




>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
> --
Ben Bromhead
CTO | Instaclustr 
+1 650 284 9692
Reliability at Scale
Cassandra, Spark, Elasticsearch on AWS, Azure, GCP and Softlayer

RE: Roadmap for 4.0

[Steinmaurer, Thomas]

IMHO, stability and manageability (want to have the old (2.1) full repair 
behavior back , yes I followed the repair scheduling thread here) should be 
the top priority before adding any new CQL enhancements or whatever. 
Manageability improvements even treated for backports into 3.11.x, as it seems 
4.0 is a long way ahead for production usage.

Just my 2 EUR cents. 

Thanks,
Thomas


-Original Message-
From: Nate McCall [mailto:zznat...@gmail.com]
Sent: Freitag, 06. April 2018 06:01
To: dev <dev@cassandra.apache.org>
Subject: Re: Roadmap for 4.0

>>
>> So long as non-user-visible improvements, including big ones, can
>> still go in 4.0 at that stage, I’m all for it.
>
>
> My understanding is that after June 1st the 4.0 branch would be
> created and would be bugfix only. It's not really a feature freeze if
> you allow improvements after that, which is why they'd instead go to trunk.
>
> I'm also on the "too soon" train so pushing it back to August or so is
> desirable to me.
>

For those wanting to delay, are we just dancing around inclusion of some pet 
features? This is fine, I just think we need to communicate what we are after 
if so.

We can do two things:
1. Lay our cards on the table about what we want included in 4.0 and work to 
get those in 2. Agree to keep June 1 follow up a lot quicker with a 4.1

I do want to remind everyone though that each new feature is at odds with our 
stability goals for 4.0.

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

The contents of this e-mail are intended for the named addressee only. It 
contains information that may be confidential. Unless you are the named 
addressee or an authorized designee, you may not copy or use it, or disclose it 
to anyone else. If you received it in error please notify us immediately and 
then destroy it. Dynatrace Austria GmbH (registration number FN 91482h) is a 
company registered in Linz whose registered office is at 4040 Linz, Austria, 
Freistädterstraße 313

Re: Roadmap for 4.0

[kurt greaves]

>
> Lay our cards on the table about what we want included in 4.0 and work to
> get those in

Are you saying we're back to where we started?  

For those wanting to delay, are we just dancing around inclusion of
> some pet features? This is fine, I just think we need to communicate
> what we are after if so.


Mostly. There are numerous large tickets that have been being worked on *for
a long time*, and have been rumoured to be nearing completion for some
time, which would be beneficial for everyone. They aren't my pet tickets
but I'd sure like to see them finally land (see: Apple tickets).

But there's more to it than that. We've also got tickets we'd like to get
committed and It's an incredibly slow process to get anyone to review your
tickets (and commit) if you're not in the club, so to speak. There's 148
tickets that are Patch available ATM, 89 of which have no reviewer. I think
it's highly unlikely a lot of these will get committed before June 1st, and
I don't think that's fair on a lot of the people who have been trying to
contribute their patches for months, potentially years in some cases, but
have been stuck waiting on feedback/reviewers/committers.

Sure it's not the end of the world, but I know from experience that it's
damn discouraging. Even missing a minor release for a bug fix because of
this is annoying as hell.

I do want to remind everyone though that each new feature is at odds
> with our stability goals for 4.0.

With all the refactoring that's already gone into 4.0 and our current lack
of testing I think we're fighting an uphill battle here anyway. Adding a
few more metres is the least of our worries IMO. The
alpha/verification/testing period is already going to be a very long one.


On 6 April 2018 at 04:01, Nate McCall  wrote:

> >>
> >> So long as non-user-visible improvements, including big ones, can still
> go
> >> in 4.0 at that stage, I’m all for it.
> >
> >
> > My understanding is that after June 1st the 4.0 branch would be created
> and
> > would be bugfix only. It's not really a feature freeze if you allow
> > improvements after that, which is why they'd instead go to trunk.
> >
> > I'm also on the "too soon" train so pushing it back to August or so is
> > desirable to me.
> >
>
> For those wanting to delay, are we just dancing around inclusion of
> some pet features? This is fine, I just think we need to communicate
> what we are after if so.
>
> We can do two things:
> 1. Lay our cards on the table about what we want included in 4.0 and
> work to get those in
> 2. Agree to keep June 1 follow up a lot quicker with a 4.1
>
> I do want to remind everyone though that each new feature is at odds
> with our stability goals for 4.0.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: Roadmap for 4.0

[Nate McCall]

>>
>> So long as non-user-visible improvements, including big ones, can still go
>> in 4.0 at that stage, I’m all for it.
>
>
> My understanding is that after June 1st the 4.0 branch would be created and
> would be bugfix only. It's not really a feature freeze if you allow
> improvements after that, which is why they'd instead go to trunk.
>
> I'm also on the "too soon" train so pushing it back to August or so is
> desirable to me.
>

For those wanting to delay, are we just dancing around inclusion of
some pet features? This is fine, I just think we need to communicate
what we are after if so.

We can do two things:
1. Lay our cards on the table about what we want included in 4.0 and
work to get those in
2. Agree to keep June 1 follow up a lot quicker with a 4.1

I do want to remind everyone though that each new feature is at odds
with our stability goals for 4.0.

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Roadmap for 4.0

[kurt greaves]

>
> So long as non-user-visible improvements, including big ones, can still go
> in 4.0 at that stage, I’m all for it.


My understanding is that after June 1st the 4.0 branch would be created and
would be bugfix only. It's not really a feature freeze if you allow
improvements after that, which is why they'd instead go to trunk.

I'm also on the "too soon" train so pushing it back to August or so is
desirable to me.


On 5 April 2018 at 21:06, Aleksey Yeshchenko  wrote:

> So long as non-user-visible improvements, including big ones, can still go
> in 4.0 at that stage, I’m all for it.
>
> —
> AY
>
> On 5 April 2018 at 21:14:03, Nate McCall (zznat...@gmail.com) wrote:
>
> >>> My understanding, from Nate's summary, was June 1 is the freeze date
> for
> >>> features. I expect we would go for at least 4 months (if not longer)
> >>> testing, fixing bugs, early dogfooding, and so on. I also equated June
> 1
> >>> with the data which we would create a 'cassandra-4.0' branch, and thus
> the
> >>> merge order becomes: 3.0->3,11->4.0->trunk.
>
> This^ (apologies - 'freeze for alpha' was a bit open for interpretation :)
>
> The idea of making this point in time the 4.0 branch date and merge
> order switch is a good one.
>
> Can we move our gelling consensus here towards this goal?
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: Roadmap for 4.0

[Aleksey Yeshchenko]

So long as non-user-visible improvements, including big ones, can still go in 
4.0 at that stage, I’m all for it.

—
AY

On 5 April 2018 at 21:14:03, Nate McCall (zznat...@gmail.com) wrote:

>>> My understanding, from Nate's summary, was June 1 is the freeze date for  
>>> features. I expect we would go for at least 4 months (if not longer)  
>>> testing, fixing bugs, early dogfooding, and so on. I also equated June 1  
>>> with the data which we would create a 'cassandra-4.0' branch, and thus the  
>>> merge order becomes: 3.0->3,11->4.0->trunk.  

This^ (apologies - 'freeze for alpha' was a bit open for interpretation :)  

The idea of making this point in time the 4.0 branch date and merge  
order switch is a good one.  

Can we move our gelling consensus here towards this goal?  

-  
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org  
For additional commands, e-mail: dev-h...@cassandra.apache.org  

Re: Roadmap for 4.0

[Nate McCall]

>>> My understanding, from Nate's summary, was June 1 is the freeze date for
>>> features. I expect we would go for at least 4 months (if not longer)
>>> testing, fixing bugs, early dogfooding, and so on. I also equated June 1
>>> with the data which we would create a 'cassandra-4.0' branch, and thus the
>>> merge order becomes: 3.0->3,11->4.0->trunk.

This^ (apologies - 'freeze for alpha' was a bit open for interpretation :)

The idea of making this point in time the 4.0 branch date and merge
order switch is a good one.

Can we move our gelling consensus here towards this goal?

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Roadmap for 4.0

[Josh McKenzie]

I'm in line w/your thinking here Jason.

On Thu, Apr 5, 2018 at 3:25 PM, Jonathan Haddad  wrote:
> That’s exactly what I was thinking too.
>
> There’s also nothing preventing features from being merged into trunk after
> we create the 4.0 branch, which in my opinion is a better approach than
> trying to jam everything in right before the release.
> On Thu, Apr 5, 2018 at 12:06 PM Jason Brown  wrote:
>
>> My understanding, from Nate's summary, was June 1 is the freeze date for
>> features. I expect we would go for at least 4 months (if not longer)
>> testing, fixing bugs, early dogfooding, and so on. I also equated June 1
>> with the data which we would create a 'cassandra-4.0' branch, and thus the
>> merge order becomes: 3.0->3,11->4.0->trunk.
>>
>> Is this different from what others are thinking? I'm open to shifting the
>> actual date, but what about the rest?
>>
>>
>> On Thu, Apr 5, 2018 at 11:39 AM, Aleksey Yeshchenko 
>> wrote:
>>
>> > June feels a bit too early to me as well.
>> >
>> > I personally would go prefer end of August / beginning of September.
>> >
>> > +1 to the idea of having a fixed date, though, just not this one.
>> >
>> > —
>> > AY
>> >
>> > On 5 April 2018 at 19:20:12, Stefan Podkowinski (s...@apache.org) wrote:
>> >
>> > June is too early.
>> >
>> >
>> > On 05.04.18 19:32, Josh McKenzie wrote:
>> > > Just as a matter of perspective, I'm personally mentally diffing from
>> > > when 3.0 hit, not 3.10.
>> > >
>> > >> commit 96f407bce56b98cd824d18e32ee012dbb99a0286
>> > >> Author: T Jake Luciani 
>> > >> Date: Fri Nov 6 14:38:34 2015 -0500
>> > >> 3.0 release versions
>> > > While June feels close to today relative to momentum for a release
>> > > before this discussion, it's certainly long enough from when the
>> > > previous traditional major released that it doesn't feel "too soon" to
>> > > me.
>> > >
>> > > On Thu, Apr 5, 2018 at 12:46 PM, sankalp kohli > >
>> > wrote:
>> > >> We can take a look on 1st June how things are then decide if we want
>> to
>> > >> freeze it and whats in and whats out.
>> > >>
>> > >> On Thu, Apr 5, 2018 at 9:31 AM, Ariel Weisberg 
>> > wrote:
>> > >>
>> > >>> Hi,
>> > >>>
>> > >>> +1 to having a feature freeze date. June 1st is earlier than I would
>> > have
>> > >>> picked.
>> > >>>
>> > >>> Ariel
>> > >>>
>> > >>> On Thu, Apr 5, 2018, at 10:57 AM, Josh McKenzie wrote:
>> >  +1 here for June 1.
>> > 
>> >  On Thu, Apr 5, 2018 at 9:50 AM, Jason Brown 
>> > >>> wrote:
>> > > +1
>> > >
>> > > On Wed, Apr 4, 2018 at 8:31 PM, Blake Eggleston <
>> > beggles...@apple.com>
>> > > wrote:
>> > >
>> > >> +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
>> > >> > 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 about the above points?
>> > >> >
>> > >> >
>> > >> >> 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-shedding hell like we
>> > >>> have
>> > >> in the
>> > >> >>> past.
>> > >> >> –––
>> > >> >>
>> > >> >> Another way of saying this: ensuring that the 4.0 release is
>> > >>> of
>> > >> high quality is more important than cutting the release on a
>> > specific
>> > > date.
>> > >> >>
>> > >> >> If we adopt Sylvain's suggestion of freezing features on a
>> > > "feature
>> > >> complete" date (modulo a "definition of done" as Josh suggested),
>> > >>> that
>> > > will
>> > >> help us align toward the polish, performance work, and dog-fooding
>> > >>> needed
>> > >> to feel great about shipping 4.0. It's a good time to start
>> thinking
>> > > about
>> > >> the approaches to testing, profiling, and dog-fooding various
>> > > contributors
>> > >> will want to 

Re: Roadmap for 4.0

[Jonathan Haddad]

That’s exactly what I was thinking too.

There’s also nothing preventing features from being merged into trunk after
we create the 4.0 branch, which in my opinion is a better approach than
trying to jam everything in right before the release.
On Thu, Apr 5, 2018 at 12:06 PM Jason Brown  wrote:

> My understanding, from Nate's summary, was June 1 is the freeze date for
> features. I expect we would go for at least 4 months (if not longer)
> testing, fixing bugs, early dogfooding, and so on. I also equated June 1
> with the data which we would create a 'cassandra-4.0' branch, and thus the
> merge order becomes: 3.0->3,11->4.0->trunk.
>
> Is this different from what others are thinking? I'm open to shifting the
> actual date, but what about the rest?
>
>
> On Thu, Apr 5, 2018 at 11:39 AM, Aleksey Yeshchenko 
> wrote:
>
> > June feels a bit too early to me as well.
> >
> > I personally would go prefer end of August / beginning of September.
> >
> > +1 to the idea of having a fixed date, though, just not this one.
> >
> > —
> > AY
> >
> > On 5 April 2018 at 19:20:12, Stefan Podkowinski (s...@apache.org) wrote:
> >
> > June is too early.
> >
> >
> > On 05.04.18 19:32, Josh McKenzie wrote:
> > > Just as a matter of perspective, I'm personally mentally diffing from
> > > when 3.0 hit, not 3.10.
> > >
> > >> commit 96f407bce56b98cd824d18e32ee012dbb99a0286
> > >> Author: T Jake Luciani 
> > >> Date: Fri Nov 6 14:38:34 2015 -0500
> > >> 3.0 release versions
> > > While June feels close to today relative to momentum for a release
> > > before this discussion, it's certainly long enough from when the
> > > previous traditional major released that it doesn't feel "too soon" to
> > > me.
> > >
> > > On Thu, Apr 5, 2018 at 12:46 PM, sankalp kohli  >
> > wrote:
> > >> We can take a look on 1st June how things are then decide if we want
> to
> > >> freeze it and whats in and whats out.
> > >>
> > >> On Thu, Apr 5, 2018 at 9:31 AM, Ariel Weisberg 
> > wrote:
> > >>
> > >>> Hi,
> > >>>
> > >>> +1 to having a feature freeze date. June 1st is earlier than I would
> > have
> > >>> picked.
> > >>>
> > >>> Ariel
> > >>>
> > >>> On Thu, Apr 5, 2018, at 10:57 AM, Josh McKenzie wrote:
> >  +1 here for June 1.
> > 
> >  On Thu, Apr 5, 2018 at 9:50 AM, Jason Brown 
> > >>> wrote:
> > > +1
> > >
> > > On Wed, Apr 4, 2018 at 8:31 PM, Blake Eggleston <
> > beggles...@apple.com>
> > > wrote:
> > >
> > >> +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
> > >> > 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 about the above points?
> > >> >
> > >> >
> > >> >> 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-shedding hell like we
> > >>> have
> > >> in the
> > >> >>> past.
> > >> >> –––
> > >> >>
> > >> >> Another way of saying this: ensuring that the 4.0 release is
> > >>> of
> > >> high quality is more important than cutting the release on a
> > specific
> > > date.
> > >> >>
> > >> >> If we adopt Sylvain's suggestion of freezing features on a
> > > "feature
> > >> complete" date (modulo a "definition of done" as Josh suggested),
> > >>> that
> > > will
> > >> help us align toward the polish, performance work, and dog-fooding
> > >>> needed
> > >> to feel great about shipping 4.0. It's a good time to start
> thinking
> > > about
> > >> the approaches to testing, profiling, and dog-fooding various
> > > contributors
> > >> will want to take on before release.
> > >> >>
> > >> >> I love how Ben put it:
> > >> >>
> > >> >>> 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
> > 

Re: Roadmap for 4.0

[Jason Brown]

My understanding, from Nate's summary, was June 1 is the freeze date for
features. I expect we would go for at least 4 months (if not longer)
testing, fixing bugs, early dogfooding, and so on. I also equated June 1
with the data which we would create a 'cassandra-4.0' branch, and thus the
merge order becomes: 3.0->3,11->4.0->trunk.

Is this different from what others are thinking? I'm open to shifting the
actual date, but what about the rest?


On Thu, Apr 5, 2018 at 11:39 AM, Aleksey Yeshchenko 
wrote:

> June feels a bit too early to me as well.
>
> I personally would go prefer end of August / beginning of September.
>
> +1 to the idea of having a fixed date, though, just not this one.
>
> —
> AY
>
> On 5 April 2018 at 19:20:12, Stefan Podkowinski (s...@apache.org) wrote:
>
> June is too early.
>
>
> On 05.04.18 19:32, Josh McKenzie wrote:
> > Just as a matter of perspective, I'm personally mentally diffing from
> > when 3.0 hit, not 3.10.
> >
> >> commit 96f407bce56b98cd824d18e32ee012dbb99a0286
> >> Author: T Jake Luciani 
> >> Date: Fri Nov 6 14:38:34 2015 -0500
> >> 3.0 release versions
> > While June feels close to today relative to momentum for a release
> > before this discussion, it's certainly long enough from when the
> > previous traditional major released that it doesn't feel "too soon" to
> > me.
> >
> > On Thu, Apr 5, 2018 at 12:46 PM, sankalp kohli 
> wrote:
> >> We can take a look on 1st June how things are then decide if we want to
> >> freeze it and whats in and whats out.
> >>
> >> On Thu, Apr 5, 2018 at 9:31 AM, Ariel Weisberg 
> wrote:
> >>
> >>> Hi,
> >>>
> >>> +1 to having a feature freeze date. June 1st is earlier than I would
> have
> >>> picked.
> >>>
> >>> Ariel
> >>>
> >>> On Thu, Apr 5, 2018, at 10:57 AM, Josh McKenzie wrote:
>  +1 here for June 1.
> 
>  On Thu, Apr 5, 2018 at 9:50 AM, Jason Brown 
> >>> wrote:
> > +1
> >
> > On Wed, Apr 4, 2018 at 8:31 PM, Blake Eggleston <
> beggles...@apple.com>
> > wrote:
> >
> >> +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
> >> > 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 about the above points?
> >> >
> >> >
> >> >> 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-shedding hell like we
> >>> have
> >> in the
> >> >>> past.
> >> >> –––
> >> >>
> >> >> Another way of saying this: ensuring that the 4.0 release is
> >>> of
> >> high quality is more important than cutting the release on a
> specific
> > date.
> >> >>
> >> >> If we adopt Sylvain's suggestion of freezing features on a
> > "feature
> >> complete" date (modulo a "definition of done" as Josh suggested),
> >>> that
> > will
> >> help us align toward the polish, performance work, and dog-fooding
> >>> needed
> >> to feel great about shipping 4.0. It's a good time to start thinking
> > about
> >> the approaches to testing, profiling, and dog-fooding various
> > contributors
> >> will want to take on before release.
> >> >>
> >> >> I love how Ben put it:
> >> >>
> >> >>> 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 will still be in the pipeline if it doesn't make
> >>> it to
> >> 4.0.
> >> >>
> >> >> That sounds great to me, too.
> >> >>
> >> >> – Scott
> >> >
> >> > 
> >> -
> >> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> >> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >> >
> >>
> >> 

Re: Roadmap for 4.0

[Aleksey Yeshchenko]

June feels a bit too early to me as well.

I personally would go prefer end of August / beginning of September.

+1 to the idea of having a fixed date, though, just not this one.

—
AY

On 5 April 2018 at 19:20:12, Stefan Podkowinski (s...@apache.org) wrote:

June is too early.  


On 05.04.18 19:32, Josh McKenzie wrote:  
> Just as a matter of perspective, I'm personally mentally diffing from  
> when 3.0 hit, not 3.10.  
>  
>> commit 96f407bce56b98cd824d18e32ee012dbb99a0286  
>> Author: T Jake Luciani   
>> Date: Fri Nov 6 14:38:34 2015 -0500  
>> 3.0 release versions  
> While June feels close to today relative to momentum for a release  
> before this discussion, it's certainly long enough from when the  
> previous traditional major released that it doesn't feel "too soon" to  
> me.  
>  
> On Thu, Apr 5, 2018 at 12:46 PM, sankalp kohli  
> wrote:  
>> We can take a look on 1st June how things are then decide if we want to  
>> freeze it and whats in and whats out.  
>>  
>> On Thu, Apr 5, 2018 at 9:31 AM, Ariel Weisberg  wrote:  
>>  
>>> Hi,  
>>>  
>>> +1 to having a feature freeze date. June 1st is earlier than I would have  
>>> picked.  
>>>  
>>> Ariel  
>>>  
>>> On Thu, Apr 5, 2018, at 10:57 AM, Josh McKenzie wrote:  
 +1 here for June 1.  
  
 On Thu, Apr 5, 2018 at 9:50 AM, Jason Brown   
>>> wrote:  
> +1  
>  
> On Wed, Apr 4, 2018 at 8:31 PM, Blake Eggleston   
> wrote:  
>  
>> +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  
>> > 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 about the above points?  
>> >  
>> >  
>> >> 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-shedding hell like we  
>>> have  
>> in the  
>> >>> past.  
>> >> –––  
>> >>  
>> >> Another way of saying this: ensuring that the 4.0 release is  
>>> of  
>> high quality is more important than cutting the release on a specific  
> date.  
>> >>  
>> >> If we adopt Sylvain's suggestion of freezing features on a  
> "feature  
>> complete" date (modulo a "definition of done" as Josh suggested),  
>>> that  
> will  
>> help us align toward the polish, performance work, and dog-fooding  
>>> needed  
>> to feel great about shipping 4.0. It's a good time to start thinking  
> about  
>> the approaches to testing, profiling, and dog-fooding various  
> contributors  
>> will want to take on before release.  
>> >>  
>> >> I love how Ben put it:  
>> >>  
>> >>> 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 will still be in the pipeline if it doesn't make  
>>> it to  
>> 4.0.  
>> >>  
>> >> That sounds great to me, too.  
>> >>  
>> >> – Scott  
>> >  
>> >   
>> -  
>> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org  
>> > For additional commands, e-mail: dev-h...@cassandra.apache.org  
>> >  
>>  
>>   
> -  
>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org  
>> For additional commands, e-mail: dev-h...@cassandra.apache.org  
>>  
>>  
>>  
>>  
>>  
>>   
>>> -  
>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org  
>> For additional commands, e-mail: dev-h...@cassandra.apache.org  
>>  
>>  
>>> 

Re: Roadmap for 4.0

[Stefan Podkowinski]

June is too early.


On 05.04.18 19:32, Josh McKenzie wrote:
> Just as a matter of perspective, I'm personally mentally diffing from
> when 3.0 hit, not 3.10.
>
>> commit 96f407bce56b98cd824d18e32ee012dbb99a0286
>> Author: T Jake Luciani 
>> Date:   Fri Nov 6 14:38:34 2015 -0500
>>  3.0 release versions
> While June feels close to today relative to momentum for a release
> before this discussion, it's certainly long enough from when the
> previous traditional major released that it doesn't feel "too soon" to
> me.
>
> On Thu, Apr 5, 2018 at 12:46 PM, sankalp kohli  wrote:
>> We can take a look on 1st June how things are then decide if we want to
>> freeze it and whats in and whats out.
>>
>> On Thu, Apr 5, 2018 at 9:31 AM, Ariel Weisberg  wrote:
>>
>>> Hi,
>>>
>>> +1 to having a feature freeze date. June 1st is earlier than I would have
>>> picked.
>>>
>>> Ariel
>>>
>>> On Thu, Apr 5, 2018, at 10:57 AM, Josh McKenzie wrote:
 +1 here for June 1.

 On Thu, Apr 5, 2018 at 9:50 AM, Jason Brown 
>>> wrote:
> +1
>
> On Wed, Apr 4, 2018 at 8:31 PM, Blake Eggleston 
> wrote:
>
>> +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
>> > 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 about the above points?
>> >
>> >
>> >> 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-shedding hell like we
>>> have
>> in the
>> >>> past.
>> >> –––
>> >>
>> >> Another way of saying this: ensuring that the 4.0 release is
>>> of
>> high quality is more important than cutting the release on a specific
> date.
>> >>
>> >> If we adopt Sylvain's suggestion of freezing features on a
> "feature
>> complete" date (modulo a "definition of done" as Josh suggested),
>>> that
> will
>> help us align toward the polish, performance work, and dog-fooding
>>> needed
>> to feel great about shipping 4.0. It's a good time to start thinking
> about
>> the approaches to testing, profiling, and dog-fooding various
> contributors
>> will want to take on before release.
>> >>
>> >> I love how Ben put it:
>> >>
>> >>> 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 will still be in the pipeline if it doesn't make
>>> it to
>> 4.0.
>> >>
>> >> That sounds great to me, too.
>> >>
>> >> – Scott
>> >
>> > 
>> -
>> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>> > For additional commands, e-mail: dev-h...@cassandra.apache.org
>> >
>>
>> 
> -
>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>> For additional commands, e-mail: dev-h...@cassandra.apache.org
>>
>>
>>
>>
>>
>> 
>>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>> For additional commands, e-mail: dev-h...@cassandra.apache.org
>>
>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>>> For additional commands, e-mail: dev-h...@cassandra.apache.org
>>>
>>>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, 

Re: Roadmap for 4.0

[Michael Shuler]

On 04/05/2018 12:32 PM, Josh McKenzie wrote:
> Just as a matter of perspective, I'm personally mentally diffing from
> when 3.0 hit, not 3.10.
> 
>> commit 96f407bce56b98cd824d18e32ee012dbb99a0286
>> Author: T Jake Luciani 
>> Date:   Fri Nov 6 14:38:34 2015 -0500
>>  3.0 release versions
> 
> While June feels close to today relative to momentum for a release
> before this discussion, it's certainly long enough from when the
> previous traditional major released that it doesn't feel "too soon" to
> me.

Since I couldn't recall the dates, I went to go look. Just a little
additional history:


mshuler@hana:~/svn/cassandra$ svn log -r r1772680

r1772680 | mshuler | 2016-12-05 08:35:47 -0600 (Mon, 05 Dec 2016) | 2 lines

Change EOLs to "after 4.0 release (date TBD)"


mshuler@hana:~/svn/cassandra$ svn diff -c r1772680 site/src/download.md
Index: site/src/download.md
===
--- site/src/download.md(revision 1772679)
+++ site/src/download.md(revision 1772680)
@@ -21,9 +21,9 @@

 The following older Cassandra releases are still supported:

-* Apache Cassandra 3.0 is supported until **May 2017**. The latest
release is {{ "3.0" | full_release_link }}.
-* Apache Cassandra 2.2 is supported until **November 2016**. The latest
release is {{ "2.2" | full_release_link }}.
-* Apache Cassandra 2.1 is supported until **November 2016** with
**critical fixes only**. The latest release is
+* Apache Cassandra 3.0 is supported until **6 months after 4.0 release
(date TBD)**. The latest release is {{ "3.0" | full_release_link }}.
+* Apache Cassandra 2.2 is supported until **4.0 release (date TBD)**.
The latest release is {{ "2.2" | full_release_link }}.
+* Apache Cassandra 2.1 is supported until **4.0 release (date TBD)**
with **critical fixes only**. The latest release is
   {{ "2.1" | full_release_link }}.

 Older (unsupported) versions of Cassandra are [archived
here](http://archive.apache.org/dist/cassandra/).

-- 
Warm regards,
Michael

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Roadmap for 4.0

[Josh McKenzie]

Just as a matter of perspective, I'm personally mentally diffing from
when 3.0 hit, not 3.10.

> commit 96f407bce56b98cd824d18e32ee012dbb99a0286
> Author: T Jake Luciani 
> Date:   Fri Nov 6 14:38:34 2015 -0500
>  3.0 release versions

While June feels close to today relative to momentum for a release
before this discussion, it's certainly long enough from when the
previous traditional major released that it doesn't feel "too soon" to
me.

On Thu, Apr 5, 2018 at 12:46 PM, sankalp kohli  wrote:
> We can take a look on 1st June how things are then decide if we want to
> freeze it and whats in and whats out.
>
> On Thu, Apr 5, 2018 at 9:31 AM, Ariel Weisberg  wrote:
>
>> Hi,
>>
>> +1 to having a feature freeze date. June 1st is earlier than I would have
>> picked.
>>
>> Ariel
>>
>> On Thu, Apr 5, 2018, at 10:57 AM, Josh McKenzie wrote:
>> > +1 here for June 1.
>> >
>> > On Thu, Apr 5, 2018 at 9:50 AM, Jason Brown 
>> wrote:
>> >
>> > > +1
>> > >
>> > > On Wed, Apr 4, 2018 at 8:31 PM, Blake Eggleston 
>> > > wrote:
>> > >
>> > > > +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
>> > > > > 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 about the above points?
>> > > > >
>> > > > >
>> > > > >> 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-shedding hell like we
>> have
>> > > > in the
>> > > > >>> past.
>> > > > >> –––
>> > > > >>
>> > > > >> Another way of saying this: ensuring that the 4.0 release is
>> of
>> > > > high quality is more important than cutting the release on a specific
>> > > date.
>> > > > >>
>> > > > >> If we adopt Sylvain's suggestion of freezing features on a
>> > > "feature
>> > > > complete" date (modulo a "definition of done" as Josh suggested),
>> that
>> > > will
>> > > > help us align toward the polish, performance work, and dog-fooding
>> needed
>> > > > to feel great about shipping 4.0. It's a good time to start thinking
>> > > about
>> > > > the approaches to testing, profiling, and dog-fooding various
>> > > contributors
>> > > > will want to take on before release.
>> > > > >>
>> > > > >> I love how Ben put it:
>> > > > >>
>> > > > >>> 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 will still be in the pipeline if it doesn't make
>> it to
>> > > > 4.0.
>> > > > >>
>> > > > >> That sounds great to me, too.
>> > > > >>
>> > > > >> – Scott
>> > > > >
>> > > > > 
>> > > > -
>> > > > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>> > > > > For additional commands, e-mail: dev-h...@cassandra.apache.org
>> > > > >
>> > > >
>> > > > 
>> > > -
>> > > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>> > > > For additional commands, e-mail: dev-h...@cassandra.apache.org
>> > > >
>> > > >
>> > > >
>> > > >
>> > > >
>> > > > 
>> -
>> > > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>> > > > For additional commands, e-mail: dev-h...@cassandra.apache.org
>> > > >
>> > > >
>> > >
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>> For additional commands, e-mail: dev-h...@cassandra.apache.org
>>
>>

-
To 

Re: Roadmap for 4.0

[sankalp kohli]

We can take a look on 1st June how things are then decide if we want to
freeze it and whats in and whats out.

On Thu, Apr 5, 2018 at 9:31 AM, Ariel Weisberg  wrote:

> Hi,
>
> +1 to having a feature freeze date. June 1st is earlier than I would have
> picked.
>
> Ariel
>
> On Thu, Apr 5, 2018, at 10:57 AM, Josh McKenzie wrote:
> > +1 here for June 1.
> >
> > On Thu, Apr 5, 2018 at 9:50 AM, Jason Brown 
> wrote:
> >
> > > +1
> > >
> > > On Wed, Apr 4, 2018 at 8:31 PM, Blake Eggleston 
> > > wrote:
> > >
> > > > +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
> > > > > 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 about the above points?
> > > > >
> > > > >
> > > > >> 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-shedding hell like we
> have
> > > > in the
> > > > >>> past.
> > > > >> –––
> > > > >>
> > > > >> Another way of saying this: ensuring that the 4.0 release is
> of
> > > > high quality is more important than cutting the release on a specific
> > > date.
> > > > >>
> > > > >> If we adopt Sylvain's suggestion of freezing features on a
> > > "feature
> > > > complete" date (modulo a "definition of done" as Josh suggested),
> that
> > > will
> > > > help us align toward the polish, performance work, and dog-fooding
> needed
> > > > to feel great about shipping 4.0. It's a good time to start thinking
> > > about
> > > > the approaches to testing, profiling, and dog-fooding various
> > > contributors
> > > > will want to take on before release.
> > > > >>
> > > > >> I love how Ben put it:
> > > > >>
> > > > >>> 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 will still be in the pipeline if it doesn't make
> it to
> > > > 4.0.
> > > > >>
> > > > >> That sounds great to me, too.
> > > > >>
> > > > >> – Scott
> > > > >
> > > > > 
> > > > -
> > > > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > > > > For additional commands, e-mail: dev-h...@cassandra.apache.org
> > > > >
> > > >
> > > > 
> > > -
> > > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > > > For additional commands, e-mail: dev-h...@cassandra.apache.org
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > 
> -
> > > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > > > For additional commands, e-mail: dev-h...@cassandra.apache.org
> > > >
> > > >
> > >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: Roadmap for 4.0

[Ariel Weisberg]

Hi,

+1 to having a feature freeze date. June 1st is earlier than I would have 
picked.

Ariel

On Thu, Apr 5, 2018, at 10:57 AM, Josh McKenzie wrote:
> +1 here for June 1.
> 
> On Thu, Apr 5, 2018 at 9:50 AM, Jason Brown  wrote:
> 
> > +1
> >
> > On Wed, Apr 4, 2018 at 8:31 PM, Blake Eggleston 
> > wrote:
> >
> > > +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
> > > > 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 about the above points?
> > > >
> > > >
> > > >> 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-shedding hell like we have
> > > in the
> > > >>> past.
> > > >> –––
> > > >>
> > > >> Another way of saying this: ensuring that the 4.0 release is of
> > > high quality is more important than cutting the release on a specific
> > date.
> > > >>
> > > >> If we adopt Sylvain's suggestion of freezing features on a
> > "feature
> > > complete" date (modulo a "definition of done" as Josh suggested), that
> > will
> > > help us align toward the polish, performance work, and dog-fooding needed
> > > to feel great about shipping 4.0. It's a good time to start thinking
> > about
> > > the approaches to testing, profiling, and dog-fooding various
> > contributors
> > > will want to take on before release.
> > > >>
> > > >> I love how Ben put it:
> > > >>
> > > >>> 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 will still be in the pipeline if it doesn't make it to
> > > 4.0.
> > > >>
> > > >> That sounds great to me, too.
> > > >>
> > > >> – Scott
> > > >
> > > > 
> > > -
> > > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > > > For additional commands, e-mail: dev-h...@cassandra.apache.org
> > > >
> > >
> > > 
> > -
> > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > > For additional commands, e-mail: dev-h...@cassandra.apache.org
> > >
> > >
> > >
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > > For additional commands, e-mail: dev-h...@cassandra.apache.org
> > >
> > >
> >

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Roadmap for 4.0

[Josh McKenzie]

+1 here for June 1.

On Thu, Apr 5, 2018 at 9:50 AM, Jason Brown  wrote:

> +1
>
> On Wed, Apr 4, 2018 at 8:31 PM, Blake Eggleston 
> wrote:
>
> > +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
> > > 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 about the above points?
> > >
> > >
> > >> 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-shedding hell like we have
> > in the
> > >>> past.
> > >> –––
> > >>
> > >> Another way of saying this: ensuring that the 4.0 release is of
> > high quality is more important than cutting the release on a specific
> date.
> > >>
> > >> If we adopt Sylvain's suggestion of freezing features on a
> "feature
> > complete" date (modulo a "definition of done" as Josh suggested), that
> will
> > help us align toward the polish, performance work, and dog-fooding needed
> > to feel great about shipping 4.0. It's a good time to start thinking
> about
> > the approaches to testing, profiling, and dog-fooding various
> contributors
> > will want to take on before release.
> > >>
> > >> I love how Ben put it:
> > >>
> > >>> 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 will still be in the pipeline if it doesn't make it to
> > 4.0.
> > >>
> > >> That sounds great to me, too.
> > >>
> > >> – Scott
> > >
> > > 
> > -
> > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > > For additional commands, e-mail: dev-h...@cassandra.apache.org
> > >
> >
> > 
> -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> >
> >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> >
>

Re: Roadmap for 4.0

[Jason Brown]

+1

On Wed, Apr 4, 2018 at 8:31 PM, Blake Eggleston 
wrote:

> +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
> > 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 about the above points?
> >
> >
> >> 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-shedding hell like we have
> in the
> >>> past.
> >> –––
> >>
> >> Another way of saying this: ensuring that the 4.0 release is of
> high quality is more important than cutting the release on a specific date.
> >>
> >> If we adopt Sylvain's suggestion of freezing features on a "feature
> complete" date (modulo a "definition of done" as Josh suggested), that will
> help us align toward the polish, performance work, and dog-fooding needed
> to feel great about shipping 4.0. It's a good time to start thinking about
> the approaches to testing, profiling, and dog-fooding various contributors
> will want to take on before release.
> >>
> >> I love how Ben put it:
> >>
> >>> 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 will still be in the pipeline if it doesn't make it to
> 4.0.
> >>
> >> That sounds great to me, too.
> >>
> >> – Scott
> >
> > 
> -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: Roadmap for 4.0

[Blake Eggleston]

+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
> 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 about the above points?
> 
> 
>> 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-shedding hell like we have in the
>>> past.
>> –––
>> 
>> Another way of saying this: ensuring that the 4.0 release is of high 
quality is more important than cutting the release on a specific date.
>> 
>> If we adopt Sylvain's suggestion of freezing features on a "feature 
complete" date (modulo a "definition of done" as Josh suggested), that will 
help us align toward the polish, performance work, and dog-fooding needed to 
feel great about shipping 4.0. It's a good time to start thinking about the 
approaches to testing, profiling, and dog-fooding various contributors will 
want to take on before release.
>> 
>> I love how Ben put it:
>> 
>>> 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 will still be in the pipeline if it doesn't make it to 4.0.
>> 
>> That sounds great to me, too.
>> 
>> – Scott
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
> 

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org





-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Roadmap for 4.0

[Alex Lourie]

+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
> >
> > > 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 testing and dogfooding
> > > implied by such before a GA)
> > >
> > > How do folks feel about the above points?
> > >
> > >
> > >> 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-shedding hell like we have in
> > the
> > >>> past.
> > >> –––
> > >>
> > >> Another way of saying this: ensuring that the 4.0 release is of high
> > quality is more important than cutting the release on a specific date.
> > >>
> > >> If we adopt Sylvain's suggestion of freezing features on a "feature
> > complete" date (modulo a "definition of done" as Josh suggested), that
> will
> > help us align toward the polish, performance work, and dog-fooding needed
> > to feel great about shipping 4.0. It's a good time to start thinking
> about
> > the approaches to testing, profiling, and dog-fooding various
> contributors
> > will want to take on before release.
> > >>
> > >> I love how Ben put it:
> > >>
> > >>> 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 will still be in the pipeline if it doesn't make it to
> 4.0.
> > >>
> > >> That sounds great to me, too.
> > >>
> > >> – Scott
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > > For additional commands, e-mail: dev-h...@cassandra.apache.org
> > >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> >
>
-- 


*Alex Lourie*
*Software Engineer*+61 423177059


   


Read our latest technical blog posts here
.

This email has been sent on behalf of Instaclustr Pty. Limited (Australia)
and Instaclustr Inc (USA).

This email and any attachments may contain confidential and legally
privileged information.  If you are not the intended recipient, do not copy
or disclose its content, but please reply to this email immediately and
highlight the error to the sender and then immediately delete the message.

Re: Roadmap for 4.0

[kurt greaves]

>
> 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).
> >
> > 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?
> >
> >
> >> 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-shedding hell like we have in
> the
> >>> past.
> >> –––
> >>
> >> Another way of saying this: ensuring that the 4.0 release is of high
> quality is more important than cutting the release on a specific date.
> >>
> >> If we adopt Sylvain's suggestion of freezing features on a "feature
> complete" date (modulo a "definition of done" as Josh suggested), that will
> help us align toward the polish, performance work, and dog-fooding needed
> to feel great about shipping 4.0. It's a good time to start thinking about
> the approaches to testing, profiling, and dog-fooding various contributors
> will want to take on before release.
> >>
> >> I love how Ben put it:
> >>
> >>> 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 will still be in the pipeline if it doesn't make it to 4.0.
> >>
> >> That sounds great to me, too.
> >>
> >> – Scott
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: Roadmap for 4.0

[J. D. Jordan]

+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 testing and dogfooding
> implied by such before a GA)
> 
> How do folks feel about the above points?
> 
> 
>> 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-shedding hell like we have in the
>>> past.
>> –––
>> 
>> Another way of saying this: ensuring that the 4.0 release is of high quality 
>> is more important than cutting the release on a specific date.
>> 
>> If we adopt Sylvain's suggestion of freezing features on a "feature 
>> complete" date (modulo a "definition of done" as Josh suggested), that will 
>> help us align toward the polish, performance work, and dog-fooding needed to 
>> feel great about shipping 4.0. It's a good time to start thinking about the 
>> approaches to testing, profiling, and dog-fooding various contributors will 
>> want to take on before release.
>> 
>> I love how Ben put it:
>> 
>>> 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 will still be in the pipeline if it doesn't make it to 4.0.
>> 
>> That sounds great to me, too.
>> 
>> – Scott
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
> 

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Roadmap for 4.0

[Jeremy Hanna]

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)
> >
> > How do folks feel about the above points?
>
> +1
> +1
>

+1 though we may need some additional work on counters ;)


> :)
> Michael
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: Roadmap for 4.0

[Ben Bromhead]

+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 GA)
> >
> > How do folks feel about the above points?
>
> +1
> +1
>
> :)
> Michael
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
> --
Ben Bromhead
CTO | Instaclustr 
+1 650 284 9692
Reliability at Scale
Cassandra, Spark, Elasticsearch on AWS, Azure, GCP and Softlayer

Re: Roadmap for 4.0

[Michael Shuler]

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

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Roadmap for 4.0

[Jeff Jirsa]

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. 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?
> 
> 
>> 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-shedding hell like we have in the
>>> past.
>> –––
>> 
>> Another way of saying this: ensuring that the 4.0 release is of high quality 
>> is more important than cutting the release on a specific date.
>> 
>> If we adopt Sylvain's suggestion of freezing features on a "feature 
>> complete" date (modulo a "definition of done" as Josh suggested), that will 
>> help us align toward the polish, performance work, and dog-fooding needed to 
>> feel great about shipping 4.0. It's a good time to start thinking about the 
>> approaches to testing, profiling, and dog-fooding various contributors will 
>> want to take on before release.
>> 
>> I love how Ben put it:
>> 
>>> 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 will still be in the pipeline if it doesn't make it to 4.0.
>> 
>> That sounds great to me, too.
>> 
>> – Scott
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
> 

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Roadmap for 4.0

[Jon Haddad]

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


-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Roadmap for 4.0

[Jonathan Ellis]

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 and dogfooding
> implied by such before a GA)
>
> How do folks feel about the above points?
>

+1

>

RE: Roadmap for 4.0

[Kenneth Brotman]

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 rushing to meet a deadline because they are holding up a version, because
that feature will just be able to go in the next version.  No pressure; and
no energy discussing how we will approach each version.  That's a lot of
high caliber talent we are consuming.

Kenneth Brotman

-Original Message-
From: Kenneth Brotman [mailto:kenbrot...@yahoo.com.INVALID] 
Sent: Wednesday, April 04, 2018 4:51 PM
To: dev@cassandra.apache.org
Subject: 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 properly develop and test a feature.  You won't want to release it until
it's ready.  So take the pressure and complication out of it.

Every once in a while a nice set of features will be ready and should not be
delayed when they are.  That's when you have a new major release.  Let it
happen more naturally instead of forcing it.

Kenneth Brotman

-Original Message-
From: Kenneth Brotman [mailto:kenbrot...@yahoo.com.INVALID]
Sent: Wednesday, April 04, 2018 4:23 PM
To: dev@cassandra.apache.org
Subject: 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-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-shedding hell like we have 
> in the past.
---

Another way of saying this: ensuring that the 4.0 release is of high quality
is more important than cutting the release on a specific date.

If we adopt Sylvain's suggestion of freezing features on a "feature
complete" date (modulo a "definition of done" as Josh suggested), that will
help us align toward the polish, performance work, and dog-fooding needed to
feel great about shipping 4.0. It's a good time to start thinking about the
approaches to testing, profiling, and dog-fooding various contributors will
want to take on before release.

I love how Ben put it:

> 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 will still be in the pipeline if it doesn't make it to 4.0.

That sounds great to me, too.

- Scott


From: Kenneth Brotman <kenbrot...@yahoo.com.INVALID>
Sent: Wednesday, April 4, 2018 2:20:59 PM
To: dev@cassandra.apache.org
Subject: 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: Roadmap for 4.0

On Thu, Apr 5, 2018 at 3:26 AM, Kenneth Brotman
<kenbrot...@yahoo.com.invalid> 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 date sometime next year ;to be decided on
by us this month.
> Versions 4.x: minor releases about every three months starting
after a major release with improvements to the code that can be ready for
release, with bug fixes as needed done in between.
> Version: 5.0: a major release of whatever significant 
> improvements
are ready for release one year after the release of 4.0
> Versions 5.x: minor releases about every three months with
improvements, with bug fixes as needed done in between,
> And so on:
> A Major release every 12 months of whatever can be 
> ready
for release in that major version,
> A minor release every 3 months of whatever can be 
> ready
for release in that minor version.
> Bug fixes as needed.
>
> The folks working on code could then get an idea 

Re: Roadmap for 4.0

[Nate McCall]

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 about the above points?


> 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-shedding hell like we have in the
>> past.
> –––
>
> Another way of saying this: ensuring that the 4.0 release is of high quality 
> is more important than cutting the release on a specific date.
>
> If we adopt Sylvain's suggestion of freezing features on a "feature complete" 
> date (modulo a "definition of done" as Josh suggested), that will help us 
> align toward the polish, performance work, and dog-fooding needed to feel 
> great about shipping 4.0. It's a good time to start thinking about the 
> approaches to testing, profiling, and dog-fooding various contributors will 
> want to take on before release.
>
> I love how Ben put it:
>
>> 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 will still be in the pipeline if it doesn't make it to 4.0.
>
> That sounds great to me, too.
>
> – Scott

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

RE: Roadmap for 4.0

[Kenneth Brotman]

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 properly develop and test a feature.  You won't want to release it until
it's ready.  So take the pressure and complication out of it.

Every once in a while a nice set of features will be ready and should not be
delayed when they are.  That's when you have a new major release.  Let it
happen more naturally instead of forcing it.

Kenneth Brotman

-Original Message-
From: Kenneth Brotman [mailto:kenbrot...@yahoo.com.INVALID] 
Sent: Wednesday, April 04, 2018 4:23 PM
To: dev@cassandra.apache.org
Subject: 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-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-shedding hell like we have 
> in the past.
---

Another way of saying this: ensuring that the 4.0 release is of high quality
is more important than cutting the release on a specific date.

If we adopt Sylvain's suggestion of freezing features on a "feature
complete" date (modulo a "definition of done" as Josh suggested), that will
help us align toward the polish, performance work, and dog-fooding needed to
feel great about shipping 4.0. It's a good time to start thinking about the
approaches to testing, profiling, and dog-fooding various contributors will
want to take on before release.

I love how Ben put it:

> 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 will still be in the pipeline if it doesn't make it to 4.0.

That sounds great to me, too.

- Scott


From: Kenneth Brotman <kenbrot...@yahoo.com.INVALID>
Sent: Wednesday, April 4, 2018 2:20:59 PM
To: dev@cassandra.apache.org
Subject: 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: Roadmap for 4.0

On Thu, Apr 5, 2018 at 3:26 AM, Kenneth Brotman
<kenbrot...@yahoo.com.invalid> 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 date sometime next year ;to be decided on
by us this month.
> Versions 4.x: minor releases about every three months starting
after a major release with improvements to the code that can be ready for
release, with bug fixes as needed done in between.
> Version: 5.0: a major release of whatever significant 
> improvements
are ready for release one year after the release of 4.0
> Versions 5.x: minor releases about every three months with
improvements, with bug fixes as needed done in between,
> And so on:
> A Major release every 12 months of whatever can be 
> ready
for release in that major version,
> A minor release every 3 months of whatever can be 
> ready
for release in that minor version.
> Bug fixes as needed.
>
> The folks working on code could then get an idea of when their code 
> would
be ready for release version-wise.
>
> Kenneth Brotman

Hi Kenneth,
Appreciate the input, but this is quite a well-trodden path of discussion.
Please see the following two (lengthy) threads from last year for
background:

https://lists.apache.org/thread.html/f7e1fa12ea2fb9c3eb366a04dfd7cab5d0d64eb
9f4057ad65bd62ace@%3Cdev.cassandra.apache.org%3E
https://lists.apache.org/thread.html/684b559bf27b9deca0be0dd9629e6cd1fff5644
598180f950ff4f478@%3Cdev.cassandra.apache.org%3E

Let's focus this thread on 4.0 release.

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org


--

RE: Roadmap for 4.0

[Kenneth Brotman]

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-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-shedding hell like we have 
> in the past.
---

Another way of saying this: ensuring that the 4.0 release is of high quality
is more important than cutting the release on a specific date.

If we adopt Sylvain's suggestion of freezing features on a "feature
complete" date (modulo a "definition of done" as Josh suggested), that will
help us align toward the polish, performance work, and dog-fooding needed to
feel great about shipping 4.0. It's a good time to start thinking about the
approaches to testing, profiling, and dog-fooding various contributors will
want to take on before release.

I love how Ben put it:

> 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 will still be in the pipeline if it doesn't make it to 4.0.

That sounds great to me, too.

- Scott


From: Kenneth Brotman <kenbrot...@yahoo.com.INVALID>
Sent: Wednesday, April 4, 2018 2:20:59 PM
To: dev@cassandra.apache.org
Subject: 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: Roadmap for 4.0

On Thu, Apr 5, 2018 at 3:26 AM, Kenneth Brotman
<kenbrot...@yahoo.com.invalid> 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 date sometime next year ;to be decided on
by us this month.
> Versions 4.x: minor releases about every three months starting
after a major release with improvements to the code that can be ready for
release, with bug fixes as needed done in between.
> Version: 5.0: a major release of whatever significant improvements
are ready for release one year after the release of 4.0
> Versions 5.x: minor releases about every three months with
improvements, with bug fixes as needed done in between,
> And so on:
> A Major release every 12 months of whatever can be ready
for release in that major version,
> A minor release every 3 months of whatever can be ready
for release in that minor version.
> Bug fixes as needed.
>
> The folks working on code could then get an idea of when their code would
be ready for release version-wise.
>
> Kenneth Brotman

Hi Kenneth,
Appreciate the input, but this is quite a well-trodden path of discussion.
Please see the following two (lengthy) threads from last year for
background:

https://lists.apache.org/thread.html/f7e1fa12ea2fb9c3eb366a04dfd7cab5d0d64eb
9f4057ad65bd62ace@%3Cdev.cassandra.apache.org%3E
https://lists.apache.org/thread.html/684b559bf27b9deca0be0dd9629e6cd1fff5644
598180f950ff4f478@%3Cdev.cassandra.apache.org%3E

Let's focus this thread on 4.0 release.

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Roadmap for 4.0

[Scott Andreas]

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-shedding hell like we have in the
> past.
–––

Another way of saying this: ensuring that the 4.0 release is of high quality is 
more important than cutting the release on a specific date.

If we adopt Sylvain's suggestion of freezing features on a "feature complete" 
date (modulo a "definition of done" as Josh suggested), that will help us align 
toward the polish, performance work, and dog-fooding needed to feel great about 
shipping 4.0. It's a good time to start thinking about the approaches to 
testing, profiling, and dog-fooding various contributors will want to take on 
before release.

I love how Ben put it:

> 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 will still be in the pipeline if it doesn't make it to 4.0.

That sounds great to me, too.

– Scott


From: Kenneth Brotman <kenbrot...@yahoo.com.INVALID>
Sent: Wednesday, April 4, 2018 2:20:59 PM
To: dev@cassandra.apache.org
Subject: 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: Roadmap for 4.0

On Thu, Apr 5, 2018 at 3:26 AM, Kenneth Brotman <kenbrot...@yahoo.com.invalid> 
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 date sometime next year ;to be decided on by 
> us this month.
> Versions 4.x: minor releases about every three months starting after 
> a major release with improvements to the code that can be ready for release, 
> with bug fixes as needed done in between.
> Version: 5.0: a major release of whatever significant improvements 
> are ready for release one year after the release of 4.0
> Versions 5.x: minor releases about every three months with 
> improvements, with bug fixes as needed done in between,
> And so on:
> A Major release every 12 months of whatever can be ready for 
> release in that major version,
> A minor release every 3 months of whatever can be ready for 
> release in that minor version.
> Bug fixes as needed.
>
> The folks working on code could then get an idea of when their code would be 
> ready for release version-wise.
>
> Kenneth Brotman

Hi Kenneth,
Appreciate the input, but this is quite a well-trodden path of discussion. 
Please see the following two (lengthy) threads from last year for background:

https://lists.apache.org/thread.html/f7e1fa12ea2fb9c3eb366a04dfd7cab5d0d64eb9f4057ad65bd62ace@%3Cdev.cassandra.apache.org%3E
https://lists.apache.org/thread.html/684b559bf27b9deca0be0dd9629e6cd1fff5644598180f950ff4f478@%3Cdev.cassandra.apache.org%3E

Let's focus this thread on 4.0 release.

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

RE: Roadmap for 4.0

[Kenneth Brotman]

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: Roadmap for 4.0

On Thu, Apr 5, 2018 at 3:26 AM, Kenneth Brotman <kenbrot...@yahoo.com.invalid> 
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 date sometime next year ;to be decided on by 
> us this month.
> Versions 4.x: minor releases about every three months starting after 
> a major release with improvements to the code that can be ready for release, 
> with bug fixes as needed done in between.
> Version: 5.0: a major release of whatever significant improvements 
> are ready for release one year after the release of 4.0
> Versions 5.x: minor releases about every three months with 
> improvements, with bug fixes as needed done in between,
> And so on:
> A Major release every 12 months of whatever can be ready for 
> release in that major version,
> A minor release every 3 months of whatever can be ready for 
> release in that minor version.
> Bug fixes as needed.
>
> The folks working on code could then get an idea of when their code would be 
> ready for release version-wise.
>
> Kenneth Brotman

Hi Kenneth,
Appreciate the input, but this is quite a well-trodden path of discussion. 
Please see the following two (lengthy) threads from last year for background:

https://lists.apache.org/thread.html/f7e1fa12ea2fb9c3eb366a04dfd7cab5d0d64eb9f4057ad65bd62ace@%3Cdev.cassandra.apache.org%3E
https://lists.apache.org/thread.html/684b559bf27b9deca0be0dd9629e6cd1fff5644598180f950ff4f478@%3Cdev.cassandra.apache.org%3E

Let's focus this thread on 4.0 release.

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Roadmap for 4.0

[Nate McCall]

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 date sometime next year ;to be decided on by 
> us this month.
> Versions 4.x: minor releases about every three months starting after 
> a major release with improvements to the code that can be ready for release, 
> with bug fixes as needed done in between.
> Version: 5.0: a major release of whatever significant improvements 
> are ready for release one year after the release of 4.0
> Versions 5.x: minor releases about every three months with 
> improvements, with bug fixes as needed done in between,
> And so on:
> A Major release every 12 months of whatever can be ready for 
> release in that major version,
> A minor release every 3 months of whatever can be ready for 
> release in that minor version.
> Bug fixes as needed.
>
> The folks working on code could then get an idea of when their code would be 
> ready for release version-wise.
>
> Kenneth Brotman

Hi Kenneth,
Appreciate the input, but this is quite a well-trodden path of
discussion. Please see the following two (lengthy) threads from last
year for background:

https://lists.apache.org/thread.html/f7e1fa12ea2fb9c3eb366a04dfd7cab5d0d64eb9f4057ad65bd62ace@%3Cdev.cassandra.apache.org%3E
https://lists.apache.org/thread.html/684b559bf27b9deca0be0dd9629e6cd1fff5644598180f950ff4f478@%3Cdev.cassandra.apache.org%3E

Let's focus this thread on 4.0 release.

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

RE: Roadmap for 4.0

[Kenneth Brotman]

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. 
Versions 4.x: minor releases about every three months starting after a 
major release with improvements to the code that can be ready for release, with 
bug fixes as needed done in between.
Version: 5.0: a major release of whatever significant improvements are 
ready for release one year after the release of 4.0
Versions 5.x: minor releases about every three months with 
improvements, with bug fixes as needed done in between,
And so on: 
A Major release every 12 months of whatever can be ready for 
release in that major version,
A minor release every 3 months of whatever can be ready for 
release in that minor version.
Bug fixes as needed.

The folks working on code could then get an idea of when their code would be 
ready for release version-wise.

Kenneth Brotman

-Original Message-
From: Jon Haddad [mailto:jonathan.had...@gmail.com] On Behalf Of Jon Haddad
Sent: Wednesday, April 04, 2018 8:00 AM
To: dev@cassandra.apache.org
Subject: 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 should really only be merging in small features 
that enhance user experience like improving nodetool output or reasonable 
optimizations.  Merging in big features at the very end of the merge window is 
a really great idea to have dozens of follow up bug fix releases that nobody 
considers stable, where the Coli conjecture always wins.  IMO, it would be 
better / more responsible to merge them into trunk *after* we branch for 4.0. 
Yes, that makes the next release less exciting, but I really don’t think 
“exciting” is what we’re shooting for.  I’m more in favor of stable.

Regarding supporting 3.0 / 3.11, since we’re talking about feature freezing 4.0 
2 months from now, and releasing it *sometime* after that, then add 6 months, 
we’re talking about close to an extra year of 3.0 support.  People are, of 
course, free to continue patching 3.0, back porting fixes, etc, but I am 
completely OK with saying there’s only 9 more months of support starting today.

I’m also in the go straight to 3.11 camp.  I see no reason to upgrade to only 
3.0 if you’re on 2.x.  

Jon

> On Apr 4, 2018, at 6:29 AM, Josh McKenzie <jmcken...@apache.org> wrote:
> 
>> 
>> 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 
> "Roadmap for 4.0" and has been concerned with how we get 4.0 out the 
> door. I don't think it's implicit that whatever strategy we settle on 
> for 4.0 is intended to apply to subsequent releases, since the 3.0.X 
> to 3.X to 4.0 relationship/delta is different than a 4.0 to 5.0 can be 
> expected to be.
> 
> 
>> sidenote: 3.10 was released in January 2017, and while the changes 
>> list for
>> 4.0 is getting quite large there's not much there that's going to win 
>> over users. It's mostly refactorings and improvements that affect 
>> developers more so than users.
> 
> If you assume most 3. users are on 3.10, this argument makes sense. I 
> believe a majority are on 3.0.X or 2.1/2.2, which leaves a minority 
> looking at the small delta from 3.10 to 4.0 in the current form.
> 
> 
> 
> On Wed, Apr 4, 2018 at 8:25 AM, kurt greaves <k...@instaclustr.com> wrote:
> 
>>> 
>>> 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 pretty clear that this was about compiling a list 
>> of things that people are currently working on and can commit to 
>> getting finished soon (which should be a relatively small list 
>> considering the limited number of full time contributors).
>> 
>> Of course, we should probably (re-(re-(re-)))start a discussion on 
>> release
>>> "strategy" in parallel because it doesn't seem we have one right 
>>> now, but that's im

Re: Roadmap for 4.0

[Ben Bromhead]

+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 will still be in the pipeline if it doesn't make it to 4.0.

On Wed, Apr 4, 2018 at 11:00 AM Jon Haddad <j...@jonhaddad.com> wrote:

> 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 really only be merging in
> small features that enhance user experience like improving nodetool output
> or reasonable optimizations.  Merging in big features at the very end of
> the merge window is a really great idea to have dozens of follow up bug fix
> releases that nobody considers stable, where the Coli conjecture always
> wins.  IMO, it would be better / more responsible to merge them into trunk
> *after* we branch for 4.0. Yes, that makes the next release less exciting,
> but I really don’t think “exciting” is what we’re shooting for.  I’m more
> in favor of stable.
>
> Regarding supporting 3.0 / 3.11, since we’re talking about feature
> freezing 4.0 2 months from now, and releasing it *sometime* after that,
> then add 6 months, we’re talking about close to an extra year of 3.0
> support.  People are, of course, free to continue patching 3.0, back
> porting fixes, etc, but I am completely OK with saying there’s only 9 more
> months of support starting today.
>
> I’m also in the go straight to 3.11 camp.  I see no reason to upgrade to
> only 3.0 if you’re on 2.x.
>
> Jon
>
> > On Apr 4, 2018, at 6:29 AM, Josh McKenzie <jmcken...@apache.org> wrote:
> >
> >>
> >> 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 "Roadmap
> for
> > 4.0" and has been concerned with how we get 4.0 out the door. I don't
> think
> > it's implicit that whatever strategy we settle on for 4.0 is intended to
> > apply to subsequent releases, since the 3.0.X to 3.X to 4.0
> > relationship/delta is different than a 4.0 to 5.0 can be expected to be.
> >
> >
> >> sidenote: 3.10 was released in January 2017, and while the changes list
> for
> >> 4.0 is getting quite large there's not much there that's going to win
> over
> >> users. It's mostly refactorings and improvements that affect developers
> >> more so than users.
> >
> > If you assume most 3. users are on 3.10, this argument makes sense. I
> > believe a majority are on 3.0.X or 2.1/2.2, which leaves a minority
> looking
> > at the small delta from 3.10 to 4.0 in the current form.
> >
> >
> >
> > On Wed, Apr 4, 2018 at 8:25 AM, kurt greaves <k...@instaclustr.com>
> wrote:
> >
> >>>
> >>> 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 pretty clear that this was about compiling a list of
> >> things that people are currently working on and can commit to getting
> >> finished soon (which should be a relatively small list considering the
> >> limited number of full time contributors).
> >>
> >> Of course, we should probably (re-(re-(re-)))start a discussion on
> release
> >>> "strategy" in parallel because it doesn't seem we have one right now,
> but
> >>> that's imo a discussion we should keep separate.
> >>
> >> 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. I don't think it's possible to have a separate
> discussion
> >> on these two things as the release strategy has a pretty big influence
> on
> >> how 4.0 is released.
> >>
> >> I'm all for 

Re: Roadmap for 4.0

[Jon Haddad]

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 really only be merging in small features 
that enhance user experience like improving nodetool output or reasonable 
optimizations.  Merging in big features at the very end of the merge window is 
a really great idea to have dozens of follow up bug fix releases that nobody 
considers stable, where the Coli conjecture always wins.  IMO, it would be 
better / more responsible to merge them into trunk *after* we branch for 4.0. 
Yes, that makes the next release less exciting, but I really don’t think 
“exciting” is what we’re shooting for.  I’m more in favor of stable.

Regarding supporting 3.0 / 3.11, since we’re talking about feature freezing 4.0 
2 months from now, and releasing it *sometime* after that, then add 6 months, 
we’re talking about close to an extra year of 3.0 support.  People are, of 
course, free to continue patching 3.0, back porting fixes, etc, but I am 
completely OK with saying there’s only 9 more months of support starting today.

I’m also in the go straight to 3.11 camp.  I see no reason to upgrade to only 
3.0 if you’re on 2.x.  

Jon

> On Apr 4, 2018, at 6:29 AM, Josh McKenzie <jmcken...@apache.org> wrote:
> 
>> 
>> 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 "Roadmap for
> 4.0" and has been concerned with how we get 4.0 out the door. I don't think
> it's implicit that whatever strategy we settle on for 4.0 is intended to
> apply to subsequent releases, since the 3.0.X to 3.X to 4.0
> relationship/delta is different than a 4.0 to 5.0 can be expected to be.
> 
> 
>> sidenote: 3.10 was released in January 2017, and while the changes list for
>> 4.0 is getting quite large there's not much there that's going to win over
>> users. It's mostly refactorings and improvements that affect developers
>> more so than users.
> 
> If you assume most 3. users are on 3.10, this argument makes sense. I
> believe a majority are on 3.0.X or 2.1/2.2, which leaves a minority looking
> at the small delta from 3.10 to 4.0 in the current form.
> 
> 
> 
> On Wed, Apr 4, 2018 at 8:25 AM, kurt greaves <k...@instaclustr.com> wrote:
> 
>>> 
>>> 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 pretty clear that this was about compiling a list of
>> things that people are currently working on and can commit to getting
>> finished soon (which should be a relatively small list considering the
>> limited number of full time contributors).
>> 
>> Of course, we should probably (re-(re-(re-)))start a discussion on release
>>> "strategy" in parallel because it doesn't seem we have one right now, but
>>> that's imo a discussion we should keep separate.
>> 
>> 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. I don't think it's possible to have a separate discussion
>> on these two things as the release strategy has a pretty big influence on
>> how 4.0 is released.
>> 
>> I'm all for a feature freeze and KISS, but I feel that this really needs a
>> bit more thought before we just jump in and set another precedent for
>> future releases. IMO the Cassandra project has had a seriously bad track
>> record of releasing major versions in the past, and we should probably work
>> at resolving that properly, rather than just continuing the current "let's
>> just try something new every time without really thinking about it".
>> 
>> Some points:
>> 
>>   1.  This strategy means that we don't care about what improvements
>>   actually make it into any given major version. This means that we will
>> have
>>   major releases with nothing/very little desirable for users, and thus
>>   little reason to upgrade other than to stay on a supported version (

Re: Roadmap for 4.0

[Josh McKenzie]

>
> 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 "Roadmap for
4.0" and has been concerned with how we get 4.0 out the door. I don't think
it's implicit that whatever strategy we settle on for 4.0 is intended to
apply to subsequent releases, since the 3.0.X to 3.X to 4.0
relationship/delta is different than a 4.0 to 5.0 can be expected to be.


> sidenote: 3.10 was released in January 2017, and while the changes list for
> 4.0 is getting quite large there's not much there that's going to win over
> users. It's mostly refactorings and improvements that affect developers
> more so than users.

If you assume most 3. users are on 3.10, this argument makes sense. I
believe a majority are on 3.0.X or 2.1/2.2, which leaves a minority looking
at the small delta from 3.10 to 4.0 in the current form.



On Wed, Apr 4, 2018 at 8:25 AM, kurt greaves <k...@instaclustr.com> wrote:

> >
> > 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 pretty clear that this was about compiling a list of
> things that people are currently working on and can commit to getting
> finished soon (which should be a relatively small list considering the
> limited number of full time contributors).
>
> Of course, we should probably (re-(re-(re-)))start a discussion on release
> > "strategy" in parallel because it doesn't seem we have one right now, but
> > that's imo a discussion we should keep separate.
>
> 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. I don't think it's possible to have a separate discussion
> on these two things as the release strategy has a pretty big influence on
> how 4.0 is released.
>
> I'm all for a feature freeze and KISS, but I feel that this really needs a
> bit more thought before we just jump in and set another precedent for
> future releases. IMO the Cassandra project has had a seriously bad track
> record of releasing major versions in the past, and we should probably work
> at resolving that properly, rather than just continuing the current "let's
> just try something new every time without really thinking about it".
>
> Some points:
>
>1.  This strategy means that we don't care about what improvements
>actually make it into any given major version. This means that we will
> have
>major releases with nothing/very little desirable for users, and thus
>little reason to upgrade other than to stay on a supported version (from
>experience this isn't terribly important to users of a database). I
> think
>this inevitably leads to supporting more versions than necessary, and in
>general a pretty poor experience for users as we spend more time
> fighting
>bugs in production rather than before we do a release (purely because of
>increased frequency of releases).
>2. We'll always be driven by feature deadlines, which for the most part
>is fine, as long as we handle verification/quality assurance/release
>candidates appropriately. The main problem here though is that we don't
>really know what's going to be in a certain release until we hit the
>freeze, and what's in it may not really make sense at that point in
> time.
>3. We'll pump out major versions fairly regularly and end up with even
>more users that are on EOL versions with complex upgrade paths to get
> to a
>supported version or a version with a feature they need (think all those
>people still out there on 1.2).
>4. This strategy has the positive effect of allowing developers to see
>their changes in production faster, but OTOH if no one really uses the
> new
>versions this doesn't really happen anyway.
>
> I'd also note that if people hadn't noticed, users tend to be pretty
> reluctant to upgrade their databases (hello everyone still running 2.1).
> This tends to be the nature of a database to some extent (if it works on
> version x, why upgrade to y?). IMO it would make more sense to support less
> versions but for a longer period of time. I'm sure most users would
> appreciate 2 years of bug fixes for only 

Re: Roadmap for 4.0

[kurt greaves]

>
> 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 pretty clear that this was about compiling a list of
things that people are currently working on and can commit to getting
finished soon (which should be a relatively small list considering the
limited number of full time contributors).

Of course, we should probably (re-(re-(re-)))start a discussion on release
> "strategy" in parallel because it doesn't seem we have one right now, but
> that's imo a discussion we should keep separate.

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. I don't think it's possible to have a separate discussion
on these two things as the release strategy has a pretty big influence on
how 4.0 is released.

I'm all for a feature freeze and KISS, but I feel that this really needs a
bit more thought before we just jump in and set another precedent for
future releases. IMO the Cassandra project has had a seriously bad track
record of releasing major versions in the past, and we should probably work
at resolving that properly, rather than just continuing the current "let's
just try something new every time without really thinking about it".

Some points:

   1.  This strategy means that we don't care about what improvements
   actually make it into any given major version. This means that we will have
   major releases with nothing/very little desirable for users, and thus
   little reason to upgrade other than to stay on a supported version (from
   experience this isn't terribly important to users of a database). I think
   this inevitably leads to supporting more versions than necessary, and in
   general a pretty poor experience for users as we spend more time fighting
   bugs in production rather than before we do a release (purely because of
   increased frequency of releases).
   2. We'll always be driven by feature deadlines, which for the most part
   is fine, as long as we handle verification/quality assurance/release
   candidates appropriately. The main problem here though is that we don't
   really know what's going to be in a certain release until we hit the
   freeze, and what's in it may not really make sense at that point in time.
   3. We'll pump out major versions fairly regularly and end up with even
   more users that are on EOL versions with complex upgrade paths to get to a
   supported version or a version with a feature they need (think all those
   people still out there on 1.2).
   4. This strategy has the positive effect of allowing developers to see
   their changes in production faster, but OTOH if no one really uses the new
   versions this doesn't really happen anyway.

I'd also note that if people hadn't noticed, users tend to be pretty
reluctant to upgrade their databases (hello everyone still running 2.1).
This tends to be the nature of a database to some extent (if it works on
version x, why upgrade to y?). IMO it would make more sense to support less
versions but for a longer period of time. I'm sure most users would
appreciate 2 years of bug fixes for only 2 branches with a new major
approximately every 2 years. Databases don't move that fast, there's not
much desirable in a feature release every year for users.

sidenote: 3.10 was released in January 2017, and while the changes list for
4.0 is getting quite large there's not much there that's going to win over
users. It's mostly refactorings and improvements that affect developers
more so than users. I'm really interested in why people believe there is an
actual benefit in pumping out feature releases on a yearly basis. Who
exactly does that benefit? From what I know, the majority of "major" users
are still backporting stuff they want to 2.1, so why rush releasing more
versions?

Regardless of whatever plan we do end up following it would still be
> valuable to have a list of tickets for 4.0 which is the overall goal of
> this email - so let's not get too worked up on the details just yet (save
> that for after I summarise/follow up).
>
 lol. dreaming.

On 4 April 2018 at 10:38, Aleksey Yeshchenko  wrote:

> 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 (date
> TBD).
>

RE: Roadmap for 4.0

[Steinmaurer, Thomas]

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 stages this year 
before deploying into production. Production-wise, we are still "stuck" and 
(more or less) happy with 2.1.

Thomas

-Original Message-
From: alek...@apple.com [mailto:alek...@apple.com]
Sent: Mittwoch, 04. April 2018 12:38
To: dev@cassandra.apache.org
Subject: 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 release (date TBD).
The contents of this e-mail are intended for the named addressee only. It 
contains information that may be confidential. Unless you are the named 
addressee or an authorized designee, you may not copy or use it, or disclose it 
to anyone else. If you received it in error please notify us immediately and 
then destroy it. Dynatrace Austria GmbH (registration number FN 91482h) is a 
company registered in Linz whose registered office is at 4040 Linz, Austria, 
Freistädterstraße 313

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Roadmap for 4.0

[Aleksey Yeshchenko]

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 (date 
TBD). 

Re: Roadmap for 4.0

[Josh McKenzie]

>
> A hard date for a feature freeze makes sense, a hard date for a release
> does not.

 Strongly agree. We should also collectively define what "Done" looks like
post freeze so we don't end up in bike-shedding hell like we have in the
past.



On Tue, Apr 3, 2018 at 5:35 PM, Jeff Jirsa  wrote:

> A hard date for a feature freeze makes sense, a hard date for a release
> does not.
>
> --
> Jeff Jirsa
>
>
> > On Apr 3, 2018, at 2:29 PM, Michael Shuler 
> wrote:
> >
> > On 04/03/2018 03:51 PM, Nate McCall wrote:
> >>> My concrete proposal would be to declare a feature freeze for 4.0 in 2
> >>> months,
> >>> so say June 1th. That leave some time for finishing features that are
> in
> >>> progress, but not too much to get derailed. And let's be strict on that
> >>> freeze.
> >>
> >> I quite like this suggestion. Thanks, Sylvain.
> >
> > Should we s/TBD/somedate/ on the downloads page and get the word out?
> >
> > Apache Cassandra 3.0 is supported until 6 months after 4.0 release (date
> > TBD).
> > Apache Cassandra 2.2 is supported until 4.0 release (date TBD).
> > Apache Cassandra 2.1 is supported until 4.0 release (date TBD) with
> > critical fixes only.
> >
> > --
> > Kind regards,
> > Michael
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: Roadmap for 4.0

[Jeff Jirsa]

A hard date for a feature freeze makes sense, a hard date for a release does 
not.

-- 
Jeff Jirsa


> On Apr 3, 2018, at 2:29 PM, Michael Shuler  wrote:
> 
> On 04/03/2018 03:51 PM, Nate McCall wrote:
>>> My concrete proposal would be to declare a feature freeze for 4.0 in 2
>>> months,
>>> so say June 1th. That leave some time for finishing features that are in
>>> progress, but not too much to get derailed. And let's be strict on that
>>> freeze.
>> 
>> I quite like this suggestion. Thanks, Sylvain.
> 
> Should we s/TBD/somedate/ on the downloads page and get the word out?
> 
> Apache Cassandra 3.0 is supported until 6 months after 4.0 release (date
> TBD).
> Apache Cassandra 2.2 is supported until 4.0 release (date TBD).
> Apache Cassandra 2.1 is supported until 4.0 release (date TBD) with
> critical fixes only.
> 
> -- 
> Kind regards,
> Michael
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
> 

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Roadmap for 4.0

[Michael Shuler]

On 04/03/2018 03:51 PM, Nate McCall wrote:
>> My concrete proposal would be to declare a feature freeze for 4.0 in 2
>> months,
>> so say June 1th. That leave some time for finishing features that are in
>> progress, but not too much to get derailed. And let's be strict on that
>> freeze.
> 
> I quite like this suggestion. Thanks, Sylvain.

Should we s/TBD/somedate/ on the downloads page and get the word out?

Apache Cassandra 3.0 is supported until 6 months after 4.0 release (date
TBD).
Apache Cassandra 2.2 is supported until 4.0 release (date TBD).
Apache Cassandra 2.1 is supported until 4.0 release (date TBD) with
critical fixes only.

-- 
Kind regards,
Michael

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Roadmap for 4.0

[Nate McCall]

> My concrete proposal would be to declare a feature freeze for 4.0 in 2
> months,
> so say June 1th. That leave some time for finishing features that are in
> progress, but not too much to get derailed. And let's be strict on that
> freeze.

I quite like this suggestion. Thanks, Sylvain.

> After that, we'll see how quickly we can get stuffs to stabilize but I'd
> suggest aiming for an alpha 3-4 weeks after that.

Yes. We've had folks step up and offer to dog-food 4.0 and can
probably solicit some more with some outreach.

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Roadmap for 4.0

[Jon Haddad]

gt;>>>> 
>>>>>>  - https://issues.apache.org/jira/browse/CASSANDRA-13951
>>>>>>  - https://issues.apache.org/jira/browse/CASSANDRA-13994
>>>>>>  - https://issues.apache.org/jira/browse/CASSANDRA-12042
>>>>>> 
>>>>>> In terms of major tickets that I would like to see land:
>>>>>> 
>>>>>>  - https://issues.apache.org/jira/browse/CASSANDRA-7622 Virtual
>>> Tables
>>>>>>  - https://issues.apache.org/jira/browse/CASSANDRA-13628 Internode
>>>> netty
>>>>>>  - https://issues.apache.org/jira/browse/CASSANDRA-13475 Pluggable
>>>>>> Storage
>>>>>>  - https://issues.apache.org/jira/browse/CASSANDRA-9633 SSTable
>>>>>> encryption
>>>>>> 
>>>>>> Ben
>>>>>> 
>>>>>>> On Mon, Feb 12, 2018 at 11:26 PM Jeff Jirsa <jji...@gmail.com>
>>> wrote:
>>>>>>> 
>>>>>>> 
>>>>>>> Advantages of cutting a release sooner than later:
>>>>>>> 1) The project needs to constantly progress forward. Releases are
>> the
>>>>>> most
>>>>>>> visible part of that.
>>>>>>> 2) Having a huge changelog in a release increases the likelihood of
>>>> bugs
>>>>>>> that take time to find.
>>>>>>> 
>>>>>>> Advantages of a slower release:
>>>>>>> 1) We don't do major versions often, and when we do breaking
>> changes
>>>>>>> (protocol, file format, etc), we should squeeze in as many as
>>> possible
>>>> to
>>>>>>> avoid having to roll new majors
>>>>>>> 2) There are probably few people actually running 3.11 at scale, so
>>>>>>> probably few people actually testing trunk.
>>>>>>> 
>>>>>>> In terms of "big" changes I'd like to see land, the ones that come
>> to
>>>>>> mind
>>>>>>> are:
>>>>>>> 
>>>>>>> https://issues.apache.org/jira/browse/CASSANDRA-9754 - "Birch"
>>>> (changes
>>>>>>> file format)
>>>>>>> https://issues.apache.org/jira/browse/CASSANDRA-13442 - Transient
>>>>>>> Replicas (probably adds new replication strategy or similar)
>>>>>>> https://issues.apache.org/jira/browse/CASSANDRA-13628 - Rest of
>> the
>>>>>>> internode netty stuff (no idea if this changes internode stuff,
>> but I
>>>> bet
>>>>>>> it's a lot easier if it lands on a major)
>>>>>>> https://issues.apache.org/jira/browse/CASSANDRA-7622 - Virtual
>>> Tables
>>>>>>> (selfish inclusion, probably doesn't need to be a major at all,
>> and I
>>>>>>> wouldn't even lose sleep if it slips, but I'd like to see it land)
>>>>>>> 
>>>>>>> Stuff I'm ok with slipping to 4.X or 5.0, but probably needs to
>> land
>>>> on a
>>>>>>> major because we'll change something big (like gossip, or the way
>>>> schema
>>>>>> is
>>>>>>> passed, etc):
>>>>>>> 
>>>>>>> https://issues.apache.org/jira/browse/CASSANDRA-9667 - Strongly
>>>>>>> consistent membership
>>>>>>> https://issues.apache.org/jira/browse/CASSANDRA-10699 - Strongly
>>>>>>> consistent schema
>>>>>>> 
>>>>>>> All that said, what I really care about is building confidence in
>> the
>>>>>>> release, which means an extended testing cycle. If all of those
>>> patches
>>>>>>> landed tomorrow, I'd still expect us to be months away from a
>>> release,
>>>>>>> because we need to bake the next major - there's too many changes
>> to
>>>>>> throw
>>>>>>> out an alpha/beta/rc and hope someone actually runs it.
>>>>>>> 
>>>>>>> I don't believe Q3/Q4 is realistic, but I may be biased (or jaded).
>>>> It's
>>>>>>> possible Q3/Q4 alpha/beta is realistic, but definitely not a
>> release.
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 

Re: Roadmap for 4.0

[Ben Bromhead]

ji...@gmail.com>
> > wrote:
> > > >>>
> > > >>>
> > > >>> Advantages of cutting a release sooner than later:
> > > >>> 1) The project needs to constantly progress forward. Releases are
> the
> > > >> most
> > > >>> visible part of that.
> > > >>> 2) Having a huge changelog in a release increases the likelihood of
> > > bugs
> > > >>> that take time to find.
> > > >>>
> > > >>> Advantages of a slower release:
> > > >>> 1) We don't do major versions often, and when we do breaking
> changes
> > > >>> (protocol, file format, etc), we should squeeze in as many as
> > possible
> > > to
> > > >>> avoid having to roll new majors
> > > >>> 2) There are probably few people actually running 3.11 at scale, so
> > > >>> probably few people actually testing trunk.
> > > >>>
> > > >>> In terms of "big" changes I'd like to see land, the ones that come
> to
> > > >> mind
> > > >>> are:
> > > >>>
> > > >>> https://issues.apache.org/jira/browse/CASSANDRA-9754 - "Birch"
> > > (changes
> > > >>> file format)
> > > >>> https://issues.apache.org/jira/browse/CASSANDRA-13442 - Transient
> > > >>> Replicas (probably adds new replication strategy or similar)
> > > >>> https://issues.apache.org/jira/browse/CASSANDRA-13628 - Rest of
> the
> > > >>> internode netty stuff (no idea if this changes internode stuff,
> but I
> > > bet
> > > >>> it's a lot easier if it lands on a major)
> > > >>> https://issues.apache.org/jira/browse/CASSANDRA-7622 - Virtual
> > Tables
> > > >>> (selfish inclusion, probably doesn't need to be a major at all,
> and I
> > > >>> wouldn't even lose sleep if it slips, but I'd like to see it land)
> > > >>>
> > > >>> Stuff I'm ok with slipping to 4.X or 5.0, but probably needs to
> land
> > > on a
> > > >>> major because we'll change something big (like gossip, or the way
> > > schema
> > > >> is
> > > >>> passed, etc):
> > > >>>
> > > >>> https://issues.apache.org/jira/browse/CASSANDRA-9667 - Strongly
> > > >>> consistent membership
> > > >>> https://issues.apache.org/jira/browse/CASSANDRA-10699 - Strongly
> > > >>> consistent schema
> > > >>>
> > > >>> All that said, what I really care about is building confidence in
> the
> > > >>> release, which means an extended testing cycle. If all of those
> > patches
> > > >>> landed tomorrow, I'd still expect us to be months away from a
> > release,
> > > >>> because we need to bake the next major - there's too many changes
> to
> > > >> throw
> > > >>> out an alpha/beta/rc and hope someone actually runs it.
> > > >>>
> > > >>> I don't believe Q3/Q4 is realistic, but I may be biased (or jaded).
> > > It's
> > > >>> possible Q3/Q4 alpha/beta is realistic, but definitely not a
> release.
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>> On Sun, Feb 11, 2018 at 8:29 PM, kurt greaves <
> k...@instaclustr.com>
> > > >>> wrote:
> > > >>>
> > > >>>> Hi friends,
> > > >>>> *TL;DR: Making a plan for 4.0, ideally everyone interested should
> > > >> provide
> > > >>>> up to two lists, one for tickets they can contribute resources to
> > > >> getting
> > > >>>> finished, and one for features they think would be desirable for
> > 4.0,
> > > >> but
> > > >>>> not necessarily have the resources to commit to helping with.*
> > > >>>>
> > > >>>> So we had that Roadmap for 4.0 discussion last year, but there was
> > > never
> > > >>>> a conclusion or a plan that came from it. Times getting on and the
> > > >> changes
> > > >>>> list for 4.0 is getting pretty big. I'm thinking it would probably
> > > make
> > > >>>> sense to define some goals t

Re: Roadmap for 4.0

[DuyHai Doan]

ind, is similar to the 3.0 approach
> >>   https://mail-archives.apache.org/mod_mbox/cassandra-dev/
> >> 201503.mbox/%3CCALdd-zjAyiTbZksMeq2LxGwLF5LPhoi_
> >> 4vsjy8JBHBRnsxH%3D8A%40mail.gmail.com%3E,
> >>   but without the subsequent tick-tock :)
> >>
> >> There are currently 3 open blockers tagged 4.0, some are old and
> probably
> >> not really blockers anymore, there are other tickets that may/should be
> >> blockers on 4.0:
> >>
> >>   - https://issues.apache.org/jira/browse/CASSANDRA-13951
> >>   - https://issues.apache.org/jira/browse/CASSANDRA-13994
> >>   - https://issues.apache.org/jira/browse/CASSANDRA-12042
> >>
> >> In terms of major tickets that I would like to see land:
> >>
> >>   - https://issues.apache.org/jira/browse/CASSANDRA-7622 Virtual Tables
> >>   - https://issues.apache.org/jira/browse/CASSANDRA-13628 Internode
> netty
> >>   - https://issues.apache.org/jira/browse/CASSANDRA-13475 Pluggable
> >> Storage
> >>   - https://issues.apache.org/jira/browse/CASSANDRA-9633 SSTable
> >> encryption
> >>
> >> Ben
> >>
> >>> On Mon, Feb 12, 2018 at 11:26 PM Jeff Jirsa <jji...@gmail.com> wrote:
> >>>
> >>>
> >>> Advantages of cutting a release sooner than later:
> >>> 1) The project needs to constantly progress forward. Releases are the
> >> most
> >>> visible part of that.
> >>> 2) Having a huge changelog in a release increases the likelihood of
> bugs
> >>> that take time to find.
> >>>
> >>> Advantages of a slower release:
> >>> 1) We don't do major versions often, and when we do breaking changes
> >>> (protocol, file format, etc), we should squeeze in as many as possible
> to
> >>> avoid having to roll new majors
> >>> 2) There are probably few people actually running 3.11 at scale, so
> >>> probably few people actually testing trunk.
> >>>
> >>> In terms of "big" changes I'd like to see land, the ones that come to
> >> mind
> >>> are:
> >>>
> >>> https://issues.apache.org/jira/browse/CASSANDRA-9754 - "Birch"
> (changes
> >>> file format)
> >>> https://issues.apache.org/jira/browse/CASSANDRA-13442 - Transient
> >>> Replicas (probably adds new replication strategy or similar)
> >>> https://issues.apache.org/jira/browse/CASSANDRA-13628 - Rest of the
> >>> internode netty stuff (no idea if this changes internode stuff, but I
> bet
> >>> it's a lot easier if it lands on a major)
> >>> https://issues.apache.org/jira/browse/CASSANDRA-7622 - Virtual Tables
> >>> (selfish inclusion, probably doesn't need to be a major at all, and I
> >>> wouldn't even lose sleep if it slips, but I'd like to see it land)
> >>>
> >>> Stuff I'm ok with slipping to 4.X or 5.0, but probably needs to land
> on a
> >>> major because we'll change something big (like gossip, or the way
> schema
> >> is
> >>> passed, etc):
> >>>
> >>> https://issues.apache.org/jira/browse/CASSANDRA-9667 - Strongly
> >>> consistent membership
> >>> https://issues.apache.org/jira/browse/CASSANDRA-10699 - Strongly
> >>> consistent schema
> >>>
> >>> All that said, what I really care about is building confidence in the
> >>> release, which means an extended testing cycle. If all of those patches
> >>> landed tomorrow, I'd still expect us to be months away from a release,
> >>> because we need to bake the next major - there's too many changes to
> >> throw
> >>> out an alpha/beta/rc and hope someone actually runs it.
> >>>
> >>> I don't believe Q3/Q4 is realistic, but I may be biased (or jaded).
> It's
> >>> possible Q3/Q4 alpha/beta is realistic, but definitely not a release.
> >>>
> >>>
> >>>
> >>>
> >>> On Sun, Feb 11, 2018 at 8:29 PM, kurt greaves <k...@instaclustr.com>
> >>> wrote:
> >>>
> >>>> Hi friends,
> >>>> *TL;DR: Making a plan for 4.0, ideally everyone interested should
> >> provide
> >>>> up to two lists, one for tickets they can contribute resources to
> >> getting
> >>>> finished, and one for features they think would be desirable for 4.0,
> >> but
> >>>> not necessarily have the res

Re: Roadmap for 4.0

[Jeff Jirsa]

CASSANDRA-9633 SSTable
>> encryption
>> 
>> Ben
>> 
>>> On Mon, Feb 12, 2018 at 11:26 PM Jeff Jirsa <jji...@gmail.com> wrote:
>>> 
>>> 
>>> Advantages of cutting a release sooner than later:
>>> 1) The project needs to constantly progress forward. Releases are the
>> most
>>> visible part of that.
>>> 2) Having a huge changelog in a release increases the likelihood of bugs
>>> that take time to find.
>>> 
>>> Advantages of a slower release:
>>> 1) We don't do major versions often, and when we do breaking changes
>>> (protocol, file format, etc), we should squeeze in as many as possible to
>>> avoid having to roll new majors
>>> 2) There are probably few people actually running 3.11 at scale, so
>>> probably few people actually testing trunk.
>>> 
>>> In terms of "big" changes I'd like to see land, the ones that come to
>> mind
>>> are:
>>> 
>>> https://issues.apache.org/jira/browse/CASSANDRA-9754 - "Birch" (changes
>>> file format)
>>> https://issues.apache.org/jira/browse/CASSANDRA-13442 - Transient
>>> Replicas (probably adds new replication strategy or similar)
>>> https://issues.apache.org/jira/browse/CASSANDRA-13628 - Rest of the
>>> internode netty stuff (no idea if this changes internode stuff, but I bet
>>> it's a lot easier if it lands on a major)
>>> https://issues.apache.org/jira/browse/CASSANDRA-7622 - Virtual Tables
>>> (selfish inclusion, probably doesn't need to be a major at all, and I
>>> wouldn't even lose sleep if it slips, but I'd like to see it land)
>>> 
>>> Stuff I'm ok with slipping to 4.X or 5.0, but probably needs to land on a
>>> major because we'll change something big (like gossip, or the way schema
>> is
>>> passed, etc):
>>> 
>>> https://issues.apache.org/jira/browse/CASSANDRA-9667 - Strongly
>>> consistent membership
>>> https://issues.apache.org/jira/browse/CASSANDRA-10699 - Strongly
>>> consistent schema
>>> 
>>> All that said, what I really care about is building confidence in the
>>> release, which means an extended testing cycle. If all of those patches
>>> landed tomorrow, I'd still expect us to be months away from a release,
>>> because we need to bake the next major - there's too many changes to
>> throw
>>> out an alpha/beta/rc and hope someone actually runs it.
>>> 
>>> I don't believe Q3/Q4 is realistic, but I may be biased (or jaded). It's
>>> possible Q3/Q4 alpha/beta is realistic, but definitely not a release.
>>> 
>>> 
>>> 
>>> 
>>> On Sun, Feb 11, 2018 at 8:29 PM, kurt greaves <k...@instaclustr.com>
>>> wrote:
>>> 
>>>> Hi friends,
>>>> *TL;DR: Making a plan for 4.0, ideally everyone interested should
>> provide
>>>> up to two lists, one for tickets they can contribute resources to
>> getting
>>>> finished, and one for features they think would be desirable for 4.0,
>> but
>>>> not necessarily have the resources to commit to helping with.*
>>>> 
>>>> So we had that Roadmap for 4.0 discussion last year, but there was never
>>>> a conclusion or a plan that came from it. Times getting on and the
>> changes
>>>> list for 4.0 is getting pretty big. I'm thinking it would probably make
>>>> sense to define some goals to getting 4.0 released/have an actual plan.
>> 4.0
>>>> is already going to be quite an unwieldy release with a lot of testing
>>>> required.
>>>> 
>>>> Note: the following is open to discussion, if people don't like the plan
>>>> feel free to speak up. But in the end it's a pretty basic plan and I
>> don't
>>>> think we should over-complicate it, I also don't want to end up in a
>>>> discussion where we "make a plan to make a plan". Regardless of whatever
>>>> plan we do end up following it would still be valuable to have a list of
>>>> tickets for 4.0 which is the overall goal of this email - so let's not
>> get
>>>> too worked up on the details just yet (save that for after I
>>>> summarise/follow up).
>>>> 
>>>> // TODO
>>>> I think the best way to go about this would be for us to come up with a
>>>> list of JIRA's that we want included in 4.0, tag these as 4.0, and all
>>>> other improvements as 4.x. We can then aim to release 4.

Re: Roadmap for 4.0

[Jason Brown]

 Advantages of a slower release:
> > 1) We don't do major versions often, and when we do breaking changes
> > (protocol, file format, etc), we should squeeze in as many as possible to
> > avoid having to roll new majors
> > 2) There are probably few people actually running 3.11 at scale, so
> > probably few people actually testing trunk.
> >
> > In terms of "big" changes I'd like to see land, the ones that come to
> mind
> > are:
> >
> > https://issues.apache.org/jira/browse/CASSANDRA-9754 - "Birch" (changes
> > file format)
> > https://issues.apache.org/jira/browse/CASSANDRA-13442 - Transient
> > Replicas (probably adds new replication strategy or similar)
> > https://issues.apache.org/jira/browse/CASSANDRA-13628 - Rest of the
> > internode netty stuff (no idea if this changes internode stuff, but I bet
> > it's a lot easier if it lands on a major)
> > https://issues.apache.org/jira/browse/CASSANDRA-7622 - Virtual Tables
> > (selfish inclusion, probably doesn't need to be a major at all, and I
> > wouldn't even lose sleep if it slips, but I'd like to see it land)
> >
> > Stuff I'm ok with slipping to 4.X or 5.0, but probably needs to land on a
> > major because we'll change something big (like gossip, or the way schema
> is
> > passed, etc):
> >
> > https://issues.apache.org/jira/browse/CASSANDRA-9667 - Strongly
> > consistent membership
> > https://issues.apache.org/jira/browse/CASSANDRA-10699 - Strongly
> > consistent schema
> >
> > All that said, what I really care about is building confidence in the
> > release, which means an extended testing cycle. If all of those patches
> > landed tomorrow, I'd still expect us to be months away from a release,
> > because we need to bake the next major - there's too many changes to
> throw
> > out an alpha/beta/rc and hope someone actually runs it.
> >
> > I don't believe Q3/Q4 is realistic, but I may be biased (or jaded). It's
> > possible Q3/Q4 alpha/beta is realistic, but definitely not a release.
> >
> >
> >
> >
> > On Sun, Feb 11, 2018 at 8:29 PM, kurt greaves <k...@instaclustr.com>
> > wrote:
> >
> >> Hi friends,
> >> *TL;DR: Making a plan for 4.0, ideally everyone interested should
> provide
> >> up to two lists, one for tickets they can contribute resources to
> getting
> >> finished, and one for features they think would be desirable for 4.0,
> but
> >> not necessarily have the resources to commit to helping with.*
> >>
> >> So we had that Roadmap for 4.0 discussion last year, but there was never
> >> a conclusion or a plan that came from it. Times getting on and the
> changes
> >> list for 4.0 is getting pretty big. I'm thinking it would probably make
> >> sense to define some goals to getting 4.0 released/have an actual plan.
> 4.0
> >> is already going to be quite an unwieldy release with a lot of testing
> >> required.
> >>
> >> Note: the following is open to discussion, if people don't like the plan
> >> feel free to speak up. But in the end it's a pretty basic plan and I
> don't
> >> think we should over-complicate it, I also don't want to end up in a
> >> discussion where we "make a plan to make a plan". Regardless of whatever
> >> plan we do end up following it would still be valuable to have a list of
> >> tickets for 4.0 which is the overall goal of this email - so let's not
> get
> >> too worked up on the details just yet (save that for after I
> >> summarise/follow up).
> >>
> >> // TODO
> >> I think the best way to go about this would be for us to come up with a
> >> list of JIRA's that we want included in 4.0, tag these as 4.0, and all
> >> other improvements as 4.x. We can then aim to release 4.0 once all the
> 4.0
> >> tagged tickets (+bug fixes/blockers) are complete.
> >>
> >> Now, the catch is that we obviously don't want to include too many
> >> tickets in 4.0, but at the same time we want to make sure 4.0 has an
> >> appealing feature set for both users/operators/developers. To minimise
> >> scope creep I think the following strategy will help:
> >>
> >> We should maintain two lists:
> >>
> >>1. JIRA's that people want in 4.0 and can commit resources to getting
> >>them implemented in 4.0.
> >>2. JIRA's that people simply think would be desirable for 4.0, but
> >>currently don't have anyone assigned to them or planned assignment.
> It
> >> 

Re: Roadmap for 4.0

[Ben Bromhead]

ips, but I'd like to see it land)
>
> Stuff I'm ok with slipping to 4.X or 5.0, but probably needs to land on a
> major because we'll change something big (like gossip, or the way schema is
> passed, etc):
>
> https://issues.apache.org/jira/browse/CASSANDRA-9667 - Strongly
> consistent membership
> https://issues.apache.org/jira/browse/CASSANDRA-10699 - Strongly
> consistent schema
>
> All that said, what I really care about is building confidence in the
> release, which means an extended testing cycle. If all of those patches
> landed tomorrow, I'd still expect us to be months away from a release,
> because we need to bake the next major - there's too many changes to throw
> out an alpha/beta/rc and hope someone actually runs it.
>
> I don't believe Q3/Q4 is realistic, but I may be biased (or jaded). It's
> possible Q3/Q4 alpha/beta is realistic, but definitely not a release.
>
>
>
>
> On Sun, Feb 11, 2018 at 8:29 PM, kurt greaves <k...@instaclustr.com>
> wrote:
>
>> Hi friends,
>> *TL;DR: Making a plan for 4.0, ideally everyone interested should provide
>> up to two lists, one for tickets they can contribute resources to getting
>> finished, and one for features they think would be desirable for 4.0, but
>> not necessarily have the resources to commit to helping with.*
>>
>> So we had that Roadmap for 4.0 discussion last year, but there was never
>> a conclusion or a plan that came from it. Times getting on and the changes
>> list for 4.0 is getting pretty big. I'm thinking it would probably make
>> sense to define some goals to getting 4.0 released/have an actual plan. 4.0
>> is already going to be quite an unwieldy release with a lot of testing
>> required.
>>
>> Note: the following is open to discussion, if people don't like the plan
>> feel free to speak up. But in the end it's a pretty basic plan and I don't
>> think we should over-complicate it, I also don't want to end up in a
>> discussion where we "make a plan to make a plan". Regardless of whatever
>> plan we do end up following it would still be valuable to have a list of
>> tickets for 4.0 which is the overall goal of this email - so let's not get
>> too worked up on the details just yet (save that for after I
>> summarise/follow up).
>>
>> // TODO
>> I think the best way to go about this would be for us to come up with a
>> list of JIRA's that we want included in 4.0, tag these as 4.0, and all
>> other improvements as 4.x. We can then aim to release 4.0 once all the 4.0
>> tagged tickets (+bug fixes/blockers) are complete.
>>
>> Now, the catch is that we obviously don't want to include too many
>> tickets in 4.0, but at the same time we want to make sure 4.0 has an
>> appealing feature set for both users/operators/developers. To minimise
>> scope creep I think the following strategy will help:
>>
>> We should maintain two lists:
>>
>>1. JIRA's that people want in 4.0 and can commit resources to getting
>>them implemented in 4.0.
>>2. JIRA's that people simply think would be desirable for 4.0, but
>>currently don't have anyone assigned to them or planned assignment. It
>>would probably make sense to label these with an additional tag in JIRA. 
>> *(User's
>>please feel free to point out what you want here)*
>>
>> From list 1 will come our source of truth for when we release 4.0. (after
>> aggregating a list I will summarise and we can vote on it).
>>
>> List 2 would be the "hopeful" list, where stories can be picked up from
>> if resourcing allows, or where someone comes along and decides it's good
>> enough to work on. I guess we can also base this on a vote system if we
>> reach the point of including some of them. (but for the moment it's purely
>> to get an idea of what users actually want).
>>
>> Please don't refrain from listing something that's already been
>> mentioned. The purpose is to get an idea of everyone's priorities/interests
>> and the resources available. We will need multiple resources for each
>> ticket, so anywhere we share an interest will make for a lot easier work
>> sharing.
>>
>> Note that we are only talking about improvements here. Bugs will be
>> treated the same as always, and major issues/regressions we'll need to fix
>> prior to 4.0 anyway.
>>
>> TIME FRAME
>> Generally I think it's a bad idea to commit to any hard deadline, but we
>> should have some time frames in mind. My idea would be to aim for a Q3/4
>> 2018 release, and as we go we just review the outstanding improvements and
>> deci