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
Tsz Wo Sze 2013-02-23, 02:32
Eli, please see my earlier response below.
On Wed, Feb 20, 2013 at 5:12 PM, Aaron T. Myers <[EMAIL PROTECTED]> wrote:

> Given that the only substantive concerns with HDFS-347 seem to be about
> Windows support for local reads, for now we only merge this branch to trunk.

Another
 substantive concern is that HDFS-347 is not as well tested as
HDFS-2246.  So, we should keep HDFS-2246 around for sometime and remove
it later.  Is this the usual practice?

HDFS-347 and HDFS-2246 are
 not mutually exclusive.  I don't understand why we must remove
HDFS-2246 immediately but not allow them to coexist.

Tsz-Wo

________________________________
 From: Eli Collins <[EMAIL PROTECTED]>
To: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
Sent: Friday, February 22, 2013 1:55 PM
Subject: Re: VOTE: HDFS-347 merge
 
On Thu, Feb 21, 2013 at 1:24 PM, Chris Douglas <[EMAIL PROTECTED]> wrote:
> On Wed, Feb 20, 2013 at 5:12 PM, Aaron T. Myers <[EMAIL PROTECTED]> wrote:
>> Given that the only substantive concerns with HDFS-347 seem to be about
>> Windows support for local reads, for now we only merge this branch to
>> trunk. Support for doing HDFS-2246 style local reads will be removed from
>> trunk, but retained in branch-2 for now. Only once someone adds support for
>> doing HDFS-347 style local reads which work on Windows will we consider
>> merging HDFS-347 to branch-2. This should ensure that there's no feature
>> regression on branch-2, but also means that we will not need to maintain
>> the HDFS-2246 code path alongside the HDFS-347 code path indefinitely.
>
> This seems reasonable, though retaining HDFS-2246 in branch-2 could be
> a workaround if a Windows port of HDFS-347 is not forthcoming. -C

This seems reasonable to me as well.  Nicholas, Suresh - how does this
sound to you?