Re: ant warning - multiple versions of ant detected in path for junit

2016-06-04 Thread Dave Brosius 

It's just a warning, so hopefully isn't an issue. It's possible that adding

includeantruntime="false"

to the  tasks may help this, altho the combination of junit and 
forking might gum up the works.


I'd expect most people see this.

On 06/04/2016 09:46 PM, Mahdi Mohammadi wrote:

Output of `ant test` for each test suit contains this warning:

*test:*
*[mkdir] Created dir: /Users/mahdi/box/cassandra/build/test/cassandra*
*[mkdir] Created dir: /Users/mahdi/box/cassandra/build/test/output*
*[junit] WARNING: multiple versions of ant detected in path for junit *
*[junit]
  
jar:file:/usr/local/Cellar/ant/1.9.6/libexec/lib/ant.jar!/org/apache/tools/ant/Project.class*
*[junit]  and
jar:file:/Users/mahdi/box/cassandra/build/lib/jars/ant-1.9.4.jar!/org/apache/tools/ant/Project.class*

How can I fix this warning?

Best Regards

Re: Cassandra Java Driver and DataStax

2016-06-04 Thread Jonathan Ellis 
He already showed himself a good man by apologizing. Please, no more
mudslinging. We're on the same team here.
On Jun 4, 2016 2:22 PM, "Michael Kjellman" 
wrote:

> No need to argue your point to me anymore. I've already tuned you out.
>
> These are good people who I consider my friends and insulting people just
> shows your arguments really have no merit.
>
> Good luck with your new driver contribution! I look forward to reviewing
> the code.
>
> Sent from my iPhone
>
> > On Jun 4, 2016, at 10:10 AM, James Carman 
> wrote:
> >
> > I apologized else-thread about that one.  It was a low blow.  Anyway, to
> > answer your question. The Cassandra community wins!  How do we know if
> they
> > won't make you pay for the driver in the future (after all your code is
> > written against it)?  It has happened before.  Also, the rest of the
> > community can have a say in the direction (because that's the Apache
> Way).
> > The driver can be more intimate with the database, because it's the same
> > people developing it.
> >
> >> On Sat, Jun 4, 2016 at 1:06 PM Aleksey Yeschenko 
> wrote:
> >>
> >> An eloquent and powerful response, but please, reply to my points
> instead
> >> of resorting to ad hominem arguments.
> >>
> >> In practical terms, who would benefit from such a merge, and who is
> >> suffering from the current state of affairs?
> >>
> >> --
> >> AY
> >>
> >> On 4 June 2016 at 18:03:05, James Carman (ja...@carmanconsulting.com)
> >> wrote:
> >>
> >> "Sr. Software Engineer at DataStax", imagine that.
> >>
> >> On Sat, Jun 4, 2016 at 1:01 PM Aleksey Yeschenko 
> >> wrote:
> >>
> >>> As a member of that governing body (Cassandra PMC), I would much prefer
> >>> not to deal with the drivers as well.
> >>>
> >>> And I’m just as certain that java-driver - and other driver
> communities -
> >>> would much rather prefer to keep their process and organisation instead
> >> of
> >>> being forced to conform to ours.
> >>>
> >>> I’m finding it hard to see a single party that would benefit from such
> a
> >>> merge, and who suffers from the current state of things.
> >>>
> >>> --
> >>> AY
> >>>
> >>> On 4 June 2016 at 17:46:48, James Carman (ja...@carmanconsulting.com)
> >>> wrote:
> >>>
> >>> How does it add more complexity by having one governing body (the PMC)?
> >>> What I am suggesting is that the driver project be somewhat of a
> >> subproject
> >>> or a "module". It can still have its own life cycle, just like it does
> >> now.
> >>>
> >>> On Sat, Jun 4, 2016 at 12:44 PM Nate McCall 
> >>> wrote:
> >>>
>  It doesnt. But then we add complexity in communicating and managing
>  versions, releases, etc. to the project. Again, from my experience
> with
>  hector, I just didnt want the hassle of owning that within the project
>  confines.
> 
>  On Sat, Jun 4, 2016 at 11:30 AM, James Carman <
> >>> ja...@carmanconsulting.com>
>  wrote:
> 
> > Who said the driver has to be released with the database?
> >
> > On Sat, Jun 4, 2016 at 12:29 PM Nate McCall 
> > wrote:
> >
> >> On Sat, Jun 4, 2016 at 10:05 AM, James Carman <
> > ja...@carmanconsulting.com>
> >> wrote:
> >>
> >>> So why not just donate the Java driver and keep that in house?
> > Cassandra
> >> is
> >>> a Java project. Makes sense to me.
> >>>
> >>>
> >> I won't deny there is an argument to be made here, but as a former
>  client
> >> maintainer (Hector), current ASF committer (Usergrid) and active
> > community
> >> member since late 2009, my opinion is that this would be a step
> > backwards.
> >>
> >> Maintaining Hector independently allowed me the freedom to release
>  major
> >> features with technology that I wanted to use while maintaining
>  backwards
> >> compatibility without having to be bound to the project's release
> >>> cycle
> > and
> >> process. (And to use a build system that didnt suck).
> >>
> >> The initial concern of the use of the word "controls" is *super*
> >> not
>  cool
> >> and I hope that this is being fixed. That said, the reality, from
> >> my
> >> (external to DataStax) perspective, is that this is not the case. I
>  like
> >> the current project separation the way it is and don't feel like
> >>> there
>  is
> >> any attempt at "control" of the java driver's direction and
>  development.
> >>
> >> -Nate
> >>
> >
> 
> 
> 
>  --
>  -
>  Nate McCall
>  Austin, TX
>  @zznate
> 
>  CTO
>  Apache Cassandra Consulting
>  http://www.thelastpickle.com
> 
> >>>
> >>
>

Re: Cassandra Java Driver and DataStax

2016-06-04 Thread Michael Kjellman 
No need to argue your point to me anymore. I've already tuned you out.

These are good people who I consider my friends and insulting people just shows 
your arguments really have no merit. 

Good luck with your new driver contribution! I look forward to reviewing the 
code. 

Sent from my iPhone

