On 9 March 2012 05:42, Alex Karasulu <akaras...@apache.org> wrote: > 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.
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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
