incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <akaras...@apache.org>
Subject Re: [DISCUSS] - Packages renaming and backward compatibility (was: Re: [VOTE] Graduate Sqoop podling from Apache Incubator)
Date Fri, 09 Mar 2012 05:42:39 GMT
On Fri, Mar 9, 2012 at 1:09 AM, Marvin Humphrey <marvin@rectangular.com>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 <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.
>
>
+1


> The second was the community issue of potentially advantaging a commercial
> entity; this response seemed to satisfy people:
>
>    http://s.apache.org/mz
>
>
+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.

-- 
Best Regards,
-- Alex

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message