incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marvin Humphrey <>
Subject Re: [DISCUSS] - Packages renaming and backward compatibility (was: Re: [VOTE] Graduate Sqoop podling from Apache Incubator)
Date Thu, 08 Mar 2012 23:09:16 GMT
On Fri, Mar 09, 2012 at 12:43:47AM +0200, Alex Karasulu wrote:
> On Thu, Mar 8, 2012 at 10:57 PM, Doug Cutting <> 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:

    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:
For additional commands, e-mail:

View raw message