Re: [VOTE-2] Apache Cassandra Release Lifecycle

2019-10-09 Thread Mick Semb Wever 


> We have discussed in the email thread[1] about Apache Cassandra Release
> Lifecycle. We came up with a doc[2] for it. We have finalized the doc
> here[3] Please vote on it if you agree with the content of the doc [3].


+1 nb

the doc is good. it adds value for users, and does not need to be perfect.
thanks Sumanth for doing this.


-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: moving the site from SVN to git

2019-10-09 Thread Jon Haddad 
OK, I checked with INFRA on some details and will finish the migration
tomorrow.

On Thu, Oct 3, 2019 at 11:32 AM Jon Haddad  wrote:

> Awesome, thanks Michael.
>
> We need to do a little bit of additional configuration to have it switch
> over.  Specifically, we need to set up the .asf.yaml config to tell the
> servers how the site should be published.  I can take care of it
> tomorrow.
>
> Reference:
> https://cwiki.apache.org/confluence/display/INFRA/.asf.yaml+features+for+git+repositories#id-.asf.yamlfeaturesforgitrepositories-Publishingabranchtoyourprojectwebsite
>
> On Thu, Oct 3, 2019 at 10:57 AM Michael Shuler 
> wrote:
>
>> committed! :)
>>
>> https://gitbox.apache.org/repos/asf?p=cassandra-website.git
>>
>> Michael
>>
>> On 10/3/19 12:22 PM, Jon Haddad wrote:
>> > I think we can safely ignore them.  Thanks for figuring this out.
>> >
>> > On Thu, Oct 3, 2019 at 10:01 AM Michael Shuler 
>> > wrote:
>> >
>> >> I'm making progress through many periodic timeouts to svn.a.o and
>> >> restarts, but it appears that svn2git is smart enough to pick up where
>> >> it left off. The first commit captured at the svn path I'm specifying
>> is
>> >> when Cassandra was moved to a top level project at r922689
>> (2010-03-13).
>> >> I don't know the old incubator path, and it's probably OK to ignore the
>> >> few older incubator commits? I imagine it would mean starting over the
>> >> entire import to pull in those older incubator svn commits, then
>> >> changing the url and somehow importing the newer path on top?
>> >>
>> >> I tried using a local path as the source to try to speed things up,
>> >> after I got my first few timeouts, but that fails.
>> >>
>> >> Curious if anyone really cares if we lose a few early commits - if so,
>> I
>> >> can try to figure out the old path and start again.
>> >>
>> >> Michael
>> >>
>> >> On 10/3/19 11:14 AM, Jon Haddad wrote:
>> >>> Thanks for taking a look, Michael.  Hopefully you have better luck
>> than
>> >> me
>> >>> :)
>> >>>
>> >>> On Thu, Oct 3, 2019 at 6:42 AM Michael Shuler > >
>> >>> wrote:
>> >>>
>>  I cloned the empty cassandra-website git repo, and I'm running:
>> 
>>  svn2git http://svn.apache.org/repos/asf/cassandra/site --rootistrunk
>>  --no-minimize-url
>> 
>>  ..to see what I get. An svn checkout of the above url says it's only
>>  69M, so I suppose it's pulling all history of all time for all
>> projects?
>> 
>>  I'll let this roll for a while I run an errand and report back!
>> 
>>  Michael
>> 
>>  On 10/2/19 9:30 PM, Jon Haddad wrote:
>> > Daniel referred me to the GitBox self service system.
>> >
>> > I've attempted to port the site over using the tool Michael
>> suggested,
>>  but
>> > after a couple hours it died with this message:
>> >
>> > command failed: r922600
>> > git checkout -f master
>> >
>> > If either of you (Mick or Michael) want to give svn2git a shot maybe
>>  you'll
>> > get a different result.I think it may have been due to the large
>> >> size
>> > of the repo and the small drive on the VM I was using.  I can try it
>>  again
>> > tomorrow with more storage to see if I get a better result.  Mick if
>> >> you
>> > want to give it a shot in the meantime that would be appreciated.
>> >
>> > Jon
>> >
>> > On Wed, Oct 2, 2019 at 3:18 PM Jon Haddad 
>> wrote:
>> >
>> >> I created an INFRA ticket here:
>> >> https://issues.apache.org/jira/browse/INFRA-19218.
>> >>
>> >> On Wed, Sep 25, 2019 at 6:04 AM Michael Shuler <
>> >> mich...@pbandjelly.org>
>> >> wrote:
>> >>
>> >>> I see no good reason to trash history. There are tools to make
>> moving
>> >>> from svn to git (hopefully) painless. We used git-svn for the
>> main c*
>> >>> source to retain history of both, which this tool uses to do
>> >> migrations
>> >>> - https://github.com/nirvdrum/svn2git
>> >>>
>> >>> Michael
>> >>>
>> >>> On 9/25/19 12:57 AM, Mick Semb Wever wrote:
>> 
>> > Personally, no, I don't.  What I need to know is if someone who
>> >>> actually
>> > works on the site needs the history in *git*.
>> 
>> 
>>  Yes. I need the history in *git*.
>> 
>> 
>>  And I believe that INFRA can do the migration for you.
>>  (For example, INFRA-12055 and spark-website)
>> 
>> 
>> >> -
>>  To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>>  For additional commands, e-mail: dev-h...@cassandra.apache.org
>> 
>> >>>
>> >>>
>> -
>> >>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>> >>> For additional commands, e-mail: dev-h...@cassandra.apache.org
>> >>>
>> >>>
>> >
>> 
>>

