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
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 <[EMAIL PROTECTED]> 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