Rough roadmap for 4.0

[Nate McCall <zz...@gmail.com>]

It was brought up recently at the PMC level that our goals as a
project are not terribly clear.

This is a pretty good point as outside of Jira 'Fix Version' labelling
(which we actually suck less at compared to a lot of other ASF
projects) this really isnt tracked anywhere outside of general tribal
knowledge about who is working on what.

I would like to see us change this for two reasons:
- it's important we are clear with our community about where we are going
- we need to start working more closely together

To that end, i've put together a list (in no particular order) of the
*major* features in which I know folks are interested, have patches
coming, are awaiting design review, etc.:

- CASSANDRA-9425 Immutable node-local schema
- CASSANDRA-10699 Strongly consistent schema alterations
- CASSANDRA-12229 NIO streaming
- CASSANDRA-8457 NIO messaging
- CASSANDRA-12345 Gossip 2.0
- CASSANDRA-9754 Birch trees

What did I miss? What else would folks like to see? Specifically, this
should be "new stuff that could/will break things" given we are upping
the major version.

To be clear, it's not my intention to set this in stone and then beat
people about the head with it. More to have it there to point it at a
high level and foster better communication with our users from the
perspective of an open source project.

Please keep in mind that given everything else going on, I think it's
a fantastic idea to keep this list small and spend some time focusing
on stability particularly as we transition to a new release process.

-Nate

Re: Rough roadmap for 4.0

[Ben Bromhead <be...@instaclustr.com>]

s/materialised views/aggregates/

also we expect to have our first larger production 3.7 LTS cluster in the
next few months.

On Thu, 17 Nov 2016 at 15:38 Ben Bromhead <be...@instaclustr.com> wrote:

> We have a few small customers clusters running on our 3.7 LTS release...
> though we are not calling it production ready yet.
>
> We also just moved our internal metrics cluster from 2.2 to 3.7 LTS to get
> materialised views and to get some 3.x production experience.
>
> On Thu, 17 Nov 2016 at 14:27 Carlos Rolo <ro...@pythian.com> wrote:
>
> No Cluster in tick-tock.
>
> Actually reverted a couple to 3.0.x
>
> 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
> <http://linkedin.com/in/carlosjuzarterolo>*
> Mobile: +351 918 918 100 <+351%20918%20918%20100>
> www.pythian.com
>
> On Thu, Nov 17, 2016 at 10:20 PM, DuyHai Doan <do...@gmail.com>
> wrote:
>
> > Be very careful, there is a serious bug about AND/OR semantics, not
> solved
> > yet and not going to be solved any soon:
> > https://issues.apache.org/jira/browse/CASSANDRA-12674
> >
> > On Thu, Nov 17, 2016 at 7:32 PM, Jeff Jirsa <je...@crowdstrike.com>
> > wrote:
> >
> > >
> > > We’ll be voting in the very near future on timing of major releases and
> > > release strategy. 4.0 won’t happen until that vote takes place.
> > >
> > > But since you asked, I have ONE tick/tock (3.9) cluster being qualified
> > > for production because it needs SASI.
> > >
> > > - Jeff
> > >
> > > On 11/17/16, 9:59 AM, "Jonathan Haddad" <jo...@jonhaddad.com> wrote:
> > >
> > > >I think it might be worth considering adopting the release strategy
> > before
> > > >4.0 release.  Are any PMC members putting tick tock in prod? Does
> anyone
> > > >even trust it?  What's the downside of changing the release cycle
> > > >independently from 4.0?
> > > >
> > > >On Thu, Nov 17, 2016 at 9:03 AM Jason Brown <ja...@gmail.com>
> > wrote:
> > > >
> > > >Jason,
> > > >
> > > >That's a separate topic, but we will have a different vote on how the
> > > >branching/release strategy should be for the future.
> > > >
> > > >On Thursday, November 17, 2016, jason zhao yang <
> > > zhaoyangsingapore@gmail.com
> > > >>
> > > >wrote:
> > > >
> > > >> Hi,
> > > >>
> > > >> Will we still use tick-tock release for 4.x and 4.0.x ?
> > > >>
> > > >> Stefan Podkowinski <spodxx@gmail.com <javascript:;>>于2016年11月16日周三
> > > >> 下午4:52写道：
> > > >>
> > > >> > From my understanding, this will also effect EOL dates of other
> > > >branches.
> > > >> >
> > > >> > "We will maintain the 2.2 stability series until 4.0 is released,
> > and
> > > >3.0
> > > >> > for six months after that.".
> > > >> >
> > > >> >
> > > >> > On Wed, Nov 16, 2016 at 5:34 AM, Nate McCall <zznate.m@gmail.com
> > > >> <javascript:;>> wrote:
> > > >> >
> > > >> > > Agreed. As long as we have a goal I don't see why we have to
> > adhere
> > > to
> > > >> > > arbitrary date for 4.0.
> > > >> > >
> > > >> > > On Nov 16, 2016 1:45 PM, "Aleksey Yeschenko" <
> > aleksey@datastax.com
> > > >> <javascript:;>>
> > > >> > wrote:
> > > >> > >
> > > >> > > > I’ll comment on the broader issue, but right now I want to
> > > elaborate
> > > >> on
> > > >> > > > 3.11/January/arbitrary cutoff date.
> > > >> > > >
> > > >> > > > Doesn’t matter what the original plan was. We should continue
> > with
> > > >> 3.X
> > > >> > > > until all the 4.0 blockers have been
> > > >> > > > committed - and there are quite a few of them remaining yet.
> > > >> > > >
> > > >> > > > So given all the holidays, and the tickets remaining, I’ll
> > > >personally
> > > >> > be
> > > >> > > > surprised if 4.0 comes out before
> > > >> > > > February/March and 3.13/3.14. Nor do I think it’s an issue.
> > > >> > > >
> > > >> > > > —
> > > >> > > > AY
> > > >> > > >
> > > >> > > > On 16 November 2016 at 00:39:03, Mick Semb Wever (
> > > >> > mick@thelastpickle.com <javascript:;>
> > > >> > > )
> > > >> > > > wrote:
> > > >> > > >
> > > >> > > > On 4 November 2016 at 13:47, Nate McCall <zznate.m@gmail.com
> > > >> <javascript:;>> wrote:
> > > >> > > >
> > > >> > > > > Specifically, this should be "new stuff that could/will
> break
> > > >> things"
> > > >> > > > > given we are upping
> > > >> > > > > the major version.
> > > >> > > > >
> > > >> > > >
> > > >> > > >
> > > >> > > > How does this co-ordinate with the tick-tock versioning¹
> leading
> > > up
> > > >> to
> > > >> > > the
> > > >> > > > 4.0 release?
> > > >> > > >
> > > >> > > > To just stop tick-tock and then say yeehaa let's jam in all
> the
> > > >> > breaking
> > > >> > > > changes we really want seems to be throwing away some of the
> > > learnt
> > > >> > > wisdom,
> > > >> > > > and not doing a very sane transition from tick-tock to
> > > >> > > > features/testing/stable². I really hope all this is done in a
> > way
> > > >> that
> > > >> > > > continues us down the path towards a stable-master.
> > > >> > > >
> > > >> > > > For example, are we fixing the release of 4.0 to November? or
> > > >> > continuing
> > > >> > > > tick-tocks until we complete the 4.0 roadmap? or starting the
> > > >> > > > features/testing/stable branching approach with 3.11?
> > > >> > > >
> > > >> > > >
> > > >> > > > Background:
> > > >> > > > ¹) Sylvain wrote in an earlier thread titled "A Home for 4.0"
> > > >> > > >
> > > >> > > > > And as 4.0 was initially supposed to come after 3.11, which
> is
> > > >> > coming,
> > > >> > > > it's probably time to have a home for those tickets.
> > > >> > > >
> > > >> > > > ²) The new versioning scheme slated for 4.0, per the
> "Proposal -
> > > >> 3.5.1"
> > > >> > > > thread
> > > >> > > >
> > > >> > > > > three branch plan with “features”, “testing”, and “stable”
> > > >starting
> > > >> > > with
> > > >> > > > 4.0?
> > > >> > > >
> > > >> > > >
> > > >> > > > Mick
> > > >> > > >
> > > >> > >
> > > >> >
> > > >>
> > >
> >
>
> --
>
>
> --
>
>
>
> --
> Ben Bromhead
> CTO | Instaclustr <https://www.instaclustr.com/>
> +1 650 284 9692 <(650)%20284-9692>
> Managed Cassandra / Spark on AWS, Azure and Softlayer
>
-- 
Ben Bromhead
CTO | Instaclustr <https://www.instaclustr.com/>
+1 650 284 9692
Managed Cassandra / Spark on AWS, Azure and Softlayer

Re: Rough roadmap for 4.0

[Ben Bromhead <be...@instaclustr.com>]

We have a few small customers clusters running on our 3.7 LTS release...
though we are not calling it production ready yet.

We also just moved our internal metrics cluster from 2.2 to 3.7 LTS to get
materialised views and to get some 3.x production experience.

On Thu, 17 Nov 2016 at 14:27 Carlos Rolo <ro...@pythian.com> wrote:

