Eli, please see my earlier response below.
On Wed, Feb 20, 2013 at 5:12 PM, Aaron T. Myers <a...@cloudera.com> 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 <e...@cloudera.com> To: "hdfs-dev@hadoop.apache.org" <hdfs-dev@hadoop.apache.org> 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 <cdoug...@apache.org> wrote: > On Wed, Feb 20, 2013 at 5:12 PM, Aaron T. Myers <a...@cloudera.com> 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?
