Re: [VOTE] Development Approach for Apache Cassandra Management process

2018-09-12 Thread Rahul Singh
A. +1.
Bias for action. Use something that works. Iterate.

Rahul Singh
Chief Executive Officer
m 202.905.2818

Anant Corporation
1010 Wisconsin Ave NW, Suite 250
Washington, D.C. 20007

We build and manage digital business technology platforms.
On Sep 12, 2018, 8:23 PM -0400, Jeff Beck , wrote:
> a. +1 to use some existing project.
>
> But I see no reason not to keep discussion going.
>
> Jeff
>
>
> On Thu, Sep 13, 2018, 7:37 AM Sankalp Kohli  wrote:
>
> > The link to the document is available in the other thread. Comparisons are
> > available in other thread as well.
> >
> > > On Sep 12, 2018, at 16:29, Mick Semb Wever  wrote:
> > >
> > >
> > > > I am hoping all the folks who are saying we should not vote will drive
> > the
> > > > other thread. Also note that there is consensus about doing a side car
> > but
> > > > no consensus on which approach to take. I hope not deciding which
> > approach
> > > > is not a poison pill for side car!!
> > >
> > >
> > > Call me pedantic, but I saw the consensus as favouring a side-car over
> > something in tree. That's not a consensus on doing a side-car, as that was
> > not an option on offer.
> > >
> > > There's certainly interest in a side-car that warrants documenting
> > further on comparisons and investigations, IMHO.
> > >
> > > -
> > > 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: Proposing an Apache Cassandra Management process

2018-09-12 Thread Blake Eggleston
Reading through the history Sankalp posted (I think it was originally posted by 
Joey?), I think part of the problem we’re having here is that we’re trying to 
solve at least 3 problems with a single solution. Also, I don’t think everyone 
has the same goals in mind. The issues we’re trying to solve are:


Repair scheduling - original proposal was for an in-process distributed 
scheduler to make cassandra eventually consistent without relying on external 
tools.

Sidecar - proposed as a helper co-process to make stuff like cluster wide 
nodetool command execution, health check, etc easier. I don’t think the 
original proposal mentioned repair.

Ops center like management application with a ui seems to have made it’s way 
into the mix at some point

These are all intended to make cassandra easier to operate, but they’re really 
separate features. It would be more productive to focus on each one as it’s own 
feature instead of trying to design a one size fits all and does everything 
management tool.

On September 12, 2018 at 6:25:11 PM, sankalp kohli (kohlisank...@gmail.com) 
wrote:

Here is a list of open discussion points from the voting thread. I think  
some are already answered but I will still gather these questions here.  

From several people:  
1. Vote is rushed and we need more time for discussion.  

From Sylvain  
2. About the voting process...I think that was addressed by Jeff Jirsa and  
deserves a separate thread as it is not directly related to this thread.  
3. Does the project need a side car.  

From Jonathan Haddad  
4. Are people doing +1 willing to contribute  

From Jonathan Ellis  
5. List of feature set, maturity, maintainer availability from Reaper or  
any other project being donated.  

Mick Semb Wever  
6. We should not vote on these things and instead build consensus.  

Open Questions from this thread  
7. What technical debts we are talking about in Reaper. Can someone give  
concrete examples.  
8. What is the timeline of donating Reaper to Apache Cassandra.  

On Wed, Sep 12, 2018 at 3:49 PM sankalp kohli   
wrote:  

> (Using this thread and not the vote thread intentionally)  
> For folks talking about vote being rushed. I would use the email from  
> Joseph to show this is not rushed. There was no email on this thread for 4  
> months until I pinged.  
>  
>  
> Dec 2016: Vinay worked with Jon and Alex to try to collaborate on Reaper to  
> come up with design goals for a repair scheduler that could work at Netflix  
> scale.  
>  
> ~Feb 2017: Netflix believes that the fundamental design gaps prevented us  
> from using Reaper as it relies heavily on remote JMX connections and  
> central coordination.  
>  
> Sep. 2017: Vinay gives a lightning talk at NGCC about a highly available  
> and distributed repair scheduling sidecar/tool. He is encouraged by  
> multiple committers to build repair scheduling into the daemon itself and  
> not as a sidecar so the database is truly eventually consistent.  
>  
> ~Jun. 2017 - Feb. 2018: Based on internal need and the positive feedback at  
> NGCC, Vinay and myself prototype the distributed repair scheduler within  
> Priam and roll it out at Netflix scale.  
>  
> Mar. 2018: I open a Jira (CASSANDRA-14346) along with a detailed 20 page  
> design document for adding repair scheduling to the daemon itself and open  
> the design up for feedback from the community. We get feedback from Alex,  
> Blake, Nate, Stefan, and Mick. As far as I know there were zero proposals  
> to contribute Reaper at this point. We hear the consensus that the  
> community would prefer repair scheduling in a separate distributed sidecar  
> rather than in the daemon itself and we re-work the design to match this  
> consensus, re-aligning with our original proposal at NGCC.  
>  
> Apr 2018: Blake brings the discussion of repair scheduling to the dev list  
> (  
>  
> https://lists.apache.org/thread.html/760fbef677f27aa5c2ab4c375c7efeb81304fea428deff986ba1c2eb@%3Cdev.cassandra.apache.org%3E
>   
> ).  
> Many community members give positive feedback that we should solve it as  
> part of Cassandra and there is still no mention of contributing Reaper at  
> this point. The last message is my attempted summary giving context on how  
> we want to take the best of all the sidecars (OpsCenter, Priam, Reaper) and  
> ship them with Cassandra.  
>  
> Apr. 2018: Dinesh opens CASSANDRA-14395 along with a public design document  
> for gathering feedback on a general management sidecar. Sankalp and Dinesh  
> encourage Vinay and myself to kickstart that sidecar using the repair  
> scheduler patch  
>  
> Apr 2018: Dinesh reaches out to the dev list (  
>  
> https://lists.apache.org/thread.html/a098341efd8f344494bcd2761dba5125e971b59b1dd54f282ffda253@%3Cdev.cassandra.apache.org%3E
>   
> )  
> about the general management process to gain further feedback. All feedback  
> remains positive as it is a potential place for multiple community members  
> to contr

Re: Proposing an Apache Cassandra Management process

2018-09-12 Thread sankalp kohli
Here is a list of open discussion points from the voting thread. I think
some are already answered but I will still gather these questions here.

>From several people:
1. Vote is rushed and we need more time for discussion.

>From Sylvain
2. About the voting process...I think that was addressed by Jeff Jirsa and
deserves a separate thread as it is not directly related to this thread.
3. Does the project need a side car.

>From Jonathan Haddad
4. Are people doing +1 willing to contribute

>From Jonathan Ellis
5. List of feature set, maturity, maintainer availability from Reaper or
any other project being donated.

Mick Semb Wever
6. We should not vote on these things and instead build consensus.

Open Questions from this thread
7. What technical debts we are talking about in Reaper. Can someone give
concrete examples.
8. What is the timeline of donating Reaper to Apache Cassandra.

On Wed, Sep 12, 2018 at 3:49 PM sankalp kohli 
wrote:

> (Using this thread and not the vote thread intentionally)
> For folks talking about vote being rushed. I would use the email from
> Joseph to show this is not rushed. There was no email on this thread for 4
> months until I pinged.
>
>
> Dec 2016: Vinay worked with Jon and Alex to try to collaborate on Reaper to
> come up with design goals for a repair scheduler that could work at Netflix
> scale.
>
> ~Feb 2017: Netflix believes that the fundamental design gaps prevented us
> from using Reaper as it relies heavily on remote JMX connections and
> central coordination.
>
> Sep. 2017: Vinay gives a lightning talk at NGCC about a highly available
> and distributed repair scheduling sidecar/tool. He is encouraged by
> multiple committers to build repair scheduling into the daemon itself and
> not as a sidecar so the database is truly eventually consistent.
>
> ~Jun. 2017 - Feb. 2018: Based on internal need and the positive feedback at
> NGCC, Vinay and myself prototype the distributed repair scheduler within
> Priam and roll it out at Netflix scale.
>
> Mar. 2018: I open a Jira (CASSANDRA-14346) along with a detailed 20 page
> design document for adding repair scheduling to the daemon itself and open
> the design up for feedback from the community. We get feedback from Alex,
> Blake, Nate, Stefan, and Mick. As far as I know there were zero proposals
> to contribute Reaper at this point. We hear the consensus that the
> community would prefer repair scheduling in a separate distributed sidecar
> rather than in the daemon itself and we re-work the design to match this
> consensus, re-aligning with our original proposal at NGCC.
>
> Apr 2018: Blake brings the discussion of repair scheduling to the dev list
> (
>
> https://lists.apache.org/thread.html/760fbef677f27aa5c2ab4c375c7efeb81304fea428deff986ba1c2eb@%3Cdev.cassandra.apache.org%3E
> ).
> Many community members give positive feedback that we should solve it as
> part of Cassandra and there is still no mention of contributing Reaper at
> this point. The last message is my attempted summary giving context on how
> we want to take the best of all the sidecars (OpsCenter, Priam, Reaper) and
> ship them with Cassandra.
>
> Apr. 2018: Dinesh opens CASSANDRA-14395 along with a public design document
> for gathering feedback on a general management sidecar. Sankalp and Dinesh
> encourage Vinay and myself to kickstart that sidecar using the repair
> scheduler patch
>
> Apr 2018: Dinesh reaches out to the dev list (
>
> https://lists.apache.org/thread.html/a098341efd8f344494bcd2761dba5125e971b59b1dd54f282ffda253@%3Cdev.cassandra.apache.org%3E
> )
> about the general management process to gain further feedback. All feedback
> remains positive as it is a potential place for multiple community members
> to contribute their various sidecar functionality.
>
> May-Jul 2017: Vinay and I work on creating a basic sidecar for running the
> repair scheduler based on the feedback from the community in
> CASSANDRA-14346 and CASSANDRA-14395
>
> Jun 2018: I bump CASSANDRA-14346 indicating we're still working on this,
> nobody objects
>
> Jul 2018: Sankalp asks on the dev list if anyone has feature Jiras anyone
> needs review for before 4.0, I mention again that we've nearly got the
> basic sidecar and repair scheduling work done and will need help with
> review. No one responds.
>
> Aug 2018: We submit a patch that brings a basic distributed sidecar and
> robust distributed repair to Cassandra itself. Dinesh mentions that he will
> try to review. Now folks appear concerned about it being in tree and
> instead maybe it should go in a different repo all together. I don't think
> we have consensus on the repo choice yet.
>
> On Sun, Sep 9, 2018 at 9:13 AM sankalp kohli 
> wrote:
>
>> I agree with Jon and I think folks who are talking about tech debts in
>> Reaper should elaborate with examples about these tech debts. Can we be
>> more precise and list them down? I see it spread out over this long email
>> thread!!
>>
>> On Sun, Sep 9, 2018 at 6:29 AM Ell

Re: [VOTE] Development Approach for Apache Cassandra Management process

2018-09-12 Thread Jeff Beck
a. +1 to use some existing project.

But I see no reason not to keep discussion going.

Jeff


On Thu, Sep 13, 2018, 7:37 AM Sankalp Kohli  wrote:

> The link to the document is available in the other thread. Comparisons are
> available in other thread as well.
>
> > On Sep 12, 2018, at 16:29, Mick Semb Wever  wrote:
> >
> >
> >> I am hoping all the folks who are saying we should not vote will drive
> the
> >> other thread.  Also note that there is consensus about doing a side car
> but
> >> no consensus on which approach to take. I hope not deciding which
> approach
> >> is not a poison pill for side car!!
> >
> >
> > Call me pedantic, but I saw the consensus as favouring a side-car over
> something in tree. That's not a consensus on doing a side-car, as that was
> not an option on offer.
> >
> > There's certainly interest in a side-car that warrants documenting
> further on comparisons and investigations, IMHO.
> >
> > -
> > 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: QA signup

2018-09-12 Thread Joseph Lynch
> In looking at the Confluence space restrictions, it appears the main page is 
> open for editing and I don't see restrictions on page creation; can you try 
> to sign in, create one, and let me know if that doesn't work?

I signed in and went to "Jira reports" and then tried to hit "Add Jira
Report" and it said "Sorry you don't have permission to create
content. Contact your space administrator to request access". Also if
I just go to the Cassandra space there is no "Create" button in the in
the top left where it normally is, all I see when logged on in the
Cassandra space is "Spaces" and "People".

> I'm planning to create a few more pages for a couple testing tracks in a few 
> days, some of which are described here [1]. Eager to collaborate on these as 
> well.

Please let me know if you create one for internode messaging, we have
(I think valuable) data/methods from last Wednesday we can share. I've
started leaving the results we have so far as well as the methodology
we used at https://issues.apache.org/jira/browse/CASSANDRA-14746 with
the label "4.0-QA" but I can copy and paste anywhere we decide to put
these things.

-Joey

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



Re: [VOTE] Development Approach for Apache Cassandra Management process

2018-09-12 Thread Sankalp Kohli
The link to the document is available in the other thread. Comparisons are 
available in other thread as well. 

> On Sep 12, 2018, at 16:29, Mick Semb Wever  wrote:
> 
> 
>> I am hoping all the folks who are saying we should not vote will drive the
>> other thread.  Also note that there is consensus about doing a side car but
>> no consensus on which approach to take. I hope not deciding which approach
>> is not a poison pill for side car!!
> 
> 
> Call me pedantic, but I saw the consensus as favouring a side-car over 
> something in tree. That's not a consensus on doing a side-car, as that was 
> not an option on offer.
> 
> There's certainly interest in a side-car that warrants documenting further on 
> comparisons and investigations, IMHO.
> 
> -
> 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] Development Approach for Apache Cassandra Management process

2018-09-12 Thread Mick Semb Wever


> I am hoping all the folks who are saying we should not vote will drive the
> other thread.  Also note that there is consensus about doing a side car but
> no consensus on which approach to take. I hope not deciding which approach
> is not a poison pill for side car!!


Call me pedantic, but I saw the consensus as favouring a side-car over 
something in tree. That's not a consensus on doing a side-car, as that was not 
an option on offer.

There's certainly interest in a side-car that warrants documenting further on 
comparisons and investigations, IMHO.

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



Re: [VOTE] Development Approach for Apache Cassandra Management process

2018-09-12 Thread sankalp kohli
I am hoping all the folks who are saying we should not vote will drive the
other thread.  Also note that there is consensus about doing a side car but
no consensus on which approach to take. I hope not deciding which approach
is not a poison pill for side car!!



On Wed, Sep 12, 2018 at 4:11 PM Mick Semb Wever  wrote:

>
> > But I'd like to see a serious investigation of the options -- feature
> set,
> > maturity, maintainer availability, etc -- before making a decision.  This
> > will take some time, but this is a place where "measure twice, cut once"
> > seems like the right approach.
>
>
> This^ 100%.
>
> I dislike the idea of a vote altogether:
> https://www.apache.org/foundation/voting.html#reasons-for-votes
>
> Discussion should resolve things, accepting something into the community
> that divides (isn't built on consensus) seems an unhealthy thing to do to
> the community. Jonathan's suggestion gives us something productive to do to
> get to consensus.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>


Re: [VOTE] Accept GoCQL driver donation and begin incubation process

2018-09-12 Thread Alex Lourie
+1.

Chris already expressed his intent to stay and keep the maintenance of the
project ongoing. As previously mentioned, I'm also going to keep
contributing to the driver.

Having it under the umbrella of Apache/Cassandra does add to it's weight as
the related project.

Alex.

On Thu., 13 Sep. 2018, 06:03 Jeremiah D Jordan, 
wrote:

> My +1 was under the assumption that the current maintainer wanted to
> continue with the project and would be brought in to do that along with the
> code.
>
> But my +1 also has no meaning in the ASF meritocracy as I am neither a
> committer or a PMC member ;).  It just expresses my opinion as a long
> standing member of the community that I think it is fine to bring the
> current GoCQL driver and its main contributors into the Apache Cassandra
> project.  I was not asking others to do the work, I was assuming the
> current people doing the work on said driver would continue to work on it.
>
> -Jeremiah
>
> > On Sep 12, 2018, at 12:55 PM, Jonathan Haddad  wrote:
> >
> > I'm +0, and I share the same concerns as Sylvain.
> >
> > For those of you that have +1'ed, are you planning on contributing to the
> > driver?  Docs, code, QA?  It's easy to throw a +1 down to make the driver
> > the responsibility of the project if you're asking others to do the work.
> > I vote this way because I already know I won't contribute to it and it's
> > irresponsible to vote something in if I have no intent on helping
> maintain
> > it.
> >
> > On Wed, Sep 12, 2018 at 10:45 AM Sumanth Pasupuleti
> >  wrote:
> >
> >> +1
> >>
> >> On Wed, Sep 12, 2018 at 10:37 AM Dinesh Joshi
> >>  wrote:
> >>
> >>> +1
> >>>
> >>> Dinesh
> >>>
>  On Sep 12, 2018, at 10:23 AM, Jaydeep Chovatia <
> >>> chovatia.jayd...@gmail.com> wrote:
> 
>  +1
> 
>  On Wed, Sep 12, 2018 at 10:00 AM Roopa Tangirala
>   wrote:
> 
> > +1
> >
> >
> > *Regards,*
> >
> > *Roopa Tangirala*
> >
> > Engineering Manager CDE
> >
> > *(408) 438-3156 - mobile*
> >
> >
> >
> >
> >
> >
> > On Wed, Sep 12, 2018 at 8:51 AM Sylvain Lebresne  >
> > wrote:
> >
> >> -0
> >>
> >> The project seems to have a hard time getting on top of reviewing
> his
> >> backlog
> >> of 'patch available' issues, so that I'm skeptical adopting more
> code
> >>> to
> >> maintain is the thing the project needs the most right now. Besides,
> >>> I'm
> >> also
> >> generally skeptical that augmenting the scope of a project makes it
> > better:
> >> I feel
> >> keeping this project focused on the core server is better. I see
> >> risks
> >> here, but
> >> the upsides haven't been made very clear for me, even for end users:
> >>> yes,
> >> it
> >> may provide a tiny bit more clarity around which Golang driver to
> >>> choose
> > by
> >> default, but I'm not sure users are that lost, and I think there is
> >>> other
> >> ways to
> >> solve that if we really want.
> >>
> >> Anyway, I reckon I may be overly pessimistic here and it's not that
> > strong
> >> of
> >> an objection if a large majority is on-board, so giving my opinion
> >> but
> > not
> >> opposing.
> >>
> >> --
> >> Sylvain
> >>
> >>
> >> On Wed, Sep 12, 2018 at 5:36 PM Jeremiah D Jordan <
> >> jeremiah.jor...@gmail.com>
> >> wrote:
> >>
> >>> +1
> >>>
> >>> But I also think getting this through incubation might take a
> >> while/be
> >>> impossible given how large the contributor list looks…
> >>>
>  On Sep 12, 2018, at 10:22 AM, Jeff Jirsa 
> wrote:
> 
>  +1
> 
>  (Incubation looks like it may be challenging to get acceptance
> from
> > all
> >>> existing contributors, though)
> 
>  --
>  Jeff Jirsa
> 
> 
> > On Sep 12, 2018, at 8:12 AM, Nate McCall 
> > wrote:
> >
> > This will be the same process used for dtest. We will need to
> walk
> > this through the incubator per the process outlined here:
> >
> >
> >>>
> >>
> >
> >>>
> >>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__incubator.apache.org_guides_ip-5Fclearance.html&d=DwIFAg&c=adz96Xi0w1RHqtPMowiL2g&r=CNZK3RiJDLqhsZDG6FQGnXn8WyPRCQhp4x_uBICNC0g&m=g-MlYFZVJ7j5Dj_ZfPfa0Ik8Nxco7QsJhTG1TnJH7xI&s=rk5T_t1HZY6PAhN5XgflBhfEtNrcZkVTIvQxixDlw9o&e=
> >
> > Pending the outcome of this vote, we will create the JIRA issues
> >> for
> > tracking and after we go through the process, and discuss adding
> > committers in a separate thread (we need to do this atomically
> > anyway
> > per general ASF committer adding processes).
> >
> > Thanks,
> > -Nate
> >
> >
> > -
> > To unsubscribe, e-mail: d

