Re: Message from the ASF Board or Directors about recent Cassandra discussions

[Nate McCall]

Bertrand,
Thank you very much for reaching out.

I put the following in the upcoming board report, but I'll repeat it
here because I think it sums things up:

"If nothing else, it's clear we all care very deeply about having
successful open source software projects."

To that end, let's all move forward. There is a lot to do, but it's
clear to me that we have the talent, resources, community and
organizational support to succeed.

Sincerest thanks,
-Nate


On Wed, Nov 9, 2016 at 6:30 AM, Bertrand Delacretaz
 wrote:
> Dear Cassandra PMC and community,
>
> The Board of Directors of the ASF apologizes for contributing to the
> sometimes heated nature of discussions in the last few days on this
> list.
>
> We have reminded board members to remain civil in such discussions,
> whatever the context and history.
>
> As published in the reports that the Cassandra PMC regularly makes to
> the Board [0] there have been concerns earlier this year about the
> project not being sufficiently independent, which is a very strong
> requirement for Apache projects.
>
> We are aware that progress is being made and are hopeful that good
> progress will be continued.
>
> As for the Cassandra community, the Board is looking forward to a
> continued healthy Cassandra project and feels that the project is on a
> good track to recover from this somewhat difficult period.
>
> We wish Cassandra a bright future and are proud to have such a
> successful project at the ASF!
>
> -- Bertrand Delacretaz, for the ASF Board of Directors.
>
> [0] https://whimsy.apache.org/board/minutes/Cassandra.html

Re: [VOTE] Release Apache Cassandra 3.10 (Take 2)

[Nate McCall]

+1

On Wed, Nov 9, 2016 at 9:09 AM, Michael Shuler  wrote:
> I propose the following artifacts for release as 3.10.
>
> sha1: 072b5271a88328b909b230d0e30df1c7476fdb3f
> Git:
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.10-tentative
> Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1133/org/apache/cassandra/apache-cassandra/3.10/
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachecassandra-1133/
>
>
>
> The Debian packages are available here:
> http://people.apache.org/~mshuler
>
>
>
> The vote will be open for 72 hours (longer if needed).
>
>
>
> [1]: (CHANGES.txt) https://goo.gl/TZa9a7
>
> [2]: (NEWS.txt) https://goo.gl/FSI1a4

Re: [VOTE] Release Apache Cassandra 3.0.10 (Take 2)

[Nate McCall]

+1

On Wed, Nov 9, 2016 at 9:08 AM, Michael Shuler  wrote:
> I propose the following artifacts for release as 3.0.10.
>
> sha1: 4e0bced5e6a82ebd22b074b8ef96d930c5f3159d
> Git:
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.0.10-tentative
> Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1132/org/apache/cassandra/apache-cassandra/3.0.10/
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachecassandra-1132/
>
> The Debian packages are available here: http://people.apache.org/~mshuler
>
> The vote will be open for 72 hours (longer if needed).
>
> [1]: (CHANGES.txt) https://goo.gl/mnmZgI
> [2]: (NEWS.txt) https://goo.gl/F1kAmR

[VOTE] Release Apache Cassandra 3.10 (Take 2)

[Michael Shuler]

I propose the following artifacts for release as 3.10.

sha1: 072b5271a88328b909b230d0e30df1c7476fdb3f
Git:
http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.10-tentative
Artifacts:
https://repository.apache.org/content/repositories/orgapachecassandra-1133/org/apache/cassandra/apache-cassandra/3.10/
Staging repository:
https://repository.apache.org/content/repositories/orgapachecassandra-1133/



The Debian packages are available here:
http://people.apache.org/~mshuler



The vote will be open for 72 hours (longer if needed).



[1]: (CHANGES.txt) https://goo.gl/TZa9a7

[2]: (NEWS.txt) https://goo.gl/FSI1a4

[VOTE] Release Apache Cassandra 3.0.10 (Take 2)

[Michael Shuler]

I propose the following artifacts for release as 3.0.10.

