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