Re: [VOTE] Development Approach for Apache Cassandra Management process

2018-09-12 Thread Mick Semb Wever


> But I'd like to see a serious investigation of the options -- feature set,
> maturity, maintainer availability, etc -- before making a decision.  This
> will take some time, but this is a place where "measure twice, cut once"
> seems like the right approach.


This^ 100%. 

I dislike the idea of a vote altogether: 
https://www.apache.org/foundation/voting.html#reasons-for-votes

Discussion should resolve things, accepting something into the community that 
divides (isn't built on consensus) seems an unhealthy thing to do to the 
community. Jonathan's suggestion gives us something productive to do to get to 
consensus.

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



Re: Proposing an Apache Cassandra Management process

2018-09-12 Thread sankalp kohli
(Using this thread and not the vote thread intentionally)
For folks talking about vote being rushed. I would use the email from
Joseph to show this is not rushed. There was no email on this thread for 4
months until I pinged.


Dec 2016: Vinay worked with Jon and Alex to try to collaborate on Reaper to
come up with design goals for a repair scheduler that could work at Netflix
scale.

~Feb 2017: Netflix believes that the fundamental design gaps prevented us
from using Reaper as it relies heavily on remote JMX connections and
central coordination.

Sep. 2017: Vinay gives a lightning talk at NGCC about a highly available
and distributed repair scheduling sidecar/tool. He is encouraged by
multiple committers to build repair scheduling into the daemon itself and
not as a sidecar so the database is truly eventually consistent.

~Jun. 2017 - Feb. 2018: Based on internal need and the positive feedback at
NGCC, Vinay and myself prototype the distributed repair scheduler within
Priam and roll it out at Netflix scale.

Mar. 2018: I open a Jira (CASSANDRA-14346) along with a detailed 20 page
design document for adding repair scheduling to the daemon itself and open
the design up for feedback from the community. We get feedback from Alex,
Blake, Nate, Stefan, and Mick. As far as I know there were zero proposals
to contribute Reaper at this point. We hear the consensus that the
community would prefer repair scheduling in a separate distributed sidecar
rather than in the daemon itself and we re-work the design to match this
consensus, re-aligning with our original proposal at NGCC.

Apr 2018: Blake brings the discussion of repair scheduling to the dev list (
https://lists.apache.org/thread.html/760fbef677f27aa5c2ab4c375c7efeb81304fea428deff986ba1c2eb@%3Cdev.cassandra.apache.org%3E
).
Many community members give positive feedback that we should solve it as
part of Cassandra and there is still no mention of contributing Reaper at
this point. The last message is my attempted summary giving context on how
we want to take the best of all the sidecars (OpsCenter, Priam, Reaper) and
ship them with Cassandra.

Apr. 2018: Dinesh opens CASSANDRA-14395 along with a public design document
for gathering feedback on a general management sidecar. Sankalp and Dinesh
encourage Vinay and myself to kickstart that sidecar using the repair
scheduler patch

Apr 2018: Dinesh reaches out to the dev list (
https://lists.apache.org/thread.html/a098341efd8f344494bcd2761dba5125e971b59b1dd54f282ffda253@%3Cdev.cassandra.apache.org%3E
)
about the general management process to gain further feedback. All feedback
remains positive as it is a potential place for multiple community members
to contribute their various sidecar functionality.

May-Jul 2017: Vinay and I work on creating a basic sidecar for running the
repair scheduler based on the feedback from the community in
CASSANDRA-14346 and CASSANDRA-14395

Jun 2018: I bump CASSANDRA-14346 indicating we're still working on this,
nobody objects

Jul 2018: Sankalp asks on the dev list if anyone has feature Jiras anyone
needs review for before 4.0, I mention again that we've nearly got the
basic sidecar and repair scheduling work done and will need help with
review. No one responds.

Aug 2018: We submit a patch that brings a basic distributed sidecar and
robust distributed repair to Cassandra itself. Dinesh mentions that he will
try to review. Now folks appear concerned about it being in tree and
instead maybe it should go in a different repo all together. I don't think
we have consensus on the repo choice yet.

On Sun, Sep 9, 2018 at 9:13 AM sankalp kohli  wrote:

> I agree with Jon and I think folks who are talking about tech debts in
> Reaper should elaborate with examples about these tech debts. Can we be
> more precise and list them down? I see it spread out over this long email
> thread!!
>
> On Sun, Sep 9, 2018 at 6:29 AM Elliott Sims  wrote:
>
>> A big one to add to your list there, IMO as a user:
>> * API for determining detailed repair state (and history?).  Essentially,
>> something beyond just "Is some sort of repair running?" so that tools like
>> Reaper can parallelize better.
>>
>> On Sun, Sep 9, 2018 at 8:30 AM, Stefan Podkowinski 
>> wrote:
>>
>> > Does it have to be a single project with functionality provided by
>> > multiple plugins? Designing a plugin API at this point seems to be a bit
>> > early and comes with additional complexity around managing plugins in
>> > general.
>> >
>> > I was more thinking into the direction of: "what can we do to enable
>> > people to create any kind of side car or tooling solution?". Thinks
>> like:
>> >
>> > Common cluster discovery and management API
>> > * Detect local Cassandra processes
>> > * Discover and receive events on cluster topology
>> > * Get assigned tokens for nodes
>> > * Read node configuration
>> > * Health checks (as already proposed)
>> >
>> > Any side cars should be easy to install on nodes that already run
>> Cassandra
>> > * Scr

Re: [VOTE] Development Approach for Apache Cassandra Management process

2018-09-12 Thread sankalp kohli
Hi Joey,
 The intention of this vote is to do what you are saying. We
want to see movement on this and not drag it for months. I am happy to drag
it for few more weeks if thats is what we agree on.

Regarding evaluating different options, if we decide on option a, we can
always do that like I wrote in the first email.

Thanks,
Sankalp

On Wed, Sep 12, 2018 at 2:51 PM Joseph Lynch  wrote:

> > I'd like to ask those of you that are +1'ing, are you willing to
> contribute
> > or are you just voting we start an admin tool from scratch because you
> > think it'll somehow produce a perfect codebase?
>
> Roopa, Vinay, Sumanth and I are voting as community members (and a
> sizeable user) and our willingness to contribute should be clear from
> the close to six months of engineering work we've invested presenting,
> prototyping, deploying, refactoring, designing, more discussing, and
> producing the patch on CASSANDRA-14346 that then happened to revive
> the April maintenance process discussion as we needed something to put
> the scheduler in. Dinesh and other Apple contributors were the ones
> who floated the idea in the first place and we just tried to help that
> proposal actually happen. Clearly we have to re-work that patch as it
> seems we have turned the management process discussion into a
> discussion about repair which was not the point and we are already in
> the process of converting the patch into a pluggable maintenance
> execution engine for any scheduled task.
>
> I didn't understand this vote as a vote on on releasing the yet to
> exist maintenance process ... I thought we're trying to get consensus
> on if we should invest in a fresh repo and build to the design (when
> we have achieved the design there can be an actual release vote) or
> start from an existing project which has made existing choices and
> trying to refactor towards the scope/desires.
>
> -Joey
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>


Re: [VOTE] Development Approach for Apache Cassandra Management process

2018-09-12 Thread Joseph Lynch
> I'd like to ask those of you that are +1'ing, are you willing to contribute
> or are you just voting we start an admin tool from scratch because you
> think it'll somehow produce a perfect codebase?

Roopa, Vinay, Sumanth and I are voting as community members (and a
sizeable user) and our willingness to contribute should be clear from
the close to six months of engineering work we've invested presenting,
prototyping, deploying, refactoring, designing, more discussing, and
producing the patch on CASSANDRA-14346 that then happened to revive
the April maintenance process discussion as we needed something to put
the scheduler in. Dinesh and other Apple contributors were the ones
who floated the idea in the first place and we just tried to help that
proposal actually happen. Clearly we have to re-work that patch as it
seems we have turned the management process discussion into a
discussion about repair which was not the point and we are already in
the process of converting the patch into a pluggable maintenance
execution engine for any scheduled task.

I didn't understand this vote as a vote on on releasing the yet to
exist maintenance process ... I thought we're trying to get consensus
on if we should invest in a fresh repo and build to the design (when
we have achieved the design there can be an actual release vote) or
start from an existing project which has made existing choices and
trying to refactor towards the scope/desires.

-Joey

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



Re: [VOTE] Development Approach for Apache Cassandra Management process

2018-09-12 Thread Joshua McKenzie
Thanks. :) sleep deprivation is real.

To Ellis' point: "But I'd like to see a serious investigation of the
options "
While we've talked about a lot of things on that email thread, I don't
think we have a distilled view of the gap between current status for these
options and the resources available and interested to focus on them, as the
success or failure of any community driven effort is going to be heavily
dependent on participation.

i.e. my gut tells me the outcome of this vote won't be something we can
disagree and commit on, but rather something where we'll split down the
middle and have half the community disengage since it's a popularity vote
atm rather than one based on data.

On Wed, Sep 12, 2018 at 5:27 PM sankalp kohli 
wrote:

> Congrats on the newborn. I am assuming others also have personal things
> going on!!
>
> Also discussion thread is ongoing from April and not last 4 days. If enough
> people think it is rushed, we can always revote.
>
> On Wed, Sep 12, 2018 at 2:24 PM Joshua McKenzie 
> wrote:
>
> > That was four days ago, and I have a newborn at home. Not a lot of time
> for
> > people to respond that have other things going on in life. :)
> >
> > On Wed, Sep 12, 2018 at 5:13 PM sankalp kohli 
> > wrote:
> >
> > > If you think vote is being forced, why not reply to my email on another
> > > thread when I said we should vote? Why was the thread dead for months
> and
> > > someone comes back with a contribution and then people starts talking?
> > >
> > > I would have happily waited for few more days!!
> > >
> > >
> > >
> > > On Wed, Sep 12, 2018 at 2:09 PM Joshua McKenzie 
> > > wrote:
> > >
> > > > >
> > > > >  It is important we make progress as we have been discussing this
> > since
> > > > > April!!
> > > >
> > > >
> > > > The discussion was making progress. Just because you want things to
> > > happen
> > > > faster is no reason to force an early vote.
> > > >
> > > > On Wed, Sep 12, 2018 at 5:04 PM sankalp kohli <
> kohlisank...@gmail.com>
> > > > wrote:
> > > >
> > > > > Also my vote is same as Jeff. d but would slightly prefer b. It is
> > > > > important we make progress as we have been discussing this since
> > > April!!
> > > > >
> > > > > On Wed, Sep 12, 2018 at 1:52 PM sankalp kohli <
> > kohlisank...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > The last email on the thread was 3 days ago and I made it clear
> > days
> > > > back
> > > > > > that we should vote on it to make progress. Without this vote, I
> am
> > > not
> > > > > > sure we will make progress.
> > > > > > Many people want to contribute on this and hence we are voting so
> > we
> > > > can
> > > > > > make progress.
> > > > > >
> > > > > > My vote is d
> > > > > >
> > > > > >
> > > > > > On Wed, Sep 12, 2018 at 1:36 PM Jonathan Haddad <
> j...@jonhaddad.com
> > >
> > > > > wrote:
> > > > > >
> > > > > >> This voting process feels a bit rushed and frankly not well
> > thought
> > > > out.
> > > > > >> In addition to Sylvain's valid points, which you (Sankalp)
> didn't
> > > > > address
> > > > > >> at all, the discussion in the other threads seemed to be
> ongoing.
> > > The
> > > > > >> last
> > > > > >> email you wrote on one of them was asking for additional
> feedback,
> > > > that
> > > > > >> indicates the discussion is still open.
> > > > > >>
> > > > > >> Out of principal I vote for none of the options (inaction).
> > You're
> > > > > >> deliberately trying to ram *something* through, and that's not
> how
> > > > this
> > > > > is
> > > > > >> supposed to work.
> > > > > >>
> > > > > >> For those of you unfamiliar with the process - please read
> > > > > >> https://www.apache.org/foundation/voting.html.
> > > > > >>
> > > > > >> I'd like to ask those of you that are +1'ing, are you willing to
> > > > > >> contribute
> > > > > >> or are you just voting we start an admin tool from scratch
> because
> > > you
> > > > > >> think it'll somehow produce a perfect codebase?
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >> On Wed, Sep 12, 2018 at 12:50 PM sankalp kohli <
> > > > kohlisank...@gmail.com>
> > > > > >> wrote:
> > > > > >>
> > > > > >> > Hi Sylvain,
> > > > > >> > I would appreciate if we can give feedback on
> > the
> > > > > >> > discussion threads and not wait for vote threads. I made it
> > clear
> > > in
> > > > > the
> > > > > >> > discussion thread that we will start a vote!!
> > > > > >> > Thanks,
> > > > > >> > Sankalp
> > > > > >> >
> > > > > >> > On Wed, Sep 12, 2018 at 12:47 PM Jeff Jirsa  >
> > > > wrote:
> > > > > >> >
> > > > > >> > > On Wed, Sep 12, 2018 at 12:41 PM Sylvain Lebresne <
> > > > > lebre...@gmail.com
> > > > > >> >
> > > > > >> > > wrote:
> > > > > >> > >
> > > > > >> > > > That's probably a stupid question, and excuse me if it is,
> > but
> > > > > what
> > > > > >> > does
> > > > > >> > > > those votes on the dev mailing list even mean?
> > > > > >> > > >
> > > > > >> > > > How do you count votes at the end? Just by co

Re: [VOTE] Development Approach for Apache Cassandra Management process

2018-09-12 Thread sankalp kohli
Congrats on the newborn. I am assuming others also have personal things
going on!!

Also discussion thread is ongoing from April and not last 4 days. If enough
people think it is rushed, we can always revote.

On Wed, Sep 12, 2018 at 2:24 PM Joshua McKenzie 
wrote:

> That was four days ago, and I have a newborn at home. Not a lot of time for
> people to respond that have other things going on in life. :)
>
> On Wed, Sep 12, 2018 at 5:13 PM sankalp kohli 
> wrote:
>
> > If you think vote is being forced, why not reply to my email on another
> > thread when I said we should vote? Why was the thread dead for months and
> > someone comes back with a contribution and then people starts talking?
> >
> > I would have happily waited for few more days!!
> >
> >
> >
> > On Wed, Sep 12, 2018 at 2:09 PM Joshua McKenzie 
> > wrote:
> >
> > > >
> > > >  It is important we make progress as we have been discussing this
> since
> > > > April!!
> > >
> > >
> > > The discussion was making progress. Just because you want things to
> > happen
> > > faster is no reason to force an early vote.
> > >
> > > On Wed, Sep 12, 2018 at 5:04 PM sankalp kohli 
> > > wrote:
> > >
> > > > Also my vote is same as Jeff. d but would slightly prefer b. It is
> > > > important we make progress as we have been discussing this since
> > April!!
> > > >
> > > > On Wed, Sep 12, 2018 at 1:52 PM sankalp kohli <
> kohlisank...@gmail.com>
> > > > wrote:
> > > >
> > > > > The last email on the thread was 3 days ago and I made it clear
> days
> > > back
> > > > > that we should vote on it to make progress. Without this vote, I am
> > not
> > > > > sure we will make progress.
> > > > > Many people want to contribute on this and hence we are voting so
> we
> > > can
> > > > > make progress.
> > > > >
> > > > > My vote is d
> > > > >
> > > > >
> > > > > On Wed, Sep 12, 2018 at 1:36 PM Jonathan Haddad  >
> > > > wrote:
> > > > >
> > > > >> This voting process feels a bit rushed and frankly not well
> thought
> > > out.
> > > > >> In addition to Sylvain's valid points, which you (Sankalp) didn't
> > > > address
> > > > >> at all, the discussion in the other threads seemed to be ongoing.
> > The
> > > > >> last
> > > > >> email you wrote on one of them was asking for additional feedback,
> > > that
> > > > >> indicates the discussion is still open.
> > > > >>
> > > > >> Out of principal I vote for none of the options (inaction).
> You're
> > > > >> deliberately trying to ram *something* through, and that's not how
> > > this
> > > > is
> > > > >> supposed to work.
> > > > >>
> > > > >> For those of you unfamiliar with the process - please read
> > > > >> https://www.apache.org/foundation/voting.html.
> > > > >>
> > > > >> I'd like to ask those of you that are +1'ing, are you willing to
> > > > >> contribute
> > > > >> or are you just voting we start an admin tool from scratch because
> > you
> > > > >> think it'll somehow produce a perfect codebase?
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >> On Wed, Sep 12, 2018 at 12:50 PM sankalp kohli <
> > > kohlisank...@gmail.com>
> > > > >> wrote:
> > > > >>
> > > > >> > Hi Sylvain,
> > > > >> > I would appreciate if we can give feedback on
> the
> > > > >> > discussion threads and not wait for vote threads. I made it
> clear
> > in
> > > > the
> > > > >> > discussion thread that we will start a vote!!
> > > > >> > Thanks,
> > > > >> > Sankalp
> > > > >> >
> > > > >> > On Wed, Sep 12, 2018 at 12:47 PM Jeff Jirsa 
> > > wrote:
> > > > >> >
> > > > >> > > On Wed, Sep 12, 2018 at 12:41 PM Sylvain Lebresne <
> > > > lebre...@gmail.com
> > > > >> >
> > > > >> > > wrote:
> > > > >> > >
> > > > >> > > > That's probably a stupid question, and excuse me if it is,
> but
> > > > what
> > > > >> > does
> > > > >> > > > those votes on the dev mailing list even mean?
> > > > >> > > >
> > > > >> > > > How do you count votes at the end? Just by counting all
> votes
> > > > cast,
> > > > >> > > > irregardless of whomever cast it? Or are we intending to
> only
> > > > count
> > > > >> PMC
> > > > >> > > > members, or maybe committers votes?
> > > > >> > > >
> > > > >> > >
> > > > >> > > I believe the intent is to try to see if there exists
> consensus.
> > > > >> > > Ultimately, PMC is going to matter more than random email
> > > addresses
> > > > >> from
> > > > >> > > people nobody recognizes. This should be in public, though,
> not
> > > > >> private,
> > > > >> > so
> > > > >> > > seeing what feedback is beyond the PMC is useful (primarily
> > > because
> > > > it
> > > > >> > will
> > > > >> > > matter when it comes time to extend and maintain it - if
> people
> > > > >> strongly
> > > > >> > > prefer one or the other, then maintenance is going to be a
> > > problem).
> > > > >> > >
> > > > >> > > If there's 100 random non-contributor votes for one option and
> > 20
> > > > pmc
> > > > >> > votes
> > > > >> > > for another options, I think the real answer will be "we don't
> > > have
> > > > >>

