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: domain of sebbaz@gmail.com designates
 209.85.214.175 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CADwPi+EKaN=6_Qg4r81KDDNjJ8X8qSz-BXFo6WriQw8SQJmkwQ@mail.gmail.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>
	<20120308230916.GA18722@rectangular.com>
	<CADwPi+EKaN=6_Qg4r81KDDNjJ8X8qSz-BXFo6WriQw8SQJmkwQ@mail.gmail.com>
Date: Fri, 9 Mar 2012 10:23:12 +0000
Message-ID: 
 <CAOGo0VbMnu-vWHD4DZSvwzh03XDYQ4fJZ0QCN0krHrdb6LvQ0w@mail.gmail.com>
Subject: Re: [DISCUSS] - Packages renaming and backward compatibility (was:
 Re: [VOTE] Graduate Sqoop podling from Apache Incubator)
From: sebb <sebbaz@gmail.com>
To: general@incubator.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 9 March 2012 05:42, Alex Karasulu <akarasulu@apache.org> wrote:
> On Fri, Mar 9, 2012 at 1:09 AM, Marvin Humphrey <marvin@rectangular.com>w=
rote:
>
>> 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 issue=
s.
>> 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 wor=
ds.
>> > >
>> > > 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.
>> =A0In
>> > > 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. =A0It seems as th=
ough
>> there may be good reasons why exceptions should be made on a case-by-cas=
e
>> basis, as Doug implies.
>>
>>
> +1
>
>
>> The second was the community issue of potentially advantaging a commerci=
al
>> entity; this response seemed to satisfy people:
>>
>> =A0 =A0http://s.apache.org/mz
>>
>>
> +1
>
>
>> =A0 =A0In fact, Sqoop already has a plan in place to completely remove
>> =A0 =A0com.cloudera.* namespace from its contents via the next major rev=
ision
>> of
>> =A0 =A0the product. The work for that has already started and currently =
exists
>> =A0 =A0under the branch sqoop2 [3], tracked by SQOOP-365 [4]. We hope th=
at in a
>> =A0 =A0few months time, we will have feature parity in this branch with =
the
>> =A0 =A0trunk, 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 n=
ot
> 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, us=
ed
> 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 ha=
ve
> 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 case=
s
> 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 a=
nd
> 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