Suresh offered to write a patch restoring HDFS-2246, so unless his timeline is unacceptable, I think we're done.
On Wed, Feb 27, 2013 at 11:45 AM, sanjay Radia <san...@hortonworks.com> wrote: > 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. > Chris argues well in an earlier email to remove 2246 on its own time and that > there is precedent for doing so: Snippet of his email below: I must have been unclear. HDFS-347 supports a subset of the current users of HDFS-2246, so some devs have asked for time to accommodate them. There's ample precedent for *that*, even when the implementation of the obsolete feature is flawed. However, that accommodation was rarely indefinite, and usually scoped to a release or two. As one of the examples: combiners incompatible with Pig's use required a config knob in a patch version; it was removed in the subsequent release. The details matter, so no policy is possible, but parties may consider the pressure applied by removing HDFS-2246 in trunk as sufficient and appropriate, even if HDFS-2246 lives on in the 2.x branch. FWIW, I think that's the compromise solution. -C > On Feb 20, 2013, at 4:29 PM, Chris Douglas wrote: > >> There's >> ample precedent for retaining obscure, clumsy features as a temporary >> stop-gap (e.g., service plugins, opaque blobs of bytes in Tasks, >> configurable combiner semantics). What's the virtue of insisting on >> removing this? > > > sanjay
