Re: [VOTE] Release Apache Tashi 201203-incubating
Looks good to me, +1 ...ant On Thu, Mar 8, 2012 at 1:32 AM, Michael Stroucken mxs+apa...@cmu.edu wrote: Hi, The Tashi project is excited to ask the incubator for approval to make our second release. The vote passed the project PPMC as follows:- +1 (binding) * 3: Michael (PPMC), Richard (PPMC), Craig Russell (IPMC) +1 (nonbinding) * 0 -1: 0 Vote thread: http://s.apache.org/VmW Result thread: http://s.apache.org/GAn Release artifacts are at http://people.apache.org/~stroucki/tashi-201203/ Release was built from tag http://svn.apache.org/repos/asf/incubator/tashi/tags/APACHE_TASHI_201203. We need 2 more binding +1s from IPMC people for the vote to pass. Thanks, Michael. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release jena-tdb-0.9.0-incubating (RC-5)
+1 ...ant On Sun, Mar 4, 2012 at 10:19 PM, Andy Seaborne a...@apache.org 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. -- Main changes from RC-4: + Added license to scripts, and XML files. small test files don't have a license; test manifests do. + New layout of dist/ http://markmail.org/message/oh5stsl2ikbslobs -- PPMC vote: http://mail-archives.apache.org/mod_mbox/incubator-jena-dev/201202.mbox/%3C4F4E9B97.7060901%40apache.org%3E We have one IPMC +1 from this thread. Staging repository: https://repository.apache.org/content/repositories/orgapachejena-001/ Proposed dist/ area: http://people.apache.org/~andy/dist-jena-tdb-0.9.0-incubating-RC-5/ This will be added to the existing released modules. Keys: http://www.apache.org/dist/incubator/jena/KEYS SVN tag: https://svn.apache.org/repos/asf/incubator/jena/Jena2/TDB/tags/jena-tdb-0.9.0-incubating-RC-5/ The module is tagged with the version and RC-5 to indicate the release candidate in this release cycle. If voted on successfully, the tag will be changed (svn mv) to the same name but minus the RC designation. 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). Andy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Thoughts on Incubator board reports
On Mon, Mar 5, 2012 at 11:29 PM, Jukka Zitting jukka.zitt...@gmail.com wrote: While there was no clear single message, the overall impression I got was that the board expects the Incubator PMC to provide better and more active oversight on podlings. And that seems understandable, however IMHO the lazer beam focus we now have on the quarterly reports doesn't necessarily help get better or active oversight, in fact it makes it even easier for mentors to just pop up every few months and mention/sign a report and then disappear for the rest of the time. Looking at how many poddlings struggle to get votes on releases maybe what we need to have is a bit of actively retiring mentors so we can get a clearer picture of who is really providing oversight on poddlings. ...ant - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release jena-tdb-0.9.0-incubating (RC-5)
Thank you ant. We still need 2 more votes, right? Paolo ant elder wrote: +1 ...ant On Sun, Mar 4, 2012 at 10:19 PM, Andy Seaborne a...@apache.org 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. -- Main changes from RC-4: + Added license to scripts, and XML files. small test files don't have a license; test manifests do. + New layout of dist/ http://markmail.org/message/oh5stsl2ikbslobs -- PPMC vote: http://mail-archives.apache.org/mod_mbox/incubator-jena-dev/201202.mbox/%3C4F4E9B97.7060901%40apache.org%3E We have one IPMC +1 from this thread. Staging repository: https://repository.apache.org/content/repositories/orgapachejena-001/ Proposed dist/ area: http://people.apache.org/~andy/dist-jena-tdb-0.9.0-incubating-RC-5/ This will be added to the existing released modules. Keys: http://www.apache.org/dist/incubator/jena/KEYS SVN tag: https://svn.apache.org/repos/asf/incubator/jena/Jena2/TDB/tags/jena-tdb-0.9.0-incubating-RC-5/ The module is tagged with the version and RC-5 to indicate the release candidate in this release cycle. If voted on successfully, the tag will be changed (svn mv) to the same name but minus the RC designation. 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). Andy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Request for an early review of an potential Apache OpenOffice release
Hi, the Apache OpenOffice podling project is moving forward to a first release that is long expected by the OpenOffice.org community and users. You know that Apache OpenOffice is the continuation of OpenOffice.org and that the project is very huge, has a very long history and a very huge user base all over the world. IP clearance work to conform to Apache standards or to conform to the Apache Way and we would like to get some early feedback if we are in shape with the Apache guidelines for a potential release. We have prepared developer snapshots over the past several weeks for our project members to test and review. This developer snapshots can be found under Source package http://people.apache.org/~jsc/developer-snapshots/src_releases/srcrelease.html Binary package https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+3.4+Unofficial+Developer+Snapshots The mac version is also signed and the check files can be found in the download directory directly http://people.apache.org/~jsc/developer-snapshots/macos/r1296433/ NOTE: Be careful with the binary packages and save your office user profiles before testing. Existing OOo 3.x installations will be overwritten. We provide full install sets to test system integration and upgrades. Currently we are not able to migrate installed extensions. And there won't be bundled dictionaries but you can download a dictionary from the migrated extensions repository (http://aoo-extensions.sourceforge.net/). But of course we are working on this. Please rename your user profile before testing our snapshot build, and re-rename your user profile after reinstalling a stable OOo version. Right now we are focusing on show stopper issues but nevertheless we would like to invite you to review the source packages and also the binary packages if they fulfill the Apache requirements (e.g license, NOTICE, ...) We know that we have no release candidate (RC) right now and that it would require some work by you. But because of the complexity of the project we would very much appreciate any kind of early feedback at this time. And the main goal is to fix potential issues early and to save time later on when we have a first RC in place. On behalf of the Apache OpenOffice PPMC Juergen - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release jena-tdb-0.9.0-incubating (RC-5)
On 08/03/12 09:14, Paolo Castagna wrote: Thank you ant. We still need 2 more votes, right? We need one more IPMC vote. We have Benson on the project vote thread on jena-dev@i and ant from general@i. Please - one more IPMC +1! Andy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release jena-tdb-0.9.0-incubating (RC-5)
Andy Seaborne wrote: On 08/03/12 09:14, Paolo Castagna wrote: Thank you ant. We still need 2 more votes, right? We need one more IPMC vote. Ops, sorry about that. We have Benson on the project vote thread on jena-dev@i and ant from general@i. Sorry Benson. Please - one more IPMC +1! Ok. Thanks Andy, Paolo Andy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] - Packages renaming and backward compatibility (was: Re: [VOTE] Graduate Sqoop podling from Apache Incubator)
On Thu, Mar 8, 2012 at 2:31 AM, Alex Karasulu akaras...@apache.org wrote: On Thu, Mar 1, 2012 at 3:03 AM, Leo Simons m...@leosimons.com wrote: On Wed, Feb 29, 2012 at 3:00 PM, Benson Margulies bimargul...@gmail.com wrote: Leo, are you out there? Hmm? Oh, this again... Having company names or trademarks in java namespaces is a pretty stupid convention. It gets us mess like this... There is no policy that incubating java projects must rename to use an org.apache namespace. There has never been such a policy. We don't need such a policy. There's (typically/usually/knock on wood) no legal/trademark issue. There's ample precedent of keeping 'legacy' namespaces around 'a while' for backwards compatibility. And that's fine. At the same time, (incubating) projects should definitely carefully consider whether it is reasonable to change their namespaces, how to go about it, etc. Incubation can be a good time and/or trigger to make such changes, especially for projects for whom backwards compatibility isn't a big issue (yet) or that are doing a major revision as part of coming here. With my incubator PMC hat on, I like to see that a project community has thought this situation through, discussed it on their dev list, and got to some kind of consensus on what to do. I'd imagine such plans will include a strategy for eventually having all their code end up in an org.apache namespace or at least not in a com.company namespace. I'm sure other people said all this already, apologies for the noise, but hey, I got prodded, so... :-) cheerio, Leo 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. Alex, there's an educational opportunity out there, yes. Best, Alex - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] - Packages renaming and backward compatibility (was: Re: [VOTE] Graduate Sqoop podling from Apache Incubator)
On Thu, Mar 8, 2012 at 6:05 PM, Benson Margulies bimargul...@gmail.comwrote: On Thu, Mar 8, 2012 at 2:31 AM, Alex Karasulu akaras...@apache.org wrote: On Thu, Mar 1, 2012 at 3:03 AM, Leo Simons m...@leosimons.com wrote: On Wed, Feb 29, 2012 at 3:00 PM, Benson Margulies bimargul...@gmail.com wrote: Leo, are you out there? Hmm? Oh, this again... Having company names or trademarks in java namespaces is a pretty stupid convention. It gets us mess like this... There is no policy that incubating java projects must rename to use an org.apache namespace. There has never been such a policy. We don't need such a policy. There's (typically/usually/knock on wood) no legal/trademark issue. There's ample precedent of keeping 'legacy' namespaces around 'a while' for backwards compatibility. And that's fine. At the same time, (incubating) projects should definitely carefully consider whether it is reasonable to change their namespaces, how to go about it, etc. Incubation can be a good time and/or trigger to make such changes, especially for projects for whom backwards compatibility isn't a big issue (yet) or that are doing a major revision as part of coming here. With my incubator PMC hat on, I like to see that a project community has thought this situation through, discussed it on their dev list, and got to some kind of consensus on what to do. I'd imagine such plans will include a strategy for eventually having all their code end up in an org.apache namespace or at least not in a com.company namespace. I'm sure other people said all this already, apologies for the noise, but hey, I got prodded, so... :-) cheerio, Leo 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. Alex, there's an educational opportunity out there, yes. Indeed. It might be a good idea perhaps to have every project at a minimum publish an informative section on their site listing any kind of intrusion into package spaces that are not owned by the project. This way at a minimum there is some awareness. -- Best Regards, -- Alex
Re: [DISCUSS] - Packages renaming and backward compatibility (was: Re: [VOTE] Graduate Sqoop podling from Apache Incubator)
On Thu, Mar 8, 2012 at 11:13 AM, Alex Karasulu akaras...@apache.org wrote: On Thu, Mar 8, 2012 at 6:05 PM, Benson Margulies bimargul...@gmail.comwrote: On Thu, Mar 8, 2012 at 2:31 AM, Alex Karasulu akaras...@apache.org wrote: On Thu, Mar 1, 2012 at 3:03 AM, Leo Simons m...@leosimons.com wrote: On Wed, Feb 29, 2012 at 3:00 PM, Benson Margulies bimargul...@gmail.com wrote: Leo, are you out there? Hmm? Oh, this again... Having company names or trademarks in java namespaces is a pretty stupid convention. It gets us mess like this... There is no policy that incubating java projects must rename to use an org.apache namespace. There has never been such a policy. We don't need such a policy. There's (typically/usually/knock on wood) no legal/trademark issue. There's ample precedent of keeping 'legacy' namespaces around 'a while' for backwards compatibility. And that's fine. At the same time, (incubating) projects should definitely carefully consider whether it is reasonable to change their namespaces, how to go about it, etc. Incubation can be a good time and/or trigger to make such changes, especially for projects for whom backwards compatibility isn't a big issue (yet) or that are doing a major revision as part of coming here. With my incubator PMC hat on, I like to see that a project community has thought this situation through, discussed it on their dev list, and got to some kind of consensus on what to do. I'd imagine such plans will include a strategy for eventually having all their code end up in an org.apache namespace or at least not in a com.company namespace. I'm sure other people said all this already, apologies for the noise, but hey, I got prodded, so... :-) cheerio, Leo 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. Alex, there's an educational opportunity out there, yes. Indeed. It might be a good idea perhaps to have every project at a minimum publish an informative section on their site listing any kind of intrusion into package spaces that are not owned by the project. This way at a minimum there is some awareness. The first problem we have here is that various well-meaning people don't understand the interactions of maven publication, TLP turf, and classpath management. Policy/practical advice on this could come out of commdev and then the incubator could merely be in the business of pushing people to it. -- Best Regards, -- Alex - 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 Mon, Mar 5, 2012 at 3:49 PM, Billie J Rinaldi billie.j.rina...@ugov.gov 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 acord...@apache.org * Adam Fuchs afu...@apache.org * Billie Rinaldi bil...@apache.org * Chris Waring cawar...@apache.org * Eric Newton e...@apache.org * Keith Turner ktur...@apache.org * David Medinets medi...@apache.org * John Vines vi...@apache.org 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? -Bertrand
Re: [DISCUSS] - Packages renaming and backward compatibility (was: Re: [VOTE] Graduate Sqoop podling from Apache Incubator)
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. Doug - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release jena-tdb-0.9.0-incubating (RC-5)
On Sun, Mar 4, 2012 at 11:19 PM, Andy Seaborne a...@apache.org 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. +1 from me. cheers, Leo - 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 Mon, Mar 5, 2012 at 3:49 PM, Billie J Rinaldi billie.j.rina...@ugov.gov wrote: Please vote on recommending the graduation of Apache Accumulo with the following resolution to the ASF Board. +1 from me. Well done, that was pretty fast :) Is it right that your PMC roster doesn't have apache members on it? That's fine, but I do hope your mentors stick around for a bit...it tends to help 'grease the wheels' during your transition to PMC. cheers, Leo - 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
I'm willing to be added or voted if the community wants to keep me around. On Thu, Mar 8, 2012 at 5:03 PM, Leo Simons m...@leosimons.com wrote: On Mon, Mar 5, 2012 at 3:49 PM, Billie J Rinaldi billie.j.rina...@ugov.gov wrote: Please vote on recommending the graduation of Apache Accumulo with the following resolution to the ASF Board. +1 from me. Well done, that was pretty fast :) Is it right that your PMC roster doesn't have apache members on it? That's fine, but I do hope your mentors stick around for a bit...it tends to help 'grease the wheels' during your transition to PMC. cheers, Leo - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Thoughts on Incubator board reports
Hey hey, Jukka this is sounding so timid :). You know, I think I'll break rank and tell you what I really think. You may want to sit down first. You [1] did a *kick ass* job on the last report. Kick. Ass. [2]. Kapow! As well as spending the time to look through and digest it all beforehand on e-mail, you made sure we had discussion about it. Which btw, wasn't a flamewar, which was nice, too. I know that prompted me to do a similar run-through on half of your list (I ran out of steam/time...I guess I'll start at the bottom next time) and I simply found nothing to add, but I did do much more overseeing by following along than I would have done if, say, I had gotten nagged a couple thousand times more. So, definitely +1 to keep going like that, thanks for spelling it out too, you should know we got your back :) cheers, Leo [1] helped by others of course, yada yada, we so love all you bearded folks, you know who you are [2] http://images.allmoviephoto.com/2010_Kick-Ass/2010_kick-ass_001.jpg On Tue, Mar 6, 2012 at 12:29 AM, Jukka Zitting jukka.zitt...@gmail.com wrote: During the February board meeting there was a discussion about what the directors would like to see in Incubator reports. ... we should keep including the individual podling reports ... the IPMC should also provide a report summary along the lines of what we did last month. ... we should also highlight any notable issues or other topics the board may want to focus on. ... we'll take some time to discuss the podling reports - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Thoughts on Incubator board reports
Jukka's recent email and activity are precisely what I was hoping for when I joined the chorus of voices for new leadership. On this thread, I have a thought or two. Of the podlings I have known, most required very little supervision. The single largest exception has always been getting the first release or two through the gauntlet. I wish that there was a way to recruit the expert scrutinizers to help out up front. What if a podling could recruit Sebb or one of the other release aces to help them set up their structure in the first place? I bet it would be less work to teach than to critique. Not all of us are so good at this particular topic. The second largest exception is pushing projects to grow into sustainable communities. It's not easy. It's not guaranteed. Report review strikes me as a pretty good solution there. Historically, I know we've had podlings with other and more interesting problems, and that disengaged mentors only make that worse. But join Leo in thinking that good report reviewing is a great step all by itself. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] - Packages renaming and backward compatibility (was: Re: [VOTE] Graduate Sqoop podling from Apache Incubator)
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. -- Best Regards, -- Alex
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 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. 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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: HCatalog status (Was: [Incubator Wiki] Update of March2012 by AshutoshChauhan)
Hi, On Wed, Mar 7, 2012 at 8:06 PM, Alan Gates ga...@hortonworks.com wrote: Ashutosh made some changes to the report to address these points. Does that look good? Yes, thanks for the added detail! I'm hoping to see the community contributions turn into new HCatalog committers over the next quarter or so. I notice you already brought that task up on the PPMC private list about a month ago (Nice post, BTW! Would you mind posting a generalized version also to general@?), so it looks like you're all set for that to happen. BR, Jukka Zitting - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] - Packages renaming and backward compatibility (was: Re: [VOTE] Graduate Sqoop podling from Apache Incubator)
On Fri, Mar 9, 2012 at 1:09 AM, Marvin Humphrey mar...@rectangular.comwrote: 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