Re: [VOTE-2] Apache Cassandra Release Lifecycle

2019-10-09 Thread Dinesh Joshi 
+1, lets evolve the document as we gain more experience with the proposed 
release lifecycle.

Dinesh

> On Oct 9, 2019, at 9:41 AM, Jon Haddad  wrote:
> 
> +1 works for me
> 
> On Wed, Oct 9, 2019 at 9:30 AM Michael Shuler 
> wrote:
> 
>> +1
>> 
>> --
>> Kind regards,
>> Michael
>> 
>> On Wed, Oct 9, 2019 at 9:06 AM Aleksey Yeshchenko
>>  wrote:
>>> 
>>> +1 as a rather reasonable starting point; we can make changes to the
>> process in the future if need be.
>>> 
 On 8 Oct 2019, at 19:00, sankalp kohli  wrote:
 
 Hi,
   We have discussed in the email thread[1] about Apache Cassandra
>> Release
 Lifecycle. We came up with a doc[2] for it. We have finalized the doc
 here[3] Please vote on it if you agree with the content of the doc [3].
 
 We did not proceed with the previous vote as we want to use confluence
>> for
 it. Here is the link for that[4]. It also mentions why we are doing
>> this
 vote.
 
 Vote will remain open for 72 hours.
 
 Thanks,
 Sankalp
 
 [1]
 
>> https://lists.apache.org/thread.html/c610b23f9002978636b66d09f0e0481ed3de9b78895050da22c91c6f@%3Cdev.cassandra.apache.org%3E
 [2]
 
>> https://docs.google.com/document/d/1bS6sr-HSrHFjZb0welife6Qx7u3ZDgRiAoENMLYlfz8/edit#heading=h.633eppni91tw
 [3]
>> https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle
 Attachments area
 [4]
 
>> https://lists.apache.org/thread.html/169b00f45dbad295e1aea1da70365fabc8452ef497f78ddfd28c311f@%3Cdev.cassandra.apache.org%3E
 <
>> https://docs.google.com/document/d/1bS6sr-HSrHFjZb0welife6Qx7u3ZDgRiAoENMLYlfz8/edit?usp=gmail#heading=h.633eppni91tw
>>> 
>>> 
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>>> For additional commands, e-mail: dev-h...@cassandra.apache.org
>>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>> For additional commands, e-mail: dev-h...@cassandra.apache.org
>> 
>> 