> No Cluster in tick-tock.
>
> Actually reverted a couple to 3.0.x
>
> 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
> <http://linkedin.com/in/carlosjuzarterolo>*
> Mobile: +351 918 918 100 <+351%20918%20918%20100>
> www.pythian.com
>
> On Thu, Nov 17, 2016 at 10:20 PM, DuyHai Doan <do...@gmail.com>
> wrote:
>
> > Be very careful, there is a serious bug about AND/OR semantics, not
> solved
> > yet and not going to be solved any soon:
> > https://issues.apache.org/jira/browse/CASSANDRA-12674
> >
> > On Thu, Nov 17, 2016 at 7:32 PM, Jeff Jirsa <je...@crowdstrike.com>
> > wrote:
> >
> > >
> > > We’ll be voting in the very near future on timing of major releases and
> > > release strategy. 4.0 won’t happen until that vote takes place.
> > >
> > > But since you asked, I have ONE tick/tock (3.9) cluster being qualified
> > > for production because it needs SASI.
> > >
> > > - Jeff
> > >
> > > On 11/17/16, 9:59 AM, "Jonathan Haddad" <jo...@jonhaddad.com> wrote:
> > >
> > > >I think it might be worth considering adopting the release strategy
> > before
> > > >4.0 release.  Are any PMC members putting tick tock in prod? Does
> anyone
> > > >even trust it?  What's the downside of changing the release cycle
> > > >independently from 4.0?
> > > >
> > > >On Thu, Nov 17, 2016 at 9:03 AM Jason Brown <ja...@gmail.com>
> > wrote:
> > > >
> > > >Jason,
> > > >
> > > >That's a separate topic, but we will have a different vote on how the
> > > >branching/release strategy should be for the future.
> > > >
> > > >On Thursday, November 17, 2016, jason zhao yang <
> > > zhaoyangsingapore@gmail.com
> > > >>
> > > >wrote:
> > > >
> > > >> Hi,
> > > >>
> > > >> Will we still use tick-tock release for 4.x and 4.0.x ?
> > > >>
> > > >> Stefan Podkowinski <spodxx@gmail.com <javascript:;>>于2016年11月16日周三
> > > >> 下午4:52写道：
> > > >>
> > > >> > From my understanding, this will also effect EOL dates of other
> > > >branches.
> > > >> >
> > > >> > "We will maintain the 2.2 stability series until 4.0 is released,
> > and
> > > >3.0
> > > >> > for six months after that.".
> > > >> >
> > > >> >
> > > >> > On Wed, Nov 16, 2016 at 5:34 AM, Nate McCall <zznate.m@gmail.com
> > > >> <javascript:;>> wrote:
> > > >> >
> > > >> > > Agreed. As long as we have a goal I don't see why we have to
> > adhere
> > > to
> > > >> > > arbitrary date for 4.0.
> > > >> > >
> > > >> > > On Nov 16, 2016 1:45 PM, "Aleksey Yeschenko" <
> > aleksey@datastax.com
> > > >> <javascript:;>>
> > > >> > wrote:
> > > >> > >
> > > >> > > > I’ll comment on the broader issue, but right now I want to
> > > elaborate
> > > >> on
> > > >> > > > 3.11/January/arbitrary cutoff date.
> > > >> > > >
> > > >> > > > Doesn’t matter what the original plan was. We should continue
> > with
> > > >> 3.X
> > > >> > > > until all the 4.0 blockers have been
> > > >> > > > committed - and there are quite a few of them remaining yet.
> > > >> > > >
> > > >> > > > So given all the holidays, and the tickets remaining, I’ll
> > > >personally
> > > >> > be
> > > >> > > > surprised if 4.0 comes out before
> > > >> > > > February/March and 3.13/3.14. Nor do I think it’s an issue.
> > > >> > > >
> > > >> > > > —
> > > >> > > > AY
> > > >> > > >
> > > >> > > > On 16 November 2016 at 00:39:03, Mick Semb Wever (
> > > >> > mick@thelastpickle.com <javascript:;>
> > > >> > > )
> > > >> > > > wrote:
> > > >> > > >
> > > >> > > > On 4 November 2016 at 13:47, Nate McCall <zznate.m@gmail.com
> > > >> <javascript:;>> wrote:
> > > >> > > >
> > > >> > > > > Specifically, this should be "new stuff that could/will
> break
> > > >> things"
> > > >> > > > > given we are upping
> > > >> > > > > the major version.
> > > >> > > > >
> > > >> > > >
> > > >> > > >
> > > >> > > > How does this co-ordinate with the tick-tock versioning¹
> leading
> > > up
> > > >> to
> > > >> > > the
> > > >> > > > 4.0 release?
> > > >> > > >
> > > >> > > > To just stop tick-tock and then say yeehaa let's jam in all
> the
> > > >> > breaking
> > > >> > > > changes we really want seems to be throwing away some of the
> > > learnt
> > > >> > > wisdom,
> > > >> > > > and not doing a very sane transition from tick-tock to
> > > >> > > > features/testing/stable². I really hope all this is done in a
> > way
> > > >> that
> > > >> > > > continues us down the path towards a stable-master.
> > > >> > > >
> > > >> > > > For example, are we fixing the release of 4.0 to November? or
> > > >> > continuing
> > > >> > > > tick-tocks until we complete the 4.0 roadmap? or starting the
> > > >> > > > features/testing/stable branching approach with 3.11?
> > > >> > > >
> > > >> > > >
> > > >> > > > Background:
> > > >> > > > ¹) Sylvain wrote in an earlier thread titled "A Home for 4.0"
> > > >> > > >
> > > >> > > > > And as 4.0 was initially supposed to come after 3.11, which
> is
> > > >> > coming,
> > > >> > > > it's probably time to have a home for those tickets.
> > > >> > > >
> > > >> > > > ²) The new versioning scheme slated for 4.0, per the
> "Proposal -
> > > >> 3.5.1"
> > > >> > > > thread
> > > >> > > >
> > > >> > > > > three branch plan with “features”, “testing”, and “stable”
> > > >starting
> > > >> > > with
> > > >> > > > 4.0?
> > > >> > > >
> > > >> > > >
> > > >> > > > Mick
> > > >> > > >
> > > >> > >
> > > >> >
> > > >>
> > >
> >
>
> --
>
>
> --
>
>
>
> --
Ben Bromhead
CTO | Instaclustr <https://www.instaclustr.com/>
+1 650 284 9692
Managed Cassandra / Spark on AWS, Azure and Softlayer

Re: Rough roadmap for 4.0

[Carlos Rolo <ro...@pythian.com>]

No Cluster in tick-tock.

Actually reverted a couple to 3.0.x

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
<http://linkedin.com/in/carlosjuzarterolo>*
Mobile: +351 918 918 100
www.pythian.com

On Thu, Nov 17, 2016 at 10:20 PM, DuyHai Doan <do...@gmail.com> wrote:

> Be very careful, there is a serious bug about AND/OR semantics, not solved
> yet and not going to be solved any soon:
> https://issues.apache.org/jira/browse/CASSANDRA-12674
>
> On Thu, Nov 17, 2016 at 7:32 PM, Jeff Jirsa <je...@crowdstrike.com>
> wrote:
>
> >
> > We’ll be voting in the very near future on timing of major releases and
> > release strategy. 4.0 won’t happen until that vote takes place.
> >
> > But since you asked, I have ONE tick/tock (3.9) cluster being qualified
> > for production because it needs SASI.
> >
> > - Jeff
> >
> > On 11/17/16, 9:59 AM, "Jonathan Haddad" <jo...@jonhaddad.com> wrote:
> >
> > >I think it might be worth considering adopting the release strategy
> before
> > >4.0 release.  Are any PMC members putting tick tock in prod? Does anyone
> > >even trust it?  What's the downside of changing the release cycle
> > >independently from 4.0?
> > >
> > >On Thu, Nov 17, 2016 at 9:03 AM Jason Brown <ja...@gmail.com>
> wrote:
> > >
> > >Jason,
> > >
> > >That's a separate topic, but we will have a different vote on how the
> > >branching/release strategy should be for the future.
> > >
> > >On Thursday, November 17, 2016, jason zhao yang <
> > zhaoyangsingapore@gmail.com
> > >>
> > >wrote:
> > >
> > >> Hi,
> > >>
> > >> Will we still use tick-tock release for 4.x and 4.0.x ?
> > >>
> > >> Stefan Podkowinski <spodxx@gmail.com <javascript:;>>于2016年11月16日周三
> > >> 下午4:52写道：
> > >>
> > >> > From my understanding, this will also effect EOL dates of other
> > >branches.
> > >> >
> > >> > "We will maintain the 2.2 stability series until 4.0 is released,
> and
> > >3.0
> > >> > for six months after that.".
> > >> >
> > >> >
> > >> > On Wed, Nov 16, 2016 at 5:34 AM, Nate McCall <zznate.m@gmail.com
> > >> <javascript:;>> wrote:
> > >> >
> > >> > > Agreed. As long as we have a goal I don't see why we have to
> adhere
> > to
> > >> > > arbitrary date for 4.0.
> > >> > >
> > >> > > On Nov 16, 2016 1:45 PM, "Aleksey Yeschenko" <
> aleksey@datastax.com
> > >> <javascript:;>>
> > >> > wrote:
> > >> > >
> > >> > > > I’ll comment on the broader issue, but right now I want to
> > elaborate
> > >> on
> > >> > > > 3.11/January/arbitrary cutoff date.
> > >> > > >
> > >> > > > Doesn’t matter what the original plan was. We should continue
> with
> > >> 3.X
> > >> > > > until all the 4.0 blockers have been
> > >> > > > committed - and there are quite a few of them remaining yet.
> > >> > > >
> > >> > > > So given all the holidays, and the tickets remaining, I’ll
> > >personally
> > >> > be
> > >> > > > surprised if 4.0 comes out before
> > >> > > > February/March and 3.13/3.14. Nor do I think it’s an issue.
> > >> > > >
> > >> > > > —
> > >> > > > AY
> > >> > > >
> > >> > > > On 16 November 2016 at 00:39:03, Mick Semb Wever (
> > >> > mick@thelastpickle.com <javascript:;>
> > >> > > )
> > >> > > > wrote:
> > >> > > >
> > >> > > > On 4 November 2016 at 13:47, Nate McCall <zznate.m@gmail.com
> > >> <javascript:;>> wrote:
> > >> > > >
> > >> > > > > Specifically, this should be "new stuff that could/will break
> > >> things"
> > >> > > > > given we are upping
> > >> > > > > the major version.
> > >> > > > >
> > >> > > >
> > >> > > >
> > >> > > > How does this co-ordinate with the tick-tock versioning¹ leading
> > up
> > >> to
> > >> > > the
> > >> > > > 4.0 release?
> > >> > > >
> > >> > > > To just stop tick-tock and then say yeehaa let's jam in all the
> > >> > breaking
> > >> > > > changes we really want seems to be throwing away some of the
> > learnt
> > >> > > wisdom,
> > >> > > > and not doing a very sane transition from tick-tock to
> > >> > > > features/testing/stable². I really hope all this is done in a
> way
> > >> that
> > >> > > > continues us down the path towards a stable-master.
> > >> > > >
> > >> > > > For example, are we fixing the release of 4.0 to November? or
> > >> > continuing
> > >> > > > tick-tocks until we complete the 4.0 roadmap? or starting the
> > >> > > > features/testing/stable branching approach with 3.11?
> > >> > > >
> > >> > > >
> > >> > > > Background:
> > >> > > > ¹) Sylvain wrote in an earlier thread titled "A Home for 4.0"
> > >> > > >
> > >> > > > > And as 4.0 was initially supposed to come after 3.11, which is
> > >> > coming,
> > >> > > > it's probably time to have a home for those tickets.
> > >> > > >
> > >> > > > ²) The new versioning scheme slated for 4.0, per the "Proposal -
> > >> 3.5.1"
> > >> > > > thread
> > >> > > >
> > >> > > > > three branch plan with “features”, “testing”, and “stable”
> > >starting
> > >> > > with
> > >> > > > 4.0?
> > >> > > >
> > >> > > >
> > >> > > > Mick
> > >> > > >
> > >> > >
> > >> >
> > >>
> >
>

-- 


--

Re: Rough roadmap for 4.0

[Brandon Williams <dr...@gmail.com>]

It's not marked fixed, it's marked resolved and the resolution is duplicate.

This is how all dupes are marked in jira.

On Fri, Nov 18, 2016 at 2:30 PM, Edward Capriolo <ed...@gmail.com>
wrote:

