On Mon, Apr 23, 2018 at 9:13 PM, San Luoji wrote:
> Dor,
>
> Setting the Thread Per Core code aside, will your developers commit to
> contribute back both https://issues.apache.org/jira/browse/CASSANDRA-2848
> and https://issues.apache.org/jira/browse/CASSANDRA-14311?
>
> Looks like CASSANDRA-284
Dor,
Setting the Thread Per Core code aside, will your developers commit to
contribute back both https://issues.apache.org/jira/browse/CASSANDRA-2848
and https://issues.apache.org/jira/browse/CASSANDRA-14311?
Looks like CASSANDRA-2848 has stalled even though some respectable work was
done, and CA
Respectfully, there’s pretty much already apparent consensus among those with a
vote (unless I missed some dissenting opinion while I was on vacation).
Its been expressed multiple times by committers and members of the PMC that
it’s Cassandra native protocol, it belongs in the protocol when it’s
Apologies Nate - didn't realize I'd overlapped with you stepping in and
trying to bring us all back to reason.
I'll take my leave of the conversation at this point. :)
On Mon, Apr 23, 2018 at 9:30 PM, Josh McKenzie wrote:
> > Datastax, Apple, Instaclstr,
> > thelastpickle and everyone else
> >
> Datastax, Apple, Instaclstr,
> thelastpickle and everyone else
> receive different benefits
You have mentioned a variety of vendors who received benefits while making
major contributions back to the project. Comparing Scylla's relationship to
the Cassandra ecosystem to this list is a false equiva
Folks,
Before this goes much further, let's take a step back for a second.
I am hearing the following: Folks are fine with CASSANDRA-14311 and
CASSANDRA-2848 *BUT* they don't make much sense from the project's
perspective without a reference implementation. I think the shard
concept is too abstrac
On Mon, Apr 23, 2018 at 5:28 PM, Josh McKenzie wrote:
> > it's not
> > reasonable to expect Scylla to contribute
> > such a huge effort to the C* server
>
> But it's reasonable that a major portion of Scylla's business model is
> profiting off those huge efforts other companies have made?
>
> See
If you are so concerned about forking protocol, why did you fork the server?
Please pick a side and not what is suitable for your Business.
On Apr 23, 2018, at 17:28, Josh McKenzie wrote:
>> it's not
>> reasonable to expect Scylla to contribute
>> such a huge effort to the C* server
>
> Bu
> it's not
> reasonable to expect Scylla to contribute
> such a huge effort to the C* server
But it's reasonable that a major portion of Scylla's business model is
profiting off those huge efforts other companies have made?
Seems a little hypocritical to me.
On Mon, Apr 23, 2018, 8:18 PM Dor Lao
On Mon, Apr 23, 2018 at 5:03 PM, Sankalp Kohli
wrote:
> Is one of the “abuse” of Apache license is ScyllaDB which is using
> Cassandra but not contributing back?
>
It's not that we have a private version of Cassandra and we don't release
all of it or some of it back..
We didn't contribute becau
Is one of the “abuse” of Apache license is ScyllaDB which is using Cassandra
but not contributing back?
Happy to be proved wrong as I am not a lawyer and don’t understand various
licenses ..
> On Apr 23, 2018, at 16:55, Dor Laor wrote:
>
>> On Mon, Apr 23, 2018 at 4:13 PM, Jonathan Haddad wro
On Mon, Apr 23, 2018 at 4:13 PM, Jonathan Haddad wrote:
> From where I stand it looks like you've got only two options for any
> feature that involves updating the protocol:
>
> 1. Don't built the feature
> 2. Built it in Cassanda & scylladb, update the drivers accordingly
>
> I don't think you h
>From where I stand it looks like you've got only two options for any
feature that involves updating the protocol:
1. Don't built the feature
2. Built it in Cassanda & scylladb, update the drivers accordingly
I don't think you have a third option, which is built it only in ScyllaDB,
because that
> >> This doesn't work without additional changes, for RF>1. The token ring
> could place two replicas of the same token range on the same physical
> server, even though those are two separate cores of the same server. You
> could add another element to the hierarchy (cluster -> datacenter -> rack
On 2018-04-22 23:35, Josh McKenzie wrote:
The drivers are not part of Cassandra, so what "the server" is for drivers is
up to their maintainer.
I'm pretty sure the driver communities don't spend a lot of time
worrying about their Scylla compatibility. That's your cross to bear.
To clarify,
On 2018-04-22 18:00, Ariel Weisberg wrote:
Hi,
This doesn't work without additional changes, for RF>1. The token ring could place two
replicas of the same token range on the same physical server, even though those are two
separate cores of the same server. You could add another element to t
16 matches
Mail list logo