Re: [VOTE] Development Approach for Apache Cassandra Management process

2018-09-12 Thread Joshua McKenzie
That was four days ago, and I have a newborn at home. Not a lot of time for
people to respond that have other things going on in life. :)

On Wed, Sep 12, 2018 at 5:13 PM sankalp kohli 
wrote:

> If you think vote is being forced, why not reply to my email on another
> thread when I said we should vote? Why was the thread dead for months and
> someone comes back with a contribution and then people starts talking?
>
> I would have happily waited for few more days!!
>
>
>
> On Wed, Sep 12, 2018 at 2:09 PM Joshua McKenzie 
> wrote:
>
> > >
> > >  It is important we make progress as we have been discussing this since
> > > April!!
> >
> >
> > The discussion was making progress. Just because you want things to
> happen
> > faster is no reason to force an early vote.
> >
> > On Wed, Sep 12, 2018 at 5:04 PM sankalp kohli 
> > wrote:
> >
> > > Also my vote is same as Jeff. d but would slightly prefer b. It is
> > > important we make progress as we have been discussing this since
> April!!
> > >
> > > On Wed, Sep 12, 2018 at 1:52 PM sankalp kohli 
> > > wrote:
> > >
> > > > The last email on the thread was 3 days ago and I made it clear days
> > back
> > > > that we should vote on it to make progress. Without this vote, I am
> not
> > > > sure we will make progress.
> > > > Many people want to contribute on this and hence we are voting so we
> > can
> > > > make progress.
> > > >
> > > > My vote is d
> > > >
> > > >
> > > > On Wed, Sep 12, 2018 at 1:36 PM Jonathan Haddad 
> > > wrote:
> > > >
> > > >> This voting process feels a bit rushed and frankly not well thought
> > out.
> > > >> In addition to Sylvain's valid points, which you (Sankalp) didn't
> > > address
> > > >> at all, the discussion in the other threads seemed to be ongoing.
> The
> > > >> last
> > > >> email you wrote on one of them was asking for additional feedback,
> > that
> > > >> indicates the discussion is still open.
> > > >>
> > > >> Out of principal I vote for none of the options (inaction).  You're
> > > >> deliberately trying to ram *something* through, and that's not how
> > this
> > > is
> > > >> supposed to work.
> > > >>
> > > >> For those of you unfamiliar with the process - please read
> > > >> https://www.apache.org/foundation/voting.html.
> > > >>
> > > >> I'd like to ask those of you that are +1'ing, are you willing to
> > > >> contribute
> > > >> or are you just voting we start an admin tool from scratch because
> you
> > > >> think it'll somehow produce a perfect codebase?
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >> On Wed, Sep 12, 2018 at 12:50 PM sankalp kohli <
> > kohlisank...@gmail.com>
> > > >> wrote:
> > > >>
> > > >> > Hi Sylvain,
> > > >> > I would appreciate if we can give feedback on the
> > > >> > discussion threads and not wait for vote threads. I made it clear
> in
> > > the
> > > >> > discussion thread that we will start a vote!!
> > > >> > Thanks,
> > > >> > Sankalp
> > > >> >
> > > >> > On Wed, Sep 12, 2018 at 12:47 PM Jeff Jirsa 
> > wrote:
> > > >> >
> > > >> > > On Wed, Sep 12, 2018 at 12:41 PM Sylvain Lebresne <
> > > lebre...@gmail.com
> > > >> >
> > > >> > > wrote:
> > > >> > >
> > > >> > > > That's probably a stupid question, and excuse me if it is, but
> > > what
> > > >> > does
> > > >> > > > those votes on the dev mailing list even mean?
> > > >> > > >
> > > >> > > > How do you count votes at the end? Just by counting all votes
> > > cast,
> > > >> > > > irregardless of whomever cast it? Or are we intending to only
> > > count
> > > >> PMC
> > > >> > > > members, or maybe committers votes?
> > > >> > > >
> > > >> > >
> > > >> > > I believe the intent is to try to see if there exists consensus.
> > > >> > > Ultimately, PMC is going to matter more than random email
> > addresses
> > > >> from
> > > >> > > people nobody recognizes. This should be in public, though, not
> > > >> private,
> > > >> > so
> > > >> > > seeing what feedback is beyond the PMC is useful (primarily
> > because
> > > it
> > > >> > will
> > > >> > > matter when it comes time to extend and maintain it - if people
> > > >> strongly
> > > >> > > prefer one or the other, then maintenance is going to be a
> > problem).
> > > >> > >
> > > >> > > If there's 100 random non-contributor votes for one option and
> 20
> > > pmc
> > > >> > votes
> > > >> > > for another options, I think the real answer will be "we don't
> > have
> > > >> > > consensus, and either we don't do it, or we do it the way the
> PMC
> > > >> thinks
> > > >> > is
> > > >> > > best", for all of the reasons you describe in the paragraphs
> > below.
> > > >> > >
> > > >> > >
> > > >> > > > If the former, that is a bit weird to me because we simply
> don't
> > > >> know
> > > >> > who
> > > >> > > > votes. And I don't mean to be rude towards anyone, but 1)
> > someone
> > > >> could
> > > >> > > > easily create 10 email addresses to vote 10 times (and sure,
> you
> > > >> could
> > > >> > > > invoke trust, and I'm not entirely against trust in genera

Re: [VOTE] Development Approach for Apache Cassandra Management process

2018-09-12 Thread sankalp kohli
If you think vote is being forced, why not reply to my email on another
thread when I said we should vote? Why was the thread dead for months and
someone comes back with a contribution and then people starts talking?

I would have happily waited for few more days!!



On Wed, Sep 12, 2018 at 2:09 PM Joshua McKenzie 
wrote:

> >
> >  It is important we make progress as we have been discussing this since
> > April!!
>
>
> The discussion was making progress. Just because you want things to happen
> faster is no reason to force an early vote.
>
> On Wed, Sep 12, 2018 at 5:04 PM sankalp kohli 
> wrote:
>
> > Also my vote is same as Jeff. d but would slightly prefer b. It is
> > important we make progress as we have been discussing this since April!!
> >
> > On Wed, Sep 12, 2018 at 1:52 PM sankalp kohli 
> > wrote:
> >
> > > The last email on the thread was 3 days ago and I made it clear days
> back
> > > that we should vote on it to make progress. Without this vote, I am not
> > > sure we will make progress.
> > > Many people want to contribute on this and hence we are voting so we
> can
> > > make progress.
> > >
> > > My vote is d
> > >
> > >
> > > On Wed, Sep 12, 2018 at 1:36 PM Jonathan Haddad 
> > wrote:
> > >
> > >> This voting process feels a bit rushed and frankly not well thought
> out.
> > >> In addition to Sylvain's valid points, which you (Sankalp) didn't
> > address
> > >> at all, the discussion in the other threads seemed to be ongoing.  The
> > >> last
> > >> email you wrote on one of them was asking for additional feedback,
> that
> > >> indicates the discussion is still open.
> > >>
> > >> Out of principal I vote for none of the options (inaction).  You're
> > >> deliberately trying to ram *something* through, and that's not how
> this
> > is
> > >> supposed to work.
> > >>
> > >> For those of you unfamiliar with the process - please read
> > >> https://www.apache.org/foundation/voting.html.
> > >>
> > >> I'd like to ask those of you that are +1'ing, are you willing to
> > >> contribute
> > >> or are you just voting we start an admin tool from scratch because you
> > >> think it'll somehow produce a perfect codebase?
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> On Wed, Sep 12, 2018 at 12:50 PM sankalp kohli <
> kohlisank...@gmail.com>
> > >> wrote:
> > >>
> > >> > Hi Sylvain,
> > >> > I would appreciate if we can give feedback on the
> > >> > discussion threads and not wait for vote threads. I made it clear in
> > the
> > >> > discussion thread that we will start a vote!!
> > >> > Thanks,
> > >> > Sankalp
> > >> >
> > >> > On Wed, Sep 12, 2018 at 12:47 PM Jeff Jirsa 
> wrote:
> > >> >
> > >> > > On Wed, Sep 12, 2018 at 12:41 PM Sylvain Lebresne <
> > lebre...@gmail.com
> > >> >
> > >> > > wrote:
> > >> > >
> > >> > > > That's probably a stupid question, and excuse me if it is, but
> > what
> > >> > does
> > >> > > > those votes on the dev mailing list even mean?
> > >> > > >
> > >> > > > How do you count votes at the end? Just by counting all votes
> > cast,
> > >> > > > irregardless of whomever cast it? Or are we intending to only
> > count
> > >> PMC
> > >> > > > members, or maybe committers votes?
> > >> > > >
> > >> > >
> > >> > > I believe the intent is to try to see if there exists consensus.
> > >> > > Ultimately, PMC is going to matter more than random email
> addresses
> > >> from
> > >> > > people nobody recognizes. This should be in public, though, not
> > >> private,
> > >> > so
> > >> > > seeing what feedback is beyond the PMC is useful (primarily
> because
> > it
> > >> > will
> > >> > > matter when it comes time to extend and maintain it - if people
> > >> strongly
> > >> > > prefer one or the other, then maintenance is going to be a
> problem).
> > >> > >
> > >> > > If there's 100 random non-contributor votes for one option and 20
> > pmc
> > >> > votes
> > >> > > for another options, I think the real answer will be "we don't
> have
> > >> > > consensus, and either we don't do it, or we do it the way the PMC
> > >> thinks
> > >> > is
> > >> > > best", for all of the reasons you describe in the paragraphs
> below.
> > >> > >
> > >> > >
> > >> > > > If the former, that is a bit weird to me because we simply don't
> > >> know
> > >> > who
> > >> > > > votes. And I don't mean to be rude towards anyone, but 1)
> someone
> > >> could
> > >> > > > easily create 10 email addresses to vote 10 times (and sure, you
> > >> could
> > >> > > > invoke trust, and I'm not entirely against trust in general, but
> > >> it's
> > >> > the
> > >> > > > internet...) and 2) this kind of decision will have non-trivial
> > >> > > > consequences for the project, particularly on those that
> maintain
> > >> it,
> > >> > so
> > >> > > I
> > >> > > > admit I'm not entirely comfortable with "anyone's voice has the
> > same
> > >> > > > weight".
> > >> > > > If the latter, then this makes more sense to me (why are we even
> > >> > > bothering
> > >> > > > voting PMC members in if it's not to handl

Re: [VOTE] Development Approach for Apache Cassandra Management process

2018-09-12 Thread Joshua McKenzie
>
>  It is important we make progress as we have been discussing this since
> April!!


The discussion was making progress. Just because you want things to happen
faster is no reason to force an early vote.

On Wed, Sep 12, 2018 at 5:04 PM sankalp kohli 
wrote:

> Also my vote is same as Jeff. d but would slightly prefer b. It is
> important we make progress as we have been discussing this since April!!
>
> On Wed, Sep 12, 2018 at 1:52 PM sankalp kohli 
> wrote:
>
> > The last email on the thread was 3 days ago and I made it clear days back
> > that we should vote on it to make progress. Without this vote, I am not
> > sure we will make progress.
> > Many people want to contribute on this and hence we are voting so we can
> > make progress.
> >
> > My vote is d
> >
> >
> > On Wed, Sep 12, 2018 at 1:36 PM Jonathan Haddad 
> wrote:
> >
> >> This voting process feels a bit rushed and frankly not well thought out.
> >> In addition to Sylvain's valid points, which you (Sankalp) didn't
> address
> >> at all, the discussion in the other threads seemed to be ongoing.  The
> >> last
> >> email you wrote on one of them was asking for additional feedback, that
> >> indicates the discussion is still open.
> >>
> >> Out of principal I vote for none of the options (inaction).  You're
> >> deliberately trying to ram *something* through, and that's not how this
> is
> >> supposed to work.
> >>
> >> For those of you unfamiliar with the process - please read
> >> https://www.apache.org/foundation/voting.html.
> >>
> >> I'd like to ask those of you that are +1'ing, are you willing to
> >> contribute
> >> or are you just voting we start an admin tool from scratch because you
> >> think it'll somehow produce a perfect codebase?
> >>
> >>
> >>
> >>
> >>
> >> On Wed, Sep 12, 2018 at 12:50 PM sankalp kohli 
> >> wrote:
> >>
> >> > Hi Sylvain,
> >> > I would appreciate if we can give feedback on the
> >> > discussion threads and not wait for vote threads. I made it clear in
> the
> >> > discussion thread that we will start a vote!!
> >> > Thanks,
> >> > Sankalp
> >> >
> >> > On Wed, Sep 12, 2018 at 12:47 PM Jeff Jirsa  wrote:
> >> >
> >> > > On Wed, Sep 12, 2018 at 12:41 PM Sylvain Lebresne <
> lebre...@gmail.com
> >> >
> >> > > wrote:
> >> > >
> >> > > > That's probably a stupid question, and excuse me if it is, but
> what
> >> > does
> >> > > > those votes on the dev mailing list even mean?
> >> > > >
> >> > > > How do you count votes at the end? Just by counting all votes
> cast,
> >> > > > irregardless of whomever cast it? Or are we intending to only
> count
> >> PMC
> >> > > > members, or maybe committers votes?
> >> > > >
> >> > >
> >> > > I believe the intent is to try to see if there exists consensus.
> >> > > Ultimately, PMC is going to matter more than random email addresses
> >> from
> >> > > people nobody recognizes. This should be in public, though, not
> >> private,
> >> > so
> >> > > seeing what feedback is beyond the PMC is useful (primarily because
> it
> >> > will
> >> > > matter when it comes time to extend and maintain it - if people
> >> strongly
> >> > > prefer one or the other, then maintenance is going to be a problem).
> >> > >
> >> > > If there's 100 random non-contributor votes for one option and 20
> pmc
> >> > votes
> >> > > for another options, I think the real answer will be "we don't have
> >> > > consensus, and either we don't do it, or we do it the way the PMC
> >> thinks
> >> > is
> >> > > best", for all of the reasons you describe in the paragraphs below.
> >> > >
> >> > >
> >> > > > If the former, that is a bit weird to me because we simply don't
> >> know
> >> > who
> >> > > > votes. And I don't mean to be rude towards anyone, but 1) someone
> >> could
> >> > > > easily create 10 email addresses to vote 10 times (and sure, you
> >> could
> >> > > > invoke trust, and I'm not entirely against trust in general, but
> >> it's
> >> > the
> >> > > > internet...) and 2) this kind of decision will have non-trivial
> >> > > > consequences for the project, particularly on those that maintain
> >> it,
> >> > so
> >> > > I
> >> > > > admit I'm not entirely comfortable with "anyone's voice has the
> same
> >> > > > weight".
> >> > > > If the latter, then this makes more sense to me (why are we even
> >> > > bothering
> >> > > > voting PMC members in if it's not to handle these kinds of
> >> decisions,
> >> > > which
> >> > > > are very "project management" related), but we should be very
> clear
> >> > about
> >> > > > this from the get go (we could still use the dev list for
> >> transparency
> >> > > > sake, that I don't mind)? We should probably also have some
> >> deadline to
> >> > > the
> >> > > > vote, one that isn't too short.
> >> > > >
> >> > >
> >> > > Like releases, I think PMC votes count
> >> > >
> >> > >
> >> > > >
> >> > > > Anyway, fwiw, my opinion on this vote is not far from the one on
> the
> >> > > golang
> >> > > > driver acceptance vote (for which my remark above also

Re: [VOTE] Development Approach for Apache Cassandra Management process

2018-09-12 Thread Jonathan Ellis
I agree that it's premature to pick an option here.

For the record, my bias would be towards option (a) because my experience
is that it's much more productive to start with something that works and
extend it, than try to build a combination of different ideas. Especially
if the latter tends towards a design-by-committee, as it usually does!

But I'd like to see a serious investigation of the options -- feature set,
maturity, maintainer availability, etc -- before making a decision.  This
will take some time, but this is a place where "measure twice, cut once"
seems like the right approach.


On Wed, Sep 12, 2018 at 3:36 PM Jonathan Haddad  wrote:

> This voting process feels a bit rushed and frankly not well thought out.
> In addition to Sylvain's valid points, which you (Sankalp) didn't address
> at all, the discussion in the other threads seemed to be ongoing.  The last
> email you wrote on one of them was asking for additional feedback, that
> indicates the discussion is still open.
>
> Out of principal I vote for none of the options (inaction).  You're
> deliberately trying to ram *something* through, and that's not how this is
> supposed to work.
>
> For those of you unfamiliar with the process - please read
> https://www.apache.org/foundation/voting.html.
>
> I'd like to ask those of you that are +1'ing, are you willing to contribute
> or are you just voting we start an admin tool from scratch because you
> think it'll somehow produce a perfect codebase?
>
>
>
>
>
> On Wed, Sep 12, 2018 at 12:50 PM sankalp kohli 
> wrote:
>
> > Hi Sylvain,
> > I would appreciate if we can give feedback on the
> > discussion threads and not wait for vote threads. I made it clear in the
> > discussion thread that we will start a vote!!
> > Thanks,
> > Sankalp
> >
> > On Wed, Sep 12, 2018 at 12:47 PM Jeff Jirsa  wrote:
> >
> > > On Wed, Sep 12, 2018 at 12:41 PM Sylvain Lebresne 
> > > wrote:
> > >
> > > > That's probably a stupid question, and excuse me if it is, but what
> > does
> > > > those votes on the dev mailing list even mean?
> > > >
> > > > How do you count votes at the end? Just by counting all votes cast,
> > > > irregardless of whomever cast it? Or are we intending to only count
> PMC
> > > > members, or maybe committers votes?
> > > >
> > >
> > > I believe the intent is to try to see if there exists consensus.
> > > Ultimately, PMC is going to matter more than random email addresses
> from
> > > people nobody recognizes. This should be in public, though, not
> private,
> > so
> > > seeing what feedback is beyond the PMC is useful (primarily because it
> > will
> > > matter when it comes time to extend and maintain it - if people
> strongly
> > > prefer one or the other, then maintenance is going to be a problem).
> > >
> > > If there's 100 random non-contributor votes for one option and 20 pmc
> > votes
> > > for another options, I think the real answer will be "we don't have
> > > consensus, and either we don't do it, or we do it the way the PMC
> thinks
> > is
> > > best", for all of the reasons you describe in the paragraphs below.
> > >
> > >
> > > > If the former, that is a bit weird to me because we simply don't know
> > who
> > > > votes. And I don't mean to be rude towards anyone, but 1) someone
> could
> > > > easily create 10 email addresses to vote 10 times (and sure, you
> could
> > > > invoke trust, and I'm not entirely against trust in general, but it's
> > the
> > > > internet...) and 2) this kind of decision will have non-trivial
> > > > consequences for the project, particularly on those that maintain it,
> > so
> > > I
> > > > admit I'm not entirely comfortable with "anyone's voice has the same
> > > > weight".
> > > > If the latter, then this makes more sense to me (why are we even
> > > bothering
> > > > voting PMC members in if it's not to handle these kinds of decisions,
> > > which
> > > > are very "project management" related), but we should be very clear
> > about
> > > > this from the get go (we could still use the dev list for
> transparency
> > > > sake, that I don't mind)? We should probably also have some deadline
> to
> > > the
> > > > vote, one that isn't too short.
> > > >
> > >
> > > Like releases, I think PMC votes count
> > >
> > >
> > > >
> > > > Anyway, fwiw, my opinion on this vote is not far from the one on the
> > > golang
> > > > driver acceptance vote (for which my remark above also apply btw): no
> > yet
> > > > 100% convinced adding more pieces and scope to the project is what
> the
> > > > project needs just right now, but not strongly opposed if people
> really
> > > > wants this (and this one makes more sense to me than the golang
> driver
> > > > actually). But if I'm to pick between a) and b), I'm leaning b).
> > > >
> > >
> > > FWIW, two of the main reasons I'm in favor is as a way to lower barrier
> > to
> > > entry to both using the software AND contributing to the project, so I
> > > think your points are valid (both on gocql thread an

Re: [VOTE] Development Approach for Apache Cassandra Management process

2018-09-12 Thread sankalp kohli
Also my vote is same as Jeff. d but would slightly prefer b. It is
important we make progress as we have been discussing this since April!!

On Wed, Sep 12, 2018 at 1:52 PM sankalp kohli 
wrote:

> The last email on the thread was 3 days ago and I made it clear days back
> that we should vote on it to make progress. Without this vote, I am not
> sure we will make progress.
> Many people want to contribute on this and hence we are voting so we can
> make progress.
>
> My vote is d
>
>
> On Wed, Sep 12, 2018 at 1:36 PM Jonathan Haddad  wrote:
>
>> This voting process feels a bit rushed and frankly not well thought out.
>> In addition to Sylvain's valid points, which you (Sankalp) didn't address
>> at all, the discussion in the other threads seemed to be ongoing.  The
>> last
>> email you wrote on one of them was asking for additional feedback, that
>> indicates the discussion is still open.
>>
>> Out of principal I vote for none of the options (inaction).  You're
>> deliberately trying to ram *something* through, and that's not how this is
>> supposed to work.
>>
>> For those of you unfamiliar with the process - please read
>> https://www.apache.org/foundation/voting.html.
>>
>> I'd like to ask those of you that are +1'ing, are you willing to
>> contribute
>> or are you just voting we start an admin tool from scratch because you
>> think it'll somehow produce a perfect codebase?
>>
>>
>>
>>
>>
>> On Wed, Sep 12, 2018 at 12:50 PM sankalp kohli 
>> wrote:
>>
>> > Hi Sylvain,
>> > I would appreciate if we can give feedback on the
>> > discussion threads and not wait for vote threads. I made it clear in the
>> > discussion thread that we will start a vote!!
>> > Thanks,
>> > Sankalp
>> >
>> > On Wed, Sep 12, 2018 at 12:47 PM Jeff Jirsa  wrote:
>> >
>> > > On Wed, Sep 12, 2018 at 12:41 PM Sylvain Lebresne > >
>> > > wrote:
>> > >
>> > > > That's probably a stupid question, and excuse me if it is, but what
>> > does
>> > > > those votes on the dev mailing list even mean?
>> > > >
>> > > > How do you count votes at the end? Just by counting all votes cast,
>> > > > irregardless of whomever cast it? Or are we intending to only count
>> PMC
>> > > > members, or maybe committers votes?
>> > > >
>> > >
>> > > I believe the intent is to try to see if there exists consensus.
>> > > Ultimately, PMC is going to matter more than random email addresses
>> from
>> > > people nobody recognizes. This should be in public, though, not
>> private,
>> > so
>> > > seeing what feedback is beyond the PMC is useful (primarily because it
>> > will
>> > > matter when it comes time to extend and maintain it - if people
>> strongly
>> > > prefer one or the other, then maintenance is going to be a problem).
>> > >
>> > > If there's 100 random non-contributor votes for one option and 20 pmc
>> > votes
>> > > for another options, I think the real answer will be "we don't have
>> > > consensus, and either we don't do it, or we do it the way the PMC
>> thinks
>> > is
>> > > best", for all of the reasons you describe in the paragraphs below.
>> > >
>> > >
>> > > > If the former, that is a bit weird to me because we simply don't
>> know
>> > who
>> > > > votes. And I don't mean to be rude towards anyone, but 1) someone
>> could
>> > > > easily create 10 email addresses to vote 10 times (and sure, you
>> could
>> > > > invoke trust, and I'm not entirely against trust in general, but
>> it's
>> > the
>> > > > internet...) and 2) this kind of decision will have non-trivial
>> > > > consequences for the project, particularly on those that maintain
>> it,
>> > so
>> > > I
>> > > > admit I'm not entirely comfortable with "anyone's voice has the same
>> > > > weight".
>> > > > If the latter, then this makes more sense to me (why are we even
>> > > bothering
>> > > > voting PMC members in if it's not to handle these kinds of
>> decisions,
>> > > which
>> > > > are very "project management" related), but we should be very clear
>> > about
>> > > > this from the get go (we could still use the dev list for
>> transparency
>> > > > sake, that I don't mind)? We should probably also have some
>> deadline to
>> > > the
>> > > > vote, one that isn't too short.
>> > > >
>> > >
>> > > Like releases, I think PMC votes count
>> > >
>> > >
>> > > >
>> > > > Anyway, fwiw, my opinion on this vote is not far from the one on the
>> > > golang
>> > > > driver acceptance vote (for which my remark above also apply btw):
>> no
>> > yet
>> > > > 100% convinced adding more pieces and scope to the project is what
>> the
>> > > > project needs just right now, but not strongly opposed if people
>> really
>> > > > wants this (and this one makes more sense to me than the golang
>> driver
>> > > > actually). But if I'm to pick between a) and b), I'm leaning b).
>> > > >
>> > >
>> > > FWIW, two of the main reasons I'm in favor is as a way to lower
>> barrier
>> > to
>> > > entry to both using the software AND contributing to the project, so I
>> > > think your points 

Re: [VOTE] Development Approach for Apache Cassandra Management process

2018-09-12 Thread sankalp kohli
The last email on the thread was 3 days ago and I made it clear days back
that we should vote on it to make progress. Without this vote, I am not
sure we will make progress.
Many people want to contribute on this and hence we are voting so we can
make progress.

My vote is d


On Wed, Sep 12, 2018 at 1:36 PM Jonathan Haddad  wrote:

> This voting process feels a bit rushed and frankly not well thought out.
> In addition to Sylvain's valid points, which you (Sankalp) didn't address
> at all, the discussion in the other threads seemed to be ongoing.  The last
> email you wrote on one of them was asking for additional feedback, that
> indicates the discussion is still open.
>
> Out of principal I vote for none of the options (inaction).  You're
> deliberately trying to ram *something* through, and that's not how this is
> supposed to work.
>
> For those of you unfamiliar with the process - please read
> https://www.apache.org/foundation/voting.html.
>
> I'd like to ask those of you that are +1'ing, are you willing to contribute
> or are you just voting we start an admin tool from scratch because you
> think it'll somehow produce a perfect codebase?
>
>
>
>
>
> On Wed, Sep 12, 2018 at 12:50 PM sankalp kohli 
> wrote:
>
> > Hi Sylvain,
> > I would appreciate if we can give feedback on the
> > discussion threads and not wait for vote threads. I made it clear in the
> > discussion thread that we will start a vote!!
> > Thanks,
> > Sankalp
> >
> > On Wed, Sep 12, 2018 at 12:47 PM Jeff Jirsa  wrote:
> >
> > > On Wed, Sep 12, 2018 at 12:41 PM Sylvain Lebresne 
> > > wrote:
> > >
> > > > That's probably a stupid question, and excuse me if it is, but what
> > does
> > > > those votes on the dev mailing list even mean?
> > > >
> > > > How do you count votes at the end? Just by counting all votes cast,
> > > > irregardless of whomever cast it? Or are we intending to only count
> PMC
> > > > members, or maybe committers votes?
> > > >
> > >
> > > I believe the intent is to try to see if there exists consensus.
> > > Ultimately, PMC is going to matter more than random email addresses
> from
> > > people nobody recognizes. This should be in public, though, not
> private,
> > so
> > > seeing what feedback is beyond the PMC is useful (primarily because it
> > will
> > > matter when it comes time to extend and maintain it - if people
> strongly
> > > prefer one or the other, then maintenance is going to be a problem).
> > >
> > > If there's 100 random non-contributor votes for one option and 20 pmc
> > votes
> > > for another options, I think the real answer will be "we don't have
> > > consensus, and either we don't do it, or we do it the way the PMC
> thinks
> > is
> > > best", for all of the reasons you describe in the paragraphs below.
> > >
> > >
> > > > If the former, that is a bit weird to me because we simply don't know
> > who
> > > > votes. And I don't mean to be rude towards anyone, but 1) someone
> could
> > > > easily create 10 email addresses to vote 10 times (and sure, you
> could
> > > > invoke trust, and I'm not entirely against trust in general, but it's
> > the
> > > > internet...) and 2) this kind of decision will have non-trivial
> > > > consequences for the project, particularly on those that maintain it,
> > so
> > > I
> > > > admit I'm not entirely comfortable with "anyone's voice has the same
> > > > weight".
> > > > If the latter, then this makes more sense to me (why are we even
> > > bothering
> > > > voting PMC members in if it's not to handle these kinds of decisions,
> > > which
> > > > are very "project management" related), but we should be very clear
> > about
> > > > this from the get go (we could still use the dev list for
> transparency
> > > > sake, that I don't mind)? We should probably also have some deadline
> to
> > > the
> > > > vote, one that isn't too short.
> > > >
> > >
> > > Like releases, I think PMC votes count
> > >
> > >
> > > >
> > > > Anyway, fwiw, my opinion on this vote is not far from the one on the
> > > golang
> > > > driver acceptance vote (for which my remark above also apply btw): no
> > yet
> > > > 100% convinced adding more pieces and scope to the project is what
> the
> > > > project needs just right now, but not strongly opposed if people
> really
> > > > wants this (and this one makes more sense to me than the golang
> driver
> > > > actually). But if I'm to pick between a) and b), I'm leaning b).
> > > >
> > >
> > > FWIW, two of the main reasons I'm in favor is as a way to lower barrier
> > to
> > > entry to both using the software AND contributing to the project, so I
> > > think your points are valid (both on gocql thread and on this note
> > above),
> > > but I think that's also part of why we should be encouraging both.
> > >
> > > - Jeff
> > >
> >
>
>
> --
> Jon Haddad
> http://www.rustyrazorblade.com
> twitter: rustyrazorblade
>