> On Jun 4, 2016, at 10:10 AM, James Carman  wrote:
> 
> I apologized else-thread about that one.  It was a low blow.  Anyway, to
> answer your question. The Cassandra community wins!  How do we know if they
> won't make you pay for the driver in the future (after all your code is
> written against it)?  It has happened before.  Also, the rest of the
> community can have a say in the direction (because that's the Apache Way).
> The driver can be more intimate with the database, because it's the same
> people developing it.
> 
>> On Sat, Jun 4, 2016 at 1:06 PM Aleksey Yeschenko  wrote:
>> 
>> An eloquent and powerful response, but please, reply to my points instead
>> of resorting to ad hominem arguments.
>> 
>> In practical terms, who would benefit from such a merge, and who is
>> suffering from the current state of affairs?
>> 
>> --
>> AY
>> 
>> On 4 June 2016 at 18:03:05, James Carman (ja...@carmanconsulting.com)
>> wrote:
>> 
>> "Sr. Software Engineer at DataStax", imagine that.
>> 
>> On Sat, Jun 4, 2016 at 1:01 PM Aleksey Yeschenko 
>> wrote:
>> 
>>> As a member of that governing body (Cassandra PMC), I would much prefer
>>> not to deal with the drivers as well.
>>> 
>>> And I’m just as certain that java-driver - and other driver communities -
>>> would much rather prefer to keep their process and organisation instead
>> of
>>> being forced to conform to ours.
>>> 
>>> I’m finding it hard to see a single party that would benefit from such a
>>> merge, and who suffers from the current state of things.
>>> 
>>> --
>>> AY
>>> 
>>> On 4 June 2016 at 17:46:48, James Carman (ja...@carmanconsulting.com)
>>> wrote:
>>> 
>>> How does it add more complexity by having one governing body (the PMC)?
>>> What I am suggesting is that the driver project be somewhat of a
>> subproject
>>> or a "module". It can still have its own life cycle, just like it does
>> now.
>>> 
>>> On Sat, Jun 4, 2016 at 12:44 PM Nate McCall 
>>> wrote:
>>> 
 It doesnt. But then we add complexity in communicating and managing
 versions, releases, etc. to the project. Again, from my experience with
 hector, I just didnt want the hassle of owning that within the project
 confines.
 
 On Sat, Jun 4, 2016 at 11:30 AM, James Carman <
>>> ja...@carmanconsulting.com>
 wrote:
 
> Who said the driver has to be released with the database?
> 
> On Sat, Jun 4, 2016 at 12:29 PM Nate McCall 
> wrote:
> 
>> On Sat, Jun 4, 2016 at 10:05 AM, James Carman <
> ja...@carmanconsulting.com>
>> wrote:
>> 
>>> So why not just donate the Java driver and keep that in house?
> Cassandra
>> is
>>> a Java project. Makes sense to me.
>>> 
>>> 
>> I won't deny there is an argument to be made here, but as a former
 client
>> maintainer (Hector), current ASF committer (Usergrid) and active
> community
>> member since late 2009, my opinion is that this would be a step
> backwards.
>> 
>> Maintaining Hector independently allowed me the freedom to release
 major
>> features with technology that I wanted to use while maintaining
 backwards
>> compatibility without having to be bound to the project's release
>>> cycle
> and
>> process. (And to use a build system that didnt suck).
>> 
>> The initial concern of the use of the word "controls" is *super*
>> not
 cool
>> and I hope that this is being fixed. That said, the reality, from
>> my
>> (external to DataStax) perspective, is that this is not the case. I
 like
>> the current project separation the way it is and don't feel like
>>> there
 is
>> any attempt at "control" of the java driver's direction and
 development.
>> 
>> -Nate
>> 
> 
 
 
 
 --
 -
 Nate McCall
 Austin, TX
 @zznate
 
 CTO
 Apache Cassandra Consulting
 http://www.thelastpickle.com
 
>>> 
>>

Re: Cassandra Java Driver and DataStax

2016-06-04 Thread Brandon Williams 
First off, full disclosure: contributor, committer, PMC member, and
finally, Datastax employee, in about that order chronologically.

All of the drivers, as far as I know, are Apache licensed, just as is
Cassandra itself.  There is no 'control', there is only momentum, since
anyone can fork the code if needed and then perhaps gain the momentum if
Datastax loses it.  Nobody is locked in to anything, and no sufficient
traction has been found to take the momentum away from Datastax yet,
because at least in my own admittedly biased opinion, our drivers team has
done an excellent job of accepting community feedback and requests.

tl;dr don't fix what is not broken

On Fri, Jun 3, 2016 at 11:11 PM, Mattmann, Chris A (3980) <
chris.a.mattm...@jpl.nasa.gov> wrote:

> Thanks Jason for the information - I’m going to continue
> researching and hope more people will chime in that are on
> the PMC.
>
> Thank you.
>
> Cheers,
> Chris
>
> ++
> Chris Mattmann, Ph.D.
> Chief Architect
> Instrument Software and Science Data Systems Section (398)
> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
> Office: 168-519, Mailstop: 168-527
> Email: chris.a.mattm...@nasa.gov
> WWW:  http://sunset.usc.edu/~mattmann/
> ++
> Director, Information Retrieval and Data Science Group (IRDS)
> Adjunct Associate Professor, Computer Science Department
> University of Southern California, Los Angeles, CA 90089 USA
> WWW: http://irds.usc.edu/
> ++
>
>
>
>
>
>
>
>
>
> On 6/3/16, 8:33 PM, "Jason Brown"  wrote:
>
> >
> >
> >
> >The client-server protocol is well defined in the Cassandra repo, so any
> one may implement a client library for any language. However, it is a far
> from trivial task, so not many folks build their own. Thus, already-built
> drivers tend to become the de facto
> > standard, but we (the Apache Cassandra committers/PMC) do not/have not
> blessed any vendor's driver(s) as official.
> >
> >
> >As to why there is not a canonical set of drivers in the Cassandra repo,
> well, we've just never gotten into that game as an OSS community.
> >
> >
> >-Jason (not affiliated with DataStax)
> >
> >On Friday, June 3, 2016, Johan Edstrom  wrote:
> >
> >
> >
> >On Jun 3, 2016, at 9:14 PM, Jeff Jirsa  > wrote:
> >
> >
> >https://github.com/hector-client/hector
> >
> >
> >
> >
> >
> >
> >So - that isn’t doing CQL, Right?
> >
> >
> >https://github.com/Netflix/astyanax
> >
> >
> >
> >
> >
> >
> >Upgrading to CQL?
> >
> >
> >
> >http://doanduyhai.github.io/Achilles/
> >
> >
> >
> >
> >
> >
> >
> >Which driver do you use?
> >
> >
> >https://github.com/noorq/casser
> >
> >
> >
> >
> >
> >
> >2.1.5
> >
> >
> >
> >
> >
> >https://github.com/impetus-opensource/Kundera
> >
> >
> >
> >
> >
> >
> >
> >ds-driver
> >
> >false
> >
> >
> >cassandra-core
> >cassandra-ds-driver
> >
> >
> >
> >thrift
> >
> >false
> >
> >
> >cassandra-core
> >cassandra-thrift
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >https://github.com/deanhiller/playorm
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >- Jeff ( Not affiliated with datastax )
> >
> >
> >
> >
> >
> >On 6/3/16, 7:58 PM, "Johan Edstrom"  > wrote:
> >
> >
> >How many Java drivers could you point out?
> >Doesn’t it strike you slightly off that you’d not have a driver for a DB
> >in the same project you found the DB?
> >
> >
> >
> >On Jun 3, 2016, at 8:51 PM, Dave Brosius  > wrote:
> >
> >There are many drivers for cassandra, supplied by various individuals and
> groups, one of those drivers was started by people at datastax which is
> available as an opensource project.
> >
> >The open source project is not open to any random person on the internet
> to commit to (just like any open source project), so i suppose in that
> regard there is some 'control'. But i doubt that is what you are fishing
> for.
> >
> >--dave
> >
> >(not affiliated with datastax)
> >
> >On 06/03/2016 10:29 PM, Chris Mattmann wrote:
> >Hi All,
> >
> >I’m investigating something a few ASF members contacted
> >me about and pointed out, so I’m hoping you can help
> >guide me here as a community. I have heard that a company,
> >DataStax, whose marketing material mentions it as the only
> >Cassandra vendor, “controls” the Java Driver for Apache
> >Cassandra.
> >
> >Of course, no company “controls” our projects or its code,
> >so I told the folks that mentioned it to me that I’d investigate
> >with my board hat on.
> >
> >I’d like to hear the community’s thoughts here on this. Does
> >anyone in the community see this “controlling” behavior going
> >on? Please speak

Re: Cassandra Java Driver and DataStax

2016-06-04 Thread Aleksey Yeschenko 
The java-driver is fully Apache licensed. In the implausible scenario something 
like that happens, we can always simply fork it and start maintaining it 
ourselves.

As long as java-driver community are good community citizens - as they are, and 
have been since day one - we are happy to have that non-trivial amount of work 
done by them.

Also, I’m curious to know where/when ‘it has happened before’.

-- 
AY

On 4 June 2016 at 18:10:35, James Carman (ja...@carmanconsulting.com) wrote:

I apologized else-thread about that one. It was a low blow. Anyway, to  
answer your question. The Cassandra community wins! How do we know if they  
won't make you pay for the driver in the future (after all your code is  
written against it)? It has happened before. Also, the rest of the  
community can have a say in the direction (because that's the Apache Way).  
The driver can be more intimate with the database, because it's the same  
people developing it.  

On Sat, Jun 4, 2016 at 1:06 PM Aleksey Yeschenko  wrote:  

> An eloquent and powerful response, but please, reply to my points instead  
> of resorting to ad hominem arguments.  
>  
> In practical terms, who would benefit from such a merge, and who is  
> suffering from the current state of affairs?  
>  
> --  
> AY  
>  
> On 4 June 2016 at 18:03:05, James Carman (ja...@carmanconsulting.com)  
> wrote:  
>  
> "Sr. Software Engineer at DataStax", imagine that.  
>  
> On Sat, Jun 4, 2016 at 1:01 PM Aleksey Yeschenko   
> wrote:  
>  
> > As a member of that governing body (Cassandra PMC), I would much prefer  
> > not to deal with the drivers as well.  
> >  
> > And I’m just as certain that java-driver - and other driver communities -  
> > would much rather prefer to keep their process and organisation instead  
> of  
> > being forced to conform to ours.  
> >  
> > I’m finding it hard to see a single party that would benefit from such a  
> > merge, and who suffers from the current state of things.  
> >  
> > --  
> > AY  
> >  
> > On 4 June 2016 at 17:46:48, James Carman (ja...@carmanconsulting.com)  
> > wrote:  
> >  
> > How does it add more complexity by having one governing body (the PMC)?  
> > What I am suggesting is that the driver project be somewhat of a  
> subproject  
> > or a "module". It can still have its own life cycle, just like it does  
> now.  
> >  
> > On Sat, Jun 4, 2016 at 12:44 PM Nate McCall   
> > wrote:  
> >  
> > > It doesnt. But then we add complexity in communicating and managing  
> > > versions, releases, etc. to the project. Again, from my experience with  
> > > hector, I just didnt want the hassle of owning that within the project  
> > > confines.  
> > >  
> > > On Sat, Jun 4, 2016 at 11:30 AM, James Carman <  
> > ja...@carmanconsulting.com>  
> > > wrote:  
> > >  
> > > > Who said the driver has to be released with the database?  
> > > >  
> > > > On Sat, Jun 4, 2016 at 12:29 PM Nate McCall   
> > > > wrote:  
> > > >  
> > > > > On Sat, Jun 4, 2016 at 10:05 AM, James Carman <  
> > > > ja...@carmanconsulting.com>  
> > > > > wrote:  
> > > > >  
> > > > > > So why not just donate the Java driver and keep that in house?  
> > > > Cassandra  
> > > > > is  
> > > > > > a Java project. Makes sense to me.  
> > > > > >  
> > > > > >  
> > > > > I won't deny there is an argument to be made here, but as a former  
> > > client  
> > > > > maintainer (Hector), current ASF committer (Usergrid) and active  
> > > > community  
> > > > > member since late 2009, my opinion is that this would be a step  
> > > > backwards.  
> > > > >  
> > > > > Maintaining Hector independently allowed me the freedom to release  
> > > major  
> > > > > features with technology that I wanted to use while maintaining  
> > > backwards  
> > > > > compatibility without having to be bound to the project's release  
> > cycle  
> > > > and  
> > > > > process. (And to use a build system that didnt suck).  
> > > > >  
> > > > > The initial concern of the use of the word "controls" is *super*  
> not  
> > > cool  
> > > > > and I hope that this is being fixed. That said, the reality, from  
> my  
> > > > > (external to DataStax) perspective, is that this is not the case. I  
> > > like  
> > > > > the current project separation the way it is and don't feel like  
> > there  
> > > is  
> > > > > any attempt at "control" of the java driver's direction and  
> > > development.  
> > > > >  
> > > > > -Nate  
> > > > >  
> > > >  
> > >  
> > >  
> > >  
> > > --  
> > > -  
> > > Nate McCall  
> > > Austin, TX  
> > > @zznate  
> > >  
> > > CTO  
> > > Apache Cassandra Consulting  
> > > http://www.thelastpickle.com  
> > >  
> >  
>

Re: Cassandra Java Driver and DataStax

2016-06-04 Thread Nate McCall 
On Sat, Jun 4, 2016 at 12:07 PM, James Carman 
wrote:
>
> On Sat, Jun 4, 2016 at 1:05 PM Nate McCall  wrote:
>
> > Whereas the health of my company and title rely heavily on a thriving
open
> > source community, yet Aleksey and I are in agreement. Let's keep it up
at
> > the level of the project and technical merits, please.
> >
> >
> Okay, that might have been a bit of a low-blow, and I apologize.  But,
> we've seen this sort of thing happen around the organization.  We need to
> make sure that things stay "fair" for everyone and that outside influences
> don't unduly drive the project.


I understand and I have been equally frustrated by other projects recently.
At the end of the day, I do appreciate the effort in looking into this.

I'm going to re-iterate and call it a day:
- I dont feel like there is an issue with the current driver being separate
- There are some technical and project direction reasons whey it's good
idea to keep it out of the PMC's purview

Cheers,
-Nate

Re: Cassandra Java Driver and DataStax

2016-06-04 Thread James Carman 
I apologized else-thread about that one.  It was a low blow.  Anyway, to
answer your question. The Cassandra community wins!  How do we know if they
won't make you pay for the driver in the future (after all your code is
written against it)?  It has happened before.  Also, the rest of the
community can have a say in the direction (because that's the Apache Way).
The driver can be more intimate with the database, because it's the same
people developing it.

On Sat, Jun 4, 2016 at 1:06 PM Aleksey Yeschenko  wrote:

> An eloquent and powerful response, but please, reply to my points instead
> of resorting to ad hominem arguments.
>
> In practical terms, who would benefit from such a merge, and who is
> suffering from the current state of affairs?
>
> --
> AY
>
> On 4 June 2016 at 18:03:05, James Carman (ja...@carmanconsulting.com)
> wrote:
>
> "Sr. Software Engineer at DataStax", imagine that.
>
> On Sat, Jun 4, 2016 at 1:01 PM Aleksey Yeschenko 
> wrote:
>
> > As a member of that governing body (Cassandra PMC), I would much prefer
> > not to deal with the drivers as well.
> >
> > And I’m just as certain that java-driver - and other driver communities -
> > would much rather prefer to keep their process and organisation instead
> of
> > being forced to conform to ours.
> >
> > I’m finding it hard to see a single party that would benefit from such a
> > merge, and who suffers from the current state of things.
> >
> > --
> > AY
> >
> > On 4 June 2016 at 17:46:48, James Carman (ja...@carmanconsulting.com)
> > wrote:
> >
> > How does it add more complexity by having one governing body (the PMC)?
> > What I am suggesting is that the driver project be somewhat of a
> subproject
> > or a "module". It can still have its own life cycle, just like it does
> now.
> >
> > On Sat, Jun 4, 2016 at 12:44 PM Nate McCall 
> > wrote:
> >
> > > It doesnt. But then we add complexity in communicating and managing
> > > versions, releases, etc. to the project. Again, from my experience with
> > > hector, I just didnt want the hassle of owning that within the project
> > > confines.
> > >
> > > On Sat, Jun 4, 2016 at 11:30 AM, James Carman <
> > ja...@carmanconsulting.com>
> > > wrote:
> > >
> > > > Who said the driver has to be released with the database?
> > > >
> > > > On Sat, Jun 4, 2016 at 12:29 PM Nate McCall 
> > > > wrote:
> > > >
> > > > > On Sat, Jun 4, 2016 at 10:05 AM, James Carman <
> > > > ja...@carmanconsulting.com>
> > > > > wrote:
> > > > >
> > > > > > So why not just donate the Java driver and keep that in house?
> > > > Cassandra
> > > > > is
> > > > > > a Java project. Makes sense to me.
> > > > > >
> > > > > >
> > > > > I won't deny there is an argument to be made here, but as a former
> > > client
> > > > > maintainer (Hector), current ASF committer (Usergrid) and active
> > > > community
> > > > > member since late 2009, my opinion is that this would be a step
> > > > backwards.
> > > > >
> > > > > Maintaining Hector independently allowed me the freedom to release
> > > major
> > > > > features with technology that I wanted to use while maintaining
> > > backwards
> > > > > compatibility without having to be bound to the project's release
> > cycle
> > > > and
> > > > > process. (And to use a build system that didnt suck).
> > > > >
> > > > > The initial concern of the use of the word "controls" is *super*
> not
> > > cool
> > > > > and I hope that this is being fixed. That said, the reality, from
> my
> > > > > (external to DataStax) perspective, is that this is not the case. I
> > > like
> > > > > the current project separation the way it is and don't feel like
> > there
> > > is
> > > > > any attempt at "control" of the java driver's direction and
> > > development.
> > > > >
> > > > > -Nate
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > -
> > > Nate McCall
> > > Austin, TX
> > > @zznate
> > >
> > > CTO
> > > Apache Cassandra Consulting
> > > http://www.thelastpickle.com
> > >
> >
>

Re: Cassandra Java Driver and DataStax

2016-06-04 Thread James Carman 
On Sat, Jun 4, 2016 at 1:05 PM Nate McCall  wrote:

> Whereas the health of my company and title rely heavily on a thriving open
> source community, yet Aleksey and I are in agreement. Let's keep it up at
> the level of the project and technical merits, please.
>
>
Okay, that might have been a bit of a low-blow, and I apologize.  But,
we've seen this sort of thing happen around the organization.  We need to
make sure that things stay "fair" for everyone and that outside influences
don't unduly drive the project.

Re: Cassandra Java Driver and DataStax

2016-06-04 Thread Aleksey Yeschenko 
An eloquent and powerful response, but please, reply to my points instead of 
resorting to ad hominem arguments.

In practical terms, who would benefit from such a merge, and who is suffering 
from the current state of affairs?

-- 
AY

On 4 June 2016 at 18:03:05, James Carman (ja...@carmanconsulting.com) wrote:

"Sr. Software Engineer at DataStax", imagine that.  

On Sat, Jun 4, 2016 at 1:01 PM Aleksey Yeschenko  wrote:  

> As a member of that governing body (Cassandra PMC), I would much prefer  
> not to deal with the drivers as well.  
>  
> And I’m just as certain that java-driver - and other driver communities -  
> would much rather prefer to keep their process and organisation instead of  
> being forced to conform to ours.  
>  
> I’m finding it hard to see a single party that would benefit from such a  
> merge, and who suffers from the current state of things.  
>  
> --  
> AY  
>  
> On 4 June 2016 at 17:46:48, James Carman (ja...@carmanconsulting.com)  
> wrote:  
>  
> How does it add more complexity by having one governing body (the PMC)?  
> What I am suggesting is that the driver project be somewhat of a subproject  
> or a "module". It can still have its own life cycle, just like it does now.  
>  
> On Sat, Jun 4, 2016 at 12:44 PM Nate McCall   
> wrote:  
>  
> > It doesnt. But then we add complexity in communicating and managing  
> > versions, releases, etc. to the project. Again, from my experience with  
> > hector, I just didnt want the hassle of owning that within the project  
> > confines.  
> >  
> > On Sat, Jun 4, 2016 at 11:30 AM, James Carman <  
> ja...@carmanconsulting.com>  
> > wrote:  
> >  
> > > Who said the driver has to be released with the database?  
> > >  
> > > On Sat, Jun 4, 2016 at 12:29 PM Nate McCall   
> > > wrote:  
> > >  
> > > > On Sat, Jun 4, 2016 at 10:05 AM, James Carman <  
> > > ja...@carmanconsulting.com>  
> > > > wrote:  
> > > >  
> > > > > So why not just donate the Java driver and keep that in house?  
> > > Cassandra  
> > > > is  
> > > > > a Java project. Makes sense to me.  
> > > > >  
> > > > >  
> > > > I won't deny there is an argument to be made here, but as a former  
> > client  
> > > > maintainer (Hector), current ASF committer (Usergrid) and active  
> > > community  
> > > > member since late 2009, my opinion is that this would be a step  
> > > backwards.  
> > > >  
> > > > Maintaining Hector independently allowed me the freedom to release  
> > major  
> > > > features with technology that I wanted to use while maintaining  
> > backwards  
> > > > compatibility without having to be bound to the project's release  
> cycle  
> > > and  
> > > > process. (And to use a build system that didnt suck).  
> > > >  
> > > > The initial concern of the use of the word "controls" is *super* not  
> > cool  
> > > > and I hope that this is being fixed. That said, the reality, from my  
> > > > (external to DataStax) perspective, is that this is not the case. I  
> > like  
> > > > the current project separation the way it is and don't feel like  
> there  
> > is  
> > > > any attempt at "control" of the java driver's direction and  
> > development.  
> > > >  
> > > > -Nate  
> > > >  
> > >  
> >  
> >  
> >  
> > --  
> > -  
> > Nate McCall  
> > Austin, TX  
> > @zznate  
> >  
> > CTO  
> > Apache Cassandra Consulting  
> > http://www.thelastpickle.com  
> >  
>

Re: Cassandra Java Driver and DataStax

2016-06-04 Thread Nate McCall 
Whereas the health of my company and title rely heavily on a thriving open
source community, yet Aleksey and I are in agreement. Let's keep it up at
the level of the project and technical merits, please.

On Sat, Jun 4, 2016 at 12:02 PM, James Carman 
wrote:

> "Sr. Software Engineer at DataStax", imagine that.
>
> On Sat, Jun 4, 2016 at 1:01 PM Aleksey Yeschenko 
> wrote:
>
> > As a member of that governing body (Cassandra PMC), I would much prefer
> > not to deal with the drivers as well.
> >
> > And I’m just as certain that java-driver - and other driver communities -
> > would much rather prefer to keep their process and organisation instead
> of
> > being forced to conform to ours.
> >
> > I’m finding it hard to see a single party that would benefit from such a
> > merge, and who suffers from the current state of things.
> >
> > --
> > AY
> >
> > On 4 June 2016 at 17:46:48, James Carman (ja...@carmanconsulting.com)
> > wrote:
> >
> > How does it add more complexity by having one governing body (the PMC)?
> > What I am suggesting is that the driver project be somewhat of a
> subproject
> > or a "module". It can still have its own life cycle, just like it does
> now.
> >
> > On Sat, Jun 4, 2016 at 12:44 PM Nate McCall 
> > wrote:
> >
> > > It doesnt. But then we add complexity in communicating and managing
> > > versions, releases, etc. to the project. Again, from my experience with
> > > hector, I just didnt want the hassle of owning that within the project
> > > confines.
> > >
> > > On Sat, Jun 4, 2016 at 11:30 AM, James Carman <
> > ja...@carmanconsulting.com>
> > > wrote:
> > >
> > > > Who said the driver has to be released with the database?
> > > >
> > > > On Sat, Jun 4, 2016 at 12:29 PM Nate McCall 
> > > > wrote:
> > > >
> > > > > On Sat, Jun 4, 2016 at 10:05 AM, James Carman <
> > > > ja...@carmanconsulting.com>
> > > > > wrote:
> > > > >
> > > > > > So why not just donate the Java driver and keep that in house?
> > > > Cassandra
> > > > > is
> > > > > > a Java project. Makes sense to me.
> > > > > >
> > > > > >
> > > > > I won't deny there is an argument to be made here, but as a former
> > > client
> > > > > maintainer (Hector), current ASF committer (Usergrid) and active
> > > > community
> > > > > member since late 2009, my opinion is that this would be a step
> > > > backwards.
> > > > >
> > > > > Maintaining Hector independently allowed me the freedom to release
> > > major
> > > > > features with technology that I wanted to use while maintaining
> > > backwards
> > > > > compatibility without having to be bound to the project's release
> > cycle
> > > > and
> > > > > process. (And to use a build system that didnt suck).
> > > > >
> > > > > The initial concern of the use of the word "controls" is *super*
> not
> > > cool
> > > > > and I hope that this is being fixed. That said, the reality, from
> my
> > > > > (external to DataStax) perspective, is that this is not the case. I
> > > like
> > > > > the current project separation the way it is and don't feel like
> > there
> > > is
> > > > > any attempt at "control" of the java driver's direction and
> > > development.
> > > > >
> > > > > -Nate
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > -
> > > Nate McCall
> > > Austin, TX
> > > @zznate
> > >
> > > CTO
> > > Apache Cassandra Consulting
> > > http://www.thelastpickle.com
> > >
> >
>



-- 
-
Nate McCall
Austin, TX
@zznate

CTO
Apache Cassandra Consulting
http://www.thelastpickle.com

Re: Cassandra Java Driver and DataStax

2016-06-04 Thread James Carman 
On Sat, Jun 4, 2016 at 1:02 PM Nate McCall  wrote:

> For me, most of the complexity would have been dealing with the governing
> body :)
>
> Seriously though, being independant allowed me to experiment with things
> like going directly to the internal Storage API from the client which would
> have definitely been -1'ed by some committers (rightly so as it would have
> provided a level of endorsement of this type of client access, making
> refactoring more difficult).
>
>
Right, you wanted "control" of you project.  I get it.

