Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 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).
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB