Return-Path: X-Original-To: apmail-hadoop-hdfs-dev-archive@minotaur.apache.org Delivered-To: apmail-hadoop-hdfs-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id D38FAEBE0 for ; Wed, 27 Feb 2013 23:29:25 +0000 (UTC) Received: (qmail 83755 invoked by uid 500); 27 Feb 2013 23:29:25 -0000 Delivered-To: apmail-hadoop-hdfs-dev-archive@hadoop.apache.org Received: (qmail 83692 invoked by uid 500); 27 Feb 2013 23:29:25 -0000 Mailing-List: contact hdfs-dev-help@hadoop.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: hdfs-dev@hadoop.apache.org Delivered-To: mailing list hdfs-dev@hadoop.apache.org Received: (qmail 83683 invoked by uid 99); 27 Feb 2013 23:29:25 -0000 Received: from minotaur.apache.org (HELO minotaur.apache.org) (140.211.11.9) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 27 Feb 2013 23:29:24 +0000 Received: from localhost (HELO mail-da0-f51.google.com) (127.0.0.1) (smtp-auth username cdouglas, mechanism plain) by minotaur.apache.org (qpsmtpd/0.29) with ESMTP; Wed, 27 Feb 2013 23:29:24 +0000 Received: by mail-da0-f51.google.com with SMTP id z17so538937dal.10 for ; Wed, 27 Feb 2013 15:29:24 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.68.231.70 with SMTP id te6mr5903770pbc.159.1362007764242; Wed, 27 Feb 2013 15:29:24 -0800 (PST) Received: by 10.68.17.67 with HTTP; Wed, 27 Feb 2013 15:29:24 -0800 (PST) In-Reply-To: <6F5A2C28-5F30-48DC-9447-09011D81DE9C@hortonworks.com> References: <1361390182.5901.YahooMailNeo@web125703.mail.ne1.yahoo.com> <1361401264.85659.YahooMailNeo@web125704.mail.ne1.yahoo.com> <1361401736.24828.YahooMailNeo@web125701.mail.ne1.yahoo.com> <1361586776.37406.YahooMailNeo@web125704.mail.ne1.yahoo.com> <1361825439.94263.YahooMailNeo@web125705.mail.ne1.yahoo.com> <6F5A2C28-5F30-48DC-9447-09011D81DE9C@hortonworks.com> Date: Wed, 27 Feb 2013 15:29:24 -0800 Message-ID: Subject: Re: VOTE: HDFS-347 merge From: Chris Douglas To: hdfs-dev@hadoop.apache.org Content-Type: text/plain; charset=ISO-8859-1 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 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