Re: Cassandra Java Driver and DataStax

2016-06-04 Thread James Carman 
"Sr. Software Engineer at DataStax", imagine that.

On Sat, Jun 4, 2016 at 1:01 PM Aleksey Yeschenko  wrote:

> As a member of that governing body (Cassandra PMC), I would much prefer
> not to deal with the drivers as well.
>
> And I’m just as certain that java-driver - and other driver communities -
> would much rather prefer to keep their process and organisation instead of
> being forced to conform to ours.
>
> I’m finding it hard to see a single party that would benefit from such a
> merge, and who suffers from the current state of things.
>
> --
> AY
>
> On 4 June 2016 at 17:46:48, James Carman (ja...@carmanconsulting.com)
> wrote:
>
> How does it add more complexity by having one governing body (the PMC)?
> What I am suggesting is that the driver project be somewhat of a subproject
> or a "module". It can still have its own life cycle, just like it does now.
>
> On Sat, Jun 4, 2016 at 12:44 PM Nate McCall 
> wrote:
>
> > It doesnt. But then we add complexity in communicating and managing
> > versions, releases, etc. to the project. Again, from my experience with
> > hector, I just didnt want the hassle of owning that within the project
> > confines.
> >
> > On Sat, Jun 4, 2016 at 11:30 AM, James Carman <
> ja...@carmanconsulting.com>
> > wrote:
> >
> > > Who said the driver has to be released with the database?
> > >
> > > On Sat, Jun 4, 2016 at 12:29 PM Nate McCall 
> > > wrote:
> > >
> > > > On Sat, Jun 4, 2016 at 10:05 AM, James Carman <
> > > ja...@carmanconsulting.com>
> > > > wrote:
> > > >
> > > > > So why not just donate the Java driver and keep that in house?
> > > Cassandra
> > > > is
> > > > > a Java project. Makes sense to me.
> > > > >
> > > > >
> > > > I won't deny there is an argument to be made here, but as a former
> > client
> > > > maintainer (Hector), current ASF committer (Usergrid) and active
> > > community
> > > > member since late 2009, my opinion is that this would be a step
> > > backwards.
> > > >
> > > > Maintaining Hector independently allowed me the freedom to release
> > major
> > > > features with technology that I wanted to use while maintaining
> > backwards
> > > > compatibility without having to be bound to the project's release
> cycle
> > > and
> > > > process. (And to use a build system that didnt suck).
> > > >
> > > > The initial concern of the use of the word "controls" is *super* not
> > cool
> > > > and I hope that this is being fixed. That said, the reality, from my
> > > > (external to DataStax) perspective, is that this is not the case. I
> > like
> > > > the current project separation the way it is and don't feel like
> there
> > is
> > > > any attempt at "control" of the java driver's direction and
> > development.
> > > >
> > > > -Nate
> > > >
> > >
> >
> >
> >
> > --
> > -
> > Nate McCall
> > Austin, TX
> > @zznate
> >
> > CTO
> > Apache Cassandra Consulting
> > http://www.thelastpickle.com
> >
>

