You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by Marvin Humphrey <ma...@rectangular.com> on 2012/03/09 00:09:16 UTC
Re: [DISCUSS] - Packages renaming and backward compatibility (was:
Re: [VOTE] Graduate Sqoop podling from Apache Incubator)
On Fri, Mar 09, 2012 at 12:43:47AM +0200, Alex Karasulu wrote:
> On Thu, Mar 8, 2012 at 10:57 PM, Doug Cutting <cu...@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
Re: [DISCUSS] - Packages renaming and backward compatibility (was:
Re: [VOTE] Graduate Sqoop podling from Apache Incubator)
Posted by sebb <se...@gmail.com>.
On 9 March 2012 05:42, Alex Karasulu <ak...@apache.org> wrote:
> On Fri, Mar 9, 2012 at 1:09 AM, Marvin Humphrey <ma...@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 <cu...@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.
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: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] - Packages renaming and backward compatibility (was:
Re: [VOTE] Graduate Sqoop podling from Apache Incubator)
Posted by Alex Karasulu <ak...@apache.org>.
On Fri, Mar 9, 2012 at 1:09 AM, Marvin Humphrey <ma...@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 <cu...@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