> These tickets claim to duplicate each other:
>
> https://issues.apache.org/jira/browse/CASSANDRA-12674
> https://issues.apache.org/jira/browse/CASSANDRA-12746
>
> But one is marked fixed and the other is still open.
>
> What is the status here?
>
> On Thu, Nov 17, 2016 at 5:20 PM, DuyHai Doan <do...@gmail.com> wrote:
>
> > Be very careful, there is a serious bug about AND/OR semantics, not
> solved
> > yet and not going to be solved any soon:
> > https://issues.apache.org/jira/browse/CASSANDRA-12674
> >
> > On Thu, Nov 17, 2016 at 7:32 PM, Jeff Jirsa <je...@crowdstrike.com>
> > wrote:
> >
> > >
> > > We’ll be voting in the very near future on timing of major releases and
> > > release strategy. 4.0 won’t happen until that vote takes place.
> > >
> > > But since you asked, I have ONE tick/tock (3.9) cluster being qualified
> > > for production because it needs SASI.
> > >
> > > - Jeff
> > >
> > > On 11/17/16, 9:59 AM, "Jonathan Haddad" <jo...@jonhaddad.com> wrote:
> > >
> > > >I think it might be worth considering adopting the release strategy
> > before
> > > >4.0 release.  Are any PMC members putting tick tock in prod? Does
> anyone
> > > >even trust it?  What's the downside of changing the release cycle
> > > >independently from 4.0?
> > > >
> > > >On Thu, Nov 17, 2016 at 9:03 AM Jason Brown <ja...@gmail.com>
> > wrote:
> > > >
> > > >Jason,
> > > >
> > > >That's a separate topic, but we will have a different vote on how the
> > > >branching/release strategy should be for the future.
> > > >
> > > >On Thursday, November 17, 2016, jason zhao yang <
> > > zhaoyangsingapore@gmail.com
> > > >>
> > > >wrote:
> > > >
> > > >> Hi,
> > > >>
> > > >> Will we still use tick-tock release for 4.x and 4.0.x ?
> > > >>
> > > >> Stefan Podkowinski <spodxx@gmail.com <javascript:;>>于2016年11月16日周三
> > > >> 下午4:52写道：
> > > >>
> > > >> > From my understanding, this will also effect EOL dates of other
> > > >branches.
> > > >> >
> > > >> > "We will maintain the 2.2 stability series until 4.0 is released,
> > and
> > > >3.0
> > > >> > for six months after that.".
> > > >> >
> > > >> >
> > > >> > On Wed, Nov 16, 2016 at 5:34 AM, Nate McCall <zznate.m@gmail.com
> > > >> <javascript:;>> wrote:
> > > >> >
> > > >> > > Agreed. As long as we have a goal I don't see why we have to
> > adhere
> > > to
> > > >> > > arbitrary date for 4.0.
> > > >> > >
> > > >> > > On Nov 16, 2016 1:45 PM, "Aleksey Yeschenko" <
> > aleksey@datastax.com
> > > >> <javascript:;>>
> > > >> > wrote:
> > > >> > >
> > > >> > > > I’ll comment on the broader issue, but right now I want to
> > > elaborate
> > > >> on
> > > >> > > > 3.11/January/arbitrary cutoff date.
> > > >> > > >
> > > >> > > > Doesn’t matter what the original plan was. We should continue
> > with
> > > >> 3.X
> > > >> > > > until all the 4.0 blockers have been
> > > >> > > > committed - and there are quite a few of them remaining yet.
> > > >> > > >
> > > >> > > > So given all the holidays, and the tickets remaining, I’ll
> > > >personally
> > > >> > be
> > > >> > > > surprised if 4.0 comes out before
> > > >> > > > February/March and 3.13/3.14. Nor do I think it’s an issue.
> > > >> > > >
> > > >> > > > —
> > > >> > > > AY
> > > >> > > >
> > > >> > > > On 16 November 2016 at 00:39:03, Mick Semb Wever (
> > > >> > mick@thelastpickle.com <javascript:;>
> > > >> > > )
> > > >> > > > wrote:
> > > >> > > >
> > > >> > > > On 4 November 2016 at 13:47, Nate McCall <zznate.m@gmail.com
> > > >> <javascript:;>> wrote:
> > > >> > > >
> > > >> > > > > Specifically, this should be "new stuff that could/will
> break
> > > >> things"
> > > >> > > > > given we are upping
> > > >> > > > > the major version.
> > > >> > > > >
> > > >> > > >
> > > >> > > >
> > > >> > > > How does this co-ordinate with the tick-tock versioning¹
> leading
> > > up
> > > >> to
> > > >> > > the
> > > >> > > > 4.0 release?
> > > >> > > >
> > > >> > > > To just stop tick-tock and then say yeehaa let's jam in all
> the
> > > >> > breaking
> > > >> > > > changes we really want seems to be throwing away some of the
> > > learnt
> > > >> > > wisdom,
> > > >> > > > and not doing a very sane transition from tick-tock to
> > > >> > > > features/testing/stable². I really hope all this is done in a
> > way
> > > >> that
> > > >> > > > continues us down the path towards a stable-master.
> > > >> > > >
> > > >> > > > For example, are we fixing the release of 4.0 to November? or
> > > >> > continuing
> > > >> > > > tick-tocks until we complete the 4.0 roadmap? or starting the
> > > >> > > > features/testing/stable branching approach with 3.11?
> > > >> > > >
> > > >> > > >
> > > >> > > > Background:
> > > >> > > > ¹) Sylvain wrote in an earlier thread titled "A Home for 4.0"
> > > >> > > >
> > > >> > > > > And as 4.0 was initially supposed to come after 3.11, which
> is
> > > >> > coming,
> > > >> > > > it's probably time to have a home for those tickets.
> > > >> > > >
> > > >> > > > ²) The new versioning scheme slated for 4.0, per the
> "Proposal -
> > > >> 3.5.1"
> > > >> > > > thread
> > > >> > > >
> > > >> > > > > three branch plan with “features”, “testing”, and “stable”
> > > >starting
> > > >> > > with
> > > >> > > > 4.0?
> > > >> > > >
> > > >> > > >
> > > >> > > > Mick
> > > >> > > >
> > > >> > >
> > > >> >
> > > >>
> > >
> >
>

Re: Rough roadmap for 4.0

[Edward Capriolo <ed...@gmail.com>]

These tickets claim to duplicate each other:

https://issues.apache.org/jira/browse/CASSANDRA-12674
https://issues.apache.org/jira/browse/CASSANDRA-12746

But one is marked fixed and the other is still open.

What is the status here?

On Thu, Nov 17, 2016 at 5:20 PM, DuyHai Doan <do...@gmail.com> wrote:

> Be very careful, there is a serious bug about AND/OR semantics, not solved
> yet and not going to be solved any soon:
> https://issues.apache.org/jira/browse/CASSANDRA-12674
>
> On Thu, Nov 17, 2016 at 7:32 PM, Jeff Jirsa <je...@crowdstrike.com>
> wrote:
>
> >
> > We’ll be voting in the very near future on timing of major releases and
> > release strategy. 4.0 won’t happen until that vote takes place.
> >
> > But since you asked, I have ONE tick/tock (3.9) cluster being qualified
> > for production because it needs SASI.
> >
> > - Jeff
> >
> > On 11/17/16, 9:59 AM, "Jonathan Haddad" <jo...@jonhaddad.com> wrote:
> >
> > >I think it might be worth considering adopting the release strategy
> before
> > >4.0 release.  Are any PMC members putting tick tock in prod? Does anyone
> > >even trust it?  What's the downside of changing the release cycle
> > >independently from 4.0?
> > >
> > >On Thu, Nov 17, 2016 at 9:03 AM Jason Brown <ja...@gmail.com>
> wrote:
> > >
> > >Jason,
> > >
> > >That's a separate topic, but we will have a different vote on how the
> > >branching/release strategy should be for the future.
> > >
> > >On Thursday, November 17, 2016, jason zhao yang <
> > zhaoyangsingapore@gmail.com
> > >>
> > >wrote:
> > >
> > >> Hi,
> > >>
> > >> Will we still use tick-tock release for 4.x and 4.0.x ?
> > >>
> > >> Stefan Podkowinski <spodxx@gmail.com <javascript:;>>于2016年11月16日周三
> > >> 下午4:52写道：
> > >>
> > >> > From my understanding, this will also effect EOL dates of other
> > >branches.
> > >> >
> > >> > "We will maintain the 2.2 stability series until 4.0 is released,
> and
> > >3.0
> > >> > for six months after that.".
> > >> >
> > >> >
> > >> > On Wed, Nov 16, 2016 at 5:34 AM, Nate McCall <zznate.m@gmail.com
> > >> <javascript:;>> wrote:
> > >> >
> > >> > > Agreed. As long as we have a goal I don't see why we have to
> adhere
> > to
> > >> > > arbitrary date for 4.0.
> > >> > >
> > >> > > On Nov 16, 2016 1:45 PM, "Aleksey Yeschenko" <
> aleksey@datastax.com
> > >> <javascript:;>>
> > >> > wrote:
> > >> > >
> > >> > > > I’ll comment on the broader issue, but right now I want to
> > elaborate
> > >> on
> > >> > > > 3.11/January/arbitrary cutoff date.
> > >> > > >
> > >> > > > Doesn’t matter what the original plan was. We should continue
> with
> > >> 3.X
> > >> > > > until all the 4.0 blockers have been
> > >> > > > committed - and there are quite a few of them remaining yet.
> > >> > > >
> > >> > > > So given all the holidays, and the tickets remaining, I’ll
> > >personally
> > >> > be
> > >> > > > surprised if 4.0 comes out before
> > >> > > > February/March and 3.13/3.14. Nor do I think it’s an issue.
> > >> > > >
> > >> > > > —
> > >> > > > AY
> > >> > > >
> > >> > > > On 16 November 2016 at 00:39:03, Mick Semb Wever (
> > >> > mick@thelastpickle.com <javascript:;>
> > >> > > )
> > >> > > > wrote:
> > >> > > >
> > >> > > > On 4 November 2016 at 13:47, Nate McCall <zznate.m@gmail.com
> > >> <javascript:;>> wrote:
> > >> > > >
> > >> > > > > Specifically, this should be "new stuff that could/will break
> > >> things"
> > >> > > > > given we are upping
> > >> > > > > the major version.
> > >> > > > >
> > >> > > >
> > >> > > >
> > >> > > > How does this co-ordinate with the tick-tock versioning¹ leading
> > up
> > >> to
> > >> > > the
> > >> > > > 4.0 release?
> > >> > > >
> > >> > > > To just stop tick-tock and then say yeehaa let's jam in all the
> > >> > breaking
> > >> > > > changes we really want seems to be throwing away some of the
> > learnt
> > >> > > wisdom,
> > >> > > > and not doing a very sane transition from tick-tock to
> > >> > > > features/testing/stable². I really hope all this is done in a
> way
> > >> that
> > >> > > > continues us down the path towards a stable-master.
> > >> > > >
> > >> > > > For example, are we fixing the release of 4.0 to November? or
> > >> > continuing
> > >> > > > tick-tocks until we complete the 4.0 roadmap? or starting the
> > >> > > > features/testing/stable branching approach with 3.11?
> > >> > > >
> > >> > > >
> > >> > > > Background:
> > >> > > > ¹) Sylvain wrote in an earlier thread titled "A Home for 4.0"
> > >> > > >
> > >> > > > > And as 4.0 was initially supposed to come after 3.11, which is
> > >> > coming,
> > >> > > > it's probably time to have a home for those tickets.
> > >> > > >
> > >> > > > ²) The new versioning scheme slated for 4.0, per the "Proposal -
> > >> 3.5.1"
> > >> > > > thread
> > >> > > >
> > >> > > > > three branch plan with “features”, “testing”, and “stable”
> > >starting
> > >> > > with
> > >> > > > 4.0?
> > >> > > >
> > >> > > >
> > >> > > > Mick
> > >> > > >
> > >> > >
> > >> >
> > >>
> >
>

Re: Rough roadmap for 4.0

[DuyHai Doan <do...@gmail.com>]

Be very careful, there is a serious bug about AND/OR semantics, not solved
yet and not going to be solved any soon:
https://issues.apache.org/jira/browse/CASSANDRA-12674

On Thu, Nov 17, 2016 at 7:32 PM, Jeff Jirsa <je...@crowdstrike.com>
wrote:

