Re: [VOTE] Development Approach for Apache Cassandra Management process
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
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
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
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
> 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
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
> 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
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
+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
> 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
(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
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
> 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
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
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
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
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
> > 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
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
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
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
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
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
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
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
+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
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
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
+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
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
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
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
+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
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
+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
+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
+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
+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
+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
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
+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
+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
-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
+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
+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
+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
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
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
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
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
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
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
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
