Mailing-List: contact general-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: general@incubator.apache.org
Received-SPF: pass (nike.apache.org: local policy)
Date: Thu, 8 Mar 2012 15:09:16 -0800
From: Marvin Humphrey <marvin@rectangular.com>
To: general@incubator.apache.org
Subject: Re: [DISCUSS] - Packages renaming and backward compatibility (was:
	Re: [VOTE] Graduate Sqoop podling from Apache Incubator)
Message-ID: <20120308230916.GA18722@rectangular.com>
References: 
 <CAOvkMoY8=PtxnXj-1O8YivLHpp47sVFTnvwVbNXhrCQbSJADWQ@mail.gmail.com>
 <CABD8fLX509hBGb-b0fbmrxFynipH0YDm_Pvj=UQ7WTxLw=Q92A@mail.gmail.com>
 <CADwPi+Hz2V=P-8acJDbxRQZ4PR_-b2nPJz8cGjrtfy0EC-hpdQ@mail.gmail.com>
 <CADwPi+Fek5M87YdEYQqRt57H-M0vs6OSKn=0eDxZg0FGB64e8g@mail.gmail.com>
 <CAOvkMobsfkxJ369NmXdkLmTpkBVFGW7qq_LWXuKHbLx5CCj1dA@mail.gmail.com>
 <CALhtWkdshjQ-Ta_2__ZgJrsrdZ85mnDugsqCoa8B-vju9pwdPg@mail.gmail.com>
 <CAJjdaOF_zMy-8vNCz0h6aOnkZ-xUTcawXcY-YQxCKiE_ZKYr6Q@mail.gmail.com>
 <CADwPi+Euh7Mgz-K=ZQtV6seX0fqwTVeMZBUhLcRXCSB=S0S=UQ@mail.gmail.com>
 <4F591D1C.8040800@apache.org>
 <CADwPi+FYPjNDf6+ddSKi-itXy37M37JWkQ5FcHjs1AH54UA+=g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
 <CADwPi+FYPjNDf6+ddSKi-itXy37M37JWkQ5FcHjs1AH54UA+=g@mail.gmail.com>
User-Agent: Mutt/1.5.18 (2008-05-17)

On Fri, Mar 09, 2012 at 12:43:47AM +0200, Alex Karasulu wrote:
> On Thu, Mar 8, 2012 at 10:57 PM, Doug Cutting <cutting@apache.org> wrote:
> 
> > On 03/07/2012 11:31 PM, Alex Karasulu wrote:
> > > Not trying to beat a dead horse to death here but I'm starting to think
> > > that we might have had some basis to these package namespace issues. The
> > > recent private Lucene-Commons threads show what can happen if this policy
> > > is that hmmm liberal. Don't know if that's the right choice of words.
> >
> > The differences between the cases should inform any policy.
> >
> > In one case you have the inclusion of an older package name for
> > back-compatibility by the same community that created the older API.  In
> > the other case you have the inclusion of an API that conflicts with one
> > managed by a different, still-active community.
> 
> 
> Regardless of the situation in which this occurs the potential problem is a
> namespace conflict. But I hear ya. The social situation is very different.

My impression was that there were two issues.

First was the technical issue of a namespace conflict.  It seems as though
there may be good reasons why exceptions should be made on a case-by-case
basis, as Doug implies.

The second was the community issue of potentially advantaging a commercial
entity; this response seemed to satisfy people:

    http://s.apache.org/mz

    In fact, Sqoop already has a plan in place to completely remove
    com.cloudera.* namespace from its contents via the next major revision of
    the product. The work for that has already started and currently exists
    under the branch sqoop2 [3], tracked by SQOOP-365 [4]. We hope that in a
    few months time, we will have feature parity in this branch with the
    trunk, which is when we will promote it to the trunk.

I would think that any generic policy would need to take both of those issues
into account.

Marvin Humphrey


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org