>
> We’ll be voting in the very near future on timing of major releases and
> release strategy. 4.0 won’t happen until that vote takes place.
>
> But since you asked, I have ONE tick/tock (3.9) cluster being qualified
> for production because it needs SASI.
>
> - Jeff
>
> On 11/17/16, 9:59 AM, "Jonathan Haddad" <jo...@jonhaddad.com> wrote:
>
> >I think it might be worth considering adopting the release strategy before
> >4.0 release.  Are any PMC members putting tick tock in prod? Does anyone
> >even trust it?  What's the downside of changing the release cycle
> >independently from 4.0?
> >
> >On Thu, Nov 17, 2016 at 9:03 AM Jason Brown <ja...@gmail.com> wrote:
> >
> >Jason,
> >
> >That's a separate topic, but we will have a different vote on how the
> >branching/release strategy should be for the future.
> >
> >On Thursday, November 17, 2016, jason zhao yang <
> zhaoyangsingapore@gmail.com
> >>
> >wrote:
> >
> >> Hi,
> >>
> >> Will we still use tick-tock release for 4.x and 4.0.x ?
> >>
> >> Stefan Podkowinski <spodxx@gmail.com <javascript:;>>于2016年11月16日周三
> >> 下午4:52写道：
> >>
> >> > From my understanding, this will also effect EOL dates of other
> >branches.
> >> >
> >> > "We will maintain the 2.2 stability series until 4.0 is released, and
> >3.0
> >> > for six months after that.".
> >> >
> >> >
> >> > On Wed, Nov 16, 2016 at 5:34 AM, Nate McCall <zznate.m@gmail.com
> >> <javascript:;>> wrote:
> >> >
> >> > > Agreed. As long as we have a goal I don't see why we have to adhere
> to
> >> > > arbitrary date for 4.0.
> >> > >
> >> > > On Nov 16, 2016 1:45 PM, "Aleksey Yeschenko" <aleksey@datastax.com
> >> <javascript:;>>
> >> > wrote:
> >> > >
> >> > > > I’ll comment on the broader issue, but right now I want to
> elaborate
> >> on
> >> > > > 3.11/January/arbitrary cutoff date.
> >> > > >
> >> > > > Doesn’t matter what the original plan was. We should continue with
> >> 3.X
> >> > > > until all the 4.0 blockers have been
> >> > > > committed - and there are quite a few of them remaining yet.
> >> > > >
> >> > > > So given all the holidays, and the tickets remaining, I’ll
> >personally
> >> > be
> >> > > > surprised if 4.0 comes out before
> >> > > > February/March and 3.13/3.14. Nor do I think it’s an issue.
> >> > > >
> >> > > > —
> >> > > > AY
> >> > > >
> >> > > > On 16 November 2016 at 00:39:03, Mick Semb Wever (
> >> > mick@thelastpickle.com <javascript:;>
> >> > > )
> >> > > > wrote:
> >> > > >
> >> > > > On 4 November 2016 at 13:47, Nate McCall <zznate.m@gmail.com
> >> <javascript:;>> wrote:
> >> > > >
> >> > > > > Specifically, this should be "new stuff that could/will break
> >> things"
> >> > > > > given we are upping
> >> > > > > the major version.
> >> > > > >
> >> > > >
> >> > > >
> >> > > > How does this co-ordinate with the tick-tock versioning¹ leading
> up
> >> to
> >> > > the
> >> > > > 4.0 release?
> >> > > >
> >> > > > To just stop tick-tock and then say yeehaa let's jam in all the
> >> > breaking
> >> > > > changes we really want seems to be throwing away some of the
> learnt
> >> > > wisdom,
> >> > > > and not doing a very sane transition from tick-tock to
> >> > > > features/testing/stable². I really hope all this is done in a way
> >> that
> >> > > > continues us down the path towards a stable-master.
> >> > > >
> >> > > > For example, are we fixing the release of 4.0 to November? or
> >> > continuing
> >> > > > tick-tocks until we complete the 4.0 roadmap? or starting the
> >> > > > features/testing/stable branching approach with 3.11?
> >> > > >
> >> > > >
> >> > > > Background:
> >> > > > ¹) Sylvain wrote in an earlier thread titled "A Home for 4.0"
> >> > > >
> >> > > > > And as 4.0 was initially supposed to come after 3.11, which is
> >> > coming,
> >> > > > it's probably time to have a home for those tickets.
> >> > > >
> >> > > > ²) The new versioning scheme slated for 4.0, per the "Proposal -
> >> 3.5.1"
> >> > > > thread
> >> > > >
> >> > > > > three branch plan with “features”, “testing”, and “stable”
> >starting
> >> > > with
> >> > > > 4.0?
> >> > > >
> >> > > >
> >> > > > Mick
> >> > > >
> >> > >
> >> >
> >>
>

Re: Rough roadmap for 4.0

[sankalp kohli <ko...@gmail.com>]

@Jeff
"But since you asked, I have ONE tick/tock (3.9) cluster being qualified
for production because it needs SASI."
You are brave :)

On Thu, Nov 17, 2016 at 10:32 AM, Jeff Jirsa <je...@crowdstrike.com>
wrote:

>
> We’ll be voting in the very near future on timing of major releases and
> release strategy. 4.0 won’t happen until that vote takes place.
>
> But since you asked, I have ONE tick/tock (3.9) cluster being qualified
> for production because it needs SASI.
>
> - Jeff
>
> On 11/17/16, 9:59 AM, "Jonathan Haddad" <jo...@jonhaddad.com> wrote:
>
> >I think it might be worth considering adopting the release strategy before
> >4.0 release.  Are any PMC members putting tick tock in prod? Does anyone
> >even trust it?  What's the downside of changing the release cycle
> >independently from 4.0?
> >
> >On Thu, Nov 17, 2016 at 9:03 AM Jason Brown <ja...@gmail.com> wrote:
> >
> >Jason,
> >
> >That's a separate topic, but we will have a different vote on how the
> >branching/release strategy should be for the future.
> >
> >On Thursday, November 17, 2016, jason zhao yang <
> zhaoyangsingapore@gmail.com
> >>
> >wrote:
> >
> >> Hi,
> >>
> >> Will we still use tick-tock release for 4.x and 4.0.x ?
> >>
> >> Stefan Podkowinski <spodxx@gmail.com <javascript:;>>于2016年11月16日周三
> >> 下午4:52写道：
> >>
> >> > From my understanding, this will also effect EOL dates of other
> >branches.
> >> >
> >> > "We will maintain the 2.2 stability series until 4.0 is released, and
> >3.0
> >> > for six months after that.".
> >> >
> >> >
> >> > On Wed, Nov 16, 2016 at 5:34 AM, Nate McCall <zznate.m@gmail.com
> >> <javascript:;>> wrote:
> >> >
> >> > > Agreed. As long as we have a goal I don't see why we have to adhere
> to
> >> > > arbitrary date for 4.0.
> >> > >
> >> > > On Nov 16, 2016 1:45 PM, "Aleksey Yeschenko" <aleksey@datastax.com
> >> <javascript:;>>
> >> > wrote:
> >> > >
> >> > > > I’ll comment on the broader issue, but right now I want to
> elaborate
> >> on
> >> > > > 3.11/January/arbitrary cutoff date.
> >> > > >
> >> > > > Doesn’t matter what the original plan was. We should continue with
> >> 3.X
> >> > > > until all the 4.0 blockers have been
> >> > > > committed - and there are quite a few of them remaining yet.
> >> > > >
> >> > > > So given all the holidays, and the tickets remaining, I’ll
> >personally
> >> > be
> >> > > > surprised if 4.0 comes out before
> >> > > > February/March and 3.13/3.14. Nor do I think it’s an issue.
> >> > > >
> >> > > > —
> >> > > > AY
> >> > > >
> >> > > > On 16 November 2016 at 00:39:03, Mick Semb Wever (
> >> > mick@thelastpickle.com <javascript:;>
> >> > > )
> >> > > > wrote:
> >> > > >
> >> > > > On 4 November 2016 at 13:47, Nate McCall <zznate.m@gmail.com
> >> <javascript:;>> wrote:
> >> > > >
> >> > > > > Specifically, this should be "new stuff that could/will break
> >> things"
> >> > > > > given we are upping
> >> > > > > the major version.
> >> > > > >
> >> > > >
> >> > > >
> >> > > > How does this co-ordinate with the tick-tock versioning¹ leading
> up
> >> to
> >> > > the
> >> > > > 4.0 release?
> >> > > >
> >> > > > To just stop tick-tock and then say yeehaa let's jam in all the
> >> > breaking
> >> > > > changes we really want seems to be throwing away some of the
> learnt
> >> > > wisdom,
> >> > > > and not doing a very sane transition from tick-tock to
> >> > > > features/testing/stable². I really hope all this is done in a way
> >> that
> >> > > > continues us down the path towards a stable-master.
> >> > > >
> >> > > > For example, are we fixing the release of 4.0 to November? or
> >> > continuing
> >> > > > tick-tocks until we complete the 4.0 roadmap? or starting the
> >> > > > features/testing/stable branching approach with 3.11?
> >> > > >
> >> > > >
> >> > > > Background:
> >> > > > ¹) Sylvain wrote in an earlier thread titled "A Home for 4.0"
> >> > > >
> >> > > > > And as 4.0 was initially supposed to come after 3.11, which is
> >> > coming,
> >> > > > it's probably time to have a home for those tickets.
> >> > > >
> >> > > > ²) The new versioning scheme slated for 4.0, per the "Proposal -
> >> 3.5.1"
> >> > > > thread
> >> > > >
> >> > > > > three branch plan with “features”, “testing”, and “stable”
> >starting
> >> > > with
> >> > > > 4.0?
> >> > > >
> >> > > >
> >> > > > Mick
> >> > > >
> >> > >
> >> >
> >>
>

Re: Rough roadmap for 4.0

[Jeff Jirsa <je...@crowdstrike.com>]

We’ll be voting in the very near future on timing of major releases and release strategy. 4.0 won’t happen until that vote takes place. 

But since you asked, I have ONE tick/tock (3.9) cluster being qualified for production because it needs SASI.

- Jeff

On 11/17/16, 9:59 AM, "Jonathan Haddad" <jo...@jonhaddad.com> wrote:

>I think it might be worth considering adopting the release strategy before
>4.0 release.  Are any PMC members putting tick tock in prod? Does anyone
>even trust it?  What's the downside of changing the release cycle
>independently from 4.0?
>
>On Thu, Nov 17, 2016 at 9:03 AM Jason Brown <ja...@gmail.com> wrote:
>
>Jason,
>
>That's a separate topic, but we will have a different vote on how the
>branching/release strategy should be for the future.
>
>On Thursday, November 17, 2016, jason zhao yang <zhaoyangsingapore@gmail.com
>>
>wrote:
>
>> Hi,
>>
>> Will we still use tick-tock release for 4.x and 4.0.x ?
>>
>> Stefan Podkowinski <spodxx@gmail.com <javascript:;>>于2016年11月16日周三
>> 下午4:52写道：
>>
>> > From my understanding, this will also effect EOL dates of other
>branches.
>> >
>> > "We will maintain the 2.2 stability series until 4.0 is released, and
>3.0
>> > for six months after that.".
>> >
>> >
>> > On Wed, Nov 16, 2016 at 5:34 AM, Nate McCall <zznate.m@gmail.com
>> <javascript:;>> wrote:
>> >
>> > > Agreed. As long as we have a goal I don't see why we have to adhere to
>> > > arbitrary date for 4.0.
>> > >
>> > > On Nov 16, 2016 1:45 PM, "Aleksey Yeschenko" <aleksey@datastax.com
>> <javascript:;>>
>> > wrote:
>> > >
>> > > > I’ll comment on the broader issue, but right now I want to elaborate
>> on
>> > > > 3.11/January/arbitrary cutoff date.
>> > > >
>> > > > Doesn’t matter what the original plan was. We should continue with
>> 3.X
>> > > > until all the 4.0 blockers have been
>> > > > committed - and there are quite a few of them remaining yet.
>> > > >
>> > > > So given all the holidays, and the tickets remaining, I’ll
>personally
>> > be
>> > > > surprised if 4.0 comes out before
>> > > > February/March and 3.13/3.14. Nor do I think it’s an issue.
>> > > >
>> > > > —
>> > > > AY
>> > > >
>> > > > On 16 November 2016 at 00:39:03, Mick Semb Wever (
>> > mick@thelastpickle.com <javascript:;>
>> > > )
>> > > > wrote:
>> > > >
>> > > > On 4 November 2016 at 13:47, Nate McCall <zznate.m@gmail.com
>> <javascript:;>> wrote:
>> > > >
>> > > > > Specifically, this should be "new stuff that could/will break
>> things"
>> > > > > given we are upping
>> > > > > the major version.
>> > > > >
>> > > >
>> > > >
>> > > > How does this co-ordinate with the tick-tock versioning¹ leading up
>> to
>> > > the
>> > > > 4.0 release?
>> > > >
>> > > > To just stop tick-tock and then say yeehaa let's jam in all the
>> > breaking
>> > > > changes we really want seems to be throwing away some of the learnt
>> > > wisdom,
>> > > > and not doing a very sane transition from tick-tock to
>> > > > features/testing/stable². I really hope all this is done in a way
>> that
>> > > > continues us down the path towards a stable-master.
>> > > >
>> > > > For example, are we fixing the release of 4.0 to November? or
>> > continuing
>> > > > tick-tocks until we complete the 4.0 roadmap? or starting the
>> > > > features/testing/stable branching approach with 3.11?
>> > > >
>> > > >
>> > > > Background:
>> > > > ¹) Sylvain wrote in an earlier thread titled "A Home for 4.0"
>> > > >
>> > > > > And as 4.0 was initially supposed to come after 3.11, which is
>> > coming,
>> > > > it's probably time to have a home for those tickets.
>> > > >
>> > > > ²) The new versioning scheme slated for 4.0, per the "Proposal -
>> 3.5.1"
>> > > > thread
>> > > >
>> > > > > three branch plan with “features”, “testing”, and “stable”
>starting
>> > > with
>> > > > 4.0?
>> > > >
>> > > >
>> > > > Mick
>> > > >
>> > >
>> >
>>