Re: Cassandra Java Driver and DataStax

2016-06-04 Thread Nate McCall 
For me, most of the complexity would have been dealing with the governing
body :)

Seriously though, being independant allowed me to experiment with things
like going directly to the internal Storage API from the client which would
have definitely been -1'ed by some committers (rightly so as it would have
provided a level of endorsement of this type of client access, making
refactoring more difficult).

On Sat, Jun 4, 2016 at 11:46 AM, James Carman 
wrote:

> How does it add more complexity by having one governing body (the PMC)?
> What I am suggesting is that the driver project be somewhat of a subproject
> or a "module". It can still have its own life cycle, just like it does now.
>
> On Sat, Jun 4, 2016 at 12:44 PM Nate McCall 
> wrote:
>
> > It doesnt. But then we add complexity in communicating and managing
> > versions, releases, etc. to the project. Again, from my experience with
> > hector, I just didnt want the hassle of owning that within the project
> > confines.
> >
> > On Sat, Jun 4, 2016 at 11:30 AM, James Carman <
> ja...@carmanconsulting.com>
> > wrote:
> >
> > > Who said the driver has to be released with the database?
> > >
> > > On Sat, Jun 4, 2016 at 12:29 PM Nate McCall 
> > > wrote:
> > >
> > > > On Sat, Jun 4, 2016 at 10:05 AM, James Carman <
> > > ja...@carmanconsulting.com>
> > > > wrote:
> > > >
> > > > > So why not just donate the Java driver and keep that in house?
> > > Cassandra
> > > > is
> > > > > a Java project. Makes sense to me.
> > > > >
> > > > >
> > > > I won't deny there is an argument to be made here, but as a former
> > client
> > > > maintainer (Hector), current ASF committer (Usergrid) and active
> > > community
> > > > member since late 2009, my opinion is that this would be a step
> > > backwards.
> > > >
> > > > Maintaining Hector independently allowed me the freedom to release
> > major
> > > > features with technology that I wanted to use while maintaining
> > backwards
> > > > compatibility without having to be bound to the project's release
> cycle
> > > and
> > > > process. (And to use a build system that didnt suck).
> > > >
> > > > The initial concern of the use of the word "controls" is *super* not
> > cool
> > > > and I hope that this is being fixed. That said, the reality, from my
> > > > (external to DataStax) perspective, is that this is not the case. I
> > like
> > > > the current project separation the way it is and don't feel like
> there
> > is
> > > > any attempt at "control" of the java driver's direction and
> > development.
> > > >
> > > > -Nate
> > > >
> > >
> >
> >
> >
> > --
> > -
> > Nate McCall
> > Austin, TX
> > @zznate
> >
> > CTO
> > Apache Cassandra Consulting
> > http://www.thelastpickle.com
> >
>



