hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Allen Wittenauer ...@altiscale.com>
Date Wed, 23 Sep 2015 01:21:21 GMT

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 <cmccabe@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 <aw@altiscale.com> wrote:
>> On Sep 14, 2015, at 5:15 PM, Colin P. McCabe <cmccabe@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.

View raw message