Re: Rough roadmap for 4.0

[Jonathan Haddad <jo...@jonhaddad.com>]

I think it might be worth considering adopting the release strategy before
4.0 release.  Are any PMC members putting tick tock in prod? Does anyone
even trust it?  What's the downside of changing the release cycle
independently from 4.0?

On Thu, Nov 17, 2016 at 9:03 AM Jason Brown <ja...@gmail.com> wrote:

Jason,

That's a separate topic, but we will have a different vote on how the
branching/release strategy should be for the future.

On Thursday, November 17, 2016, jason zhao yang <zhaoyangsingapore@gmail.com
>
wrote:

> Hi,
>
> Will we still use tick-tock release for 4.x and 4.0.x ?
>
> Stefan Podkowinski <spodxx@gmail.com <javascript:;>>于2016年11月16日周三
> 下午4:52写道：
>
> > From my understanding, this will also effect EOL dates of other
branches.
> >
> > "We will maintain the 2.2 stability series until 4.0 is released, and
3.0
> > for six months after that.".
> >
> >
> > On Wed, Nov 16, 2016 at 5:34 AM, Nate McCall <zznate.m@gmail.com
> <javascript:;>> wrote:
> >
> > > Agreed. As long as we have a goal I don't see why we have to adhere to
> > > arbitrary date for 4.0.
> > >
> > > On Nov 16, 2016 1:45 PM, "Aleksey Yeschenko" <aleksey@datastax.com
> <javascript:;>>
> > wrote:
> > >
> > > > I’ll comment on the broader issue, but right now I want to elaborate
> on
> > > > 3.11/January/arbitrary cutoff date.
> > > >
> > > > Doesn’t matter what the original plan was. We should continue with
> 3.X
> > > > until all the 4.0 blockers have been
> > > > committed - and there are quite a few of them remaining yet.
> > > >
> > > > So given all the holidays, and the tickets remaining, I’ll
personally
> > be
> > > > surprised if 4.0 comes out before
> > > > February/March and 3.13/3.14. Nor do I think it’s an issue.
> > > >
> > > > —
> > > > AY
> > > >
> > > > On 16 November 2016 at 00:39:03, Mick Semb Wever (
> > mick@thelastpickle.com <javascript:;>
> > > )
> > > > wrote:
> > > >
> > > > On 4 November 2016 at 13:47, Nate McCall <zznate.m@gmail.com
> <javascript:;>> wrote:
> > > >
> > > > > Specifically, this should be "new stuff that could/will break
> things"
> > > > > given we are upping
> > > > > the major version.
> > > > >
> > > >
> > > >
> > > > How does this co-ordinate with the tick-tock versioning¹ leading up
> to
> > > the
> > > > 4.0 release?
> > > >
> > > > To just stop tick-tock and then say yeehaa let's jam in all the
> > breaking
> > > > changes we really want seems to be throwing away some of the learnt
> > > wisdom,
> > > > and not doing a very sane transition from tick-tock to
> > > > features/testing/stable². I really hope all this is done in a way
> that
> > > > continues us down the path towards a stable-master.
> > > >
> > > > For example, are we fixing the release of 4.0 to November? or
> > continuing
> > > > tick-tocks until we complete the 4.0 roadmap? or starting the
> > > > features/testing/stable branching approach with 3.11?
> > > >
> > > >
> > > > Background:
> > > > ¹) Sylvain wrote in an earlier thread titled "A Home for 4.0"
> > > >
> > > > > And as 4.0 was initially supposed to come after 3.11, which is
> > coming,
> > > > it's probably time to have a home for those tickets.
> > > >
> > > > ²) The new versioning scheme slated for 4.0, per the "Proposal -
> 3.5.1"
> > > > thread
> > > >
> > > > > three branch plan with “features”, “testing”, and “stable”
starting
> > > with
> > > > 4.0?
> > > >
> > > >
> > > > Mick
> > > >
> > >
> >
>

Re: Rough roadmap for 4.0

[Jason Brown <ja...@gmail.com>]

Jason,

That's a separate topic, but we will have a different vote on how the
branching/release strategy should be for the future.

On Thursday, November 17, 2016, jason zhao yang <zh...@gmail.com>
wrote:

> Hi,
>
> Will we still use tick-tock release for 4.x and 4.0.x ?
>
> Stefan Podkowinski <spodxx@gmail.com <javascript:;>>于2016年11月16日周三
> 下午4:52写道：
>
> > From my understanding, this will also effect EOL dates of other branches.
> >
> > "We will maintain the 2.2 stability series until 4.0 is released, and 3.0
> > for six months after that.".
> >
> >
> > On Wed, Nov 16, 2016 at 5:34 AM, Nate McCall <zznate.m@gmail.com
> <javascript:;>> wrote:
> >
> > > Agreed. As long as we have a goal I don't see why we have to adhere to
> > > arbitrary date for 4.0.
> > >
> > > On Nov 16, 2016 1:45 PM, "Aleksey Yeschenko" <aleksey@datastax.com
> <javascript:;>>
> > wrote:
> > >
> > > > I’ll comment on the broader issue, but right now I want to elaborate
> on
> > > > 3.11/January/arbitrary cutoff date.
> > > >
> > > > Doesn’t matter what the original plan was. We should continue with
> 3.X
> > > > until all the 4.0 blockers have been
> > > > committed - and there are quite a few of them remaining yet.
> > > >
> > > > So given all the holidays, and the tickets remaining, I’ll personally
> > be
> > > > surprised if 4.0 comes out before
> > > > February/March and 3.13/3.14. Nor do I think it’s an issue.
> > > >
> > > > —
> > > > AY
> > > >
> > > > On 16 November 2016 at 00:39:03, Mick Semb Wever (
> > mick@thelastpickle.com <javascript:;>
> > > )
> > > > wrote:
> > > >
> > > > On 4 November 2016 at 13:47, Nate McCall <zznate.m@gmail.com
> <javascript:;>> wrote:
> > > >
> > > > > Specifically, this should be "new stuff that could/will break
> things"
> > > > > given we are upping
> > > > > the major version.
> > > > >
> > > >
> > > >
> > > > How does this co-ordinate with the tick-tock versioning¹ leading up
> to
> > > the
> > > > 4.0 release?
> > > >
> > > > To just stop tick-tock and then say yeehaa let's jam in all the
> > breaking
> > > > changes we really want seems to be throwing away some of the learnt
> > > wisdom,
> > > > and not doing a very sane transition from tick-tock to
> > > > features/testing/stable². I really hope all this is done in a way
> that
> > > > continues us down the path towards a stable-master.
> > > >
> > > > For example, are we fixing the release of 4.0 to November? or
> > continuing
> > > > tick-tocks until we complete the 4.0 roadmap? or starting the
> > > > features/testing/stable branching approach with 3.11?
> > > >
> > > >
> > > > Background:
> > > > ¹) Sylvain wrote in an earlier thread titled "A Home for 4.0"
> > > >
> > > > > And as 4.0 was initially supposed to come after 3.11, which is
> > coming,
> > > > it's probably time to have a home for those tickets.
> > > >
> > > > ²) The new versioning scheme slated for 4.0, per the "Proposal -
> 3.5.1"
> > > > thread
> > > >
> > > > > three branch plan with “features”, “testing”, and “stable” starting
> > > with
> > > > 4.0?
> > > >
> > > >
> > > > Mick
> > > >
> > >
> >
>

Re: Rough roadmap for 4.0

[jason zhao yang <zh...@gmail.com>]

Hi,

Will we still use tick-tock release for 4.x and 4.0.x ?

Stefan Podkowinski <sp...@gmail.com>于2016年11月16日周三 下午4:52写道：

> From my understanding, this will also effect EOL dates of other branches.
>
> "We will maintain the 2.2 stability series until 4.0 is released, and 3.0
> for six months after that.".
>
>
> On Wed, Nov 16, 2016 at 5:34 AM, Nate McCall <zz...@gmail.com> wrote:
>
> > Agreed. As long as we have a goal I don't see why we have to adhere to
> > arbitrary date for 4.0.
> >
> > On Nov 16, 2016 1:45 PM, "Aleksey Yeschenko" <al...@datastax.com>
> wrote:
> >
> > > I’ll comment on the broader issue, but right now I want to elaborate on
> > > 3.11/January/arbitrary cutoff date.
> > >
> > > Doesn’t matter what the original plan was. We should continue with 3.X
> > > until all the 4.0 blockers have been
> > > committed - and there are quite a few of them remaining yet.
> > >
> > > So given all the holidays, and the tickets remaining, I’ll personally
> be
> > > surprised if 4.0 comes out before
> > > February/March and 3.13/3.14. Nor do I think it’s an issue.
> > >
> > > —
> > > AY
> > >
> > > On 16 November 2016 at 00:39:03, Mick Semb Wever (
> mick@thelastpickle.com
> > )
> > > wrote:
> > >
> > > On 4 November 2016 at 13:47, Nate McCall <zz...@gmail.com> wrote:
> > >
> > > > Specifically, this should be "new stuff that could/will break things"
> > > > given we are upping
> > > > the major version.
> > > >
> > >
> > >
> > > How does this co-ordinate with the tick-tock versioning¹ leading up to
> > the
> > > 4.0 release?
> > >
> > > To just stop tick-tock and then say yeehaa let's jam in all the
> breaking
> > > changes we really want seems to be throwing away some of the learnt
> > wisdom,
> > > and not doing a very sane transition from tick-tock to
> > > features/testing/stable². I really hope all this is done in a way that
> > > continues us down the path towards a stable-master.
> > >
> > > For example, are we fixing the release of 4.0 to November? or
> continuing
> > > tick-tocks until we complete the 4.0 roadmap? or starting the
> > > features/testing/stable branching approach with 3.11?
> > >
> > >
> > > Background:
> > > ¹) Sylvain wrote in an earlier thread titled "A Home for 4.0"
> > >
> > > > And as 4.0 was initially supposed to come after 3.11, which is
> coming,
> > > it's probably time to have a home for those tickets.
> > >
> > > ²) The new versioning scheme slated for 4.0, per the "Proposal - 3.5.1"
> > > thread
> > >
> > > > three branch plan with “features”, “testing”, and “stable” starting
> > with
> > > 4.0?
> > >
> > >
> > > Mick
> > >
> >
>

Re: Rough roadmap for 4.0

[Stefan Podkowinski <sp...@gmail.com>]

From my understanding, this will also effect EOL dates of other branches.

"We will maintain the 2.2 stability series until 4.0 is released, and 3.0
for six months after that.".


On Wed, Nov 16, 2016 at 5:34 AM, Nate McCall <zz...@gmail.com> wrote:

> Agreed. As long as we have a goal I don't see why we have to adhere to
> arbitrary date for 4.0.
>
> On Nov 16, 2016 1:45 PM, "Aleksey Yeschenko" <al...@datastax.com> wrote:
>
> > I’ll comment on the broader issue, but right now I want to elaborate on
> > 3.11/January/arbitrary cutoff date.
> >
> > Doesn’t matter what the original plan was. We should continue with 3.X
> > until all the 4.0 blockers have been
> > committed - and there are quite a few of them remaining yet.
> >
> > So given all the holidays, and the tickets remaining, I’ll personally be
> > surprised if 4.0 comes out before
> > February/March and 3.13/3.14. Nor do I think it’s an issue.
> >
> > —
> > AY
> >
> > On 16 November 2016 at 00:39:03, Mick Semb Wever (mick@thelastpickle.com
> )
> > wrote:
> >
> > On 4 November 2016 at 13:47, Nate McCall <zz...@gmail.com> wrote:
> >
> > > Specifically, this should be "new stuff that could/will break things"
> > > given we are upping
> > > the major version.
> > >
> >
> >
> > How does this co-ordinate with the tick-tock versioning¹ leading up to
> the
> > 4.0 release?
> >
> > To just stop tick-tock and then say yeehaa let's jam in all the breaking
> > changes we really want seems to be throwing away some of the learnt
> wisdom,
> > and not doing a very sane transition from tick-tock to
> > features/testing/stable². I really hope all this is done in a way that
> > continues us down the path towards a stable-master.
> >
> > For example, are we fixing the release of 4.0 to November? or continuing
> > tick-tocks until we complete the 4.0 roadmap? or starting the
> > features/testing/stable branching approach with 3.11?
> >
> >
> > Background:
> > ¹) Sylvain wrote in an earlier thread titled "A Home for 4.0"
> >
> > > And as 4.0 was initially supposed to come after 3.11, which is coming,
> > it's probably time to have a home for those tickets.
> >
> > ²) The new versioning scheme slated for 4.0, per the "Proposal - 3.5.1"
> > thread
> >
> > > three branch plan with “features”, “testing”, and “stable” starting
> with
> > 4.0?
> >
> >
> > Mick
> >
>