-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Protocol-impacting (internode and client) changes for 4.0

2019-10-09 Thread Dinesh Joshi 
+1

Dinesh

> On Oct 9, 2019, at 12:41 PM, Joshua McKenzie  wrote:
> 
>> 
>> each one of them is extremely low risk, which means that any validation
>> effort that has already happened won't have to be re-done
> 
> +1
> 
> On Wed, Oct 9, 2019 at 1:46 PM Jon Haddad  wrote:
> 
>> Seems reasonable, especially since we're in alpha mode.
>> 
>> On Wed, Oct 9, 2019 at 10:28 AM Aleksey Yeshchenko
>>  wrote:
>> 
>>> +1; in particular since the protocol itself is still in beta
>>> 
 On 9 Oct 2019, at 17:26, Oleksandr Petrov 
>>> wrote:
 
 Hi,
 
 During NGCC/ACNA19 we've had quite a few conversations around the 4.0
 release. Many (minor) features and changes suggested during that time
>> are
 possible to implement in 4.next without any problem. However, some
>>> changes
 that seem to be very important for the community, which got mentioned
>> in
 several conversations, are not possible to implement without protocol
 changes. By *protocol* changes here I mean both native and client
>>> protocol.
 
 Here's a shortlist of the issues in question:
 https://issues.apache.org/jira/browse/CASSANDRA-15349 Add “Going away”
 message to the client protocol
 https://issues.apache.org/jira/browse/CASSANDRA-15350 Add CAS
>>> “uncertainty”
 and “contention" messages that are currently propagated as a
 WriteTimeoutException.
 https://issues.apache.org/jira/browse/CASSANDRA-15351 Allow
>> configuring
 timeouts on the per-request basis
 https://issues.apache.org/jira/browse/CASSANDRA-15352 Replica failure
 propagation to coordinator and client
 https://issues.apache.org/jira/browse/CASSANDRA-15299 Improve
>>> checksumming
 and compression in protocol v5-beta
 
 And, less importantly - CASSANDRA-14683 (paging state issue).
 
 My suggestion would be to lift a freeze for all (or at least some) of
>>> these
 issues, since they seem to be quite important for operators and each
>> one
>>> of
 them is extremely low risk, which means that any validation effort that
>>> has
 already happened won't have to be re-done. All of the issues are fairly
 easy to implement, which means they won't delay the release.
 
 To my best knowledge, there's no client that fully supports 4.0, I
>> think
 doing this now actually makes sense, meaning that driver implementers
>>> won't
 really have to redo anything.
 
 Your thoughts on this are welcome,
 -- Alex
>>> 
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>>> For additional commands, e-mail: dev-h...@cassandra.apache.org
>>> 
>>> 
>> 


-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Protocol-impacting (internode and client) changes for 4.0

2019-10-09 Thread Joshua McKenzie 
>
> each one of them is extremely low risk, which means that any validation
> effort that has already happened won't have to be re-done

+1

On Wed, Oct 9, 2019 at 1:46 PM Jon Haddad  wrote:

