Re: [VOTE] Development Approach for Apache Cassandra Management process
On Wed, Sep 12, 2018 at 10: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 As others have pointed out, I think we're placing too much of an emphasis on voting; What we need is consensus, not a majority ruling. Obtaining consensus can be difficult, frustrating, and time-consuming, but IMO always worth it. My interpretation of the discussion is that there was at least consensus on the value of a project-supported management stack, as well as (I think) the notion that it should be kept loosely coupled to the database, beyond that things seem contentious. Assuming I'm not wrong, and there is consensus on a loosely-coupled project, why do we need to rush a decision on inclusion? What prevents those who are vested in one approach (or existing project) or another from working on what they think best? I suspect developing consensus here would be a lot easier if we were talking about something a bit more concrete. -- Eric Evans john.eric.ev...@gmail.com - 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
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: [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] 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: [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
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
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
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
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
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] 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] 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] 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] 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] 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] 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 >
[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
