Mailing-List: contact hdfs-dev-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
MIME-Version: 1.0
In-Reply-To: <846EF988-50E9-48F3-8F33-AEA01A8C35A5@apache.org>
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>
From: larry mccay <lmccay@apache.org>
Date: Mon, 6 Jun 2016 17:12:56 -0400
Message-ID: <CACRbFygU=iBGDLGJEbxH-qzNRDRVwVhJ_35xvehKf+8OCVapjg@mail.gmail.com>
Subject: Re: Why there are so many revert operations on trunk?
To: Vinod Kumar Vavilapalli <vinodkv@apache.org>
Cc: Andrew Wang <andrew.wang@cloudera.com>, Junping Du <jdu@hortonworks.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=001a1135b7f05072710534a2895e
archived-at: Mon, 06 Jun 2016 21:12:59 -0000

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

inline....


On Mon, Jun 6, 2016 at 4:36 PM, Vinod Kumar Vavilapalli <vinodkv@apache.org=
>
wrote:

> 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.
>
>
Agreed.


> 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 t=
hat 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) t=
he
> RM saying "no, don=E2=80=99t put in-progress stuff and (b) the contributo=
rs saying
> =E2=80=9Cno we don=E2=80=99t want the overhead of a branch=E2=80=9D. I=E2=
=80=99ve raised related topics
> (but only focusing on incompatible changes) before -
> http://markmail.org/message/m6x73t6srlchywsn <
> 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.
>

+1

In essence, by moving commits to a feature branch so that we can release
from trunk is creating a "trunk-branch". :)


> > * 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, b=
ut
> > 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

--001a1135b7f05072710534a2895e--