incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <>
Subject Re: [DISCUSS] - Packages renaming and backward compatibility (was: Re: [VOTE] Graduate Sqoop podling from Apache Incubator)
Date Fri, 09 Mar 2012 10:23:12 GMT
On 9 March 2012 05:42, Alex Karasulu <> wrote:
> On Fri, Mar 9, 2012 at 1:09 AM, Marvin Humphrey <>wrote:
>> 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.
> +1
>> The second was the community issue of potentially advantaging a commercial
>> entity; this response seemed to satisfy people:
> +1
>>    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.
> I feel the Cloudera folks have benign concerns in this case and this is not
> an attempt to take advantage. As you reminded us above they're simply
> trying to facilitate compatibility to accomodate their users which is
> admirable. Also as Doug pointed out they're in control of both namespaces
> so they can handle it without conflict.
> However my primary point was when you start allowing this practice even
> just a little for benign, positive reasons (as is the case for Scoop), it
> can quickly lead to chaos through misuse, and result in community discord.
> It's not easy to quantify/clarify whether the usage is meant for good, used
> carelessly without consideration, or used explicitly to gain a commercial
> advantage. It's going to start ruffling feathers at some point or another
> when accusations start flying. Some folks are going to be pissed due to
> disruptions, some are going to be on a witch hunt, others are going to have
> valid concerns, some just won't care, while those accused will fight
> vehemently feeling unjustly attacked. In the end, this feels like a
> pandora's box. We just saw how damaging this can be with the recent
> Lucene/Solr incident concerning commons CSV. [Just using a reference here
> to minimise public discussion of a private list thread.]
> So is there a way we can allow the practice to occur at a minimal scale
> with positive gains, without the potential negative impact?
> My rather weak suggestion of having projects explicitly announce the cases
> where they "infringe" on another project or party's namespace just raises
> awareness and makes it so the potentially "infringing" party exposes it's
> intentions before accusations start flying. I'm sure there are better
> solutions to this problem where we minimize the administrative overhead and
> the negative impact. I just could not think of a better way at this point.

Isn't it about who owns and manages the namespace?

If the owner gives permission, then OK, otherwise not OK.

> --
> Best Regards,
> -- Alex

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message