-- 
-
Nate McCall
Austin, TX
@zznate

CTO
Apache Cassandra Consulting
http://www.thelastpickle.com

Re: Cassandra Java Driver and DataStax

2016-06-04 Thread Aleksey Yeschenko 
As a member of that governing body (Cassandra PMC), I would much prefer not to 
deal with the drivers as well.

And I’m just as certain that java-driver - and other driver communities - would 
much rather prefer to keep their process and organisation instead of being 
forced to conform to ours.

I’m finding it hard to see a single party that would benefit from such a merge, 
and who suffers from the current state of things.

-- 
AY

On 4 June 2016 at 17:46:48, James Carman (ja...@carmanconsulting.com) wrote:

How does it add more complexity by having one governing body (the PMC)?  
What I am suggesting is that the driver project be somewhat of a subproject  
or a "module". It can still have its own life cycle, just like it does now.  

On Sat, Jun 4, 2016 at 12:44 PM Nate McCall  wrote:  

> It doesnt. But then we add complexity in communicating and managing  
> versions, releases, etc. to the project. Again, from my experience with  
> hector, I just didnt want the hassle of owning that within the project  
> confines.  
>  
> On Sat, Jun 4, 2016 at 11:30 AM, James Carman   
> wrote:  
>  
> > Who said the driver has to be released with the database?  
> >  
> > On Sat, Jun 4, 2016 at 12:29 PM Nate McCall   
> > wrote:  
> >  
> > > On Sat, Jun 4, 2016 at 10:05 AM, James Carman <  
> > ja...@carmanconsulting.com>  
> > > wrote:  
> > >  
> > > > So why not just donate the Java driver and keep that in house?  
> > Cassandra  
> > > is  
> > > > a Java project. Makes sense to me.  
> > > >  
> > > >  
> > > I won't deny there is an argument to be made here, but as a former  
> client  
> > > maintainer (Hector), current ASF committer (Usergrid) and active  
> > community  
> > > member since late 2009, my opinion is that this would be a step  
> > backwards.  
> > >  
> > > Maintaining Hector independently allowed me the freedom to release  
> major  
> > > features with technology that I wanted to use while maintaining  
> backwards  
> > > compatibility without having to be bound to the project's release cycle  
> > and  
> > > process. (And to use a build system that didnt suck).  
> > >  
> > > The initial concern of the use of the word "controls" is *super* not  
> cool  
> > > and I hope that this is being fixed. That said, the reality, from my  
> > > (external to DataStax) perspective, is that this is not the case. I  
> like  
> > > the current project separation the way it is and don't feel like there  
> is  
> > > any attempt at "control" of the java driver's direction and  
> development.  
> > >  
> > > -Nate  
> > >  
> >  
>  
>  
>  
> --  
> -  
> Nate McCall  
> Austin, TX  
> @zznate  
>  
> CTO  
> Apache Cassandra Consulting  
> http://www.thelastpickle.com  
>

