hadoop-hdfs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ravi Prakash <ravihad...@gmail.com>
Subject Re: Why there are so many revert operations on trunk?
Date Tue, 07 Jun 2016 19:02:29 GMT
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.mccay@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 <ravihadoop@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 <jdu@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 <vinodkv@apache.org>
>> > Sent: Monday, June 06, 2016 9:36 PM
>> > To: Andrew Wang
>> > Cc: Junping Du; Aaron T. Myers; common-dev@hadoop.apache.org;
>> > hdfs-dev@hadoop.apache.org; mapreduce-dev@hadoop.apache.org;
>> > yarn-dev@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
>> >
>>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message