sha1: 4e0bced5e6a82ebd22b074b8ef96d930c5f3159d
Git:
http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.0.10-tentative
Artifacts:
https://repository.apache.org/content/repositories/orgapachecassandra-1132/org/apache/cassandra/apache-cassandra/3.0.10/
Staging repository:
https://repository.apache.org/content/repositories/orgapachecassandra-1132/

The Debian packages are available here: http://people.apache.org/~mshuler

The vote will be open for 72 hours (longer if needed).

[1]: (CHANGES.txt) https://goo.gl/mnmZgI
[2]: (NEWS.txt) https://goo.gl/F1kAmR

Re: Slow performance after upgrading from 2.0.9 to 2.1.11

[Dikang Gu]

Michael, thanks for the info. It sounds to me a very serious performance
regression. :(

On Tue, Nov 8, 2016 at 11:39 AM, Michael Kjellman <
mkjell...@internalcircle.com> wrote:

> Yes, We hit this as well. We have a internal patch that I wrote to mostly
> revert the behavior back to ByteBuffers with as small amount of code change
> as possible. Performance of our build is now even with 2.0.x and we've also
> forward ported it to 3.x (although the 3.x patch was even more complicated
> due to Bounds, RangeTombstoneBound, ClusteringPrefix which actually
> increases the number of allocations to somewhere between 11 and 13
> depending on how I count it per indexed block -- making it even worse than
> what you're observing in 2.1.
>
> We haven't upstreamed it as 2.1 is obviously not taking any changes at
> this point and the longer term solution is https://issues.apache.org/
> jira/browse/CASSANDRA-9754 (which also includes the changes to go back to
> ByteBuffers and remove as much of the Composites from the storage engine as
> possible.) Also, the solution is a bit of a hack -- although it was a
> blocker from us deploying 2.1 -- so i'm not sure how "hacky" it is if it
> works..
>
> best,
> kjellman
>
>
> On Nov 8, 2016, at 11:31 AM, Dikang Gu  an...@gmail.com>> wrote:
>
> This is very expensive:
>
> "MessagingService-Incoming-/2401:db00:21:1029:face:0:9:0" prio=10
> tid=0x7f2fd57e1800 nid=0x1cc510 runnable [0x7f2b971b]
>java.lang.Thread.State: RUNNABLE
> at org.apache.cassandra.db.marshal.IntegerType.compare(
> IntegerType.java:29)
> at org.apache.cassandra.db.composites.AbstractSimpleCellNameType.
> compare(AbstractSimpleCellNameType.java:98)
> at org.apache.cassandra.db.composites.AbstractSimpleCellNameType.
> compare(AbstractSimpleCellNameType.java:31)
> at java.util.TreeMap.put(TreeMap.java:545)
> at java.util.TreeSet.add(TreeSet.java:255)
> at org.apache.cassandra.db.filter.NamesQueryFilter$
> Serializer.deserialize(NamesQueryFilter.java:254)
> at org.apache.cassandra.db.filter.NamesQueryFilter$
> Serializer.deserialize(NamesQueryFilter.java:228)
> at org.apache.cassandra.db.SliceByNamesReadCommandSeriali
> zer.deserialize(SliceByNamesReadCommand.java:104)
> at org.apache.cassandra.db.ReadCommandSerializer.
> deserialize(ReadCommand.java:156)
> at org.apache.cassandra.db.ReadCommandSerializer.
> deserialize(ReadCommand.java:132)
> at org.apache.cassandra.net.MessageIn.read(MessageIn.java:99)
> at org.apache.cassandra.net.IncomingTcpConnection.receiveMessage(
> IncomingTcpConnection.java:195)
> at org.apache.cassandra.net.IncomingTcpConnection.receiveMessages(
> IncomingTcpConnection.java:172)
> at org.apache.cassandra.net.IncomingTcpConnection.run(
> IncomingTcpConnection.java:88)
>
>
> Checked the git history, it comes from this jira:
> https://issues.apache.org/jira/browse/CASSANDRA-5417
>
> Any thoughts?
> ​
>
> On Fri, Oct 28, 2016 at 10:32 AM, Paulo Motta  mailto:pauloricard...@gmail.com>> wrote:
> Haven't seen this before, but perhaps it's related to CASSANDRA-10433?
> This is just a wild guess as it's in a related codepath, but maybe worth
> trying out the patch available to see if it helps anything...
>
> 2016-10-28 15:03 GMT-02:00 Dikang Gu  an...@gmail.com>>:
> We are seeing huge cpu regression when upgrading one of our 2.0.16 cluster
> to 2.1.14 as well. The 2.1.14 node is not able to handle the same amount of
> read traffic as the 2.0.16 node, actually, it's less than 50%.
>
> And in the perf results, the first line could go as high as 50%, as we
> turn up the read traffic, which never appeared in 2.0.16.
>
> Any thoughts?
> Thanks
>
>
> Samples: 952K of event 'cycles', Event count (approx.): 229681774560
> Overhead  Shared Object  Symbol
>6.52%  perf-196410.map[.]
> Lorg/apache/cassandra/db/marshal/IntegerType;.compare in
> Lorg/apache/cassandra/db/composites/AbstractSimpleCellNameType;.compare
>4.84%  libzip.so  [.] adler32
>2.88%  perf-196410.map[.]
> Ljava/nio/HeapByteBuffer;.get in Lorg/apache/cassandra/db/
> marshal/IntegerType;.compare
>2.39%  perf-196410.map[.]
> Ljava/nio/Buffer;.checkIndex in Lorg/apache/cassandra/db/
> marshal/IntegerType;.findMostSignificantByte
>2.03%  perf-196410.map[.]
> Ljava/math/BigInteger;.compareTo in Lorg/apache/cassandra/db/
> DecoratedKey;.compareTo
>1.65%  perf-196410.map[.] vtable chunks
>1.44%  perf-196410.map[.]
> Lorg/apache/cassandra/db/DecoratedKey;.compareTo in Ljava/util/concurrent/
> ConcurrentSkipListMap;.findNode
>1.02%  perf-196410.map[.]
> 

Re: Slow performance after upgrading from 2.0.9 to 2.1.11

[Michael Kjellman]

Yes, We hit this as well. We have a internal patch that I wrote to mostly 
revert the behavior back to ByteBuffers with as small amount of code change as 
possible. Performance of our build is now even with 2.0.x and we've also 
forward ported it to 3.x (although the 3.x patch was even more complicated due 
to Bounds, RangeTombstoneBound, ClusteringPrefix which actually increases the 
number of allocations to somewhere between 11 and 13 depending on how I count 
it per indexed block -- making it even worse than what you're observing in 2.1.

We haven't upstreamed it as 2.1 is obviously not taking any changes at this 
point and the longer term solution is 
https://issues.apache.org/jira/browse/CASSANDRA-9754 (which also includes the 
changes to go back to ByteBuffers and remove as much of the Composites from the 
storage engine as possible.) Also, the solution is a bit of a hack -- although 
it was a blocker from us deploying 2.1 -- so i'm not sure how "hacky" it is if 
it works..

best,
kjellman


On Nov 8, 2016, at 11:31 AM, Dikang Gu 
> wrote:

This is very expensive:

"MessagingService-Incoming-/2401:db00:21:1029:face:0:9:0" prio=10 
tid=0x7f2fd57e1800 nid=0x1cc510 runnable [0x7f2b971b]
   java.lang.Thread.State: RUNNABLE
at 
org.apache.cassandra.db.marshal.IntegerType.compare(IntegerType.java:29)
at 
org.apache.cassandra.db.composites.AbstractSimpleCellNameType.compare(AbstractSimpleCellNameType.java:98)
at 
org.apache.cassandra.db.composites.AbstractSimpleCellNameType.compare(AbstractSimpleCellNameType.java:31)
at java.util.TreeMap.put(TreeMap.java:545)
at java.util.TreeSet.add(TreeSet.java:255)
at 
org.apache.cassandra.db.filter.NamesQueryFilter$Serializer.deserialize(NamesQueryFilter.java:254)
at 
org.apache.cassandra.db.filter.NamesQueryFilter$Serializer.deserialize(NamesQueryFilter.java:228)
at 
org.apache.cassandra.db.SliceByNamesReadCommandSerializer.deserialize(SliceByNamesReadCommand.java:104)
at 
org.apache.cassandra.db.ReadCommandSerializer.deserialize(ReadCommand.java:156)
at 
org.apache.cassandra.db.ReadCommandSerializer.deserialize(ReadCommand.java:132)
at org.apache.cassandra.net.MessageIn.read(MessageIn.java:99)
at 
org.apache.cassandra.net.IncomingTcpConnection.receiveMessage(IncomingTcpConnection.java:195)
at 
org.apache.cassandra.net.IncomingTcpConnection.receiveMessages(IncomingTcpConnection.java:172)
at 
org.apache.cassandra.net.IncomingTcpConnection.run(IncomingTcpConnection.java:88)


Checked the git history, it comes from this jira: 
https://issues.apache.org/jira/browse/CASSANDRA-5417

Any thoughts?
​

On Fri, Oct 28, 2016 at 10:32 AM, Paulo Motta 
> wrote:
Haven't seen this before, but perhaps it's related to CASSANDRA-10433? This is 
just a wild guess as it's in a related codepath, but maybe worth trying out the 
patch available to see if it helps anything...

2016-10-28 15:03 GMT-02:00 Dikang Gu 
>:
We are seeing huge cpu regression when upgrading one of our 2.0.16 cluster to 
2.1.14 as well. The 2.1.14 node is not able to handle the same amount of read 
traffic as the 2.0.16 node, actually, it's less than 50%.

And in the perf results, the first line could go as high as 50%, as we turn up 
the read traffic, which never appeared in 2.0.16.

Any thoughts?
Thanks


Samples: 952K of event 'cycles', Event count (approx.): 229681774560
Overhead  Shared Object  Symbol
   6.52%  perf-196410.map[.] 
Lorg/apache/cassandra/db/marshal/IntegerType;.compare in 
Lorg/apache/cassandra/db/composites/AbstractSimpleCellNameType;.compare
   4.84%  libzip.so  [.] adler32
   2.88%  perf-196410.map[.] 
Ljava/nio/HeapByteBuffer;.get in 
Lorg/apache/cassandra/db/marshal/IntegerType;.compare
   2.39%  perf-196410.map[.] 
Ljava/nio/Buffer;.checkIndex in 
Lorg/apache/cassandra/db/marshal/IntegerType;.findMostSignificantByte
   2.03%  perf-196410.map[.] 
Ljava/math/BigInteger;.compareTo in 
Lorg/apache/cassandra/db/DecoratedKey;.compareTo
   1.65%  perf-196410.map[.] vtable chunks
   1.44%  perf-196410.map[.] 
Lorg/apache/cassandra/db/DecoratedKey;.compareTo in 
Ljava/util/concurrent/ConcurrentSkipListMap;.findNode
   1.02%  perf-196410.map[.] 
Lorg/apache/cassandra/db/composites/AbstractSimpleCellNameType;.compare
   1.00%  
snappy-1.0.5.2-libsnappyjava.so
[.] 0x3804
   0.87%  perf-196410.map[.] 
Ljava/io/DataInputStream;.readFully in 
Lorg/apache/cassandra/db/AbstractCell$1;.computeNext
   0.82%  

Re: Slow performance after upgrading from 2.0.9 to 2.1.11

[Dikang Gu]

This is very expensive:

"MessagingService-Incoming-/2401:db00:21:1029:face:0:9:0" prio=10
tid=0x7f2fd57e1800 nid=0x1cc510 runnable [0x7f2b971b]
   java.lang.Thread.State: RUNNABLE
at
org.apache.cassandra.db.marshal.IntegerType.compare(IntegerType.java:29)
at
org.apache.cassandra.db.composites.AbstractSimpleCellNameType.compare(AbstractSimpleCellNameType.java:98)
at
org.apache.cassandra.db.composites.AbstractSimpleCellNameType.compare(AbstractSimpleCellNameType.java:31)
at java.util.TreeMap.put(TreeMap.java:545)
at java.util.TreeSet.add(TreeSet.java:255)
at
org.apache.cassandra.db.filter.NamesQueryFilter$Serializer.deserialize(NamesQueryFilter.java:254)
at
org.apache.cassandra.db.filter.NamesQueryFilter$Serializer.deserialize(NamesQueryFilter.java:228)
at
org.apache.cassandra.db.SliceByNamesReadCommandSerializer.deserialize(SliceByNamesReadCommand.java:104)
at
org.apache.cassandra.db.ReadCommandSerializer.deserialize(ReadCommand.java:156)
at
org.apache.cassandra.db.ReadCommandSerializer.deserialize(ReadCommand.java:132)
at org.apache.cassandra.net.MessageIn.read(MessageIn.java:99)
at
org.apache.cassandra.net.IncomingTcpConnection.receiveMessage(IncomingTcpConnection.java:195)
at
org.apache.cassandra.net.IncomingTcpConnection.receiveMessages(IncomingTcpConnection.java:172)
at
org.apache.cassandra.net.IncomingTcpConnection.run(IncomingTcpConnection.java:88)


Checked the git history, it comes from this jira:
https://issues.apache.org/jira/browse/CASSANDRA-5417

Any thoughts?
​

On Fri, Oct 28, 2016 at 10:32 AM, Paulo Motta 
wrote:

> Haven't seen this before, but perhaps it's related to CASSANDRA-10433?
> This is just a wild guess as it's in a related codepath, but maybe worth
> trying out the patch available to see if it helps anything...
>
> 2016-10-28 15:03 GMT-02:00 Dikang Gu :
>
>> We are seeing huge cpu regression when upgrading one of our 2.0.16
>> cluster to 2.1.14 as well. The 2.1.14 node is not able to handle the same
>> amount of read traffic as the 2.0.16 node, actually, it's less than 50%.
>>
>> And in the perf results, the first line could go as high as 50%, as we
>> turn up the read traffic, which never appeared in 2.0.16.
>>
>> Any thoughts?
>> Thanks
>>
>>
>> Samples: 952K of event 'cycles', Event count (approx.): 229681774560
>> Overhead  Shared Object  Symbol
>>6.52%  perf-196410.map[.]
>> Lorg/apache/cassandra/db/marshal/IntegerType;.compare in
>> Lorg/apache/cassandra/db/composites/AbstractSimpleCellNameType;.compare
>>4.84%  libzip.so  [.] adler32
>>2.88%  perf-196410.map[.]
>> Ljava/nio/HeapByteBuffer;.get in Lorg/apache/cassandra/db/marsh
>> al/IntegerType;.compare
>>2.39%  perf-196410.map[.]
>> Ljava/nio/Buffer;.checkIndex in Lorg/apache/cassandra/db/marsh
>> al/IntegerType;.findMostSignificantByte
>>2.03%  perf-196410.map[.]
>> Ljava/math/BigInteger;.compareTo in Lorg/apache/cassandra/db/Decor
>> atedKey;.compareTo
>>1.65%  perf-196410.map[.] vtable chunks
>>1.44%  perf-196410.map[.]
>> Lorg/apache/cassandra/db/DecoratedKey;.compareTo in
>> Ljava/util/concurrent/ConcurrentSkipListMap;.findNode
>>1.02%  perf-196410.map[.]
>> Lorg/apache/cassandra/db/composites/AbstractSimpleCellNameType;.compare
>>1.00%  snappy-1.0.5.2-libsnappyjava.so[.] 0x3804
>>0.87%  perf-196410.map[.]
>> Ljava/io/DataInputStream;.readFully in Lorg/apache/cassandra/db/Abstr
>> actCell$1;.computeNext
>>0.82%  snappy-1.0.5.2-libsnappyjava.so[.] 0x36dc
>>0.79%  [kernel]   [k]
>> copy_user_generic_string
>>0.73%  perf-196410.map[.] vtable chunks
>>0.71%  perf-196410.map[.]
>> Lorg/apache/cassandra/db/OnDiskAtom$Serializer;.deserializeFromSSTable
>> in Lorg/apache/cassandra/db/AbstractCell$1;.computeNext
>>0.70%  [kernel]   [k] find_busiest_group
>>0.69%  perf-196410.map[.] <80>H3^?
>>0.68%  perf-196410.map[.]
>> Lorg/apache/cassandra/db/DecoratedKey;.compareTo
>>0.65%  perf-196410.map[.]
>> jbyte_disjoint_arraycopy
>>0.64%  [kernel]   [k] _raw_spin_lock
>>0.63%  [kernel]   [k] __schedule
>>0.45%  snappy-1.0.5.2-libsnappyjava.so[.] 0x36df
>>
>> On Fri, Jan 29, 2016 at 2:11 PM, Corry Opdenakker 
>> wrote:
>>
>>> @JC, Get the pid of your target java process (something like "ps -ef |
>>> grep -i cassandra") .
>>> Then do a 

Re: [VOTE] Close client-...@cassandra.apache.org mailing list

[Ben Bromhead]

+1 (non-binding)

On Tue, 8 Nov 2016 at 10:05 Jake Farrell  wrote:

> +1
>
> -Jake
>
> On Mon, Nov 7, 2016 at 12:11 AM, Jeff Jirsa  wrote:
>
> > There exists a nearly unused mailing list,
> client-...@cassandra.apache.org
> > [0].
> >
> > This is a summary of the email threads over the past 12 months on that
> > list:
> >
> > 1) ApacheCon Seville CFP Close notice
> > 2) Datastax .NET driver question
> > 3) Datastax Java driver question
> > 4) FOSDEM announce
> > 5) ApacheCon NA CFP Open noticed
> >
> > In order to avoid confusion, and given the lack of relevant and
> > appropriate traffic, I propose we close the client-dev@ list entirely.
> > Any traffic appropriate for the client-dev@ list would likely be better
> > served if it were directed at dev@, which is more active.
> >
> > This vote will remain open for 72 hours.
> >
> > 0: https://lists.apache.org/list.html?client-...@cassandra.apache.org
> >
> >
> >
>
-- 
Ben Bromhead
CTO | Instaclustr 
+1 650 284 9692
Managed Cassandra / Spark on AWS, Azure and Softlayer