> Seems reasonable, especially since we're in alpha mode.
>
> On Wed, Oct 9, 2019 at 10:28 AM Aleksey Yeshchenko
>  wrote:
>
> > +1; in particular since the protocol itself is still in beta
> >
> > > On 9 Oct 2019, at 17:26, Oleksandr Petrov 
> > wrote:
> > >
> > > Hi,
> > >
> > > During NGCC/ACNA19 we've had quite a few conversations around the 4.0
> > > release. Many (minor) features and changes suggested during that time
> are
> > > possible to implement in 4.next without any problem. However, some
> > changes
> > > that seem to be very important for the community, which got mentioned
> in
> > > several conversations, are not possible to implement without protocol
> > > changes. By *protocol* changes here I mean both native and client
> > protocol.
> > >
> > > Here's a shortlist of the issues in question:
> > > https://issues.apache.org/jira/browse/CASSANDRA-15349 Add “Going away”
> > > message to the client protocol
> > > https://issues.apache.org/jira/browse/CASSANDRA-15350 Add CAS
> > “uncertainty”
> > > and “contention" messages that are currently propagated as a
> > > WriteTimeoutException.
> > > https://issues.apache.org/jira/browse/CASSANDRA-15351 Allow
> configuring
> > > timeouts on the per-request basis
> > > https://issues.apache.org/jira/browse/CASSANDRA-15352 Replica failure
> > > propagation to coordinator and client
> > > https://issues.apache.org/jira/browse/CASSANDRA-15299 Improve
> > checksumming
> > > and compression in protocol v5-beta
> > >
> > > And, less importantly - CASSANDRA-14683 (paging state issue).
> > >
> > > My suggestion would be to lift a freeze for all (or at least some) of
> > these
> > > issues, since they seem to be quite important for operators and each
> one
> > of
> > > them is extremely low risk, which means that any validation effort that
> > has
> > > already happened won't have to be re-done. All of the issues are fairly
> > > easy to implement, which means they won't delay the release.
> > >
> > > To my best knowledge, there's no client that fully supports 4.0, I
> think
> > > doing this now actually makes sense, meaning that driver implementers
> > won't
> > > really have to redo anything.
> > >
> > > Your thoughts on this are welcome,
> > > -- Alex
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> >
>

Re: Protocol-impacting (internode and client) changes for 4.0

2019-10-09 Thread Jon Haddad 
Seems reasonable, especially since we're in alpha mode.

On Wed, Oct 9, 2019 at 10:28 AM Aleksey Yeshchenko
 wrote:

> +1; in particular since the protocol itself is still in beta
>
> > On 9 Oct 2019, at 17:26, Oleksandr Petrov 
> wrote:
> >
> > Hi,
> >
> > During NGCC/ACNA19 we've had quite a few conversations around the 4.0
> > release. Many (minor) features and changes suggested during that time are
> > possible to implement in 4.next without any problem. However, some
> changes
> > that seem to be very important for the community, which got mentioned in
> > several conversations, are not possible to implement without protocol
> > changes. By *protocol* changes here I mean both native and client
> protocol.
> >
> > Here's a shortlist of the issues in question:
> > https://issues.apache.org/jira/browse/CASSANDRA-15349 Add “Going away”
> > message to the client protocol
> > https://issues.apache.org/jira/browse/CASSANDRA-15350 Add CAS
> “uncertainty”
> > and “contention" messages that are currently propagated as a
> > WriteTimeoutException.
> > https://issues.apache.org/jira/browse/CASSANDRA-15351 Allow configuring
> > timeouts on the per-request basis
> > https://issues.apache.org/jira/browse/CASSANDRA-15352 Replica failure
> > propagation to coordinator and client
> > https://issues.apache.org/jira/browse/CASSANDRA-15299 Improve
> checksumming
> > and compression in protocol v5-beta
> >
> > And, less importantly - CASSANDRA-14683 (paging state issue).
> >
> > My suggestion would be to lift a freeze for all (or at least some) of
> these
> > issues, since they seem to be quite important for operators and each one
> of
> > them is extremely low risk, which means that any validation effort that
> has
> > already happened won't have to be re-done. All of the issues are fairly
> > easy to implement, which means they won't delay the release.
> >
> > To my best knowledge, there's no client that fully supports 4.0, I think
> > doing this now actually makes sense, meaning that driver implementers
> won't
> > really have to redo anything.
> >
> > Your thoughts on this are welcome,
> > -- Alex
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: Protocol-impacting (internode and client) changes for 4.0

2019-10-09 Thread Aleksey Yeshchenko 
+1; in particular since the protocol itself is still in beta