Re: [VOTE] Development Approach for Apache Cassandra Management process

2018-09-12 Thread Jonathan Haddad
This voting process feels a bit rushed and frankly not well thought out.
In addition to Sylvain's valid points, which you (Sankalp) didn't address
at all, the discussion in the other threads seemed to be ongoing.  The last
email you wrote on one of them was asking for additional feedback, that
indicates the discussion is still open.

Out of principal I vote for none of the options (inaction).  You're
deliberately trying to ram *something* through, and that's not how this is
supposed to work.

For those of you unfamiliar with the process - please read
https://www.apache.org/foundation/voting.html.

I'd like to ask those of you that are +1'ing, are you willing to contribute
or are you just voting we start an admin tool from scratch because you
think it'll somehow produce a perfect codebase?





On Wed, Sep 12, 2018 at 12:50 PM sankalp kohli 
wrote:

> Hi Sylvain,
> I would appreciate if we can give feedback on the
> discussion threads and not wait for vote threads. I made it clear in the
> discussion thread that we will start a vote!!
> Thanks,
> Sankalp
>
> On Wed, Sep 12, 2018 at 12:47 PM Jeff Jirsa  wrote:
>
> > On Wed, Sep 12, 2018 at 12:41 PM Sylvain Lebresne 
> > wrote:
> >
> > > That's probably a stupid question, and excuse me if it is, but what
> does
> > > those votes on the dev mailing list even mean?
> > >
> > > How do you count votes at the end? Just by counting all votes cast,
> > > irregardless of whomever cast it? Or are we intending to only count PMC
> > > members, or maybe committers votes?
> > >
> >
> > I believe the intent is to try to see if there exists consensus.
> > Ultimately, PMC is going to matter more than random email addresses from
> > people nobody recognizes. This should be in public, though, not private,
> so
> > seeing what feedback is beyond the PMC is useful (primarily because it
> will
> > matter when it comes time to extend and maintain it - if people strongly
> > prefer one or the other, then maintenance is going to be a problem).
> >
> > If there's 100 random non-contributor votes for one option and 20 pmc
> votes
> > for another options, I think the real answer will be "we don't have
> > consensus, and either we don't do it, or we do it the way the PMC thinks
> is
> > best", for all of the reasons you describe in the paragraphs below.
> >
> >
> > > If the former, that is a bit weird to me because we simply don't know
> who
> > > votes. And I don't mean to be rude towards anyone, but 1) someone could
> > > easily create 10 email addresses to vote 10 times (and sure, you could
> > > invoke trust, and I'm not entirely against trust in general, but it's
> the
> > > internet...) and 2) this kind of decision will have non-trivial
> > > consequences for the project, particularly on those that maintain it,
> so
> > I
> > > admit I'm not entirely comfortable with "anyone's voice has the same
> > > weight".
> > > If the latter, then this makes more sense to me (why are we even
> > bothering
> > > voting PMC members in if it's not to handle these kinds of decisions,
> > which
> > > are very "project management" related), but we should be very clear
> about
> > > this from the get go (we could still use the dev list for transparency
> > > sake, that I don't mind)? We should probably also have some deadline to
> > the
> > > vote, one that isn't too short.
> > >
> >
> > Like releases, I think PMC votes count
> >
> >
> > >
> > > Anyway, fwiw, my opinion on this vote is not far from the one on the
> > golang
> > > driver acceptance vote (for which my remark above also apply btw): no
> yet
> > > 100% convinced adding more pieces and scope to the project is what the
> > > project needs just right now, but not strongly opposed if people really
> > > wants this (and this one makes more sense to me than the golang driver
> > > actually). But if I'm to pick between a) and b), I'm leaning b).
> > >
> >
> > FWIW, two of the main reasons I'm in favor is as a way to lower barrier
> to
> > entry to both using the software AND contributing to the project, so I
> > think your points are valid (both on gocql thread and on this note
> above),
> > but I think that's also part of why we should be encouraging both.
> >
> > - Jeff
> >
>


-- 
Jon Haddad
http://www.rustyrazorblade.com
twitter: rustyrazorblade


Re: [VOTE] Accept GoCQL driver donation and begin incubation process

2018-09-12 Thread Jeremiah D Jordan
My +1 was under the assumption that the current maintainer wanted to continue 
with the project and would be brought in to do that along with the code.

But my +1 also has no meaning in the ASF meritocracy as I am neither a 
committer or a PMC member ;).  It just expresses my opinion as a long standing 
member of the community that I think it is fine to bring the current GoCQL 
driver and its main contributors into the Apache Cassandra project.  I was not 
asking others to do the work, I was assuming the current people doing the work 
on said driver would continue to work on it.

-Jeremiah

> On Sep 12, 2018, at 12:55 PM, Jonathan Haddad  wrote:
> 
> I'm +0, and I share the same concerns as Sylvain.
> 
> For those of you that have +1'ed, are you planning on contributing to the
> driver?  Docs, code, QA?  It's easy to throw a +1 down to make the driver
> the responsibility of the project if you're asking others to do the work.
> I vote this way because I already know I won't contribute to it and it's
> irresponsible to vote something in if I have no intent on helping maintain
> it.
> 
> On Wed, Sep 12, 2018 at 10:45 AM Sumanth Pasupuleti
>  wrote:
> 
>> +1
>> 
>> On Wed, Sep 12, 2018 at 10:37 AM Dinesh Joshi
>>  wrote:
>> 
>>> +1
>>> 
>>> Dinesh
>>> 
 On Sep 12, 2018, at 10:23 AM, Jaydeep Chovatia <
>>> chovatia.jayd...@gmail.com> wrote:
 
 +1
 
 On Wed, Sep 12, 2018 at 10:00 AM Roopa Tangirala
  wrote:
 
> +1
> 
> 
> *Regards,*
> 
> *Roopa Tangirala*
> 
> Engineering Manager CDE
> 
> *(408) 438-3156 - mobile*
> 
> 
> 
> 
> 
> 
> On Wed, Sep 12, 2018 at 8:51 AM Sylvain Lebresne 
> wrote:
> 
>> -0
>> 
>> The project seems to have a hard time getting on top of reviewing his
>> backlog
>> of 'patch available' issues, so that I'm skeptical adopting more code
>>> to
>> maintain is the thing the project needs the most right now. Besides,
>>> I'm
>> also
>> generally skeptical that augmenting the scope of a project makes it
> better:
>> I feel
>> keeping this project focused on the core server is better. I see
>> risks
>> here, but
>> the upsides haven't been made very clear for me, even for end users:
>>> yes,
>> it
>> may provide a tiny bit more clarity around which Golang driver to
>>> choose
> by
>> default, but I'm not sure users are that lost, and I think there is
>>> other
>> ways to
>> solve that if we really want.
>> 
>> Anyway, I reckon I may be overly pessimistic here and it's not that
> strong
>> of
>> an objection if a large majority is on-board, so giving my opinion
>> but
> not
>> opposing.
>> 
>> --
>> Sylvain
>> 
>> 
>> On Wed, Sep 12, 2018 at 5:36 PM Jeremiah D Jordan <
>> jeremiah.jor...@gmail.com>
>> wrote:
>> 
>>> +1
>>> 
>>> But I also think getting this through incubation might take a
>> while/be
>>> impossible given how large the contributor list looks…
>>> 
 On Sep 12, 2018, at 10:22 AM, Jeff Jirsa  wrote:
 
 +1
 
 (Incubation looks like it may be challenging to get acceptance from
> all
>>> existing contributors, though)
 
 --
 Jeff Jirsa
 
 