Re: [VOTE] Close client-...@cassandra.apache.org mailing list

[Jake Farrell]

+1

-Jake

On Mon, Nov 7, 2016 at 12:11 AM, Jeff Jirsa  wrote:

> There exists a nearly unused mailing list, client-...@cassandra.apache.org
> [0].
>
> This is a summary of the email threads over the past 12 months on that
> list:
>
> 1) ApacheCon Seville CFP Close notice
> 2) Datastax .NET driver question
> 3) Datastax Java driver question
> 4) FOSDEM announce
> 5) ApacheCon NA CFP Open noticed
>
> In order to avoid confusion, and given the lack of relevant and
> appropriate traffic, I propose we close the client-dev@ list entirely.
> Any traffic appropriate for the client-dev@ list would likely be better
> served if it were directed at dev@, which is more active.
>
> This vote will remain open for 72 hours.
>
> 0: https://lists.apache.org/list.html?client-...@cassandra.apache.org
>
>
>

Re: Review of Cassandra actions

[Mark Thomas]

On 07/11/2016 10:52, Benedict Elliott Smith wrote:
> Hi Mark,
> 
> Thanks, that was a calm and diplomatic email.
> 
> recognise where they might need to apologise
> 
> 
> I will start the ball rolling here, as I have not always been generous in
> my interpretations of others' actions, and have certainly contributed to
> escalation.
> 
> But I wonder if you would also help get the ball rolling; your reasonable
> tone gives me hope that you can.  The topic for me has been: can board
> members recognise publicly where they have misstepped.  Doing so provides
> assurances to the whole ASF community that the board can be trusted.
> 
> https://www.mail-archive.com/user@cassandra.apache.org/msg48692.html
> 
> In this email chain not long ago, you attempted to apply a misreading of
> the ASF guidelines to non-ASF individuals.  When I pointed this out, you
> went silent.  In that chain, as now, I had a righteous indignation that no
> doubt inflamed the topic, and could have resolved the issue with more
> diplomacy.  I'm also sure you had excellent intentions.
> 
> Nevertheless, you did misstep as a board member by quite badly misapplying
> the guidelines.  With no public recognition of this, I was left with an
> impression of unaccountability; I don't know how others responded.

