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?

best,
Colin


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
it.
>
> 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).

Mime
View raw message