> On Sep 12, 2018, at 8:12 AM, Nate McCall 
> wrote:
> 
> This will be the same process used for dtest. We will need to walk
> this through the incubator per the process outlined here:
> 
> 
>>> 
>> 
> 
>>> 
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__incubator.apache.org_guides_ip-5Fclearance.html&d=DwIFAg&c=adz96Xi0w1RHqtPMowiL2g&r=CNZK3RiJDLqhsZDG6FQGnXn8WyPRCQhp4x_uBICNC0g&m=g-MlYFZVJ7j5Dj_ZfPfa0Ik8Nxco7QsJhTG1TnJH7xI&s=rk5T_t1HZY6PAhN5XgflBhfEtNrcZkVTIvQxixDlw9o&e=
> 
> Pending the outcome of this vote, we will create the JIRA issues
>> for
> tracking and after we go through the process, and discuss adding
> committers in a separate thread (we need to do this atomically
> anyway
> per general ASF committer adding processes).
> 
> Thanks,
> -Nate
> 
> 
> -
> 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.

Re: [VOTE] Accept GoCQL driver donation and begin incubation process

2018-09-12 Thread Jeremiah D Jordan
No, doesn’t change it.  Any code donation has to go through the incubation 
process, which is where all the legal stuff about it being donated is handled.  
This would be like the dtest repo which was donated a little while back, and 
followed this same process.

-Jeremiah

> On Sep 12, 2018, at 3:05 PM, kurt greaves  wrote:
> 
> In the previous thread we seemed to come to the conclusion it would be
> under the same project with same committers/pmc. I don't know if sending it
> through incubation changes that?
> 
> On Wed., 12 Sep. 2018, 13:03 Jeremy Hanna, 
> wrote:
> 
>> I don’t know if others have this same question, but what does accepting
>> the gocql driver donation mean?  It becomes a full Apache project separate
>> from Cassandra and there exists a separate set of PMC members and such?  Or
>> does it become part of the Cassandra project itself?  From Sylvain and
>> Jon’s responses, it seems like it’s the latter.  I have some memories of
>> the Apache Extras and some things that lived in there for a time and those
>> were eventually phased out so I didn’t know if that applied to this
>> discussion as well.
>> 
>>> On Sep 12, 2018, at 10:12 AM, Nate McCall  wrote:
>>> 
>>> This will be the same process used for dtest. We will need to walk
>>> this through the incubator per the process outlined here:
>>> 
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__incubator.apache.org_guides_ip-5Fclearance.html&d=DwIFaQ&c=adz96Xi0w1RHqtPMowiL2g&r=CNZK3RiJDLqhsZDG6FQGnXn8WyPRCQhp4x_uBICNC0g&m=4y7Q74EaQxyVFLgnLFlWg-O71SM3eibG4Z0uQTS2Pr4&s=iDEkpoH0oy1goQ_ohPa05DdMdH_zbEztl_-EfMzs-Gc&e=
>>> 
>>> Pending the outcome of this vote, we will create the JIRA issues for
>>> tracking and after we go through the process, and discuss adding
>>> committers in a separate thread (we need to do this atomically anyway
>>> per general ASF committer adding processes).
>>> 
>>> Thanks,
>>> -Nate
>>> 
>>> -
>>> 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: [VOTE] Accept GoCQL driver donation and begin incubation process

2018-09-12 Thread kurt greaves
In the previous thread we seemed to come to the conclusion it would be
under the same project with same committers/pmc. I don't know if sending it
through incubation changes that?

On Wed., 12 Sep. 2018, 13:03 Jeremy Hanna, 
wrote:

> I don’t know if others have this same question, but what does accepting
> the gocql driver donation mean?  It becomes a full Apache project separate
> from Cassandra and there exists a separate set of PMC members and such?  Or
> does it become part of the Cassandra project itself?  From Sylvain and
> Jon’s responses, it seems like it’s the latter.  I have some memories of
> the Apache Extras and some things that lived in there for a time and those
> were eventually phased out so I didn’t know if that applied to this
> discussion as well.
>
> > On Sep 12, 2018, at 10:12 AM, Nate McCall  wrote:
> >
> > This will be the same process used for dtest. We will need to walk
> > this through the incubator per the process outlined here:
> >
> > https://incubator.apache.org/guides/ip_clearance.html
> >
> > Pending the outcome of this vote, we will create the JIRA issues for
> > tracking and after we go through the process, and discuss adding
> > committers in a separate thread (we need to do this atomically anyway
> > per general ASF committer adding processes).
> >
> > Thanks,
> > -Nate
> >
> > -
> > 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] Accept GoCQL driver donation and begin incubation process

2018-09-12 Thread kurt greaves
+1. I do share the same concerns as Sylvain, but I think it's important we
get more driver experience/exposure in the project, as it seems lacking
since datastax moved off, and I don't think this will be something we can
just leave to the userbase to solve.

I'm definitely looking to contribute as well.

On Wed., 12 Sep. 2018, 12:48 Ben Bromhead,  wrote:

> +1
>
> On Wed, Sep 12, 2018 at 1:55 PM Jonathan Haddad  wrote:
>
> > I'm +0, and I share the same concerns as Sylvain.
> >
> > For those of you that have +1'ed, are you planning on contributing to the
> > driver?  Docs, code, QA?  It's easy to throw a +1 down to make the driver
> > the responsibility of the project if you're asking others to do the work.
> > I vote this way because I already know I won't contribute to it and it's
> > irresponsible to vote something in if I have no intent on helping
> maintain
> > it.
> >
> > On Wed, Sep 12, 2018 at 10:45 AM Sumanth Pasupuleti
> >  wrote:
> >
> > > +1
> > >
> > > On Wed, Sep 12, 2018 at 10:37 AM Dinesh Joshi
> > >  wrote:
> > >
> > > > +1
> > > >
> > > > Dinesh
> > > >
> > > > > On Sep 12, 2018, at 10:23 AM, Jaydeep Chovatia <
> > > > chovatia.jayd...@gmail.com> wrote:
> > > > >
> > > > > +1
> > > > >
> > > > > On Wed, Sep 12, 2018 at 10:00 AM Roopa Tangirala
> > > > >  wrote:
> > > > >
> > > > >> +1
> > > > >>
> > > > >>
> > > > >> *Regards,*
> > > > >>
> > > > >> *Roopa Tangirala*
> > > > >>
> > > > >> Engineering Manager CDE
> > > > >>
> > > > >> *(408) 438-3156 - mobile*
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >> On Wed, Sep 12, 2018 at 8:51 AM Sylvain Lebresne <
> > lebre...@gmail.com>
> > > > >> wrote:
> > > > >>
> > > > >>> -0
> > > > >>>
> > > > >>> The project seems to have a hard time getting on top of reviewing
> > his
> > > > >>> backlog
> > > > >>> of 'patch available' issues, so that I'm skeptical adopting more
> > code
> > > > to
> > > > >>> maintain is the thing the project needs the most right now.
> > Besides,
> > > > I'm
> > > > >>> also
> > > > >>> generally skeptical that augmenting the scope of a project makes
> it
> > > > >> better:
> > > > >>> I feel
> > > > >>> keeping this project focused on the core server is better. I see
> > > risks
> > > > >>> here, but
> > > > >>> the upsides haven't been made very clear for me, even for end
> > users:
> > > > yes,
> > > > >>> it
> > > > >>> may provide a tiny bit more clarity around which Golang driver to
> > > > choose
> > > > >> by
> > > > >>> default, but I'm not sure users are that lost, and I think there
> is
> > > > other
> > > > >>> ways to
> > > > >>> solve that if we really want.
> > > > >>>
> > > > >>> Anyway, I reckon I may be overly pessimistic here and it's not
> that
> > > > >> strong
> > > > >>> of
> > > > >>> an objection if a large majority is on-board, so giving my
> opinion
> > > but
> > > > >> not
> > > > >>> opposing.
> > > > >>>
> > > > >>> --
> > > > >>> Sylvain
> > > > >>>
> > > > >>>
> > > > >>> On Wed, Sep 12, 2018 at 5:36 PM Jeremiah D Jordan <
> > > > >>> jeremiah.jor...@gmail.com>
> > > > >>> wrote:
> > > > >>>
> > > >  +1
> > > > 
> > > >  But I also think getting this through incubation might take a
> > > while/be
> > > >  impossible given how large the contributor list looks…
> > > > 
> > > > > On Sep 12, 2018, at 10:22 AM, Jeff Jirsa 
> > wrote:
> > > > >
> > > > > +1
> > > > >
> > > > > (Incubation looks like it may be challenging to get acceptance
> > from
> > > > >> all
> > > >  existing contributors, though)
> > > > >
> > > > > --
> > > > > Jeff Jirsa
> > > > >
> > > > >
> > > > >> On Sep 12, 2018, at 8:12 AM, Nate McCall 
> > > > >> wrote:
> > > > >>
> > > > >> This will be the same process used for dtest. We will need to
> > walk
> > > > >> this through the incubator per the process outlined here:
> > > > >>
> > > > >>
> > > > 
> > > > >>>
> > > > >>
> > > >
> > >
> >
> https://urldefense.proofpoint.com/v2/url?u=https-3A__incubator.apache.org_guides_ip-5Fclearance.html&d=DwIFAg&c=adz96Xi0w1RHqtPMowiL2g&r=CNZK3RiJDLqhsZDG6FQGnXn8WyPRCQhp4x_uBICNC0g&m=g-MlYFZVJ7j5Dj_ZfPfa0Ik8Nxco7QsJhTG1TnJH7xI&s=rk5T_t1HZY6PAhN5XgflBhfEtNrcZkVTIvQxixDlw9o&e=
> > > > >>
> > > > >> Pending the outcome of this vote, we will create the JIRA
> issues
> > > for
> > > > >> tracking and after we go through the process, and discuss
> adding
> > > > >> committers in a separate thread (we need to do this atomically
> > > > >> anyway
> > > > >> per general ASF committer adding processes).
> > > > >>
> > > > >> Thanks,
> > > > >> -Nate
> > > > >>
> > > > >>
> > > > >>
> > -
> > > > >> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > > > >> For additional commands, e-mail:
> dev-h...@cassandra.apache.org
> > > > >>
> > > > >
> > > > >
> > > ---

Re: [VOTE] Accept GoCQL driver donation and begin incubation process

2018-09-12 Thread Jeremy Hanna
I don’t know if others have this same question, but what does accepting the 
gocql driver donation mean?  It becomes a full Apache project separate from 
Cassandra and there exists a separate set of PMC members and such?  Or does it 
become part of the Cassandra project itself?  From Sylvain and Jon’s responses, 
it seems like it’s the latter.  I have some memories of the Apache Extras and 
some things that lived in there for a time and those were eventually phased out 
so I didn’t know if that applied to this discussion as well.

> On Sep 12, 2018, at 10:12 AM, Nate McCall  wrote:
> 
> This will be the same process used for dtest. We will need to walk
> this through the incubator per the process outlined here:
> 
> https://incubator.apache.org/guides/ip_clearance.html
> 
> Pending the outcome of this vote, we will create the JIRA issues for
> tracking and after we go through the process, and discuss adding
> committers in a separate thread (we need to do this atomically anyway
> per general ASF committer adding processes).
> 
> Thanks,
> -Nate
> 
> -
> 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] Development Approach for Apache Cassandra Management process

2018-09-12 Thread sankalp kohli
Hi Sylvain,
I would appreciate if we can give feedback on the
discussion threads and not wait for vote threads. I made it clear in the
discussion thread that we will start a vote!!
Thanks,
Sankalp

On Wed, Sep 12, 2018 at 12:47 PM Jeff Jirsa  wrote:

> On Wed, Sep 12, 2018 at 12:41 PM Sylvain Lebresne 
> wrote:
>
> > That's probably a stupid question, and excuse me if it is, but what does
> > those votes on the dev mailing list even mean?
> >
> > How do you count votes at the end? Just by counting all votes cast,
> > irregardless of whomever cast it? Or are we intending to only count PMC
> > members, or maybe committers votes?
> >
>
> I believe the intent is to try to see if there exists consensus.
> Ultimately, PMC is going to matter more than random email addresses from
> people nobody recognizes. This should be in public, though, not private, so
> seeing what feedback is beyond the PMC is useful (primarily because it will
> matter when it comes time to extend and maintain it - if people strongly
> prefer one or the other, then maintenance is going to be a problem).
>
> If there's 100 random non-contributor votes for one option and 20 pmc votes
> for another options, I think the real answer will be "we don't have
> consensus, and either we don't do it, or we do it the way the PMC thinks is
> best", for all of the reasons you describe in the paragraphs below.
>
>
> > If the former, that is a bit weird to me because we simply don't know who
> > votes. And I don't mean to be rude towards anyone, but 1) someone could
> > easily create 10 email addresses to vote 10 times (and sure, you could
> > invoke trust, and I'm not entirely against trust in general, but it's the
> > internet...) and 2) this kind of decision will have non-trivial
> > consequences for the project, particularly on those that maintain it, so
> I
> > admit I'm not entirely comfortable with "anyone's voice has the same
> > weight".
> > If the latter, then this makes more sense to me (why are we even
> bothering
> > voting PMC members in if it's not to handle these kinds of decisions,
> which
> > are very "project management" related), but we should be very clear about
> > this from the get go (we could still use the dev list for transparency
> > sake, that I don't mind)? We should probably also have some deadline to
> the
> > vote, one that isn't too short.
> >
>
> Like releases, I think PMC votes count
>
>
> >
> > Anyway, fwiw, my opinion on this vote is not far from the one on the
> golang
> > driver acceptance vote (for which my remark above also apply btw): no yet
> > 100% convinced adding more pieces and scope to the project is what the
> > project needs just right now, but not strongly opposed if people really
> > wants this (and this one makes more sense to me than the golang driver
> > actually). But if I'm to pick between a) and b), I'm leaning b).
> >
>
> FWIW, two of the main reasons I'm in favor is as a way to lower barrier to
> entry to both using the software AND contributing to the project, so I
> think your points are valid (both on gocql thread and on this note above),
> but I think that's also part of why we should be encouraging both.
>
> - Jeff
>


Re: [VOTE] Accept GoCQL driver donation and begin incubation process

2018-09-12 Thread Ben Bromhead
+1

On Wed, Sep 12, 2018 at 1:55 PM Jonathan Haddad  wrote:

> I'm +0, and I share the same concerns as Sylvain.
>
> For those of you that have +1'ed, are you planning on contributing to the
> driver?  Docs, code, QA?  It's easy to throw a +1 down to make the driver
> the responsibility of the project if you're asking others to do the work.
> I vote this way because I already know I won't contribute to it and it's
> irresponsible to vote something in if I have no intent on helping maintain
> it.
>
> On Wed, Sep 12, 2018 at 10:45 AM Sumanth Pasupuleti
>  wrote:
>
> > +1
> >
> > On Wed, Sep 12, 2018 at 10:37 AM Dinesh Joshi
> >  wrote:
> >
> > > +1
> > >
> > > Dinesh
> > >
> > > > On Sep 12, 2018, at 10:23 AM, Jaydeep Chovatia <
> > > chovatia.jayd...@gmail.com> wrote:
> > > >
> > > > +1
> > > >
> > > > On Wed, Sep 12, 2018 at 10:00 AM Roopa Tangirala
> > > >  wrote:
> > > >
> > > >> +1
> > > >>
> > > >>
> > > >> *Regards,*
> > > >>
> > > >> *Roopa Tangirala*
> > > >>
> > > >> Engineering Manager CDE
> > > >>
> > > >> *(408) 438-3156 - mobile*
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >> On Wed, Sep 12, 2018 at 8:51 AM Sylvain Lebresne <
> lebre...@gmail.com>
> > > >> wrote:
> > > >>
> > > >>> -0
> > > >>>
> > > >>> The project seems to have a hard time getting on top of reviewing
> his
> > > >>> backlog
> > > >>> of 'patch available' issues, so that I'm skeptical adopting more
> code
> > > to
> > > >>> maintain is the thing the project needs the most right now.
> Besides,
> > > I'm
> > > >>> also
> > > >>> generally skeptical that augmenting the scope of a project makes it
> > > >> better:
> > > >>> I feel
> > > >>> keeping this project focused on the core server is better. I see
> > risks
> > > >>> here, but
> > > >>> the upsides haven't been made very clear for me, even for end
> users:
> > > yes,
> > > >>> it
> > > >>> may provide a tiny bit more clarity around which Golang driver to
> > > choose
> > > >> by
> > > >>> default, but I'm not sure users are that lost, and I think there is
> > > other
> > > >>> ways to
> > > >>> solve that if we really want.
> > > >>>
> > > >>> Anyway, I reckon I may be overly pessimistic here and it's not that
> > > >> strong
> > > >>> of
> > > >>> an objection if a large majority is on-board, so giving my opinion
> > but
> > > >> not
> > > >>> opposing.
> > > >>>
> > > >>> --
> > > >>> Sylvain
> > > >>>
> > > >>>
> > > >>> On Wed, Sep 12, 2018 at 5:36 PM Jeremiah D Jordan <
> > > >>> jeremiah.jor...@gmail.com>
> > > >>> wrote:
> > > >>>
> > >  +1
> > > 
> > >  But I also think getting this through incubation might take a
> > while/be
> > >  impossible given how large the contributor list looks…
> > > 
> > > > On Sep 12, 2018, at 10:22 AM, Jeff Jirsa 
> wrote:
> > > >
> > > > +1
> > > >
> > > > (Incubation looks like it may be challenging to get acceptance
> from
> > > >> all
> > >  existing contributors, though)
> > > >
> > > > --
> > > > Jeff Jirsa
> > > >
> > > >
> > > >> On Sep 12, 2018, at 8:12 AM, Nate McCall 
> > > >> wrote:
> > > >>
> > > >> This will be the same process used for dtest. We will need to
> walk
> > > >> this through the incubator per the process outlined here:
> > > >>
> > > >>
> > > 
> > > >>>
> > > >>
> > >
> >
> https://urldefense.proofpoint.com/v2/url?u=https-3A__incubator.apache.org_guides_ip-5Fclearance.html&d=DwIFAg&c=adz96Xi0w1RHqtPMowiL2g&r=CNZK3RiJDLqhsZDG6FQGnXn8WyPRCQhp4x_uBICNC0g&m=g-MlYFZVJ7j5Dj_ZfPfa0Ik8Nxco7QsJhTG1TnJH7xI&s=rk5T_t1HZY6PAhN5XgflBhfEtNrcZkVTIvQxixDlw9o&e=
> > > >>
> > > >> Pending the outcome of this vote, we will create the JIRA issues
> > for
> > > >> tracking and after we go through the process, and discuss adding
> > > >> committers in a separate thread (we need to do this atomically
> > > >> anyway
> > > >> per general ASF committer adding processes).
> > > >>
> > > >> Thanks,
> > > >> -Nate
> > > >>
> > > >>
> > > >>
> -
> > > >> 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
> > > 
> > > 
> > > >>>
> > > >>
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > > For additional command