Benedict,

First of all, let me explain why I didn't respond. That particular
sub-thread had all the indications that it was heading towards the same
sort of heated, unproductive, negative discussion that has been observed
recently on this list. I wanted to avoid that. It is possible that the
tone could have been turned around with the right e-mail but writing
those e-mails takes time that I didn't have. I therefore took the option
to simply ignore your email. It might not have been the perfect choice
but it did mean that the heated discussion was avoided and I had more
time for other ASF things, both inside Apache Cassandra and outside.

Clearly you are unhappy about how you view my actions in that thread. I
believe that that is primarily due to a misunderstanding. Let me try and
correct that by providing more explanation and context. I could have,
and with hindsight should have, provided that explanation and context at
the time. Had I done so, I think the misunderstanding could have been
avoided. Consider that a lesson learned.

One of the topics at the August board meeting was the continuing
concerns that had been raised with the board (from various sources both
within the project and externally) regarding Apache Cassandra. There was
a generally productive discussion between the board and the PMC members
who attended the meeting and one of the points made by the PMC was that,
while they agreed that there were issues, they were unsure what they
could/should be doing to address them. The PMC asked if the board could
provide a set of concrete actions it expected from the PMC. As a board
member who had not been directly involved in Cassandra to that point, I
volunteered to review the various threads discussing the concerns, put
together the list of actions and provide the Cassandra PMC with a point
of contact if they had any questions or concerns as they worked through
those actions. I provided the list to the PMC towards the end of August.

