hadoop-hdfs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Douglas <cdoug...@apache.org>
Subject Re: VOTE: HDFS-347 merge
Date Wed, 27 Feb 2013 23:29:24 GMT
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 <sanjay@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

Mime
View raw message