Eli, you've sent the same email a half dozen times in the last ~24 hours. You might try a different tactic.
Suresh, if you're willing to "support and maintain" HDFS-2246, do you have cycles to propose a patch to the HDFS-347 branch reintegrating HDFS-2246 with the simplifications you outlined? In your review, did you find anything else you'd like to address prior to the merge, or is this the only item? -C On Tue, Feb 26, 2013 at 1:51 PM, Eli Collins <e...@cloudera.com> wrote: > On Tue, Feb 26, 2013 at 11:35 AM, Suresh Srinivas > <sur...@hortonworks.com> wrote: >>> >>> >>> I assume you mean in trunk? Given that ATM's proposal is to only >>> remove HDFS-2246 from branch-2 once (a) we're confident in HDFS-347 >>> and (b) adds Windows support, and we won't be releasing from trunk any >>> time soon - from a user perspective - HDFS-2246 will only be replaced >>> with HDFS-347 until it supports Windows. Ie ATM's compromise appears >>> to satisfy your requirement. >>> >> >> This means, HDFS-347 becomes available in branch-2 only when the >> corresponding windows work completes. Given that there is interest >> in HDFS-347 (see Andrew's email), not removing HDFS-2246 will make >> it available in an Apache release sooner. >> >> I am not sure why removing HDFS-2246 is so important in HDFS-347? Is it >> because you need to spend bunch of time to rework the code to add it back? > > Yes, this would require updating all the code to make the fallback > paths to work properly and re-testing. Given that all the patches > posted to 347 have removed 2246 for a while now (this is not a new > approach, Colin has been giving heads up months now about the patches > and the merge), and 2246 was supposed to be a short-term fix (2246 was > only supported on the condition that 347 was a wholesale replacement), > 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. > > We'd all like to see 347 show up in branch-2 soon, and the original > proposal to merge 347 accomplishes that, it's one of the downsides of > the compromise for Windows. > > Thanks, > Eli On Tue, Feb 26, 2013 at 1:51 PM, Eli Collins <e...@cloudera.com> wrote: > On Tue, Feb 26, 2013 at 11:35 AM, Suresh Srinivas > <sur...@hortonworks.com> wrote: >>> >>> >>> I assume you mean in trunk? Given that ATM's proposal is to only >>> remove HDFS-2246 from branch-2 once (a) we're confident in HDFS-347 >>> and (b) adds Windows support, and we won't be releasing from trunk any >>> time soon - from a user perspective - HDFS-2246 will only be replaced >>> with HDFS-347 until it supports Windows. Ie ATM's compromise appears >>> to satisfy your requirement. >>> >> >> This means, HDFS-347 becomes available in branch-2 only when the >> corresponding windows work completes. Given that there is interest >> in HDFS-347 (see Andrew's email), not removing HDFS-2246 will make >> it available in an Apache release sooner. >> >> I am not sure why removing HDFS-2246 is so important in HDFS-347? Is it >> because you need to spend bunch of time to rework the code to add it back? > > Yes, this would require updating all the code to make the fallback > paths to work properly and re-testing. Given that all the patches > posted to 347 have removed 2246 for a while now (this is not a new > approach, Colin has been giving heads up months now about the patches > and the merge), and 2246 was supposed to be a short-term fix (2246 was > only supported on the condition that 347 was a wholesale replacement), > 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. > > We'd all like to see 347 show up in branch-2 soon, and the original > proposal to merge 347 accomplishes that, it's one of the downsides of > the compromise for Windows. > > Thanks, > Eli