Re: Rough roadmap for 4.0

[Ariel Weisberg <ar...@weisberg.ws>]

Hi,

I think one additional issue to add to the pile is CASSANDRA-7544 "Allow
storage port to be configurable per node"

I think no matter what we land on implementation wise it will only
possible to make this change in a major release as it will means change
to the system schema as well as internode messaging protocol. 

Having this properly done and reviewed by January is optimistic. I think
it wouldn't slip past February/March.

Ariel

On Tue, Nov 15, 2016, at 11:34 PM, Nate McCall wrote:
> Agreed. As long as we have a goal I don't see why we have to adhere to
> arbitrary date for 4.0.
> 
> On Nov 16, 2016 1:45 PM, "Aleksey Yeschenko" <al...@datastax.com>
> wrote:
> 
> > I’ll comment on the broader issue, but right now I want to elaborate on
> > 3.11/January/arbitrary cutoff date.
> >
> > Doesn’t matter what the original plan was. We should continue with 3.X
> > until all the 4.0 blockers have been
> > committed - and there are quite a few of them remaining yet.
> >
> > So given all the holidays, and the tickets remaining, I’ll personally be
> > surprised if 4.0 comes out before
> > February/March and 3.13/3.14. Nor do I think it’s an issue.
> >
> > —
> > AY
> >
> > On 16 November 2016 at 00:39:03, Mick Semb Wever (mick@thelastpickle.com)
> > wrote:
> >
> > On 4 November 2016 at 13:47, Nate McCall <zz...@gmail.com> wrote:
> >
> > > Specifically, this should be "new stuff that could/will break things"
> > > given we are upping
> > > the major version.
> > >
> >
> >
> > How does this co-ordinate with the tick-tock versioning¹ leading up to the
> > 4.0 release?
> >
> > To just stop tick-tock and then say yeehaa let's jam in all the breaking
> > changes we really want seems to be throwing away some of the learnt wisdom,
> > and not doing a very sane transition from tick-tock to
> > features/testing/stable². I really hope all this is done in a way that
> > continues us down the path towards a stable-master.
> >
> > For example, are we fixing the release of 4.0 to November? or continuing
> > tick-tocks until we complete the 4.0 roadmap? or starting the
> > features/testing/stable branching approach with 3.11?
> >
> >
> > Background:
> > ¹) Sylvain wrote in an earlier thread titled "A Home for 4.0"
> >
> > > And as 4.0 was initially supposed to come after 3.11, which is coming,
> > it's probably time to have a home for those tickets.
> >
> > ²) The new versioning scheme slated for 4.0, per the "Proposal - 3.5.1"
> > thread
> >
> > > three branch plan with “features”, “testing”, and “stable” starting with
> > 4.0?
> >
> >
> > Mick
> >

Re: Rough roadmap for 4.0

[Nate McCall <zz...@gmail.com>]

Agreed. As long as we have a goal I don't see why we have to adhere to
arbitrary date for 4.0.

On Nov 16, 2016 1:45 PM, "Aleksey Yeschenko" <al...@datastax.com> wrote:

> I’ll comment on the broader issue, but right now I want to elaborate on
> 3.11/January/arbitrary cutoff date.
>
> Doesn’t matter what the original plan was. We should continue with 3.X
> until all the 4.0 blockers have been
> committed - and there are quite a few of them remaining yet.
>
> So given all the holidays, and the tickets remaining, I’ll personally be
> surprised if 4.0 comes out before
> February/March and 3.13/3.14. Nor do I think it’s an issue.
>
> —
> AY
>
> On 16 November 2016 at 00:39:03, Mick Semb Wever (mick@thelastpickle.com)
> wrote:
>
> On 4 November 2016 at 13:47, Nate McCall <zz...@gmail.com> wrote:
>
> > Specifically, this should be "new stuff that could/will break things"
> > given we are upping
> > the major version.
> >
>
>
> How does this co-ordinate with the tick-tock versioning¹ leading up to the
> 4.0 release?
>
> To just stop tick-tock and then say yeehaa let's jam in all the breaking
> changes we really want seems to be throwing away some of the learnt wisdom,
> and not doing a very sane transition from tick-tock to
> features/testing/stable². I really hope all this is done in a way that
> continues us down the path towards a stable-master.
>
> For example, are we fixing the release of 4.0 to November? or continuing
> tick-tocks until we complete the 4.0 roadmap? or starting the
> features/testing/stable branching approach with 3.11?
>
>
> Background:
> ¹) Sylvain wrote in an earlier thread titled "A Home for 4.0"
>
> > And as 4.0 was initially supposed to come after 3.11, which is coming,
> it's probably time to have a home for those tickets.
>
> ²) The new versioning scheme slated for 4.0, per the "Proposal - 3.5.1"
> thread
>
> > three branch plan with “features”, “testing”, and “stable” starting with
> 4.0?
>
>
> Mick
>

Re: Rough roadmap for 4.0

[Mick Semb Wever <mi...@thelastpickle.com>]

We should continue with 3.X until all the 4.0 blockers have been
>> committed - and there are quite a few of them remaining yet.
>
>

And… are we right to presume that all the "roadmap 4.0" issues that don't
break any compatibility will be released in the 3.X tock releases leading
up to 4.0?

Re: Rough roadmap for 4.0

[Mick Semb Wever <mi...@thelastpickle.com>]

On 16 November 2016 at 11:45, Aleksey Yeschenko <al...@datastax.com>
wrote:

>
> Doesn’t matter what the original plan was. We should continue with 3.X
> until all the 4.0 blockers have been
> committed - and there are quite a few of them remaining yet.




Thanks for the clarity, the quick reply I was hoping for :-)

Re: Rough roadmap for 4.0

[Aleksey Yeschenko <al...@datastax.com>]

I’ll comment on the broader issue, but right now I want to elaborate on 3.11/January/arbitrary cutoff date.

Doesn’t matter what the original plan was. We should continue with 3.X until all the 4.0 blockers have been
committed - and there are quite a few of them remaining yet.

So given all the holidays, and the tickets remaining, I’ll personally be surprised if 4.0 comes out before
February/March and 3.13/3.14. Nor do I think it’s an issue. 

—
AY

On 16 November 2016 at 00:39:03, Mick Semb Wever (mick@thelastpickle.com) wrote:

On 4 November 2016 at 13:47, Nate McCall <zz...@gmail.com> wrote:  

> Specifically, this should be "new stuff that could/will break things"  
> given we are upping  
> the major version.  
>  


How does this co-ordinate with the tick-tock versioning¹ leading up to the  
4.0 release?  

To just stop tick-tock and then say yeehaa let's jam in all the breaking  
changes we really want seems to be throwing away some of the learnt wisdom,  
and not doing a very sane transition from tick-tock to  
features/testing/stable². I really hope all this is done in a way that  
continues us down the path towards a stable-master.  

For example, are we fixing the release of 4.0 to November? or continuing  
tick-tocks until we complete the 4.0 roadmap? or starting the  
features/testing/stable branching approach with 3.11?  


Background:  
¹) Sylvain wrote in an earlier thread titled "A Home for 4.0"  

> And as 4.0 was initially supposed to come after 3.11, which is coming,  
it's probably time to have a home for those tickets.  

²) The new versioning scheme slated for 4.0, per the "Proposal - 3.5.1"  
thread  

> three branch plan with “features”, “testing”, and “stable” starting with  
4.0?  


Mick  

Re: Rough roadmap for 4.0

[Mick Semb Wever <mi...@thelastpickle.com>]

On 4 November 2016 at 13:47, Nate McCall <zz...@gmail.com> wrote:

> Specifically, this should be "new stuff that could/will break things"
> given we are upping
> the major version.
>


How does this co-ordinate with the tick-tock versioning¹ leading up to the
4.0 release?

To just stop tick-tock and then say yeehaa let's jam in all the breaking
changes we really want seems to be throwing away some of the learnt wisdom,
and not doing a very sane transition from tick-tock to
features/testing/stable². I really hope all this is done in a way that
continues us down the path towards a stable-master.

For example, are we fixing the release of 4.0 to November? or continuing
tick-tocks until we complete the 4.0 roadmap? or starting the
features/testing/stable branching approach with 3.11?


Background:
 ¹) Sylvain wrote in an earlier thread titled "A Home for 4.0"

> And as 4.0 was initially supposed to come after 3.11, which is coming,
it's probably time to have a home for those tickets.

 ²) The new versioning scheme slated for 4.0, per the "Proposal - 3.5.1"
thread

> three branch plan with “features”, “testing”, and “stable” starting with
4.0?


Mick

Re: Rough roadmap for 4.0

[Nate McCall <zz...@gmail.com>]

Hi Stefan,
Thank you very much for bringing this up. I moved this to a new thread
because, though closely related, I think it is a very important
discussion to have on it's own as it does have a big impact.

Thanks,
-Nate

On Sat, Nov 5, 2016 at 9:15 AM, Stefan Podkowinski <sp...@gmail.com> wrote:
> There has been a lot of discussions about diversity and getting new
> contributors and I think this aspect should be kept in mind as well when
> talking about a roadmap, additionally to the listed tickets that are
> already in the pipeline. What can inspiring developers contribute to 4.0
> that would move the project forward to it’s goals and would be very likely
> included in the final release? What should people work on that would not be
> left ignored, because there’s no need for it or no time to really take care
> of it?
>
> Same applies for reviewing tickets and I’m afraid the situations could get
> even worse with the recent organisational changes. If there are no goals on
> what should be included in 4.0, reviewers will probably just pick what they
> personally find relevant or related to what they already worked on. Other
> work will just be left ignored and I think that’s the worst thing to do
> while trying to build up a bigger developer community. Each contribution
> deserves some kind of response and even if it’s just a “not relevant for
> next release, will look into it another time” type of reply. Having clear
> goals or a certain theme for the release should make it easier to decide
> what to review and where to decline. Does that make sense?
>
> On Fri, Nov 4, 2016 at 3:47 AM, Nate McCall <zz...@gmail.com> wrote:
>
>> It was brought up recently at the PMC level that our goals as a
>> project are not terribly clear.
>>
>> This is a pretty good point as outside of Jira 'Fix Version' labelling
>> (which we actually suck less at compared to a lot of other ASF
>> projects) this really isnt tracked anywhere outside of general tribal
>> knowledge about who is working on what.
>>
>> I would like to see us change this for two reasons:
>> - it's important we are clear with our community about where we are going
>> - we need to start working more closely together
>>
>> To that end, i've put together a list (in no particular order) of the
>> *major* features in which I know folks are interested, have patches
>> coming, are awaiting design review, etc.:
>>
>> - CASSANDRA-9425 Immutable node-local schema
>> - CASSANDRA-10699 Strongly consistent schema alterations
>> - CASSANDRA-12229 NIO streaming
>> - CASSANDRA-8457 NIO messaging
>> - CASSANDRA-12345 Gossip 2.0
>> - CASSANDRA-9754 Birch trees
>>
>> What did I miss? What else would folks like to see? Specifically, this
>> should be "new stuff that could/will break things" given we are upping
>> the major version.
>>
>> To be clear, it's not my intention to set this in stone and then beat
>> people about the head with it. More to have it there to point it at a
>> high level and foster better communication with our users from the
>> perspective of an open source project.
>>
>> Please keep in mind that given everything else going on, I think it's
>> a fantastic idea to keep this list small and spend some time focusing
>> on stability particularly as we transition to a new release process.
>>
>> -Nate
>>

