I think it's extremely unrealistic to expect Hadoop to ever follow a branchless development model. In fact, the recent trend has been in the opposite direction-- prominent members of the community have pointed out that we don't have enough long-running, well-tested and well-supported branches. Producing such a branch was the goal of the ongoing 2.6.1 release effort. Even if we did somehow switch to a branchless development model, we have numerous people backporting patches to their own repositories-- both Hadoop vendors and large organizations that run Hadoop internally and have their own branches.
Branchless development especially doesn't make sense for HDFS, since it would force people to do time-consuming and potentially risky layout versions just to get small bugfixes. Very few cluster operators want to update the version of their data on-disk just to get this month's urgent bugfix. There are similar issues in other parts of the stack such as YARN. Anyway, as Steve pointed out in his original post, merge conflicts in CHANGES.txt are not the only problem caused by that file. It's simply very inaccurate and misleading, since it must be manually updated. In more than 3 years of working with Hadoop, I've never found CHANGES.txt useful for anything. git log and JIRA tell you everything you need to know. CHANGES.txt is a burden to update, misleading to operators, and a relic that should have been removed years ago. I really hope this CHANGES.txt thread doesn't peter out like the rest of them. Please, let's fix this, finally. Autogenerate this file. best, Colin On Mon, Sep 14, 2015 at 7:10 PM, Allen Wittenauer <a...@altiscale.com> wrote: > > On Sep 14, 2015, at 5:15 PM, Colin P. McCabe <cmcc...@apache.org> wrote: > >> Let's stay focused on the title of the thread-- CHANGES.txt-- and >> discuss issues surrounding releasing trunk in a separate thread. > > > It directly addresses the thread: if one isn’t cherry picking > patches because there aren’t multiple primary branches in development, the > changes.txt conflicts effectively go away.