Re: Cassandra Java Driver and DataStax

2016-06-04 Thread James Carman 
How does it add more complexity by having one governing body (the PMC)?
What I am suggesting is that the driver project be somewhat of a subproject
or a "module". It can still have its own life cycle, just like it does now.

On Sat, Jun 4, 2016 at 12:44 PM Nate McCall  wrote:

> It doesnt. But then we add complexity in communicating and managing
> versions, releases, etc. to the project. Again, from my experience with
> hector, I just didnt want the hassle of owning that within the project
> confines.
>
> On Sat, Jun 4, 2016 at 11:30 AM, James Carman 
> wrote:
>
> > Who said the driver has to be released with the database?
> >
> > On Sat, Jun 4, 2016 at 12:29 PM Nate McCall 
> > wrote:
> >
> > > On Sat, Jun 4, 2016 at 10:05 AM, James Carman <
> > ja...@carmanconsulting.com>
> > > wrote:
> > >
> > > > So why not just donate the Java driver and keep that in house?
> > Cassandra
> > > is
> > > > a Java project. Makes sense to me.
> > > >
> > > >
> > > I won't deny there is an argument to be made here, but as a former
> client
> > > maintainer (Hector), current ASF committer (Usergrid) and active
> > community
> > > member since late 2009, my opinion is that this would be a step
> > backwards.
> > >
> > > Maintaining Hector independently allowed me the freedom to release
> major
> > > features with technology that I wanted to use while maintaining
> backwards
> > > compatibility without having to be bound to the project's release cycle
> > and
> > > process. (And to use a build system that didnt suck).
> > >
> > > The initial concern of the use of the word "controls" is *super* not
> cool
> > > and I hope that this is being fixed. That said, the reality, from my
> > > (external to DataStax) perspective, is that this is not the case. I
> like
> > > the current project separation the way it is and don't feel like there
> is
> > > any attempt at "control" of the java driver's direction and
> development.
> > >
> > > -Nate
> > >
> >
>
>
>
> --
> -
> Nate McCall
> Austin, TX
> @zznate
>
> CTO
> Apache Cassandra Consulting
> http://www.thelastpickle.com
>