Re: Rough roadmap for 4.0

[Stefan Podkowinski <sp...@gmail.com>]

There has been a lot of discussions about diversity and getting new
contributors and I think this aspect should be kept in mind as well when
talking about a roadmap, additionally to the listed tickets that are
already in the pipeline. What can inspiring developers contribute to 4.0
that would move the project forward to it’s goals and would be very likely
included in the final release? What should people work on that would not be
left ignored, because there’s no need for it or no time to really take care
of it?

Same applies for reviewing tickets and I’m afraid the situations could get
even worse with the recent organisational changes. If there are no goals on
what should be included in 4.0, reviewers will probably just pick what they
personally find relevant or related to what they already worked on. Other
work will just be left ignored and I think that’s the worst thing to do
while trying to build up a bigger developer community. Each contribution
deserves some kind of response and even if it’s just a “not relevant for
next release, will look into it another time” type of reply. Having clear
goals or a certain theme for the release should make it easier to decide
what to review and where to decline. Does that make sense?

On Fri, Nov 4, 2016 at 3:47 AM, Nate McCall <zz...@gmail.com> wrote:

> It was brought up recently at the PMC level that our goals as a
> project are not terribly clear.
>
> This is a pretty good point as outside of Jira 'Fix Version' labelling
> (which we actually suck less at compared to a lot of other ASF
> projects) this really isnt tracked anywhere outside of general tribal
> knowledge about who is working on what.
>
> I would like to see us change this for two reasons:
> - it's important we are clear with our community about where we are going
> - we need to start working more closely together
>
> To that end, i've put together a list (in no particular order) of the
> *major* features in which I know folks are interested, have patches
> coming, are awaiting design review, etc.:
>
> - CASSANDRA-9425 Immutable node-local schema
> - CASSANDRA-10699 Strongly consistent schema alterations
> - CASSANDRA-12229 NIO streaming
> - CASSANDRA-8457 NIO messaging
> - CASSANDRA-12345 Gossip 2.0
> - CASSANDRA-9754 Birch trees
>
> What did I miss? What else would folks like to see? Specifically, this
> should be "new stuff that could/will break things" given we are upping
> the major version.
>
> To be clear, it's not my intention to set this in stone and then beat
> people about the head with it. More to have it there to point it at a
> high level and foster better communication with our users from the
> perspective of an open source project.
>
> Please keep in mind that given everything else going on, I think it's
> a fantastic idea to keep this list small and spend some time focusing
> on stability particularly as we transition to a new release process.
>
> -Nate
>

Re: Rough roadmap for 4.0

[Jeff Jirsa <jj...@gmail.com>]

Also https://issues.apache.org/jira/browse/CASSANDRA-12676



-- 
Jeff Jirsa


> On Nov 4, 2016, at 11:51 AM, Jason Brown <ja...@gmail.com> wrote:
> 
> +1 to epaxos
> 
>> On Fri, Nov 4, 2016 at 11:40 AM, Jonathan Haddad <jo...@jonhaddad.com> wrote:
>> 
>> epaxos would be nice, it's been about 2 years since it was started, and
>> Blake asked for a first review well over a year ago.  the benchmarks and
>> thorough test suite look like a huge improvement over the current
>> situation.
>> 
>> https://issues.apache.org/jira/browse/CASSANDRA-6246
>> 
>> On Fri, Nov 4, 2016 at 3:28 AM Edward Capriolo <ed...@gmail.com>
>> wrote:
>> 
>>> I would like to propose features around seeds:
>>> https://issues.apache.org/jira/browse/CASSANDRA-12627
>>> 
>>> I have other follow up issues like getting seeds from Amazon API, or from
>>> JNDI/ DNS, etc.
>>> 
>>> I was hoping 12627 was an easy way to grease the wheels.
>>> 
>>> 
>>> On Fri, Nov 4, 2016 at 8:39 AM, Jason Brown <ja...@gmail.com>
>> wrote:
>>> 
>>>> Hey Nate,
>>>> 
>>>> I'd like to add CASSANDRA-11559 (Enhance node representation) to the
>>> list,
>>>> including the comment I made on the ticket (different storage ports for
>>>> each node). For us, it's a great "would really like to have" as our
>> group
>>>> will probably need this in production within the next 1 year or less.
>>>> However since it hasn't gotten much attention, I'm not sure if we
>> should
>>>> add it to the list of "must haves" for 4.0. I'm planning on bringing it
>>> up
>>>> internally today, as well.
>>>> 
>>>> Also, from the previous 4.0 email thread that Jonathan started back in
>>> July
>>>> (
>>>> https://mail-archives.apache.org/mod_mbox/cassandra-dev/
>>>> 201607.mbox/%3CCALdd-zhW3qJ%3DOWida9nMXPj0JOsru7guOYh6-
>>>> 7uTjqEBvacrgQ%40mail.gmail.com%3E
>>>> )
>>>> 
>>>> - CASSANDRA-11115 (thrift removal) - ticket not mentioned explicitly in
>>> the
>>>> email, but the notion of removing thrift was
>>>> - CASSANDRA-10857 (Allow dropping COMPACT STORAGE flag)
>>>> 
>>>> Thanks,
>>>> 
>>>> -Jason
>>>> 
>>>> On Thu, Nov 3, 2016 at 8:43 PM, sankalp kohli <ko...@gmail.com>
>>>> wrote:
>>>> 
>>>>> List looks really good. I will let you know if there is something
>> else
>>> we
>>>>> plan to add to this list.
>>>>> 
>>>>> On Thu, Nov 3, 2016 at 7:47 PM, Nate McCall <zz...@gmail.com>
>>> wrote:
>>>>> 
>>>>>> It was brought up recently at the PMC level that our goals as a
>>>>>> project are not terribly clear.
>>>>>> 
>>>>>> This is a pretty good point as outside of Jira 'Fix Version'
>>> labelling
>>>>>> (which we actually suck less at compared to a lot of other ASF
>>>>>> projects) this really isnt tracked anywhere outside of general
>> tribal
>>>>>> knowledge about who is working on what.
>>>>>> 
>>>>>> I would like to see us change this for two reasons:
>>>>>> - it's important we are clear with our community about where we are
>>>> going
>>>>>> - we need to start working more closely together
>>>>>> 
>>>>>> To that end, i've put together a list (in no particular order) of
>> the
>>>>>> *major* features in which I know folks are interested, have patches
>>>>>> coming, are awaiting design review, etc.:
>>>>>> 
>>>>>> - CASSANDRA-9425 Immutable node-local schema
>>>>>> - CASSANDRA-10699 Strongly consistent schema alterations
>>>>>> - CASSANDRA-12229 NIO streaming
>>>>>> - CASSANDRA-8457 NIO messaging
>>>>>> - CASSANDRA-12345 Gossip 2.0
>>>>>> - CASSANDRA-9754 Birch trees
>>>>>> 
>>>>>> What did I miss? What else would folks like to see? Specifically,
>>> this
>>>>>> should be "new stuff that could/will break things" given we are
>>> upping
>>>>>> the major version.
>>>>>> 
>>>>>> To be clear, it's not my intention to set this in stone and then
>> beat
>>>>>> people about the head with it. More to have it there to point it
>> at a
>>>>>> high level and foster better communication with our users from the
>>>>>> perspective of an open source project.
>>>>>> 
>>>>>> Please keep in mind that given everything else going on, I think
>> it's
>>>>>> a fantastic idea to keep this list small and spend some time
>> focusing
>>>>>> on stability particularly as we transition to a new release
>> process.
>>>>>> 
>>>>>> -Nate
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 

Re: Rough roadmap for 4.0

[Jason Brown <ja...@gmail.com>]

+1 to epaxos

On Fri, Nov 4, 2016 at 11:40 AM, Jonathan Haddad <jo...@jonhaddad.com> wrote:

> epaxos would be nice, it's been about 2 years since it was started, and
> Blake asked for a first review well over a year ago.  the benchmarks and
> thorough test suite look like a huge improvement over the current
> situation.
>
> https://issues.apache.org/jira/browse/CASSANDRA-6246
>
> On Fri, Nov 4, 2016 at 3:28 AM Edward Capriolo <ed...@gmail.com>
> wrote:
>
> > I would like to propose features around seeds:
> > https://issues.apache.org/jira/browse/CASSANDRA-12627
> >
> > I have other follow up issues like getting seeds from Amazon API, or from
> > JNDI/ DNS, etc.
> >
> > I was hoping 12627 was an easy way to grease the wheels.
> >
> >
> > On Fri, Nov 4, 2016 at 8:39 AM, Jason Brown <ja...@gmail.com>
> wrote:
> >
> > > Hey Nate,
> > >
> > > I'd like to add CASSANDRA-11559 (Enhance node representation) to the
> > list,
> > > including the comment I made on the ticket (different storage ports for
> > > each node). For us, it's a great "would really like to have" as our
> group
> > > will probably need this in production within the next 1 year or less.
> > > However since it hasn't gotten much attention, I'm not sure if we
> should
> > > add it to the list of "must haves" for 4.0. I'm planning on bringing it
> > up
> > > internally today, as well.
> > >
> > > Also, from the previous 4.0 email thread that Jonathan started back in
> > July
> > > (
> > > https://mail-archives.apache.org/mod_mbox/cassandra-dev/
> > > 201607.mbox/%3CCALdd-zhW3qJ%3DOWida9nMXPj0JOsru7guOYh6-
> > > 7uTjqEBvacrgQ%40mail.gmail.com%3E
> > > )
> > >
> > > - CASSANDRA-11115 (thrift removal) - ticket not mentioned explicitly in
> > the
> > > email, but the notion of removing thrift was
> > > - CASSANDRA-10857 (Allow dropping COMPACT STORAGE flag)
> > >
> > > Thanks,
> > >
> > > -Jason
> > >
> > > On Thu, Nov 3, 2016 at 8:43 PM, sankalp kohli <ko...@gmail.com>
> > > wrote:
> > >
> > > > List looks really good. I will let you know if there is something
> else
> > we
> > > > plan to add to this list.
> > > >
> > > > On Thu, Nov 3, 2016 at 7:47 PM, Nate McCall <zz...@gmail.com>
> > wrote:
> > > >
> > > > > It was brought up recently at the PMC level that our goals as a
> > > > > project are not terribly clear.
> > > > >
> > > > > This is a pretty good point as outside of Jira 'Fix Version'
> > labelling
> > > > > (which we actually suck less at compared to a lot of other ASF
> > > > > projects) this really isnt tracked anywhere outside of general
> tribal
> > > > > knowledge about who is working on what.
> > > > >
> > > > > I would like to see us change this for two reasons:
> > > > > - it's important we are clear with our community about where we are
> > > going
> > > > > - we need to start working more closely together
> > > > >
> > > > > To that end, i've put together a list (in no particular order) of
> the
> > > > > *major* features in which I know folks are interested, have patches
> > > > > coming, are awaiting design review, etc.:
> > > > >
> > > > > - CASSANDRA-9425 Immutable node-local schema
> > > > > - CASSANDRA-10699 Strongly consistent schema alterations
> > > > > - CASSANDRA-12229 NIO streaming
> > > > > - CASSANDRA-8457 NIO messaging
> > > > > - CASSANDRA-12345 Gossip 2.0
> > > > > - CASSANDRA-9754 Birch trees
> > > > >
> > > > > What did I miss? What else would folks like to see? Specifically,
> > this
> > > > > should be "new stuff that could/will break things" given we are
> > upping
> > > > > the major version.
> > > > >
> > > > > To be clear, it's not my intention to set this in stone and then
> beat
> > > > > people about the head with it. More to have it there to point it
> at a
> > > > > high level and foster better communication with our users from the
> > > > > perspective of an open source project.
> > > > >
> > > > > Please keep in mind that given everything else going on, I think
> it's
> > > > > a fantastic idea to keep this list small and spend some time
> focusing
> > > > > on stability particularly as we transition to a new release
> process.
> > > > >
> > > > > -Nate
> > > > >
> > > >
> > >
> >
>

