Re: Roadmap for 4.0

[Ben Bromhead]

Apologies all, I didn't realize I was responding to this discussion only on
the @user list. One of the perils of responding to a thread that is on both
user and dev...

For context, I have included my response to Kurt's previous discussion on
this topic as it only ended up on the user list.

*After some further discussions with folks offline, I'd like to revive this
discussion. *

*As Kurt mentioned, to keep it simple I if we can simply build consensus
around what is in for 4.0 and what is out. We can then start the process of
working off a 4.0 branch towards betas and release candidates. Again as
Kurt mentioned, assigning a timeline to it right now is difficult, but
having a firm line in the sand around what features/patches are in, then
limiting future 4.0 work to bug fixes will give folks a less nebulous
target to work on. *

*The other thing to mention is that once we have a 4.0 branch to work off,
we at Instaclustr have a commitment to dogfooding the release candidates on
our internal staging and internal production workloads before 4.0 becomes
generally available. I know other folks have similar commitments and simply
having a 4.0 branch with a clear list of things that are in or out will
allow everyone to start testing and driving towards a quality release. *

*The other thing is that there are already a large number of changes ready
for 4.0, I would suggest not recommending tickets for 4.0 that have not yet
been finished/have outstanding work unless you are the person working on it
(or are offering to work on it instead) and can get it ready for review in
a timely fashion. That way we can build a more realistic working target.
For other major breaking changes, there is always 5.0 or 4.1 or whatever we
end up doing :)*

Thinking further about it, I would suggest a similar process that was
applied to releasing 3.0, in order to get to 4.0:

   - Clean up ticket labeling. Move tickets unlikely to make it / be worked
   on for 4.0 to something else (e.g. 4.x or whatever).
   - Tickets labeled 4.0 will be the line in the sand, with some trigger
   ("done") event where all features not done by a certain event will simply
   move into the next release. For the 3.0 branch, this occurred after a
   large review of 8099. For 4.0 it could simply be resolving all current
   blockers/major tickets tagged 4.0... doesn't have to be / nor is it
   something I would strongly advocate.
   - Once we hit this "done" event. Cut a Cassandra-4.0 branch and start
   the alpha/beta/rc cycle from that branch, with only bugfixes going into
   it
   - This, in my mind, 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  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 

Re: A Simple List of New Major Features Desired for Apache Cassandra Version 4.0

[Ben Bromhead]

Thank you, Kenneth, for listening to the PMC and for putting the discussion
in the correct list. I also appreciate your enthusiasm.

