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