Re: [VOTE] Development Approach for Apache Cassandra Management process

2018-09-12 Thread Jeff Jirsa
On Wed, Sep 12, 2018 at 12:41 PM Sylvain Lebresne 
wrote:

> That's probably a stupid question, and excuse me if it is, but what does
> those votes on the dev mailing list even mean?
>
> How do you count votes at the end? Just by counting all votes cast,
> irregardless of whomever cast it? Or are we intending to only count PMC
> members, or maybe committers votes?
>

I believe the intent is to try to see if there exists consensus.
Ultimately, PMC is going to matter more than random email addresses from
people nobody recognizes. This should be in public, though, not private, so
seeing what feedback is beyond the PMC is useful (primarily because it will
matter when it comes time to extend and maintain it - if people strongly
prefer one or the other, then maintenance is going to be a problem).

If there's 100 random non-contributor votes for one option and 20 pmc votes
for another options, I think the real answer will be "we don't have
consensus, and either we don't do it, or we do it the way the PMC thinks is
best", for all of the reasons you describe in the paragraphs below.


> If the former, that is a bit weird to me because we simply don't know who
> votes. And I don't mean to be rude towards anyone, but 1) someone could
> easily create 10 email addresses to vote 10 times (and sure, you could
> invoke trust, and I'm not entirely against trust in general, but it's the
> internet...) and 2) this kind of decision will have non-trivial
> consequences for the project, particularly on those that maintain it, so I
> admit I'm not entirely comfortable with "anyone's voice has the same
> weight".
> If the latter, then this makes more sense to me (why are we even bothering
> voting PMC members in if it's not to handle these kinds of decisions, which
> are very "project management" related), but we should be very clear about
> this from the get go (we could still use the dev list for transparency
> sake, that I don't mind)? We should probably also have some deadline to the
> vote, one that isn't too short.
>

Like releases, I think PMC votes count


>
> Anyway, fwiw, my opinion on this vote is not far from the one on the golang
> driver acceptance vote (for which my remark above also apply btw): no yet
> 100% convinced adding more pieces and scope to the project is what the
> project needs just right now, but not strongly opposed if people really
> wants this (and this one makes more sense to me than the golang driver
> actually). But if I'm to pick between a) and b), I'm leaning b).
>

FWIW, two of the main reasons I'm in favor is as a way to lower barrier to
entry to both using the software AND contributing to the project, so I
think your points are valid (both on gocql thread and on this note above),
but I think that's also part of why we should be encouraging both.

- Jeff


Re: [VOTE] Development Approach for Apache Cassandra Management process

2018-09-12 Thread Sylvain Lebresne
That's probably a stupid question, and excuse me if it is, but what does
those votes on the dev mailing list even mean?

How do you count votes at the end? Just by counting all votes cast,
irregardless of whomever cast it? Or are we intending to only count PMC
members, or maybe committers votes?
If the former, that is a bit weird to me because we simply don't know who
votes. And I don't mean to be rude towards anyone, but 1) someone could
easily create 10 email addresses to vote 10 times (and sure, you could
invoke trust, and I'm not entirely against trust in general, but it's the
internet...) and 2) this kind of decision will have non-trivial
consequences for the project, particularly on those that maintain it, so I
admit I'm not entirely comfortable with "anyone's voice has the same
weight".
If the latter, then this makes more sense to me (why are we even bothering
voting PMC members in if it's not to handle these kinds of decisions, which
are very "project management" related), but we should be very clear about
this from the get go (we could still use the dev list for transparency
sake, that I don't mind)? We should probably also have some deadline to the
vote, one that isn't too short.

Anyway, fwiw, my opinion on this vote is not far from the one on the golang
driver acceptance vote (for which my remark above also apply btw): no yet
100% convinced adding more pieces and scope to the project is what the
project needs just right now, but not strongly opposed if people really
wants this (and this one makes more sense to me than the golang driver
actually). But if I'm to pick between a) and b), I'm leaning b).

--
Sylvain


On Wed, Sep 12, 2018 at 8:45 PM Joseph Lynch  wrote:

> +1 for piecemeal (option b).
>
> I think I've explained my opinion on all the various threads and tickets.
>
> -Joey
> On Wed, Sep 12, 2018 at 10:48 AM Vinay Chella 
> wrote:
> >
> > +1 for option b, considering the advantages mentioned in dev email thread
> > that Sankalp linked.
> >
> > ~Vinay
> >
> >
> > On Wed, Sep 12, 2018 at 10:36 AM Dinesh Joshi
> >  wrote:
> >
> > > +1 for piecemeal (option b)
> > >
> > > Dinesh
> > >
> > > > On Sep 12, 2018, at 8:18 AM, sankalp kohli 
> > > wrote:
> > > >
> > > > Hi,
> > > >Community has been discussing about Apache Cassandra Management
> > > process
> > > > since April and we had lot of discussion about which approach to
> take to
> > > > get started. Several contributors have been interested in doing this
> and
> > > we
> > > > need to make a decision of which approach to take.
> > > >
> > > > The current approaches being evaluated are
> > > > a. Donate an existing project to Apache Cassandra like Reaper. If
> this
> > > > option is selected, we will evaluate various projects and see which
> one
> > > > fits best.
> > > > b. Take a piecemeal approach and use the features from different OSS
> > > > projects and build a new project.
> > > >
> > > > Available options to vote
> > > > a. +1 to use existing project.
> > > > b. +1 to take piecemeal approach
> > > > c  -1 to both
> > > > d +0 I dont mind either option
> > > >
> > > > You can also just type a,b,c,d as well to chose an option.
> > > >
> > > > Dev threads with discussions
> > > >
> > > >
> > >
> https://lists.apache.org/thread.html/4eace8cb258aab83fc3a220ff2203a281ea59f4d6557ebeb1af7b7f1@%3Cdev.cassandra.apache.org%3E
> > > >
> > > >
> > >
> https://lists.apache.org/thread.html/4a7e608c46aa2256e8bcb696104a4e6d6aaa1f302834d211018ec96e@%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] Development Approach for Apache Cassandra Management process

2018-09-12 Thread Jeff Jirsa
d - good with either option, but would probably slightly prefer b, as it
can be build towards the design doc.



On Wed, Sep 12, 2018 at 8:19 AM sankalp kohli 
wrote:

> Hi,
> Community has been discussing about Apache Cassandra Management process
> since April and we had lot of discussion about which approach to take to
> get started. Several contributors have been interested in doing this and we
> need to make a decision of which approach to take.
>
> The current approaches being evaluated are
> a. Donate an existing project to Apache Cassandra like Reaper. If this
> option is selected, we will evaluate various projects and see which one
> fits best.
> b. Take a piecemeal approach and use the features from different OSS
> projects and build a new project.
>
> Available options to vote
> a. +1 to use existing project.
> b. +1 to take piecemeal approach
> c  -1 to both
> d +0 I dont mind either option
>
> You can also just type a,b,c,d as well to chose an option.
>
> Dev threads with discussions
>
>
> https://lists.apache.org/thread.html/4eace8cb258aab83fc3a220ff2203a281ea59f4d6557ebeb1af7b7f1@%3Cdev.cassandra.apache.org%3E
>
>
> https://lists.apache.org/thread.html/4a7e608c46aa2256e8bcb696104a4e6d6aaa1f302834d211018ec96e@%3Cdev.cassandra.apache.org%3E
>


Re: [VOTE] Development Approach for Apache Cassandra Management process

2018-09-12 Thread Joseph Lynch
+1 for piecemeal (option b).

I think I've explained my opinion on all the various threads and tickets.

-Joey
On Wed, Sep 12, 2018 at 10:48 AM Vinay Chella  wrote:
>
> +1 for option b, considering the advantages mentioned in dev email thread
> that Sankalp linked.
>
> ~Vinay
>
>
> On Wed, Sep 12, 2018 at 10:36 AM Dinesh Joshi
>  wrote:
>
> > +1 for piecemeal (option b)
> >
> > Dinesh
> >
> > > On Sep 12, 2018, at 8:18 AM, sankalp kohli 
> > wrote:
> > >
> > > Hi,
> > >Community has been discussing about Apache Cassandra Management
> > process
> > > since April and we had lot of discussion about which approach to take to
> > > get started. Several contributors have been interested in doing this and
> > we
> > > need to make a decision of which approach to take.
> > >
> > > The current approaches being evaluated are
> > > a. Donate an existing project to Apache Cassandra like Reaper. If this
> > > option is selected, we will evaluate various projects and see which one
> > > fits best.
> > > b. Take a piecemeal approach and use the features from different OSS
> > > projects and build a new project.
> > >
> > > Available options to vote
> > > a. +1 to use existing project.
> > > b. +1 to take piecemeal approach
> > > c  -1 to both
> > > d +0 I dont mind either option
> > >
> > > You can also just type a,b,c,d as well to chose an option.
> > >
> > > Dev threads with discussions
> > >
> > >
> > https://lists.apache.org/thread.html/4eace8cb258aab83fc3a220ff2203a281ea59f4d6557ebeb1af7b7f1@%3Cdev.cassandra.apache.org%3E
> > >
> > >
> > https://lists.apache.org/thread.html/4a7e608c46aa2256e8bcb696104a4e6d6aaa1f302834d211018ec96e@%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] Accept GoCQL driver donation and begin incubation process

2018-09-12 Thread Jonathan Haddad
I'm +0, and I share the same concerns as Sylvain.

For those of you that have +1'ed, are you planning on contributing to the
driver?  Docs, code, QA?  It's easy to throw a +1 down to make the driver
the responsibility of the project if you're asking others to do the work.
I vote this way because I already know I won't contribute to it and it's
irresponsible to vote something in if I have no intent on helping maintain
it.

On Wed, Sep 12, 2018 at 10:45 AM Sumanth Pasupuleti
 wrote:

> +1
>
> On Wed, Sep 12, 2018 at 10:37 AM Dinesh Joshi
>  wrote:
>
> > +1
> >
> > Dinesh
> >
> > > On Sep 12, 2018, at 10:23 AM, Jaydeep Chovatia <
> > chovatia.jayd...@gmail.com> wrote:
> > >
> > > +1
> > >
> > > On Wed, Sep 12, 2018 at 10:00 AM Roopa Tangirala
> > >  wrote:
> > >
> > >> +1
> > >>
> > >>
> > >> *Regards,*
> > >>
> > >> *Roopa Tangirala*
> > >>
> > >> Engineering Manager CDE
> > >>
> > >> *(408) 438-3156 - mobile*
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> On Wed, Sep 12, 2018 at 8:51 AM Sylvain Lebresne 
> > >> wrote:
> > >>
> > >>> -0
> > >>>
> > >>> The project seems to have a hard time getting on top of reviewing his
> > >>> backlog
> > >>> of 'patch available' issues, so that I'm skeptical adopting more code
> > to
> > >>> maintain is the thing the project needs the most right now. Besides,
> > I'm
> > >>> also
> > >>> generally skeptical that augmenting the scope of a project makes it
> > >> better:
> > >>> I feel
> > >>> keeping this project focused on the core server is better. I see
> risks
> > >>> here, but
> > >>> the upsides haven't been made very clear for me, even for end users:
> > yes,
> > >>> it
> > >>> may provide a tiny bit more clarity around which Golang driver to
> > choose
> > >> by
> > >>> default, but I'm not sure users are that lost, and I think there is
> > other
> > >>> ways to
> > >>> solve that if we really want.
> > >>>
> > >>> Anyway, I reckon I may be overly pessimistic here and it's not that
> > >> strong
> > >>> of
> > >>> an objection if a large majority is on-board, so giving my opinion
> but
> > >> not
> > >>> opposing.
> > >>>
> > >>> --
> > >>> Sylvain
> > >>>
> > >>>
> > >>> On Wed, Sep 12, 2018 at 5:36 PM Jeremiah D Jordan <
> > >>> jeremiah.jor...@gmail.com>
> > >>> wrote:
> > >>>
> >  +1
> > 
> >  But I also think getting this through incubation might take a
> while/be
> >  impossible given how large the contributor list looks…
> > 
> > > On Sep 12, 2018, at 10:22 AM, Jeff Jirsa  wrote:
> > >
> > > +1
> > >
> > > (Incubation looks like it may be challenging to get acceptance from
> > >> all
> >  existing contributors, though)
> > >
> > > --
> > > Jeff Jirsa
> > >
> > >
> > >> On Sep 12, 2018, at 8:12 AM, Nate McCall 
> > >> wrote:
> > >>
> > >> This will be the same process used for dtest. We will need to walk
> > >> this through the incubator per the process outlined here:
> > >>
> > >>
> > 
> > >>>
> > >>
> >
> https://urldefense.proofpoint.com/v2/url?u=https-3A__incubator.apache.org_guides_ip-5Fclearance.html&d=DwIFAg&c=adz96Xi0w1RHqtPMowiL2g&r=CNZK3RiJDLqhsZDG6FQGnXn8WyPRCQhp4x_uBICNC0g&m=g-MlYFZVJ7j5Dj_ZfPfa0Ik8Nxco7QsJhTG1TnJH7xI&s=rk5T_t1HZY6PAhN5XgflBhfEtNrcZkVTIvQxixDlw9o&e=
> > >>
> > >> Pending the outcome of this vote, we will create the JIRA issues
> for
> > >> tracking and after we go through the process, and discuss adding
> > >> committers in a separate thread (we need to do this atomically
> > >> anyway
> > >> per general ASF committer adding processes).
> > >>
> > >> Thanks,
> > >> -Nate
> > >>
> > >>
> > >> -
> > >> 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
> > 
> > 
> > >>>
> > >>
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> >
>


-- 
Jon Haddad
http://www.rustyrazorblade.com
twitter: rustyrazorblade


Re: [VOTE] Development Approach for Apache Cassandra Management process

2018-09-12 Thread Vinay Chella
+1 for option b, considering the advantages mentioned in dev email thread
that Sankalp linked.

~Vinay


On Wed, Sep 12, 2018 at 10:36 AM Dinesh Joshi
 wrote:

> +1 for piecemeal (option b)
>
> Dinesh
>
> > On Sep 12, 2018, at 8:18 AM, sankalp kohli 
> wrote:
> >
> > Hi,
> >Community has been discussing about Apache Cassandra Management
> process
> > since April and we had lot of discussion about which approach to take to
> > get started. Several contributors have been interested in doing this and
> we
> > need to make a decision of which approach to take.
> >
> > The current approaches being evaluated are
> > a. Donate an existing project to Apache Cassandra like Reaper. If this
> > option is selected, we will evaluate various projects and see which one
> > fits best.
> > b. Take a piecemeal approach and use the features from different OSS
> > projects and build a new project.
> >
> > Available options to vote
> > a. +1 to use existing project.
> > b. +1 to take piecemeal approach
> > c  -1 to both
> > d +0 I dont mind either option
> >
> > You can also just type a,b,c,d as well to chose an option.
> >
> > Dev threads with discussions
> >
> >
> https://lists.apache.org/thread.html/4eace8cb258aab83fc3a220ff2203a281ea59f4d6557ebeb1af7b7f1@%3Cdev.cassandra.apache.org%3E
> >
> >
> https://lists.apache.org/thread.html/4a7e608c46aa2256e8bcb696104a4e6d6aaa1f302834d211018ec96e@%3Cdev.cassandra.apache.org%3E
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>


Re: [VOTE] Accept GoCQL driver donation and begin incubation process

2018-09-12 Thread Sumanth Pasupuleti
+1

On Wed, Sep 12, 2018 at 10:37 AM Dinesh Joshi
 wrote:

> +1
>
> Dinesh
>
> > On Sep 12, 2018, at 10:23 AM, Jaydeep Chovatia <
> chovatia.jayd...@gmail.com> wrote:
> >
> > +1
> >
> > On Wed, Sep 12, 2018 at 10:00 AM Roopa Tangirala
> >  wrote:
> >
> >> +1
> >>
> >>
> >> *Regards,*
> >>
> >> *Roopa Tangirala*
> >>
> >> Engineering Manager CDE
> >>
> >> *(408) 438-3156 - mobile*
> >>
> >>
> >>
> >>
> >>
> >>
> >> On Wed, Sep 12, 2018 at 8:51 AM Sylvain Lebresne 
> >> wrote:
> >>
> >>> -0
> >>>
> >>> The project seems to have a hard time getting on top of reviewing his
> >>> backlog
> >>> of 'patch available' issues, so that I'm skeptical adopting more code
> to
> >>> maintain is the thing the project needs the most right now. Besides,
> I'm
> >>> also
> >>> generally skeptical that augmenting the scope of a project makes it
> >> better:
> >>> I feel
> >>> keeping this project focused on the core server is better. I see risks
> >>> here, but
> >>> the upsides haven't been made very clear for me, even for end users:
> yes,
> >>> it
> >>> may provide a tiny bit more clarity around which Golang driver to
> choose
> >> by
> >>> default, but I'm not sure users are that lost, and I think there is
> other
> >>> ways to
> >>> solve that if we really want.
> >>>
> >>> Anyway, I reckon I may be overly pessimistic here and it's not that
> >> strong
> >>> of
> >>> an objection if a large majority is on-board, so giving my opinion but
> >> not
> >>> opposing.
> >>>
> >>> --
> >>> Sylvain
> >>>
> >>>
> >>> On Wed, Sep 12, 2018 at 5:36 PM Jeremiah D Jordan <
> >>> jeremiah.jor...@gmail.com>
> >>> wrote:
> >>>
>  +1
> 
>  But I also think getting this through incubation might take a while/be
>  impossible given how large the contributor list looks…
> 
> > On Sep 12, 2018, at 10:22 AM, Jeff Jirsa  wrote:
> >
> > +1
> >
> > (Incubation looks like it may be challenging to get acceptance from
> >> all
>  existing contributors, though)
> >
> > --
> > Jeff Jirsa
> >
> >
> >> On Sep 12, 2018, at 8:12 AM, Nate McCall 
> >> wrote:
> >>
> >> This will be the same process used for dtest. We will need to walk
> >> this through the incubator per the process outlined here:
> >>
> >>
> 
> >>>
> >>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__incubator.apache.org_guides_ip-5Fclearance.html&d=DwIFAg&c=adz96Xi0w1RHqtPMowiL2g&r=CNZK3RiJDLqhsZDG6FQGnXn8WyPRCQhp4x_uBICNC0g&m=g-MlYFZVJ7j5Dj_ZfPfa0Ik8Nxco7QsJhTG1TnJH7xI&s=rk5T_t1HZY6PAhN5XgflBhfEtNrcZkVTIvQxixDlw9o&e=
> >>
> >> Pending the outcome of this vote, we will create the JIRA issues for
> >> tracking and after we go through the process, and discuss adding
> >> committers in a separate thread (we need to do this atomically
> >> anyway
> >> per general ASF committer adding processes).
> >>
> >> Thanks,
> >> -Nate
> >>
> >>
> >> -
> >> 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
> 
> 
> >>>
> >>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>