To address a few of your points from your previous emails in no particular
order:

   - There is already a compiled list of features slated for 4.0, this list
   is simply a search using the following JQL on JIRA - `project =
   CASSANDRA AND fixVersion = 4.0 ORDER BY priority DESC, updated DESC`. By
   looking at this list, we can see fixes/patches/features that have been
   committed to trunk as well as tickets that are still in progress but
   someone at some point thought it was likely to land in 4.0
   - I appreciate a desire to create a bucket list of any and all desired
   features for 4.0, the reality is that this is an open source project driven
   by individual contributors and so what goes in 4.0 is largely up to those
   who do the work and put those features in.
   - Whilst it has been a long time since 3.0 was first released, the 3.x
   tick-tock experiment resulted in a large number of major releases in short
   succession and as such, I think most folks are simply recovering from that
   push + there is no longer a march to a vendors drum beat. Hence the slow
   down in major feature release and a focus on getting existing features more
   stable.
   - The major release of 3.11 was only released at the end of June 2017
   and it has had 2 point releases in the meantime.
   - Whilst not having a consistent major release schedule can be
   frustrating for end users and product marketers, not having a stable
   database is far more maddening.
   - Having said that, there is a good body of both large and small changes
   that are in "done/resolved", "patch ready", "awaiting feedback" etc and
   slated for 4.0 which would be good to get out the door. While this is a
   matter of opinion I think it's about reaching a nice balance of having not
   too many changes making it a larger adoption risk and having enough time to
   work on some good things (e.g.
   https://issues.apache.org/jira/browse/CASSANDRA-12229), such that it's
   actually worth working toward cutting a major release.
   - I'd respectfully disagree that we have a "basic collaboration
   challenge". This is primarily a community that communicates by gradually
   moving towards consensus (which takes time) and this thread is simply one
   of the many discussions and interactions that move towards consensus about
   4.0. If anything we are resource/people constrained, but that is true of
   all open source communities.

I've decided to respond on the previous thread, "Roadmap to 4.0"
(however just via the dev list where the discussion should live) with my
suggestions as I don't want to ignore both Kurt and Jeffs previous
contributions on this subject.

On Fri, Mar 30, 2018 at 6:49 PM Kenneth Brotman
 wrote:

> Just list any desired new major features for 4.0 that you want added.  I
> will maintain a compiled list for all to see.  Don't worry about any steps
> beyond this.  Don't make any judgements about or make any comments at all
> about what others add.
>
> No judgments at this point.  This is a list of everyone's suggestions.  Add
> your suggestions for new major features you desire to be added for version
> 4.0 only. Keep it simple, not detailed yet.  That comes a few steps from
> now.  What we have is a basic collaboration challenge.  No problem.
>
> Kenneth Brotman
>
>
>
>
>
> --
Ben Bromhead
CTO | Instaclustr 
+1 650 284 9692
Reliability at Scale
Cassandra, Spark, Elasticsearch on AWS, Azure, GCP and Softlayer

RE: A Simple List of New Major Features Desired for Apache Cassandra Version 4.0

[Kenneth Brotman]

Thanks Ben for taking the time to write your response.  I am still learning the 
culture and ways of the group.  I'm admittedly new to the open source way of 
doing things.  I am always anxious to pitch in.  Carry on.  I will leave it 
alone for now.

Kenneth Brotman

-Original Message-
From: Ben Bromhead [mailto:b...@instaclustr.com] 
Sent: Saturday, March 31, 2018 6:59 PM
To: dev@cassandra.apache.org
Subject: Re: A Simple List of New Major Features Desired for Apache Cassandra 
Version 4.0

Thank you, Kenneth, for listening to the PMC and for putting the discussion in 
the correct list. I also appreciate your enthusiasm.

To address a few of your points from your previous emails in no particular
order:

   - There is already a compiled list of features slated for 4.0, this list
   is simply a search using the following JQL on JIRA - `project =
   CASSANDRA AND fixVersion = 4.0 ORDER BY priority DESC, updated DESC`. By
   looking at this list, we can see fixes/patches/features that have been
   committed to trunk as well as tickets that are still in progress but
   someone at some point thought it was likely to land in 4.0
   - I appreciate a desire to create a bucket list of any and all desired
   features for 4.0, the reality is that this is an open source project driven
   by individual contributors and so what goes in 4.0 is largely up to those
   who do the work and put those features in.
   - Whilst it has been a long time since 3.0 was first released, the 3.x
   tick-tock experiment resulted in a large number of major releases in short
   succession and as such, I think most folks are simply recovering from that
   push + there is no longer a march to a vendors drum beat. Hence the slow
   down in major feature release and a focus on getting existing features more
   stable.
   - The major release of 3.11 was only released at the end of June 2017
   and it has had 2 point releases in the meantime.
   - Whilst not having a consistent major release schedule can be
   frustrating for end users and product marketers, not having a stable
   database is far more maddening.
   - Having said that, there is a good body of both large and small changes
   that are in "done/resolved", "patch ready", "awaiting feedback" etc and
   slated for 4.0 which would be good to get out the door. While this is a
   matter of opinion I think it's about reaching a nice balance of having not
   too many changes making it a larger adoption risk and having enough time to
   work on some good things (e.g.
   https://issues.apache.org/jira/browse/CASSANDRA-12229), such that it's
   actually worth working toward cutting a major release.
   - I'd respectfully disagree that we have a "basic collaboration
   challenge". This is primarily a community that communicates by gradually
   moving towards consensus (which takes time) and this thread is simply one
   of the many discussions and interactions that move towards consensus about
   4.0. If anything we are resource/people constrained, but that is true of
   all open source communities.

I've decided to respond on the previous thread, "Roadmap to 4.0"
(however just via the dev list where the discussion should live) with my 
suggestions as I don't want to ignore both Kurt and Jeffs previous 
contributions on this subject.

On Fri, Mar 30, 2018 at 6:49 PM Kenneth Brotman  
wrote:

> Just list any desired new major features for 4.0 that you want added.  
> I will maintain a compiled list for all to see.  Don't worry about any 
> steps beyond this.  Don't make any judgements about or make any 
> comments at all about what others add.
>
> No judgments at this point.  This is a list of everyone's suggestions.  
> Add your suggestions for new major features you desire to be added for 
> version
> 4.0 only. Keep it simple, not detailed yet.  That comes a few steps 
> from now.  What we have is a basic collaboration challenge.  No problem.
>
> Kenneth Brotman
>
>
>
>
>
> --
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