Mailing-List: contact yarn-dev-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
MIME-Version: 1.0
In-Reply-To: <1465311433317.96400@hortonworks.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>
From: Ravi Prakash <ravihadoop@gmail.com>
Date: Tue, 7 Jun 2016 10:15:42 -0700
Message-ID: <CAMs9kVj1CXwG1i_kvBsC0EgfjFqOsS2E=C1-nD8RnDQWC_mtNw@mail.gmail.com>
Subject: Re: Why there are so many revert operations on trunk?
To: Junping Du <jdu@hortonworks.com>
Cc: 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=001a11448756bdd22f0534b3564b
archived-at: Tue, 07 Jun 2016 17:15:55 -0000

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

+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 ho=
ld
> 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 ju=
st
> like Larry mentioned.
>
>
> - Reverts (or revert and move to a feature-branch) shouldn=E2=80=99t have=
 been
> unequivocally done without dropping a note / informing everyone / buildin=
g
> 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 w=
e
> 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 stopped
> before restarting again but only after consensus
> - Reverts (or revert and move to a feature-branch) shouldn=E2=80=99t have=
 been
> unequivocally done without dropping a note / informing everyone / buildin=
g
> 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=99ve =
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 tha=
t
> 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 topic=
s (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 o=
ff
> 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 absenc=
e
> 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 before=
 making
> what the other side perceives as unacceptable moves.
>
> From 2.8.0 perspective, it shouldn=E2=80=99t have landed there in the fir=
st 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 o=
n
> 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
>

--001a11448756bdd22f0534b3564b--