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 <e...@cloudera.com> wrote: > On Wed, Feb 27, 2013 at 11:45 AM, sanjay Radia <san...@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).
