Re: [DISCUSS] - Packages renaming and backward compatibility (was: Re: [VOTE] Graduate Sqoop podling from Apache Incubator)
On 9 March 2012 05:42, Alex Karasulu wrote: > On Fri, Mar 9, 2012 at 1:09 AM, Marvin Humphrey 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 >> 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
[VOTE] [Result] Release jena-tdb-0.9.0-incubating (RC-5)
On 04/03/12 22:19, Andy Seaborne wrote: The Jena PPMC has voted to release Apache Jena TDB 0.9.0-incubating and we would now be grateful if members of IPMC would review and vote for this release. -- ... Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Don't release, because ... This vote will be open until: Wednesday 7/March 23:59 UTC (3 whole days: 72 hours from the same hour tonight). Result of the vote for release of Jena TDB 0.9.0 (RC-5) on jena-dev: The vote passes. +1 votes: 3 IPMC votes: Benson Margulies ant elder Leo Simons 0 votes: none -1 votes: none Call for the VOTE email and thread: Vote started 2012-03-04: http://mail-archives.apache.org/mod_mbox/incubator-general/201203.mbox/%3C4F53EA65.4030604%40apache.org%3E Thanks everyone, Andy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Graduate Apache Accumulo to TLP
On Thursday, March 8, 2012 11:27:54 AM, "Bertrand Delacretaz" wrote: > On Mon, Mar 5, 2012 at 3:49 PM, Billie J Rinaldi > wrote: > > ... RESOLVED, that the persons listed immediately below be and > > hereby are appointed to serve as the initial members of the > > Apache Accumulo Project: > > > > * Aaron Cordova > > * Adam Fuchs > > * Billie Rinaldi > > * Chris Waring > > * Eric Newton > > * Keith Turner > > * David Medinets > > * John Vines > > Sorry if I missed a discussion on this - I think it's good for a PMC > to include at least one ASF member, would one of your mentors agree to > stay on the PMC for a while? Benson agreed to stay on our PMC. He is included in the revised resolution below. Billie X. Establish the Apache Accumulo Project WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software related to a robust, scalable distributed key/value store with cell-based access control and customizable server-side processing for distribution at no charge to the public. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the "Apache Accumulo Project", be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache Accumulo Project be and hereby is responsible for the creation and maintenance of software related to a robust, scalable distributed key/value store with cell-based access control and customizable server-side processing and be it further RESOLVED, that the office of "Vice President, Apache Accumulo" be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache Accumulo Project, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache Accumulo Project; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache Accumulo Project: * Aaron Cordova * Adam Fuchs * Billie Rinaldi * Benson Margulies * Chris Waring * Eric Newton * Keith Turner * David Medinets * John Vines NOW, THEREFORE, BE IT FURTHER RESOLVED, that Billie Rinaldi be appointed to the office of Vice President, Apache Accumulo, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the initial Apache Accumulo PMC be and hereby is tasked with the creation of a set of bylaws intended to encourage open development and increased participation in the Apache Accumulo Project; and be it further RESOLVED, that the Apache Accumulo Project be and hereby is tasked with the migration and rationalization of the Apache Incubator Accumulo podling; and be it further RESOLVED, that all responsibilities pertaining to the Apache Incubator Accumulo podling encumbered upon the Apache Incubator Project are hereafter discharged. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
