cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Ellis <jbel...@gmail.com>
Subject Re: Cassandra Java Driver and DataStax
Date Sat, 04 Jun 2016 14:58:16 GMT
On Sat, Jun 4, 2016 at 8:59 AM, Chris Mattmann <mattmann@apache.org> wrote:

> Thanks Jonathan. I’m starting to get a clearer idea of what’s
> going on here. Do you think it was a walled garden in terms of
> making reviews for incoming driver patches when you did have
> them in the tree?


Not exactly sure what you mean, but we did see our responsibility in terms
of maintaining our project extend to reviewing patches for drivers while
they were in tree.


> What you are talking about in the first paragraph
> is precisely the reason that your community expands and that you
> create new PMC members and committers as they contribute things.
>

In principle I agree, but when you have six or seven or more parts of the
tree whose committers' expertise does not overlap, I think it really does
make sense for these to be organized as separate projects.

Furthermore, it sounds like you are saying for Java and Python
> these weren’t “fly by” contributions and more work has gone on
> in those drivers than e.g., compared to Clojure, C++, etc.
>

That was the case five years ago, and would probably still be the case if
we had kept drivers in tree.  Making them their own projects has resulted
in more and higher quality drivers overall.

I note that among similar Apache projects,

- CouchDB drivers are not maintained in-tree
<https://cwiki.apache.org/confluence/display/COUCHDB/CouchDB+clients>
- HBase maintains only a Java driver in-tree
- Accumulo maintains only a Java driver in-tree

Put another way, I see four projects that have all more or less
independently concluded that trying to maintain a lot of drivers as part of
a single Apache project is not a good way to organize things.

-- 
Jonathan Ellis
Project Chair, Apache Cassandra
co-founder, http://www.datastax.com
@spyced

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message