hadoop-yarn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Wang <andrew.w...@cloudera.com>
Subject Re: Why there are so many revert operations on trunk?
Date Mon, 06 Jun 2016 17:56:58 GMT
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
* 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.


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