Mailing-List: contact common-dev-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
MIME-Version: 1.0
In-Reply-To: <CAGB5D2Z1m3BLJ9EPvWne_9pvN8MCSBS3E-2MpQKL89GZDOMjcQ@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>
From: larry mccay <lmccay@apache.org>
Date: Mon, 6 Jun 2016 16:26:49 -0400
Message-ID: <CACRbFyisbrnbvrCRRb5wUBGmi8X9hWuem=EYeLWnHVcxaKwE_Q@mail.gmail.com>
Subject: Re: Why there are so many revert operations on trunk?
To: Andrew Wang <andrew.wang@cloudera.com>
Cc: 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=001a1141f5f66d7f620534a1e498
archived-at: Mon, 06 Jun 2016 20:26:54 -0000

--001a1141f5f66d7f620534a1e498
Content-Type: text/plain; charset=UTF-8

This seems like something that is going to probably happen again if we
continue to cut releases from trunk.
I know that this has been discussed at length in a separate thread but I
think it would be good to recognize that it is the core of the issue here.

Either we:

* need to define what will happen on trunk in such circumstances and
clearly communicate an action before taking it on the dev@ list or
* we need to not introduce this sort of thrashing on trunk by releasing
from it directly

My humble 2 cents...

--larry


On Mon, Jun 6, 2016 at 1:56 PM, Andrew Wang <andrew.wang@cloudera.com>
wrote:

> To clarify what happened here, I moved the commits to a feature branch, not
> just reverting the commits. The intent was to make it easy to merge back in
> later, and also to unblock the 2.8 and 3.0 releases we've been trying very
> hard to wrap up for weeks. This doesn't slow down development since you can
> keep committing to a branch, and I did the git work to make it easy to
> merge back in alter. I'm also happy to review the merge if the concern is
> getting three +1s.
>
> In the comments on HDFS-9924, you can see comments from a month ago raising
> concerns about the API and also that this significant expansion of the HDFS
> API is being done on release branches. There is an explicit -1 on continued
> commits to trunk, and a request to move the commits to a feature branch.
> Similar concerns have been raised by multiple contributors on that JIRA.
> Yet, the commits remained in release branches, and new patches continued to
> be committed to release branches.
>
> There's no need to attribute malicious intent to slow down feature
> development; for some reason I keep seeing this accusation thrown around
> when there are many people chiming in on HDFS-9924 with concerns about the
> feature. Considering how it's expanding the HDFS API, this is also the kind
> of work that should go through a merge vote anyway to get more eyes on it.
>
> We've been converging on the API requirements, but until the user-facing
> API is ready, I don't see the advantage of having this code in a release
> branch. As noted by the contributors on this JIRA, it's new separate code,
> so there's little to no overhead to keeping a feature branch in sync.
>
> So, to sum it up, I moved these commits to a branch because:
>
> * The discussion about the user API is still ongoing, and there is
> currently no user-facing API
> * We are very late in the 2.8 and 3.0 release cycles, trying to do blocker
> burndown
> * This code is separate and thus easy to keep in sync on a branch and merge
> in later
> * 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.
>
> Thanks,
> Andrew
>

--001a1141f5f66d7f620534a1e498--