hadoop-hdfs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Colin McCabe <cmcc...@alumni.cmu.edu>
Subject Re: VOTE: HDFS-347 merge
Date Wed, 27 Feb 2013 23:28:16 GMT
Here is a compromise proposal, which hopefully will satisfy both sides:
We keep the old block reader and have a configuration option that enables it.

So in addition to dfs.client.use.legacy.blockreader, which we already
have, we would have dfs.client.use.legacy.blockreader.local.

Does that make sense?


On Wed, Feb 27, 2013 at 12:06 PM, Eli Collins <eli@cloudera.com> wrote:
> On Wed, Feb 27, 2013 at 11:45 AM, sanjay Radia <sanjay@hortonworks.com> wrote:
>> On Feb 26, 2013, at 1:51 PM, Eli Collins wrote:
>>> it doesn't seem right to hold up 347 up for Windows support given that
>>> Windows support has not been merged to trunk yet, is not in any Apache
>>> release, etc. Personally I don't like establishing the precedent here
>>> that we can hold up a merge due to requirements from an unmerged
>>> branch.
>> It is not being held back of for the windows port. It is being held back because
2246 should not be removed as part of 347; a separate jira should had been filed to remove
> This isn't about just having a separate jira though right?  We could
> easily pull the change out to two jiras (one removes 2246 and then
> next adds 347), they weren't separated because the goal for 347 was to
> be a re-write of the same feature (direct reads).  You commented on
> 2246 that it is a temporary workaround for 347, do you no longer feel
> that way?  Your reply to ATM made it seem like this was something that
> we'd be maintaining for a while (vs being a stopgap until 347 adds
> Windows support).

View raw message