hadoop-hdfs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eli Collins <...@cloudera.com>
Subject Re: VOTE: HDFS-347 merge
Date Wed, 27 Feb 2013 23:42:55 GMT

It sounds like restoring 2246 to the 347 patch is the only path
forward (ie there will be zero compromise on a proposal that removes
2246 in any form) in which case this seems like a good way to
implement that (similar to what Sanjay suggested earlier). We can have
a separate jira for removing 2246 and/or adding Windows support to
347, and move the discussion about how long 2246 should last, and in
what branches there.

On Wed, Feb 27, 2013 at 3:28 PM, Colin McCabe <cmccabe@alumni.cmu.edu> wrote:
> 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
>> 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