Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
HDFS >> mail # dev >> VOTE: HDFS-347 merge


Copy link to this message
-
Re: VOTE: HDFS-347 merge
+1

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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote:
>> On Wed, Feb 27, 2013 at 11:45 AM, sanjay Radia <[EMAIL PROTECTED]> 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).