Lolz! Thanks for your opinion Larry. I have often seen "-1 until this is done according to my way rather than your way" (obviously not in those words), even when both ways are perfectly reasonable. Anyway, I didn't expect the voting rules to change. :-)
Cheers Ravi On Tue, Jun 7, 2016 at 11:02 AM, larry mccay <larry.mc...@gmail.com> wrote: > -1 needs not be a taken as a derogatory statement being a number should > actually make it less emotional. > It is dangerous to a community to become oversensitive to it. > > I generally see language such as "I am -1 on this until this particular > thing is fixed" or that it violates some common pattern or precedence set > in the project. This is perfectly reasonable language and there is no > reason to make the reviewer provide an alternative. > > So, I am giving my -1 to any proposal for rule changes on -1 votes. :) > > > On Tue, Jun 7, 2016 at 1:15 PM, Ravi Prakash <ravihad...@gmail.com> wrote: > >> +1 on being more respectful. We seem to be having a lot of distasteful >> discussions recently. If we fight each other, we are only helping our >> competitors win (and trust me, its out there). >> >> I would also respectfully request people not to throw -1s around. I have >> faced this a few times and its really frustrating. Every one has opinions >> and some times different people can't fathom why someone else thinks the >> way they do. I am pretty sure none of us is acting with malicious intent, >> so perhaps a little more tolerance, faith and trust will help all of us >> improve Hadoop and the ecosystem much faster. That's not to say that >> sometimes -1s are not warranted, but we should look to it as an extreme >> measure. Unfortunately there is very little disincentive right now to vote >> -1 . Maybe we should modify the rules..... if you vote -1 , you have to >> come up with an alternative implementation? (perhaps limit the amount of >> time you have to the amount already spent in producing the patch that you >> are against)? >> >> Just my 2 cents >> Ravi >> >> >> On Tue, Jun 7, 2016 at 7:54 AM, Junping Du <j...@hortonworks.com> wrote: >> >> > - We need to at the least force a reset of expectations w.r.t how trunk >> > and small / medium / incompatible changes there are treated. We should >> hold >> > off making a release off trunk before this gets fully discussed in the >> > community and we all reach a consensus. >> > >> > +1. We should hold off any release work off trunk before we reach a >> > consensus. Or more and more developing work/features could be affected >> just >> > like Larry mentioned. >> > >> > >> > - Reverts (or revert and move to a feature-branch) shouldn’t have been >> > unequivocally done without dropping a note / informing everyone / >> building >> > consensus. >> > >> > Agree. To revert commits from other committers, I think we need to: 1) >> > provide technical evidence/reason that is solid as rack, like: break >> > functionality, tests, API compatibility, or significantly offend code >> > convention, etc. 2) Making consensus with related >> contributors/committers >> > based on these technical reasons/evidences. Unfortunately, I didn't see >> we >> > ever do either thing in this case. >> > >> > >> > - Freaking out on -1’s and reverts - we as a community need to be less >> > stigmatic about -1s / reverts. >> > >> > +1. As a community, I believe we all prefer to work in a more friendly >> > environment. In many cases, -1 without solid reason will frustrate >> people >> > who are doing contributions. I think we should restraint our -1 unless >> it >> > is really necessary. >> > >> > >> > >> > Thanks, >> > >> > >> > Junping >> > >> > >> > ________________________________ >> > From: Vinod Kumar Vavilapalli <vino...@apache.org> >> > Sent: Monday, June 06, 2016 9:36 PM >> > To: Andrew Wang >> > Cc: Junping Du; Aaron T. Myers; common-...@hadoop.apache.org; >> > hdfs-...@hadoop.apache.org; mapreduce-dev@hadoop.apache.org; >> > yarn-...@hadoop.apache.org >> > Subject: Re: Why there are so many revert operations on trunk? >> > >> > Folks, >> > >> > It is truly disappointing how we are escalating situations that can be >> > resolved through basic communication. >> > >> > Things that shouldn’t have happened >> > - After a few objections were raised, commits should have simply stopped >> > before restarting again but only after consensus >> > - Reverts (or revert and move to a feature-branch) shouldn’t have been >> > unequivocally done without dropping a note / informing everyone / >> building >> > consensus. And no, not even a release-manager gets this free pass. Not >> on >> > branch-2, not on trunk, not anywhere. >> > - Freaking out on -1’s and reverts - we as a community need to be less >> > stigmatic about -1s / reverts. >> > >> > Trunk releases: >> > This is the other important bit about huge difference of expectations >> > between the two sides w.r.t trunk and branching. Till now, we’ve never >> made >> > releases out of trunk. So in-progress features that people deemed to not >> > need a feature branch could go into trunk without much trouble. Given >> that >> > we are now making releases off trunk, I can see (a) the RM saying "no, >> > don’t put in-progress stuff and (b) the contributors saying “no we don’t >> > want the overhead of a branch”. I’ve raised related topics (but only >> > focusing on incompatible changes) before - >> > http://markmail.org/message/m6x73t6srlchywsn - but we never decided >> > anything. >> > >> > We need to at the least force a reset of expectations w.r.t how trunk >> and >> > small / medium / incompatible changes there are treated. We should hold >> off >> > making a release off trunk before this gets fully discussed in the >> > community and we all reach a consensus. >> > >> > * Without a user API, there's no way for people to use it, so not much >> > advantage to having it in a release >> > >> > Since the code is separate and probably won't break any existing code, I >> > won't -1 if you want to include this in a release without a user API, >> but >> > again, I question the utility of including code that can't be used. >> > >> > Clearly, there are two sides to this argument. One side claims the >> absence >> > of user-facing public / stable APIs, and that for all purposes this is >> > dead-code for everyone other than the few early adopters who want to >> > experiment with it. The other argument is to not put this code before a >> > user API. Again, I’d discuss with fellow community members before making >> > what the other side perceives as unacceptable moves. >> > >> > From 2.8.0 perspective, it shouldn’t have landed there in the first >> place >> > - I have been pushing for a release for a while with help only from a >> few >> > members of the community. But if you say that it has no material impact >> on >> > the user story, having a by-default switched-off feature that *doesn’t* >> > destabilize the core release, I’d be willing to let it pass. >> > >> > +Vinod >> > >> > >