Re: Rough roadmap for 4.0

[Jonathan Haddad <jo...@jonhaddad.com>]

epaxos would be nice, it's been about 2 years since it was started, and
Blake asked for a first review well over a year ago.  the benchmarks and
thorough test suite look like a huge improvement over the current situation.

https://issues.apache.org/jira/browse/CASSANDRA-6246

On Fri, Nov 4, 2016 at 3:28 AM Edward Capriolo <ed...@gmail.com>
wrote:

> I would like to propose features around seeds:
> https://issues.apache.org/jira/browse/CASSANDRA-12627
>
> I have other follow up issues like getting seeds from Amazon API, or from
> JNDI/ DNS, etc.
>
> I was hoping 12627 was an easy way to grease the wheels.
>
>
> On Fri, Nov 4, 2016 at 8:39 AM, Jason Brown <ja...@gmail.com> wrote:
>
> > Hey Nate,
> >
> > I'd like to add CASSANDRA-11559 (Enhance node representation) to the
> list,
> > including the comment I made on the ticket (different storage ports for
> > each node). For us, it's a great "would really like to have" as our group
> > will probably need this in production within the next 1 year or less.
> > However since it hasn't gotten much attention, I'm not sure if we should
> > add it to the list of "must haves" for 4.0. I'm planning on bringing it
> up
> > internally today, as well.
> >
> > Also, from the previous 4.0 email thread that Jonathan started back in
> July
> > (
> > https://mail-archives.apache.org/mod_mbox/cassandra-dev/
> > 201607.mbox/%3CCALdd-zhW3qJ%3DOWida9nMXPj0JOsru7guOYh6-
> > 7uTjqEBvacrgQ%40mail.gmail.com%3E
> > )
> >
> > - CASSANDRA-11115 (thrift removal) - ticket not mentioned explicitly in
> the
> > email, but the notion of removing thrift was
> > - CASSANDRA-10857 (Allow dropping COMPACT STORAGE flag)
> >
> > Thanks,
> >
> > -Jason
> >
> > On Thu, Nov 3, 2016 at 8:43 PM, sankalp kohli <ko...@gmail.com>
> > wrote:
> >
> > > List looks really good. I will let you know if there is something else
> we
> > > plan to add to this list.
> > >
> > > On Thu, Nov 3, 2016 at 7:47 PM, Nate McCall <zz...@gmail.com>
> wrote:
> > >
> > > > It was brought up recently at the PMC level that our goals as a
> > > > project are not terribly clear.
> > > >
> > > > This is a pretty good point as outside of Jira 'Fix Version'
> labelling
> > > > (which we actually suck less at compared to a lot of other ASF
> > > > projects) this really isnt tracked anywhere outside of general tribal
> > > > knowledge about who is working on what.
> > > >
> > > > I would like to see us change this for two reasons:
> > > > - it's important we are clear with our community about where we are
> > going
> > > > - we need to start working more closely together
> > > >
> > > > To that end, i've put together a list (in no particular order) of the
> > > > *major* features in which I know folks are interested, have patches
> > > > coming, are awaiting design review, etc.:
> > > >
> > > > - CASSANDRA-9425 Immutable node-local schema
> > > > - CASSANDRA-10699 Strongly consistent schema alterations
> > > > - CASSANDRA-12229 NIO streaming
> > > > - CASSANDRA-8457 NIO messaging
> > > > - CASSANDRA-12345 Gossip 2.0
> > > > - CASSANDRA-9754 Birch trees
> > > >
> > > > What did I miss? What else would folks like to see? Specifically,
> this
> > > > should be "new stuff that could/will break things" given we are
> upping
> > > > the major version.
> > > >
> > > > To be clear, it's not my intention to set this in stone and then beat
> > > > people about the head with it. More to have it there to point it at a
> > > > high level and foster better communication with our users from the
> > > > perspective of an open source project.
> > > >
> > > > Please keep in mind that given everything else going on, I think it's
> > > > a fantastic idea to keep this list small and spend some time focusing
> > > > on stability particularly as we transition to a new release process.
> > > >
> > > > -Nate
> > > >
> > >
> >
>

Re: Rough roadmap for 4.0

[Edward Capriolo <ed...@gmail.com>]

I would like to propose features around seeds:
https://issues.apache.org/jira/browse/CASSANDRA-12627

I have other follow up issues like getting seeds from Amazon API, or from
JNDI/ DNS, etc.

I was hoping 12627 was an easy way to grease the wheels.


On Fri, Nov 4, 2016 at 8:39 AM, Jason Brown <ja...@gmail.com> wrote:

> Hey Nate,
>
> I'd like to add CASSANDRA-11559 (Enhance node representation) to the list,
> including the comment I made on the ticket (different storage ports for
> each node). For us, it's a great "would really like to have" as our group
> will probably need this in production within the next 1 year or less.
> However since it hasn't gotten much attention, I'm not sure if we should
> add it to the list of "must haves" for 4.0. I'm planning on bringing it up
> internally today, as well.
>
> Also, from the previous 4.0 email thread that Jonathan started back in July
> (
> https://mail-archives.apache.org/mod_mbox/cassandra-dev/
> 201607.mbox/%3CCALdd-zhW3qJ%3DOWida9nMXPj0JOsru7guOYh6-
> 7uTjqEBvacrgQ%40mail.gmail.com%3E
> )
>
> - CASSANDRA-11115 (thrift removal) - ticket not mentioned explicitly in the
> email, but the notion of removing thrift was
> - CASSANDRA-10857 (Allow dropping COMPACT STORAGE flag)
>
> Thanks,
>
> -Jason
>
> On Thu, Nov 3, 2016 at 8:43 PM, sankalp kohli <ko...@gmail.com>
> wrote:
>
> > List looks really good. I will let you know if there is something else we
> > plan to add to this list.
> >
> > On Thu, Nov 3, 2016 at 7:47 PM, Nate McCall <zz...@gmail.com> wrote:
> >
> > > It was brought up recently at the PMC level that our goals as a
> > > project are not terribly clear.
> > >
> > > This is a pretty good point as outside of Jira 'Fix Version' labelling
> > > (which we actually suck less at compared to a lot of other ASF
> > > projects) this really isnt tracked anywhere outside of general tribal
> > > knowledge about who is working on what.
> > >
> > > I would like to see us change this for two reasons:
> > > - it's important we are clear with our community about where we are
> going
> > > - we need to start working more closely together
> > >
> > > To that end, i've put together a list (in no particular order) of the
> > > *major* features in which I know folks are interested, have patches
> > > coming, are awaiting design review, etc.:
> > >
> > > - CASSANDRA-9425 Immutable node-local schema
> > > - CASSANDRA-10699 Strongly consistent schema alterations
> > > - CASSANDRA-12229 NIO streaming
> > > - CASSANDRA-8457 NIO messaging
> > > - CASSANDRA-12345 Gossip 2.0
> > > - CASSANDRA-9754 Birch trees
> > >
> > > What did I miss? What else would folks like to see? Specifically, this
> > > should be "new stuff that could/will break things" given we are upping
> > > the major version.
> > >
> > > To be clear, it's not my intention to set this in stone and then beat
> > > people about the head with it. More to have it there to point it at a
> > > high level and foster better communication with our users from the
> > > perspective of an open source project.
> > >
> > > Please keep in mind that given everything else going on, I think it's
> > > a fantastic idea to keep this list small and spend some time focusing
> > > on stability particularly as we transition to a new release process.
> > >
> > > -Nate
> > >
> >
>

Re: Rough roadmap for 4.0

[Jason Brown <ja...@gmail.com>]

Hey Nate,

I'd like to add CASSANDRA-11559 (Enhance node representation) to the list,
including the comment I made on the ticket (different storage ports for
each node). For us, it's a great "would really like to have" as our group
will probably need this in production within the next 1 year or less.
However since it hasn't gotten much attention, I'm not sure if we should
add it to the list of "must haves" for 4.0. I'm planning on bringing it up
internally today, as well.

Also, from the previous 4.0 email thread that Jonathan started back in July
(
https://mail-archives.apache.org/mod_mbox/cassandra-dev/201607.mbox/%3CCALdd-zhW3qJ%3DOWida9nMXPj0JOsru7guOYh6-7uTjqEBvacrgQ%40mail.gmail.com%3E
)

- CASSANDRA-11115 (thrift removal) - ticket not mentioned explicitly in the
email, but the notion of removing thrift was
- CASSANDRA-10857 (Allow dropping COMPACT STORAGE flag)

Thanks,

-Jason

On Thu, Nov 3, 2016 at 8:43 PM, sankalp kohli <ko...@gmail.com>
wrote:

> List looks really good. I will let you know if there is something else we
> plan to add to this list.
>
> On Thu, Nov 3, 2016 at 7:47 PM, Nate McCall <zz...@gmail.com> wrote:
>
> > It was brought up recently at the PMC level that our goals as a
> > project are not terribly clear.
> >
> > This is a pretty good point as outside of Jira 'Fix Version' labelling
> > (which we actually suck less at compared to a lot of other ASF
> > projects) this really isnt tracked anywhere outside of general tribal
> > knowledge about who is working on what.
> >
> > I would like to see us change this for two reasons:
> > - it's important we are clear with our community about where we are going
> > - we need to start working more closely together
> >
> > To that end, i've put together a list (in no particular order) of the
> > *major* features in which I know folks are interested, have patches
> > coming, are awaiting design review, etc.:
> >
> > - CASSANDRA-9425 Immutable node-local schema
> > - CASSANDRA-10699 Strongly consistent schema alterations
> > - CASSANDRA-12229 NIO streaming
> > - CASSANDRA-8457 NIO messaging
> > - CASSANDRA-12345 Gossip 2.0
> > - CASSANDRA-9754 Birch trees
> >
> > What did I miss? What else would folks like to see? Specifically, this
> > should be "new stuff that could/will break things" given we are upping
> > the major version.
> >
> > To be clear, it's not my intention to set this in stone and then beat
> > people about the head with it. More to have it there to point it at a
> > high level and foster better communication with our users from the
> > perspective of an open source project.
> >
> > Please keep in mind that given everything else going on, I think it's
> > a fantastic idea to keep this list small and spend some time focusing
> > on stability particularly as we transition to a new release process.
> >
> > -Nate
> >
>

Re: Rough roadmap for 4.0

[sankalp kohli <ko...@gmail.com>]

List looks really good. I will let you know if there is something else we
plan to add to this list.

On Thu, Nov 3, 2016 at 7:47 PM, Nate McCall <zz...@gmail.com> wrote:

> It was brought up recently at the PMC level that our goals as a
> project are not terribly clear.
>
> This is a pretty good point as outside of Jira 'Fix Version' labelling
> (which we actually suck less at compared to a lot of other ASF
> projects) this really isnt tracked anywhere outside of general tribal
> knowledge about who is working on what.
>
> I would like to see us change this for two reasons:
> - it's important we are clear with our community about where we are going
> - we need to start working more closely together
>
> To that end, i've put together a list (in no particular order) of the
> *major* features in which I know folks are interested, have patches
> coming, are awaiting design review, etc.:
>
> - CASSANDRA-9425 Immutable node-local schema
> - CASSANDRA-10699 Strongly consistent schema alterations
> - CASSANDRA-12229 NIO streaming
> - CASSANDRA-8457 NIO messaging
> - CASSANDRA-12345 Gossip 2.0
> - CASSANDRA-9754 Birch trees
>
> What did I miss? What else would folks like to see? Specifically, this
> should be "new stuff that could/will break things" given we are upping
> the major version.
>
> To be clear, it's not my intention to set this in stone and then beat
> people about the head with it. More to have it there to point it at a
> high level and foster better communication with our users from the
> perspective of an open source project.
>
> Please keep in mind that given everything else going on, I think it's
> a fantastic idea to keep this list small and spend some time focusing
> on stability particularly as we transition to a new release process.
>
> -Nate
>