Re: [VOTE] Accept GoCQL driver donation and begin incubation process

2018-09-12 Thread Dinesh Joshi
+1

Dinesh

> On Sep 12, 2018, at 10:23 AM, Jaydeep Chovatia  
> wrote:
> 
> +1
> 
> On Wed, Sep 12, 2018 at 10:00 AM Roopa Tangirala
>  wrote:
> 
>> +1
>> 
>> 
>> *Regards,*
>> 
>> *Roopa Tangirala*
>> 
>> Engineering Manager CDE
>> 
>> *(408) 438-3156 - mobile*
>> 
>> 
>> 
>> 
>> 
>> 
>> On Wed, Sep 12, 2018 at 8:51 AM Sylvain Lebresne 
>> wrote:
>> 
>>> -0
>>> 
>>> The project seems to have a hard time getting on top of reviewing his
>>> backlog
>>> of 'patch available' issues, so that I'm skeptical adopting more code to
>>> maintain is the thing the project needs the most right now. Besides, I'm
>>> also
>>> generally skeptical that augmenting the scope of a project makes it
>> better:
>>> I feel
>>> keeping this project focused on the core server is better. I see risks
>>> here, but
>>> the upsides haven't been made very clear for me, even for end users: yes,
>>> it
>>> may provide a tiny bit more clarity around which Golang driver to choose
>> by
>>> default, but I'm not sure users are that lost, and I think there is other
>>> ways to
>>> solve that if we really want.
>>> 
>>> Anyway, I reckon I may be overly pessimistic here and it's not that
>> strong
>>> of
>>> an objection if a large majority is on-board, so giving my opinion but
>> not
>>> opposing.
>>> 
>>> --
>>> Sylvain
>>> 
>>> 
>>> On Wed, Sep 12, 2018 at 5:36 PM Jeremiah D Jordan <
>>> jeremiah.jor...@gmail.com>
>>> wrote:
>>> 
 +1
 
 But I also think getting this through incubation might take a while/be
 impossible given how large the contributor list looks…
 
> On Sep 12, 2018, at 10:22 AM, Jeff Jirsa  wrote:
> 
> +1
> 
> (Incubation looks like it may be challenging to get acceptance from
>> all
 existing contributors, though)
> 
> --
> Jeff Jirsa
> 
> 
>> On Sep 12, 2018, at 8:12 AM, Nate McCall 
>> wrote:
>> 
>> This will be the same process used for dtest. We will need to walk
>> this through the incubator per the process outlined here:
>> 
>> 
 
>>> 
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__incubator.apache.org_guides_ip-5Fclearance.html&d=DwIFAg&c=adz96Xi0w1RHqtPMowiL2g&r=CNZK3RiJDLqhsZDG6FQGnXn8WyPRCQhp4x_uBICNC0g&m=g-MlYFZVJ7j5Dj_ZfPfa0Ik8Nxco7QsJhTG1TnJH7xI&s=rk5T_t1HZY6PAhN5XgflBhfEtNrcZkVTIvQxixDlw9o&e=
>> 
>> Pending the outcome of this vote, we will create the JIRA issues for
>> tracking and after we go through the process, and discuss adding
>> committers in a separate thread (we need to do this atomically
>> anyway
>> per general ASF committer adding processes).
>> 
>> Thanks,
>> -Nate
>> 
>> 
>> -
>> 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
 
 
>>> 
>> 


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



Re: [VOTE] Development Approach for Apache Cassandra Management process

2018-09-12 Thread Dinesh Joshi
+1 for piecemeal (option b)

Dinesh

> On Sep 12, 2018, at 8:18 AM, sankalp kohli  wrote:
> 
> Hi,
>Community has been discussing about Apache Cassandra Management process
> since April and we had lot of discussion about which approach to take to
> get started. Several contributors have been interested in doing this and we
> need to make a decision of which approach to take.
> 
> The current approaches being evaluated are
> a. Donate an existing project to Apache Cassandra like Reaper. If this
> option is selected, we will evaluate various projects and see which one
> fits best.
> b. Take a piecemeal approach and use the features from different OSS
> projects and build a new project.
> 
> Available options to vote
> a. +1 to use existing project.
> b. +1 to take piecemeal approach
> c  -1 to both
> d +0 I dont mind either option
> 
> You can also just type a,b,c,d as well to chose an option.
> 
> Dev threads with discussions
> 
> https://lists.apache.org/thread.html/4eace8cb258aab83fc3a220ff2203a281ea59f4d6557ebeb1af7b7f1@%3Cdev.cassandra.apache.org%3E
> 
> https://lists.apache.org/thread.html/4a7e608c46aa2256e8bcb696104a4e6d6aaa1f302834d211018ec96e@%3Cdev.cassandra.apache.org%3E


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



Re: [VOTE] Accept GoCQL driver donation and begin incubation process

2018-09-12 Thread Jaydeep Chovatia
+1

On Wed, Sep 12, 2018 at 10:00 AM Roopa Tangirala
 wrote:

> +1
>
>
> *Regards,*
>
> *Roopa Tangirala*
>
> Engineering Manager CDE
>
> *(408) 438-3156 - mobile*
>
>
>
>
>
>
> On Wed, Sep 12, 2018 at 8:51 AM Sylvain Lebresne 
> wrote:
>
> > -0
> >
> > The project seems to have a hard time getting on top of reviewing his
> > backlog
> > of 'patch available' issues, so that I'm skeptical adopting more code to
> > maintain is the thing the project needs the most right now. Besides, I'm
> > also
> > generally skeptical that augmenting the scope of a project makes it
> better:
> > I feel
> > keeping this project focused on the core server is better. I see risks
> > here, but
> > the upsides haven't been made very clear for me, even for end users: yes,
> > it
> > may provide a tiny bit more clarity around which Golang driver to choose
> by
> > default, but I'm not sure users are that lost, and I think there is other
> > ways to
> > solve that if we really want.
> >
> > Anyway, I reckon I may be overly pessimistic here and it's not that
> strong
> > of
> > an objection if a large majority is on-board, so giving my opinion but
> not
> > opposing.
> >
> > --
> > Sylvain
> >
> >
> > On Wed, Sep 12, 2018 at 5:36 PM Jeremiah D Jordan <
> > jeremiah.jor...@gmail.com>
> > wrote:
> >
> > > +1
> > >
> > > But I also think getting this through incubation might take a while/be
> > > impossible given how large the contributor list looks…
> > >
> > > > On Sep 12, 2018, at 10:22 AM, Jeff Jirsa  wrote:
> > > >
> > > > +1
> > > >
> > > > (Incubation looks like it may be challenging to get acceptance from
> all
> > > existing contributors, though)
> > > >
> > > > --
> > > > Jeff Jirsa
> > > >
> > > >
> > > >> On Sep 12, 2018, at 8:12 AM, Nate McCall 
> wrote:
> > > >>
> > > >> This will be the same process used for dtest. We will need to walk
> > > >> this through the incubator per the process outlined here:
> > > >>
> > > >>
> > >
> >
> https://urldefense.proofpoint.com/v2/url?u=https-3A__incubator.apache.org_guides_ip-5Fclearance.html&d=DwIFAg&c=adz96Xi0w1RHqtPMowiL2g&r=CNZK3RiJDLqhsZDG6FQGnXn8WyPRCQhp4x_uBICNC0g&m=g-MlYFZVJ7j5Dj_ZfPfa0Ik8Nxco7QsJhTG1TnJH7xI&s=rk5T_t1HZY6PAhN5XgflBhfEtNrcZkVTIvQxixDlw9o&e=
> > > >>
> > > >> Pending the outcome of this vote, we will create the JIRA issues for
> > > >> tracking and after we go through the process, and discuss adding
> > > >> committers in a separate thread (we need to do this atomically
> anyway
> > > >> per general ASF committer adding processes).
> > > >>
> > > >> Thanks,
> > > >> -Nate
> > > >>
> > > >>
> -
> > > >> 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: [VOTE] Development Approach for Apache Cassandra Management process

2018-09-12 Thread Sumanth Pasupuleti
Option "b".

Thanks,
Sumanth

On Wed, Sep 12, 2018 at 9:59 AM Roopa Tangirala
 wrote:

> +1 to b Take the best from existing side cars and make a great side car
> which ships with cassandra
>
>
> *Regards,*
>
> *Roopa Tangirala*
>
> Engineering Manager CDE
>
> *(408) 438-3156 - mobile*
>
>
>
>
>
>
> On Wed, Sep 12, 2018 at 8:19 AM sankalp kohli 
> wrote:
>
> > Hi,
> > Community has been discussing about Apache Cassandra Management
> process
> > since April and we had lot of discussion about which approach to take to
> > get started. Several contributors have been interested in doing this and
> we
> > need to make a decision of which approach to take.
> >
> > The current approaches being evaluated are
> > a. Donate an existing project to Apache Cassandra like Reaper. If this
> > option is selected, we will evaluate various projects and see which one
> > fits best.
> > b. Take a piecemeal approach and use the features from different OSS
> > projects and build a new project.
> >
> > Available options to vote
> > a. +1 to use existing project.
> > b. +1 to take piecemeal approach
> > c  -1 to both
> > d +0 I dont mind either option
> >
> > You can also just type a,b,c,d as well to chose an option.
> >
> > Dev threads with discussions
> >
> >
> >
> https://lists.apache.org/thread.html/4eace8cb258aab83fc3a220ff2203a281ea59f4d6557ebeb1af7b7f1@%3Cdev.cassandra.apache.org%3E
> >
> >
> >
> https://lists.apache.org/thread.html/4a7e608c46aa2256e8bcb696104a4e6d6aaa1f302834d211018ec96e@%3Cdev.cassandra.apache.org%3E
> >
>


Re: [VOTE] Accept GoCQL driver donation and begin incubation process

2018-09-12 Thread Roopa Tangirala
+1


*Regards,*

*Roopa Tangirala*

Engineering Manager CDE

*(408) 438-3156 - mobile*






On Wed, Sep 12, 2018 at 8:51 AM Sylvain Lebresne  wrote:

> -0
>
> The project seems to have a hard time getting on top of reviewing his
> backlog
> of 'patch available' issues, so that I'm skeptical adopting more code to
> maintain is the thing the project needs the most right now. Besides, I'm
> also
> generally skeptical that augmenting the scope of a project makes it better:
> I feel
> keeping this project focused on the core server is better. I see risks
> here, but
> the upsides haven't been made very clear for me, even for end users: yes,
> it
> may provide a tiny bit more clarity around which Golang driver to choose by
> default, but I'm not sure users are that lost, and I think there is other
> ways to
> solve that if we really want.
>
> Anyway, I reckon I may be overly pessimistic here and it's not that strong
> of
> an objection if a large majority is on-board, so giving my opinion but not
> opposing.
>
> --
> Sylvain
>
>
> On Wed, Sep 12, 2018 at 5:36 PM Jeremiah D Jordan <
> jeremiah.jor...@gmail.com>
> wrote:
>
> > +1
> >
> > But I also think getting this through incubation might take a while/be
> > impossible given how large the contributor list looks…
> >
> > > On Sep 12, 2018, at 10:22 AM, Jeff Jirsa  wrote:
> > >
> > > +1
> > >
> > > (Incubation looks like it may be challenging to get acceptance from all
> > existing contributors, though)
> > >
> > > --
> > > Jeff Jirsa
> > >
> > >
> > >> On Sep 12, 2018, at 8:12 AM, Nate McCall  wrote:
> > >>
> > >> This will be the same process used for dtest. We will need to walk
> > >> this through the incubator per the process outlined here:
> > >>
> > >>
> >
> https://urldefense.proofpoint.com/v2/url?u=https-3A__incubator.apache.org_guides_ip-5Fclearance.html&d=DwIFAg&c=adz96Xi0w1RHqtPMowiL2g&r=CNZK3RiJDLqhsZDG6FQGnXn8WyPRCQhp4x_uBICNC0g&m=g-MlYFZVJ7j5Dj_ZfPfa0Ik8Nxco7QsJhTG1TnJH7xI&s=rk5T_t1HZY6PAhN5XgflBhfEtNrcZkVTIvQxixDlw9o&e=
> > >>
> > >> Pending the outcome of this vote, we will create the JIRA issues for
> > >> tracking and after we go through the process, and discuss adding
> > >> committers in a separate thread (we need to do this atomically anyway
> > >> per general ASF committer adding processes).
> > >>
> > >> Thanks,
> > >> -Nate
> > >>
> > >> -
> > >> 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: [VOTE] Development Approach for Apache Cassandra Management process

2018-09-12 Thread Roopa Tangirala
+1 to b Take the best from existing side cars and make a great side car
which ships with cassandra


*Regards,*

*Roopa Tangirala*

Engineering Manager CDE

*(408) 438-3156 - mobile*






On Wed, Sep 12, 2018 at 8:19 AM sankalp kohli 
wrote:

> Hi,
> Community has been discussing about Apache Cassandra Management process
> since April and we had lot of discussion about which approach to take to
> get started. Several contributors have been interested in doing this and we
> need to make a decision of which approach to take.
>
> The current approaches being evaluated are
> a. Donate an existing project to Apache Cassandra like Reaper. If this
> option is selected, we will evaluate various projects and see which one
> fits best.
> b. Take a piecemeal approach and use the features from different OSS
> projects and build a new project.
>
> Available options to vote
> a. +1 to use existing project.
> b. +1 to take piecemeal approach
> c  -1 to both
> d +0 I dont mind either option
>
> You can also just type a,b,c,d as well to chose an option.
>
> Dev threads with discussions
>
>
> https://lists.apache.org/thread.html/4eace8cb258aab83fc3a220ff2203a281ea59f4d6557ebeb1af7b7f1@%3Cdev.cassandra.apache.org%3E
>
>
> https://lists.apache.org/thread.html/4a7e608c46aa2256e8bcb696104a4e6d6aaa1f302834d211018ec96e@%3Cdev.cassandra.apache.org%3E
>


Re: [VOTE] Accept GoCQL driver donation and begin incubation process

2018-09-12 Thread Sylvain Lebresne
-0

The project seems to have a hard time getting on top of reviewing his
backlog
of 'patch available' issues, so that I'm skeptical adopting more code to
maintain is the thing the project needs the most right now. Besides, I'm
also
generally skeptical that augmenting the scope of a project makes it better:
I feel
keeping this project focused on the core server is better. I see risks
here, but
the upsides haven't been made very clear for me, even for end users: yes, it
may provide a tiny bit more clarity around which Golang driver to choose by
default, but I'm not sure users are that lost, and I think there is other
ways to
solve that if we really want.

Anyway, I reckon I may be overly pessimistic here and it's not that strong
of
an objection if a large majority is on-board, so giving my opinion but not
opposing.

--
Sylvain


On Wed, Sep 12, 2018 at 5:36 PM Jeremiah D Jordan 
wrote:

> +1
>
> But I also think getting this through incubation might take a while/be
> impossible given how large the contributor list looks…
>
> > On Sep 12, 2018, at 10:22 AM, Jeff Jirsa  wrote:
> >
> > +1
> >
> > (Incubation looks like it may be challenging to get acceptance from all
> existing contributors, though)
> >
> > --
> > Jeff Jirsa
> >
> >
> >> On Sep 12, 2018, at 8:12 AM, Nate McCall  wrote:
> >>
> >> This will be the same process used for dtest. We will need to walk
> >> this through the incubator per the process outlined here:
> >>
> >>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__incubator.apache.org_guides_ip-5Fclearance.html&d=DwIFAg&c=adz96Xi0w1RHqtPMowiL2g&r=CNZK3RiJDLqhsZDG6FQGnXn8WyPRCQhp4x_uBICNC0g&m=g-MlYFZVJ7j5Dj_ZfPfa0Ik8Nxco7QsJhTG1TnJH7xI&s=rk5T_t1HZY6PAhN5XgflBhfEtNrcZkVTIvQxixDlw9o&e=
> >>
> >> Pending the outcome of this vote, we will create the JIRA issues for
> >> tracking and after we go through the process, and discuss adding
> >> committers in a separate thread (we need to do this atomically anyway
> >> per general ASF committer adding processes).
> >>
> >> Thanks,
> >> -Nate
> >>
> >> -
> >> 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: [VOTE] Accept GoCQL driver donation and begin incubation process

2018-09-12 Thread Jeremiah D Jordan
+1

But I also think getting this through incubation might take a while/be 
impossible given how large the contributor list looks…

> On Sep 12, 2018, at 10:22 AM, Jeff Jirsa  wrote:
> 
> +1
> 
> (Incubation looks like it may be challenging to get acceptance from all 
> existing contributors, though)
> 
> -- 
> Jeff Jirsa
> 
> 
>> On Sep 12, 2018, at 8:12 AM, Nate McCall  wrote:
>> 
>> This will be the same process used for dtest. We will need to walk
>> this through the incubator per the process outlined here:
>> 
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__incubator.apache.org_guides_ip-5Fclearance.html&d=DwIFAg&c=adz96Xi0w1RHqtPMowiL2g&r=CNZK3RiJDLqhsZDG6FQGnXn8WyPRCQhp4x_uBICNC0g&m=g-MlYFZVJ7j5Dj_ZfPfa0Ik8Nxco7QsJhTG1TnJH7xI&s=rk5T_t1HZY6PAhN5XgflBhfEtNrcZkVTIvQxixDlw9o&e=
>> 
>> Pending the outcome of this vote, we will create the JIRA issues for
>> tracking and after we go through the process, and discuss adding
>> committers in a separate thread (we need to do this atomically anyway
>> per general ASF committer adding processes).
>> 
>> Thanks,
>> -Nate
>> 
>> -
>> 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: [VOTE] Accept GoCQL driver donation and begin incubation process

2018-09-12 Thread Jeff Jirsa
+1

(Incubation looks like it may be challenging to get acceptance from all 
existing contributors, though)

