-1
Discussions here and on slack have brought up a number of important
concerns. I think those concerns need to be summarised here before any
informal vote.
It was my understanding that some of those concerns may even be blockers to
a move to 16. That is we have to presume the worse case scenario
+1 on 8
rahul.xavier.si...@gmail.com
http://cassandra.link
The Apache Cassandra Knowledge Base.
On Feb 17, 2020, 5:20 PM -0500, Erick Ramirez ,
wrote:
> +1 on 8 tokens. I'd personally like us to be able to move this along pretty
> quickly as it's confusing for users looking for direction. Cheers
> On Feb 17, 2020, at 12:52 PM, Jeff Jirsa wrote:
>
> Hard to see an argument for CASSANDRA-2848 being in scope for 4.0 (beyond the
> client proto change being painful for anything other than major releases).
>
Even if it doesn't affect v4 protocol?
Dinesh
--
+1 on 8 tokens. I'd personally like us to be able to move this along pretty
quickly as it's confusing for users looking for direction. Cheers!
On Tue, 18 Feb 2020, 9:14 am Jeremy Hanna,
wrote:
> I just wanted to close the loop on this if possible. After some discussion
> in slack about various
I just wanted to close the loop on this if possible. After some discussion
in slack about various topics, I would like to see if people are okay with
num_tokens=8 by default (as it's not much different operationally than
16). Joey brought up a few small changes that I can put on the ticket. It
a
Hard to see an argument for CASSANDRA-2848 being in scope for 4.0 (beyond the
client proto change being painful for anything other than major releases).
> On Feb 17, 2020, at 12:43 PM, Jon Meredith wrote:
>
> My turn to give an update on 4.0 status. The 4.0 board created by Josh can
> be
My turn to give an update on 4.0 status. The 4.0 board created by Josh can
be found at
https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=355.
We have 94 unresolved tickets marked against the 4.0 release. [1]
Things seem to have settled into a phase of working to resolve issues,
