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.w...@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 >