> On 9 Oct 2019, at 17:26, Oleksandr Petrov  wrote:
> 
> Hi,
> 
> During NGCC/ACNA19 we've had quite a few conversations around the 4.0
> release. Many (minor) features and changes suggested during that time are
> possible to implement in 4.next without any problem. However, some changes
> that seem to be very important for the community, which got mentioned in
> several conversations, are not possible to implement without protocol
> changes. By *protocol* changes here I mean both native and client protocol.
> 
> Here's a shortlist of the issues in question:
> https://issues.apache.org/jira/browse/CASSANDRA-15349 Add “Going away”
> message to the client protocol
> https://issues.apache.org/jira/browse/CASSANDRA-15350 Add CAS “uncertainty”
> and “contention" messages that are currently propagated as a
> WriteTimeoutException.
> https://issues.apache.org/jira/browse/CASSANDRA-15351 Allow configuring
> timeouts on the per-request basis
> https://issues.apache.org/jira/browse/CASSANDRA-15352 Replica failure
> propagation to coordinator and client
> https://issues.apache.org/jira/browse/CASSANDRA-15299 Improve checksumming
> and compression in protocol v5-beta
> 
> And, less importantly - CASSANDRA-14683 (paging state issue).
> 
> My suggestion would be to lift a freeze for all (or at least some) of these
> issues, since they seem to be quite important for operators and each one of
> them is extremely low risk, which means that any validation effort that has
> already happened won't have to be re-done. All of the issues are fairly
> easy to implement, which means they won't delay the release.
> 
> To my best knowledge, there's no client that fully supports 4.0, I think
> doing this now actually makes sense, meaning that driver implementers won't
> really have to redo anything.
> 
> Your thoughts on this are welcome,
> -- Alex


-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Protocol-impacting (internode and client) changes for 4.0

2019-10-09 Thread Benedict Elliott Smith 
+1

On 09/10/2019, 17:50, "Oleksandr Petrov"  wrote:

Hi,

During NGCC/ACNA19 we've had quite a few conversations around the 4.0
release. Many (minor) features and changes suggested during that time are
possible to implement in 4.next without any problem. However, some changes
that seem to be very important for the community, which got mentioned in
several conversations, are not possible to implement without protocol
changes. By *protocol* changes here I mean both native and client protocol.

Here's a shortlist of the issues in question:
https://issues.apache.org/jira/browse/CASSANDRA-15349 Add “Going away”
message to the client protocol
https://issues.apache.org/jira/browse/CASSANDRA-15350 Add CAS “uncertainty”
and “contention" messages that are currently propagated as a
WriteTimeoutException.
https://issues.apache.org/jira/browse/CASSANDRA-15351 Allow configuring
timeouts on the per-request basis
https://issues.apache.org/jira/browse/CASSANDRA-15352 Replica failure
propagation to coordinator and client
https://issues.apache.org/jira/browse/CASSANDRA-15299 Improve checksumming
and compression in protocol v5-beta

And, less importantly - CASSANDRA-14683 (paging state issue).

My suggestion would be to lift a freeze for all (or at least some) of these
issues, since they seem to be quite important for operators and each one of
them is extremely low risk, which means that any validation effort that has
already happened won't have to be re-done. All of the issues are fairly
easy to implement, which means they won't delay the release.

To my best knowledge, there's no client that fully supports 4.0, I think
doing this now actually makes sense, meaning that driver implementers won't
really have to redo anything.

Your thoughts on this are welcome,
-- Alex




-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Protocol-impacting (internode and client) changes for 4.0

2019-10-09 Thread Oleksandr Petrov 
Hi,

During NGCC/ACNA19 we've had quite a few conversations around the 4.0
release. Many (minor) features and changes suggested during that time are
possible to implement in 4.next without any problem. However, some changes
that seem to be very important for the community, which got mentioned in
several conversations, are not possible to implement without protocol
changes. By *protocol* changes here I mean both native and client protocol.