-- 
Jeff Jirsa


> On Sep 12, 2018, at 8:12 AM, Nate McCall  wrote:
> 
> This will be the same process used for dtest. We will need to walk
> this through the incubator per the process outlined here:
> 
> https://incubator.apache.org/guides/ip_clearance.html
> 
> Pending the outcome of this vote, we will create the JIRA issues for
> tracking and after we go through the process, and discuss adding
> committers in a separate thread (we need to do this atomically anyway
> per general ASF committer adding processes).
> 
> Thanks,
> -Nate
> 
> -
> 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] Accept GoCQL driver donation and begin incubation process

2018-09-12 Thread sankalp kohli
+1

On Wed, Sep 12, 2018 at 8:12 AM Nate McCall  wrote:

> This will be the same process used for dtest. We will need to walk
> this through the incubator per the process outlined here:
>
> https://incubator.apache.org/guides/ip_clearance.html
>
> Pending the outcome of this vote, we will create the JIRA issues for
> tracking and after we go through the process, and discuss adding
> committers in a separate thread (we need to do this atomically anyway
> per general ASF committer adding processes).
>
> Thanks,
> -Nate
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>


Re: [Discuss] Accept GoCQL driver donation

2018-09-12 Thread sankalp kohli
Great..please start the vote to get consensus.

On Wed, Sep 12, 2018 at 8:06 AM Nate McCall  wrote:

> Yep - that sounds like the best next step to me.
>
> (apologies for spotty comms folks - been/still on vacation).
> On Wed, Sep 12, 2018 at 8:03 AM sankalp kohli 
> wrote:
> >
> > Hi Nate,
> > Looks like we had a lot of discussion here and everyone seems
> > to be in favor. What is the next step? A vote?
> > Thanks,
> > Sankalp
> >
> > On Fri, Aug 31, 2018 at 10:48 PM Alex Lourie 
> wrote:
> >
> > > Same here. I've been working on this project for a bit now, and I'm
> > > planning to continue and contribute.
> > >
> > > I also like the idea of this project becoming an officially endorsed
> golang
> > > Cassandra driver. Makes a lot of sense too.
> > >
> > > Alex.
> > >
> > >
> > > On Sat., 1 Sep. 2018, 01:08 Chris Bannister, 
> > > wrote:
> > >
> > > > I intend to stay on and continue to contribute.
> > > >
> > > > On Fri, 31 Aug 2018 at 4:37 pm, Jonathan Ellis 
> > > wrote:
> > > >
> > > > > On Fri, Aug 31, 2018 at 9:14 AM Nate McCall 
> > > wrote:
> > > > >
> > > > > > Hi folks,
> > > > > > So I was recently talking with, Chris Bannister  the gocql [0]
> > > > > > maintainer, and he expressed an interest in donating the driver
> to
> > > the
> > > > > > ASF.
> > > > > >
> > > > >
> > > > > Is he looking to continue to maintain it or is he looking to give
> it a
> > > > good
> > > > > home when he moves on?
> > > > >
> > > > > We could accept this along the same lines as how we took in the
> dtest
> > > > > > donation - going through the incubator IP clearance process [1],
> but
> > > > > > in this case it's much simpler as an individual (Chris) owns the
> > > > > > copyright.
> > > > > >
> > > > >
> > > > > Is that actually the case?  Github says 128 contributors, and I
> don't
> > > see
> > > > > any mention of a CLA in
> > > > > https://github.com/gocql/gocql/blob/master/CONTRIBUTING.md.
> > > > >
> > > > > --
> > > > > Jonathan Ellis
> > > > > co-founder, http://www.datastax.com
> > > > > @spyced
> > > > >
> > > >
> > >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>


[VOTE] Development Approach for Apache Cassandra Management process

2018-09-12 Thread sankalp kohli
Hi,
Community has been discussing about Apache Cassandra Management process
since April and we had lot of discussion about which approach to take to
get started. Several contributors have been interested in doing this and we
need to make a decision of which approach to take.

The current approaches being evaluated are
a. Donate an existing project to Apache Cassandra like Reaper. If this
option is selected, we will evaluate various projects and see which one
fits best.
b. Take a piecemeal approach and use the features from different OSS
projects and build a new project.

Available options to vote
a. +1 to use existing project.
b. +1 to take piecemeal approach
c  -1 to both
d +0 I dont mind either option

You can also just type a,b,c,d as well to chose an option.

Dev threads with discussions

https://lists.apache.org/thread.html/4eace8cb258aab83fc3a220ff2203a281ea59f4d6557ebeb1af7b7f1@%3Cdev.cassandra.apache.org%3E

https://lists.apache.org/thread.html/4a7e608c46aa2256e8bcb696104a4e6d6aaa1f302834d211018ec96e@%3Cdev.cassandra.apache.org%3E


[VOTE] Accept GoCQL driver donation and begin incubation process

2018-09-12 Thread Nate McCall
This will be the same process used for dtest. We will need to walk
this through the incubator per the process outlined here:

https://incubator.apache.org/guides/ip_clearance.html

Pending the outcome of this vote, we will create the JIRA issues for
tracking and after we go through the process, and discuss adding
committers in a separate thread (we need to do this atomically anyway
per general ASF committer adding processes).

Thanks,
-Nate

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



Re: [Discuss] Accept GoCQL driver donation

2018-09-12 Thread Nate McCall
Yep - that sounds like the best next step to me.

(apologies for spotty comms folks - been/still on vacation).
On Wed, Sep 12, 2018 at 8:03 AM sankalp kohli  wrote:
>
> Hi Nate,
> Looks like we had a lot of discussion here and everyone seems
> to be in favor. What is the next step? A vote?
> Thanks,
> Sankalp
>
> On Fri, Aug 31, 2018 at 10:48 PM Alex Lourie  wrote:
>
> > Same here. I've been working on this project for a bit now, and I'm
> > planning to continue and contribute.
> >
> > I also like the idea of this project becoming an officially endorsed golang
> > Cassandra driver. Makes a lot of sense too.
> >
> > Alex.
> >
> >
> > On Sat., 1 Sep. 2018, 01:08 Chris Bannister, 
> > wrote:
> >
> > > I intend to stay on and continue to contribute.
> > >
> > > On Fri, 31 Aug 2018 at 4:37 pm, Jonathan Ellis 
> > wrote:
> > >
> > > > On Fri, Aug 31, 2018 at 9:14 AM Nate McCall 
> > wrote:
> > > >
> > > > > Hi folks,
> > > > > So I was recently talking with, Chris Bannister  the gocql [0]
> > > > > maintainer, and he expressed an interest in donating the driver to
> > the
> > > > > ASF.
> > > > >
> > > >
> > > > Is he looking to continue to maintain it or is he looking to give it a
> > > good
> > > > home when he moves on?
> > > >
> > > > We could accept this along the same lines as how we took in the dtest
> > > > > donation - going through the incubator IP clearance process [1], but
> > > > > in this case it's much simpler as an individual (Chris) owns the
> > > > > copyright.
> > > > >
> > > >
> > > > Is that actually the case?  Github says 128 contributors, and I don't
> > see
> > > > any mention of a CLA in
> > > > https://github.com/gocql/gocql/blob/master/CONTRIBUTING.md.
> > > >
> > > > --
> > > > Jonathan Ellis
> > > > co-founder, http://www.datastax.com
> > > > @spyced
> > > >
> > >
> >

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



Re: [Discuss] Accept GoCQL driver donation

2018-09-12 Thread sankalp kohli
Hi Nate,
Looks like we had a lot of discussion here and everyone seems
to be in favor. What is the next step? A vote?
Thanks,
Sankalp

On Fri, Aug 31, 2018 at 10:48 PM Alex Lourie  wrote:

> Same here. I've been working on this project for a bit now, and I'm
> planning to continue and contribute.
>
> I also like the idea of this project becoming an officially endorsed golang
> Cassandra driver. Makes a lot of sense too.
>
> Alex.
>
>
> On Sat., 1 Sep. 2018, 01:08 Chris Bannister, 
> wrote:
>
> > I intend to stay on and continue to contribute.
> >
> > On Fri, 31 Aug 2018 at 4:37 pm, Jonathan Ellis 
> wrote:
> >
> > > On Fri, Aug 31, 2018 at 9:14 AM Nate McCall 
> wrote:
> > >
> > > > Hi folks,
> > > > So I was recently talking with, Chris Bannister  the gocql [0]
> > > > maintainer, and he expressed an interest in donating the driver to
> the
> > > > ASF.
> > > >
> > >
> > > Is he looking to continue to maintain it or is he looking to give it a
> > good
> > > home when he moves on?
> > >
> > > We could accept this along the same lines as how we took in the dtest
> > > > donation - going through the incubator IP clearance process [1], but
> > > > in this case it's much simpler as an individual (Chris) owns the
> > > > copyright.
> > > >
> > >
> > > Is that actually the case?  Github says 128 contributors, and I don't
> see
> > > any mention of a CLA in
> > > https://github.com/gocql/gocql/blob/master/CONTRIBUTING.md.
> > >
> > > --
> > > Jonathan Ellis
> > > co-founder, http://www.datastax.com
> > > @spyced
> > >
> >
>


Re: UDF

2018-09-12 Thread Sylvain Lebresne
I'm +1 with this solution going in 4.0.

That said, this make we realize that through this dependency we've
ended up exposing (publicly) a bit too much to UDF. Namely, all we really
need/want to expose for UDF is the "value" classes (UDTValue, TupleValue,
Duration and LocalDate) and the types (DataType and his 2 subclasses
UserType
and TupleType).

But we end up exposing quite a bit more: some abstract classes that are
public
(AbstractGettableData, AbstractSettableData, ...), but more problematic imo,
the CodecRegistry class (whose only need to be public is, as far as I can
tell, the UserType/TupeType.of() methods, which aren't useful to UDF at
all)
which 1) is overly complex for what we care about in UDF and 2) brings
transitive dependencies (TypeCodec and all his sub-classes, TypeToken).

So my suggestion is that we go with Robert's patch, but on top of that we
add detection for usage of all those classes/methods that have no business
being
exposed. For brand new UDFs, we could just reject them if they use any of
those
in 4.0. For existing UDFs, we'd log a warning at startup that say it's
deprecated and that the UDF should be replaced or things will break in the
next
major. Honestly, my expectation is that no-one uses those classes/methods
(since again, they aren't exactly useful) so I don't anticipate doing so
being
a big deal. But unless we do it, we won't be able to clean up the code
added by
this.

And there is quite a bit that would be nice to cleanup at some point here
imo.
Not that the driver code is bad in any way; just that 1) some of the
complexity
it exposes is overkill for UDF (registering TypeCodec typically), and that a
lot of the code added duplicates things we already have server side).

--
Sylvain


On Wed, Sep 12, 2018 at 11:46 AM Aleksey Yeschenko 
wrote:

> It’s my understanding that the duplicated code is being fully donated - so
> it’ll have all the usual ASF license/copyright headers when it lands in
> trunk. No special steps to take here.
>
> —
> AY
>
> On 11 September 2018 at 19:43:58, Jeremiah D Jordan (
> jeremiah.jor...@gmail.com) wrote:
>
> Be careful when pulling in source files from the DataStax Java Driver (or
> anywhere) to make sure and respect its Apache License, Version 2.0 and keep
> all Copyright's etc with said files.
>
> -Jeremiah
>
> > On Sep 11, 2018, at 12:29 PM, Jeff Jirsa  wrote:
> >
> > +1 as well.
> >
> > On Tue, Sep 11, 2018 at 10:27 AM Aleksey Yeschenko 
>
> > wrote:
> >
> >> If this is about inclusion in 4.0, then I support it.
> >>
> >> Technically this is *mostly* just a move+donation of some code from
> >> java-driver to Cassandra. Given how important this seemingly is to the
> >> board and PMC for us to not have the dependency on the driver, the
> sooner
> >> it’s gone, the better.
> >>
> >> I’d be +1 for committing to trunk.
> >>
> >> —
> >> AY
> >>
> >> On 11 September 2018 at 14:43:29, Robert Stupp (sn...@snazy.de)
> wrote:
> >>
> >> The patch is technically complete - i.e. it works and does its thing.
> >>
> >> It's not strictly a bug fix but targets trunk. That's why I started
> the
> >> discussion.
> >>
> >>
> >> On 09/11/2018 02:53 PM, Jason Brown wrote:
> >>> Hi Robert,
> >>>
> >>> Thanks for taking on this work. Is this message a heads up that a
> patch
> >> is
> >>> coming/complete, or to spawn a discussion about including this in
> 4.0?
> >>>
> >>> Thanks,
> >>>
> >>> -Jason
> >>>
> >>> On Tue, Sep 11, 2018 at 2:32 AM, Robert Stupp 
> wrote:
> >>>
>  In an effort to clean up our hygiene and limit the dependencies used
> >> by
>  UDFs/UDAs, I think we should refactor the UDF code parts and remove
> >> the
>  dependency to the Java Driver in that area without breaking existing
>  UDFs/UDAs.
> 
>  A working prototype is in this branch:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_snazy_&d=DwIFaQ&c=adz96Xi0w1RHqtPMowiL2g&r=CNZK3RiJDLqhsZDG6FQGnXn8WyPRCQhp4x_uBICNC0g&m=Gesm79MRSHznQEKqQabvh3Ie1L3xzqlPsfLfEfadHTM&s=6lUpmmETCKbmt_zcp_DCLIxCGPjVyf7zdX0UjBVOZX4&e=
>
>  cassandra/tree/feature/remove-udf-driver-dep-trunk <
> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_snazy_cassandra_tree_feature_remove-2D&d=DwIFaQ&c=adz96Xi0w1RHqtPMowiL2g&r=CNZK3RiJDLqhsZDG6FQGnXn8WyPRCQhp4x_uBICNC0g&m=Gesm79MRSHznQEKqQabvh3Ie1L3xzqlPsfLfEfadHTM&s=fBx64l59d8Y9Q7m9j0nNH9VvcaHc3QfoCAx4st5UJDM&e=
>
>  udf-driver-dep-trunk> . The changes are rather trivial and provide
> >> 100%
>  backwards compatibility for existing UDFs.
> 
>  The prototype copies the necessary parts from the Java Driver into
> the
> >> C*
>  source tree to org.apache.cassandra.cql3.functions.types and adopts
> >> its
>  usages - i.e. UDF/UDA code plus CQLSSTableWriter +
> >> StressCQLSSTableWriter.
>  The latter two classes have a reference to UDF’s UDHelper and had to
> >> be
>  changed as well.
> 
>  Some functionality, like type parsing & handling, is duplicated in
> the
>  code b

Re: UDF

2018-09-12 Thread Aleksey Yeschenko
It’s my understanding that the duplicated code is being fully donated - so 
it’ll have all the usual ASF license/copyright headers when it lands in trunk. 
No special steps to take here.

—
AY

On 11 September 2018 at 19:43:58, Jeremiah D Jordan (jeremiah.jor...@gmail.com) 
wrote:

Be careful when pulling in source files from the DataStax Java Driver (or 
anywhere) to make sure and respect its Apache License, Version 2.0 and keep all 
Copyright's etc with said files.  

-Jeremiah  

> On Sep 11, 2018, at 12:29 PM, Jeff Jirsa  wrote:  
>  
> +1 as well.  
>  
> On Tue, Sep 11, 2018 at 10:27 AM Aleksey Yeschenko   
> wrote:  
>  
>> If this is about inclusion in 4.0, then I support it.  
>>  
>> Technically this is *mostly* just a move+donation of some code from  
>> java-driver to Cassandra. Given how important this seemingly is to the  
>> board and PMC for us to not have the dependency on the driver, the sooner  
>> it’s gone, the better.  
>>  
>> I’d be +1 for committing to trunk.  
>>  
>> —  
>> AY  
>>  
>> On 11 September 2018 at 14:43:29, Robert Stupp (sn...@snazy.de) wrote:  
>>  
>> The patch is technically complete - i.e. it works and does its thing.  
>>  
>> It's not strictly a bug fix but targets trunk. That's why I started the  
>> discussion.  
>>  
>>  
>> On 09/11/2018 02:53 PM, Jason Brown wrote:  
>>> Hi Robert,  
>>>  
>>> Thanks for taking on this work. Is this message a heads up that a patch  
>> is  
>>> coming/complete, or to spawn a discussion about including this in 4.0?  
>>>  
>>> Thanks,  
>>>  
>>> -Jason  
>>>  
>>> On Tue, Sep 11, 2018 at 2:32 AM, Robert Stupp  wrote:  
>>>  
 In an effort to clean up our hygiene and limit the dependencies used  
>> by  
 UDFs/UDAs, I think we should refactor the UDF code parts and remove  
>> the  
 dependency to the Java Driver in that area without breaking existing  
 UDFs/UDAs.  
  
 A working prototype is in this branch: 
 https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_snazy_&d=DwIFaQ&c=adz96Xi0w1RHqtPMowiL2g&r=CNZK3RiJDLqhsZDG6FQGnXn8WyPRCQhp4x_uBICNC0g&m=Gesm79MRSHznQEKqQabvh3Ie1L3xzqlPsfLfEfadHTM&s=6lUpmmETCKbmt_zcp_DCLIxCGPjVyf7zdX0UjBVOZX4&e=
   
 cassandra/tree/feature/remove-udf-driver-dep-trunk <  
 https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_snazy_cassandra_tree_feature_remove-2D&d=DwIFaQ&c=adz96Xi0w1RHqtPMowiL2g&r=CNZK3RiJDLqhsZDG6FQGnXn8WyPRCQhp4x_uBICNC0g&m=Gesm79MRSHznQEKqQabvh3Ie1L3xzqlPsfLfEfadHTM&s=fBx64l59d8Y9Q7m9j0nNH9VvcaHc3QfoCAx4st5UJDM&e=
   
 udf-driver-dep-trunk> . The changes are rather trivial and provide  
>> 100%  
 backwards compatibility for existing UDFs.  
  
 The prototype copies the necessary parts from the Java Driver into the  
>> C*  
 source tree to org.apache.cassandra.cql3.functions.types and adopts  
>> its  
 usages - i.e. UDF/UDA code plus CQLSSTableWriter +  
>> StressCQLSSTableWriter.  
 The latter two classes have a reference to UDF’s UDHelper and had to  
>> be  
 changed as well.  
  
 Some functionality, like type parsing & handling, is duplicated in the  
 code base with this prototype - once in the “current” source tree and  
>> once  
 for UDFs. However, unifying the code paths is not trivial, since the  
>> UDF  
 sandbox prohibits the use of internal classes (direct and likely  
>> indirect  
 dependencies).  
  
 Robert  
  
 —  
 Robert Stupp  
 @snazy  
  
  
>>  
>> --  
>> Robert Stupp  
>> @snazy  
>>  
>>  
>> -  
>> 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