Re: Cassandra Java Driver and DataStax

2016-06-04 Thread Nate McCall 
It doesnt. But then we add complexity in communicating and managing
versions, releases, etc. to the project. Again, from my experience with
hector, I just didnt want the hassle of owning that within the project
confines.

On Sat, Jun 4, 2016 at 11:30 AM, James Carman 
wrote:

> Who said the driver has to be released with the database?
>
> On Sat, Jun 4, 2016 at 12:29 PM Nate McCall 
> wrote:
>
> > On Sat, Jun 4, 2016 at 10:05 AM, James Carman <
> ja...@carmanconsulting.com>
> > wrote:
> >
> > > So why not just donate the Java driver and keep that in house?
> Cassandra
> > is
> > > a Java project. Makes sense to me.
> > >
> > >
> > I won't deny there is an argument to be made here, but as a former client
> > maintainer (Hector), current ASF committer (Usergrid) and active
> community
> > member since late 2009, my opinion is that this would be a step
> backwards.
> >
> > Maintaining Hector independently allowed me the freedom to release major
> > features with technology that I wanted to use while maintaining backwards
> > compatibility without having to be bound to the project's release cycle
> and
> > process. (And to use a build system that didnt suck).
> >
> > The initial concern of the use of the word "controls" is *super* not cool
> > and I hope that this is being fixed. That said, the reality, from my
> > (external to DataStax) perspective, is that this is not the case. I like
> > the current project separation the way it is and don't feel like there is
> > any attempt at "control" of the java driver's direction and development.
> >
> > -Nate
> >
>



