I don’t whether your ability to completely miss my point every time we communicate with each other, regardless of the issue, is intentional or just a special talent.
On Sep 22, 2015, at 8:52 AM, Colin P. McCabe <cmcc...@apache.org> wrote: > 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.
