cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From kurt greaves <>
Subject Roadmap for 4.0
Date Mon, 12 Feb 2018 04:29:32 GMT
Hi friends,
*TL;DR: Making a plan for 4.0, ideally everyone interested should provide
up to two lists, one for tickets they can contribute resources to getting
finished, and one for features they think would be desirable for 4.0, but
not necessarily have the resources to commit to helping with.*

So we had that Roadmap for 4.0 discussion last year, but there was never a
conclusion or a plan that came from it. Times getting on and the changes
list for 4.0 is getting pretty big. I'm thinking it would probably make
sense to define some goals to getting 4.0 released/have an actual plan. 4.0
is already going to be quite an unwieldy release with a lot of testing

Note: the following is open to discussion, if people don't like the plan
feel free to speak up. But in the end it's a pretty basic plan and I don't
think we should over-complicate it, I also don't want to end up in a
discussion where we "make a plan to make a plan". Regardless of whatever
plan we do end up following it would still be valuable to have a list of
tickets for 4.0 which is the overall goal of this email - so let's not get
too worked up on the details just yet (save that for after I
summarise/follow up).

I think the best way to go about this would be for us to come up with a
list of JIRA's that we want included in 4.0, tag these as 4.0, and all
other improvements as 4.x. We can then aim to release 4.0 once all the 4.0
tagged tickets (+bug fixes/blockers) are complete.

Now, the catch is that we obviously don't want to include too many tickets
in 4.0, but at the same time we want to make sure 4.0 has an appealing
feature set for both users/operators/developers. To minimise scope creep I
think the following strategy will help:

We should maintain two lists:

   1. JIRA's that people want in 4.0 and can commit resources to getting
   them implemented in 4.0.
   2. JIRA's that people simply think would be desirable for 4.0, but
   currently don't have anyone assigned to them or planned assignment. It
   would probably make sense to label these with an additional tag in
JIRA. *(User's
   please feel free to point out what you want here)*

>From list 1 will come our source of truth for when we release 4.0. (after
aggregating a list I will summarise and we can vote on it).

List 2 would be the "hopeful" list, where stories can be picked up from if
resourcing allows, or where someone comes along and decides it's good
enough to work on. I guess we can also base this on a vote system if we
reach the point of including some of them. (but for the moment it's purely
to get an idea of what users actually want).

Please don't refrain from listing something that's already been mentioned.
The purpose is to get an idea of everyone's priorities/interests and the
resources available. We will need multiple resources for each ticket, so
anywhere we share an interest will make for a lot easier work sharing.

Note that we are only talking about improvements here. Bugs will be treated
the same as always, and major issues/regressions we'll need to fix prior to
4.0 anyway.

Generally I think it's a bad idea to commit to any hard deadline, but we
should have some time frames in mind. My idea would be to aim for a Q3/4
2018 release, and as we go we just review the outstanding improvements and
decide whether it's worth pushing it back or if we've got enough to
release. I suppose keep this time frame in mind when choosing your tickets.

We can aim for an earlier date (midyear?) but I figure the
testing/validation/bugfixing period prior to release might drag on a bit so
being a bit conservative here.
The main goal would be to not let list 1 grow unless we're well ahead, and
only cull from it if we're heavily over-committed or we decide the
improvement can wait. I assume this all sounds like common sense but
figured it's better to spell it out now.

After 2 weeks/whenever the discussion dies off I'll consolidate all the
tickets, relevant comments and follow up with a summary, where we can
discuss/nitpick issues and come up with a final list to go ahead with.

On a side note, in conjunction with this effort we'll obviously have to do
something about validation and testing. I'll keep that out of this email
for now, but there will be a follow up so that those of us willing to help
validate/test trunk can avoid duplicating effort.

This is the list of "huge/breaking" tickets that got mentioned in the last
roadmap discussion and their statuses. This is not terribly important but
just so we can keep in mind what we previously talked about. I think we
leave it up to the relevant contributors to decide whether they want to get
the still open tickets into 4.0.

CASSANDRA-9425 Immutable node-local schema
<> - Committed
CASSANDRA-10699 Strongly consistent schema alterations
<> - Open, no
discussion in quite some time.
CASSANDRA-12229 NIO streaming
<> - Committed
CASSANDRA-8457 NIO messaging
<> - Committed
CASSANDRA-12345 Gossip 2.0
<> - Open, no sign of
any action.
CASSANDRA-9754 Make index info heap friendly for large CQL partitions
<> - In progress but no
update in a long time.
CASSANDRA-11559 enhanced node representation
<> - Open, no change
since early 2016.
CASSANDRA-6246 epaxos <> -
In progress but no update since Feb 2017.
CASSANDRA-7544 storage port configurable per node
<> - Committed
CASSANDRA-11115 remove thrift support
<> - Committed
CASSANDRA-10857 dropping compact storage
<> - Committed

To start us off...
And here are my lists to get us started.
CASSANDRA-8460 - Tiered/Cold storage for TWCS
CASSANDRA-12783 - Batchlog redesign
CASSANDRA-11559 - Enchance node representation
    CASSANDRA-12344 - Forward writes to replacement node with same address
CASSANDRA-8119 - More expressive Consistency Levels
CASSANDRA-14210 - Optimise SSTables upgrade task scheduling
CASSANDRA-10540 - RangeAwareCompaction

CASSANDRA-10726 - Read repair inserts should not be blocking
CASSANDRA-9754 - Make index info heap friendly for large CQL partitions
CASSANDRA-12294 - LDAP auth
CASSANDRA-12151 - Audit logging
CASSANDRA-10495 - Fix streaming with vnodes

Also, here's some handy JQL to start you off:
project = CASSANDRA AND fixVersion in (4.x, 4.0) AND issue in
watchedIssues() AND status != Resolved

View raw message