Here's a shortlist of the issues in question:
https://issues.apache.org/jira/browse/CASSANDRA-15349 Add “Going away”
message to the client protocol
https://issues.apache.org/jira/browse/CASSANDRA-15350 Add CAS “uncertainty”
and “contention" messages that are currently propagated as a
WriteTimeoutException.
https://issues.apache.org/jira/browse/CASSANDRA-15351 Allow configuring
timeouts on the per-request basis
https://issues.apache.org/jira/browse/CASSANDRA-15352 Replica failure
propagation to coordinator and client
https://issues.apache.org/jira/browse/CASSANDRA-15299 Improve checksumming
and compression in protocol v5-beta

And, less importantly - CASSANDRA-14683 (paging state issue).

My suggestion would be to lift a freeze for all (or at least some) of these
issues, since they seem to be quite important for operators and each one of
them is extremely low risk, which means that any validation effort that has
already happened won't have to be re-done. All of the issues are fairly
easy to implement, which means they won't delay the release.

To my best knowledge, there's no client that fully supports 4.0, I think
doing this now actually makes sense, meaning that driver implementers won't
really have to redo anything.

Your thoughts on this are welcome,
-- Alex

Re: [VOTE-2] Apache Cassandra Release Lifecycle

2019-10-09 Thread Michael Shuler 
+1

-- 
Kind regards,
Michael

On Wed, Oct 9, 2019 at 9:06 AM Aleksey Yeshchenko
 wrote:
>
> +1 as a rather reasonable starting point; we can make changes to the process 
> in the future if need be.
>
> > On 8 Oct 2019, at 19:00, sankalp kohli  wrote:
> >
> > Hi,
> >We have discussed in the email thread[1] about Apache Cassandra Release
> > Lifecycle. We came up with a doc[2] for it. We have finalized the doc
> > here[3] Please vote on it if you agree with the content of the doc [3].
> >
> > We did not proceed with the previous vote as we want to use confluence for
> > it. Here is the link for that[4]. It also mentions why we are doing this
> > vote.
> >
> > Vote will remain open for 72 hours.
> >
> > Thanks,
> > Sankalp
> >
> > [1]
> > https://lists.apache.org/thread.html/c610b23f9002978636b66d09f0e0481ed3de9b78895050da22c91c6f@%3Cdev.cassandra.apache.org%3E
> > [2]
> > https://docs.google.com/document/d/1bS6sr-HSrHFjZb0welife6Qx7u3ZDgRiAoENMLYlfz8/edit#heading=h.633eppni91tw
> > [3]https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle
> > Attachments area
> > [4]
> > https://lists.apache.org/thread.html/169b00f45dbad295e1aea1da70365fabc8452ef497f78ddfd28c311f@%3Cdev.cassandra.apache.org%3E
> > 
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: [VOTE-2] Apache Cassandra Release Lifecycle

2019-10-09 Thread Aleksey Yeshchenko 
+1 as a rather reasonable starting point; we can make changes to the process in 
the future if need be.

> On 8 Oct 2019, at 19:00, sankalp kohli  wrote:
> 
> Hi,
>We have discussed in the email thread[1] about Apache Cassandra Release
> Lifecycle. We came up with a doc[2] for it. We have finalized the doc
> here[3] Please vote on it if you agree with the content of the doc [3].
> 
> We did not proceed with the previous vote as we want to use confluence for
> it. Here is the link for that[4]. It also mentions why we are doing this
> vote.
> 
> Vote will remain open for 72 hours.
> 
> Thanks,
> Sankalp
> 
> [1]
> https://lists.apache.org/thread.html/c610b23f9002978636b66d09f0e0481ed3de9b78895050da22c91c6f@%3Cdev.cassandra.apache.org%3E
> [2]
> https://docs.google.com/document/d/1bS6sr-HSrHFjZb0welife6Qx7u3ZDgRiAoENMLYlfz8/edit#heading=h.633eppni91tw
> [3]https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle
> Attachments area
> [4]
> https://lists.apache.org/thread.html/169b00f45dbad295e1aea1da70365fabc8452ef497f78ddfd28c311f@%3Cdev.cassandra.apache.org%3E
> 


-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org