-- 
-
Nate McCall
Austin, TX
@zznate

CTO
Apache Cassandra Consulting
http://www.thelastpickle.com

Re: Cassandra Java Driver and DataStax

2016-06-04 Thread James Carman 
Who said the driver has to be released with the database?

On Sat, Jun 4, 2016 at 12:29 PM Nate McCall  wrote:

> On Sat, Jun 4, 2016 at 10:05 AM, James Carman 
> wrote:
>
> > So why not just donate the Java driver and keep that in house? Cassandra
> is
> > a Java project. Makes sense to me.
> >
> >
> I won't deny there is an argument to be made here, but as a former client
> maintainer (Hector), current ASF committer (Usergrid) and active community
> member since late 2009, my opinion is that this would be a step backwards.
>
> Maintaining Hector independently allowed me the freedom to release major
> features with technology that I wanted to use while maintaining backwards
> compatibility without having to be bound to the project's release cycle and
> process. (And to use a build system that didnt suck).
>
> The initial concern of the use of the word "controls" is *super* not cool
> and I hope that this is being fixed. That said, the reality, from my
> (external to DataStax) perspective, is that this is not the case. I like
> the current project separation the way it is and don't feel like there is
> any attempt at "control" of the java driver's direction and development.
>
> -Nate
>

Re: Cassandra Java Driver and DataStax

2016-06-04 Thread Nate McCall 
On Sat, Jun 4, 2016 at 10:05 AM, James Carman 
wrote:

> So why not just donate the Java driver and keep that in house? Cassandra is
> a Java project. Makes sense to me.
>
>
I won't deny there is an argument to be made here, but as a former client
maintainer (Hector), current ASF committer (Usergrid) and active community
member since late 2009, my opinion is that this would be a step backwards.

Maintaining Hector independently allowed me the freedom to release major
features with technology that I wanted to use while maintaining backwards
compatibility without having to be bound to the project's release cycle and
process. (And to use a build system that didnt suck).

The initial concern of the use of the word "controls" is *super* not cool
and I hope that this is being fixed. That said, the reality, from my
(external to DataStax) perspective, is that this is not the case. I like
the current project separation the way it is and don't feel like there is
any attempt at "control" of the java driver's direction and development.

-Nate

Re: Cassandra Java Driver and DataStax

2016-06-04 Thread James Carman 
So why not just donate the Java driver and keep that in house? Cassandra is
a Java project. Makes sense to me.

On Sat, Jun 4, 2016 at 10:58 AM Jonathan Ellis  wrote:

> On Sat, Jun 4, 2016 at 8:59 AM, Chris Mattmann 
> 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
> 
> - 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
>

Re: Cassandra Java Driver and DataStax

2016-06-04 Thread Jonathan Ellis 
On Sat, Jun 4, 2016 at 8:59 AM, Chris Mattmann  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

- 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

Re: Cassandra Java Driver and DataStax

2016-06-04 Thread Chris Mattmann 
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? 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.
You inevitably as a community will run into that situation and
in those cases it’s time to make the new people PMC members and
committers especially if you didn’t have the expertise in the
code they are contributing to start with.

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.

Thoughts?

Cheers,
Chris




On 6/4/16, 5:38 AM, "Jonathan Ellis"  wrote:

>FWIW, in very very ancient history we actually had the drivers in tree.  It
>sucked, because the people who wanted to contribute to the drivers were for
>the most part not Committers, and the committers for the most part weren't
>interested in reviewing drivers patches, and you have different,
>non-overlapping sets of contributors for each driver.  (A C++ driver author
>generally isn't very interested in clojure and vice versa.)
>
>Two things really convinced us they didn't belong in tree, even if we
>wanted to live with the above drawbacks:
>
>- If it's in tree, then the Apache committers are viewed as responsible for
>maintaining it.  Never mind if the Perl driver was (hypothetically)
>contributed by some guy who disappeared after a month and none of the
>committers know Perl, we have by committing it implicitly promised to fix
>bugs and keep it up to date with new features.
>- The obvious solution to this problem is to just not commit any driver
>that we don't have enough expertise to maintain ourselves or are not
>sufficiently confident in the author's commitment.  But then you have a
>very clear distinction between "first class," in tree drivers (probably
>just Java, maybe Python too) and everyone else, which didn't sit right with
>us either.
>
>On Fri, Jun 3, 2016 at 10:47 PM, J. D. Jordan 
>wrote:
>
>> This is the way our community has operated for at least the 6ish years I
>> have been involved with it. The Apache project develops the database,
>> others in the community develop drivers. It's the way we have always
>> worked, I'm sorry if you don't like that.
>>
>
>-- 
>Jonathan Ellis
>Project Chair, Apache Cassandra
>co-founder, http://www.datastax.com
>@spyced

Re: Cassandra Java Driver and DataStax

2016-06-04 Thread Jonathan Ellis 
FWIW, in very very ancient history we actually had the drivers in tree.  It
sucked, because the people who wanted to contribute to the drivers were for
the most part not Committers, and the committers for the most part weren't
interested in reviewing drivers patches, and you have different,
non-overlapping sets of contributors for each driver.  (A C++ driver author
generally isn't very interested in clojure and vice versa.)

Two things really convinced us they didn't belong in tree, even if we
wanted to live with the above drawbacks:

- If it's in tree, then the Apache committers are viewed as responsible for
maintaining it.  Never mind if the Perl driver was (hypothetically)
contributed by some guy who disappeared after a month and none of the
committers know Perl, we have by committing it implicitly promised to fix
bugs and keep it up to date with new features.
- The obvious solution to this problem is to just not commit any driver
that we don't have enough expertise to maintain ourselves or are not
sufficiently confident in the author's commitment.  But then you have a
very clear distinction between "first class," in tree drivers (probably
just Java, maybe Python too) and everyone else, which didn't sit right with
us either.

On Fri, Jun 3, 2016 at 10:47 PM, J. D. Jordan 
wrote:

> This is the way our community has operated for at least the 6ish years I
> have been involved with it. The Apache project develops the database,
> others in the community develop drivers. It's the way we have always
> worked, I'm sorry if you don't like that.
>

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