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 <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 <alek...@apache.org> 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 <alek...@apache.org> >> 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 <n...@thelastpickle.com> >>> 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 <n...@thelastpickle.com> >>>>> 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 >>>> >>> >>
