On Fri, Mar 9, 2012 at 1:09 AM, Marvin Humphrey <mar...@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 <cutt...@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
