Mailing-List: contact hdfs-dev-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
MIME-Version: 1.0
In-Reply-To: <CACRbFyhxnnGCz3vdf5RcX-sbsEFKVQepR-n0utDnY4_cmQzwEA@mail.gmail.com>
References: <1465223008024.45875@hortonworks.com> <CA+4052nvqDw-1JC6HtkS5R1phHXzS1MwTxL2-KMJaFC+DJhr2w@mail.gmail.com>
 <1465231154205.38002@hortonworks.com> <CAGB5D2Z1m3BLJ9EPvWne_9pvN8MCSBS3E-2MpQKL89GZDOMjcQ@mail.gmail.com>
 <846EF988-50E9-48F3-8F33-AEA01A8C35A5@apache.org> <1465311433317.96400@hortonworks.com>
 <CAMs9kVj1CXwG1i_kvBsC0EgfjFqOsS2E=C1-nD8RnDQWC_mtNw@mail.gmail.com> <CACRbFyhxnnGCz3vdf5RcX-sbsEFKVQepR-n0utDnY4_cmQzwEA@mail.gmail.com>
From: Ravi Prakash <ravihadoop@gmail.com>
Date: Tue, 7 Jun 2016 12:02:29 -0700
Message-ID: <CAMs9kVhtNPaNe4EyQX+W8dx1sK493DyrLmzpDW-enSidBNxvxw@mail.gmail.com>
Subject: Re: Why there are so many revert operations on trunk?
To: larry mccay <larry.mccay@gmail.com>
Cc: Junping Du <jdu@hortonworks.com>, Vinod Kumar Vavilapalli <vinodkv@apache.org>,
	Andrew Wang <andrew.wang@cloudera.com>, "Aaron T. Myers" <atm@cloudera.com>,
	"common-dev@hadoop.apache.org" <common-dev@hadoop.apache.org>,
	"hdfs-dev@hadoop.apache.org" <hdfs-dev@hadoop.apache.org>,
	"mapreduce-dev@hadoop.apache.org" <mapreduce-dev@hadoop.apache.org>,
	"yarn-dev@hadoop.apache.org" <yarn-dev@hadoop.apache.org>
Content-Type: multipart/alternative; boundary=001a113ecbfeb1a9d70534b4d481
archived-at: Tue, 07 Jun 2016 19:02:41 -0000

--001a113ecbfeb1a9d70534b4d481
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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 opinion=
s
>> 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 vo=
te
>> -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 yo=
u
>> 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 trun=
k
>> > 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=E2=80=99t h=
ave 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 se=
e
>> we
>> > ever do either thing in this case.
>> >
>> >
>> > - Freaking out on -1=E2=80=99s 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=E2=80=99t have happened
>> > - After a few objections were raised, commits should have simply stopp=
ed
>> > before restarting again but only after consensus
>> > - Reverts (or revert and move to a feature-branch) shouldn=E2=80=99t h=
ave 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=E2=80=99s 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=E2=80=99=
ve never
>> made
>> > releases out of trunk. So in-progress features that people deemed to n=
ot
>> > 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=E2=80=99t put in-progress stuff and (b) the contributors saying =
=E2=80=9Cno we don=E2=80=99t
>> > want the overhead of a branch=E2=80=9D. I=E2=80=99ve raised related to=
pics (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 hol=
d
>> 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=E2=80=99d discuss with fellow community members bef=
ore making
>> > what the other side perceives as unacceptable moves.
>> >
>> > From 2.8.0 perspective, it shouldn=E2=80=99t 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 impac=
t
>> on
>> > the user story, having a by-default switched-off feature that *doesn=
=E2=80=99t*
>> > destabilize the core release, I=E2=80=99d be willing to let it pass.
>> >
>> > +Vinod
>> >
>>
>
>

--001a113ecbfeb1a9d70534b4d481--