[
https://issues.apache.org/jira/browse/HADOOP-9151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13537565#comment-13537565
]
Todd Lipcon commented on HADOOP-9151:
-------------------------------------
{quote}
We are talking about Apache 2.0.x-alpha release here. How CDH manages its
distribution, backward compatibility does not guide how Apache releases are
done or what goes into Apache releases. The fact that you chose include a
content that is not in trunk or decided to tag a release in some other way
should not put constraints on the Apache releases. Wearing my Apache hat on, if
this is the main reason for -1, then it has no merit.
If there was no issue to CDH distribution, would you have objected to this
change?
I would like others to comment on why a vendor's distribution or compatibility
to it should put artificial constraints in Apache.
{quote}
Regardless of the existence of CDH, I would have argued that HDFS and Common
should have been labeled "Stable" months ago. For people who don't care to run
MR2, I've found HDFS2 to be far more stable than HDFS1, in addition to offering
many other benefits. But we've already beaten that horse to death on the
mailing list.
So, given that I already consider HDFS to be "stable", and know people running
this branch in production scenarios where a rolling upgrade is required, I
would make the same argument that we should not break compatibility.
bq. I would like others to comment on why a vendor's distribution or
compatibility to it should put artificial constraints in Apache.
There are lots of people out there using this distro. If we break
compatibility, people will have a harder time moving from the distro _back_ to
Apache, if that's the angle you want to look at it from.
----
If this issue were a case of a big performance improvement, or a security
issue, or even a feature improvement, I would weigh it stronger. But given that
it's a code cleanup that brings no improvement at all to users, and only a very
slight improvement for the 3 or 4 people in the world who are trying to
implement Hadoop-compatible RPC in another langauge (one of whom happens to be
me!), I think it needs much more motivation.
> Include RPC error info in RpcResponseHeader instead of sending it separately
> ----------------------------------------------------------------------------
>
> Key: HADOOP-9151
> URL: https://issues.apache.org/jira/browse/HADOOP-9151
> Project: Hadoop Common
> Issue Type: Sub-task
> Reporter: Sanjay Radia
> Assignee: Sanjay Radia
> Attachments: HADOOP-9151.patch
>
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
