hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Colin P. McCabe" <cmcc...@apache.org>
Date Wed, 23 Sep 2015 20:19:11 GMT
I don't understand your negative tone.  What point specifically did I
and other people in the conversation miss?


On Tue, Sep 22, 2015 at 6:21 PM, Allen Wittenauer <aw@altiscale.com> wrote:
> 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