Around the same time I subscribed to all of the Apache Cassandra mailing
lists. This was primarily to monitor the PMC's progress with their actions.

One of the things I quickly noticed was that many users required
additional resources (reference docs, how to guides, components, tools)
over and above that provided directly by the project. While
individually, none of these resources gave cause for concern,
collectively, I was left with a perception of the project not being as
firmly rooted at the ASF as it could/should be.

Getting to the thread in question, it resonated with the perception I
had of the project not being firmly rooted at the ASF. A user was being
directed to 3rd party docs rather than the official Apache Cassandra
docs and it appeared that the official docs were better (more up to date
/ complete).

I did not intend to suggest Ryan was trying to do anything but help a
user. My intention was to try and understand why/how it had happened
with a view to improving things going forward. If I left Ryan in
particular or anyone else with the impression that I thought Ryan was
somehow at fault, I apologise. I did not then, and do not now, think
Ryan did anything wrong.

Ryan's explanation made perfect sense. I still think it is worth the
project looking at whether there is any SEO tuning that can be done to
improve the search ranking of cassandra.a.o for "CQL" (and any other
terms relevant to the project). I say this because other Apache projects
I have been involved have been able to improve their search ranking with
various web-site tweaks. I don't know enough about SEO to know if those
tweaks would help Cassandra.

I would have pursued this more at the time but I read the second
paragraph of