Re: [VOTE] Subversion podling for graduation
On Thu, Feb 11, 2010 at 11:08 PM, Greg Stein gst...@gmail.com wrote: Hello all, I started a discussion thread a week-ish ago to seek out issues for Subversion's graduation. The couple bits that were raised[1] have been handled, I believe. So with that said, I am unaware of any potential showstoppers, and would like to request a vote for graduating the Subversion podling. Should this result in a successful vote, I will put a resolution before the Board (for its Feb 17 mtg) to construct a new Subversion PMC. Please vote: [ ] +1 Graduation [ ] -1 Hold, and continue incubating +1 -garrett - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL][VOTE] Subversion
On Tue, Nov 10, 2009 at 11:29 AM, Jochen Wiedmann jochen.wiedm...@gmail.com wrote: On Tue, Nov 10, 2009 at 3:59 PM, C. Michael Pilato cmpil...@collab.net wrote: Subversion client and server that doesn't use a DAV layer at all. The Subversion community has never released binaries -- ever -- not do we plan to. That would a completely new philosophy for an Apache project, which always aimed very heavily on distributions. It might either enforce to look at legal aspects in a different view - or lead to changing your philosophy. :-) Personally, I don't see any reason why things like creation of Windows binaries should be left to outsiders. (Apart from CollabNets business interests, which I wouldn't like to count.) Umm, how is it a completely new philosophy for an Apache project? There are a number of Apache projects that ship source without official binaries. APR and the Apache HTTPD server are two prime examples. Don't assume that the way the projects you're familiar with are run is the only way to run ASF projects. -garrett - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL][VOTE] Subversion
On Wed, Nov 4, 2009 at 3:12 PM, Greg Stein gst...@gmail.com wrote: Subversion is a version control system. You probably know it well as it is the version control system employed by the Apache Software Foundation. +1 -garrett - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: The graduation of Buildr and Abdera... + Rant
On Fri, Feb 20, 2009 at 2:10 AM, Niclas Hedhman nic...@hedhman.org wrote: Gang, I think that the Graduation of these two projects have not been 'clean'. Both are still listed as Incubating Projects on projects/index.html, as well as part of the Incubator project navigation. Buildr is not listed in projects on www.apache.org, Abdera is listed there. And neither have updated their STATUS pages to reflect the graduation. I'm sure that patches to fix any of these issues are more than welcome. -garrett - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: The graduation of Buildr and Abdera... + Rant
On Fri, Feb 20, 2009 at 2:10 AM, Niclas Hedhman nic...@hedhman.org wrote: Gang, I think that the Graduation of these two projects have not been 'clean'. Both are still listed as Incubating Projects on projects/index.html, as well as part of the Incubator project navigation. Buildr is not listed in projects on www.apache.org, Abdera is listed there. And neither have updated their STATUS pages to reflect the graduation. You know, I was going to leave it at a nice patches welcome, but hell with it. If you're so damn concerned about some web pages not getting updated, fix it your damn self. I've spent more time than I actually have right now updating the 9 million little things that have to get done when Abdera graduated, and opening my email today and hearing that apparently I'm doing a shitty job because I missed some of them was not exactly what I had in mind for starting my day. The entire process of going through incubation with Abdera has been a giant pain in my ass, and I'm sick of it. I no longer have the energy to deal with this anymore. Have fun with your overly complex rules and guidelines, building bureaucracy for the sake of bureaucracy with little to no gain. I'm done with it. -garrett - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: The graduation of Buildr and Abdera... + Rant
On Fri, Feb 20, 2009 at 3:52 PM, Bernd Fondermann bernd.fonderm...@googlemail.com wrote: Wow, this reminds me of the moments when I ask my children to clean up the mess they created when happily playing. And I get very grumpy when _I_ am the one who cleans up in the end, because I some other stuff to do, too. But hey - they are my kids! And we cannot leave it that way. For what it's worth, I fixed the damn site, that wasn't what I was pissed about. What I'm pissed about is that apparently the right way to deal with a task that hasn't been done is to post a rant to a widely read mailing list saying that the mentors of the project are falling down on the job. Perhaps an email saying hey, these web pages need to be updated, it doesn't look like you've taken care of it yet, could you? would have been more appropriate. Whatever, like I said, I have no more time for the incubator anyway. -garrett - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Abdera graduated, still incubating?
On Thu, Dec 4, 2008 at 9:36 AM, Martijn Dashorst [EMAIL PROTECTED] wrote: Abdera graduated (CONGRATS!). We voted +1 for their graduation, their resolution was put in front of the board and it passed. So why does the clutch status page still consider them incubating? I don't know where clutch pulls its data from, but we're still in the process of migrating abdera, so it's quite likely it's just something I haven't gotten to yet. -garrett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Abdera graduated, still incubating?
On Thu, Dec 4, 2008 at 9:46 AM, Garrett Rooney [EMAIL PROTECTED] wrote: On Thu, Dec 4, 2008 at 9:36 AM, Martijn Dashorst [EMAIL PROTECTED] wrote: Abdera graduated (CONGRATS!). We voted +1 for their graduation, their resolution was put in front of the board and it passed. So why does the clutch status page still consider them incubating? I don't know where clutch pulls its data from, but we're still in the process of migrating abdera, so it's quite likely it's just something I haven't gotten to yet. Ahh, it hadn't been removed from the ReportingSchedule wiki page, which is what clutch bases its list of projects on. I'm rerunning clutch now, and will submit the updated version once it finishes. -garrett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Abdera graduated, still incubating?
On Thu, Dec 4, 2008 at 10:09 AM, David Crossley [EMAIL PROTECTED] wrote: You probably found out, but it gets its data from various sources: http://incubator.apache.org/clutch.html#notes Whatever it gets fed. I will be pleased to see if Clutch works for you. My crappy first attempt at Python. Worked fine. Once I removed Abdera from the ReportingSchedule wiki page it dropped right off the chart. One thing that was not immediately obvious was that after running clutch.py I also had to explicitly regenerate the incubator web site, since clutch just updates the clutch.xml file in site-author. -garrett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Abdera Graduation to TLP
On Thu, Nov 13, 2008 at 8:59 AM, Garrett Rooney [EMAIL PROTECTED] wrote: After some brief discussion here and a vote on the Abdera private list, it seems everyone is in favor of this, so I'd like to propose that we ask the board to make Abdera a new TLP. It's been quite the long incubation process (started in May 2006!), but I think the Abdera community, while small, is now diverse enough that I have no question as to its ability to survive as its own Apache project. So please vote away. A +1 vote is for sending the following motion to the board for its approval. And the total comes to 15 +1 votes, a significant number (much more than 3, I haven't gone through and done an exact count) being binding votes from Incubator PMC members. There were no -1 votes or abstentions. The motion carries, and I'll forward the graduation proposal on to the board. The requested vote on the Abdera dev list also passed with no objections. Thanks, -garrett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] Abdera Graduation to TLP
After some brief discussion here and a vote on the Abdera private list, it seems everyone is in favor of this, so I'd like to propose that we ask the board to make Abdera a new TLP. It's been quite the long incubation process (started in May 2006!), but I think the Abdera community, while small, is now diverse enough that I have no question as to its ability to survive as its own Apache project. So please vote away. A +1 vote is for sending the following motion to the board for its approval. -garrett 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 framework for building clients and servers for the Atom Publishing Protocol and other related technology, for distribution at no charge to the public. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the The Apache Abdera Project, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that The Apache Abdera Project be and hereby is responsible for the creation and maintenance of a software project related to a framework for building clients and servers for the Atom Publishing Protocol and other related technology. RESOLVED, that the office of Vice President, Apache Abdera 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 Abdera Project, and to have primary responsibility for management of the projects within the scope of responsibility of The Apache Abdera 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 Abdera Project: - James M. Snell ([EMAIL PROTECTED]) - Garrett Rooney ([EMAIL PROTECTED]) - Stephen Duncan Jr. ([EMAIL PROTECTED]) - Ugo Cei ([EMAIL PROTECTED]) - Dan Diephouse ([EMAIL PROTECTED]) - David Calavera ([EMAIL PROTECTED]) - Jim Ancona ([EMAIL PROTECTED]) NOW, THEREFORE, BE IT FURTHER RESOLVED, that Garrett Rooney be and hereby is appointed to the office of Vice President, Apache Abdera, 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 Abdera 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 Abdera Project; and be it further RESOLVED, that the initial Apache Abdera Project be and hereby is tasked with the migration and rationalization of the Apache Incubator Abdera podling; and be it further RESOLVED, that all responsibility pertaining to the Apache Incubator Abdera podling encumbered upon the Apache Incubator PMC are hereafter discharged. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Abdera Graduation to TLP
On Thu, Nov 13, 2008 at 8:59 AM, Garrett Rooney [EMAIL PROTECTED] wrote: After some brief discussion here and a vote on the Abdera private list, it seems everyone is in favor of this, so I'd like to propose that we ask the board to make Abdera a new TLP. It's been quite the long incubation process (started in May 2006!), but I think the Abdera community, while small, is now diverse enough that I have no question as to its ability to survive as its own Apache project. So please vote away. A +1 vote is for sending the following motion to the board for its approval. Oh, and it goes without saying, +1 from me ;-) -garrett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Abdera Graduation to TLP
On Thu, Nov 13, 2008 at 9:22 AM, Martijn Dashorst [EMAIL PROTECTED] wrote: On Thu, Nov 13, 2008 at 2:59 PM, Garrett Rooney [EMAIL PROTECTED] wrote: After some brief discussion here and a vote on the Abdera private list Why wasn't this done on dev@ (especially the vote)? The Apache Way(tm) suggests that these decisions should be done in public (a quick poll on private@ is not a problem) The discussion included determining the list of people to put on the final PMC list. The actual list of Abdera committers was larger, but many of them had not participated in the project in some time or at all, or had explicitly left the project. Since I didn't want to come right out in a public forum and say you know, I think committer X doesn't deserve to be on the PMC I started the discussion in private. -garrett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Abdera Graduation to TLP
On Thu, Nov 13, 2008 at 10:37 PM, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: Garrett Rooney wrote: The discussion included determining the list of people to put on the final PMC list. The actual list of Abdera committers was larger, but many of them had not participated in the project in some time or at all, or had explicitly left the project. Since I didn't want to come right out in a public forum and say you know, I think committer X doesn't deserve to be on the PMC I started the discussion in private. I'm presuming there was not a dev@ vote yet by the Abdera community itself? If not, could you please call that vote ASAP in parallel with the general@ vote? Monday evening is not to late to put this on the board agenda. There was already a vote on the abdera private list with more than 50% of the developers voting +1 and none voting -1. If you're really concerned that it's not on the dev list I can restart the vote there, but it seems awfully futile. -garrett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Abdera Graduation to TLP
On Thu, Nov 13, 2008 at 10:54 PM, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: Garrett Rooney wrote: On Thu, Nov 13, 2008 at 10:37 PM, William A. Rowe, Jr. I'm presuming there was not a dev@ vote yet by the Abdera community itself? If not, could you please call that vote ASAP in parallel with the general@ vote? Monday evening is not to late to put this on the board agenda. There was already a vote on the abdera private list with more than 50% of the developers voting +1 and none voting -1. If you're really concerned that it's not on the dev list I can restart the vote there, but it seems awfully futile. The point is that yes, we hold votes (discussions) about people on private lists, so it was certainly appropriate to decide the initial composition on that list. But it is still for the dev@ list to sanity check the decision by the powers-that-be... that ensures I have no issues if you wish to 'seed' the vote with the list of ipmc members who have already voted in the affirmative, to spare them the trouble of re-voting. Fine. Whatever. I've started yet another vote, this time on [EMAIL PROTECTED] For the curious, this is now the 4th vote or vote-like thread I've started about this graduation in the past week. You'll understand if I'm getting a bit sick of it, especially when all we're doing is following procedure for procedure's sake. -garrett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Feedback on Abdera Graduation
I'd like to propose that the Abdera project move on to graduate from the incubator and become its own top level project. The project has been operating well for some time, with a small but steady stream of bugs being reported and fixed by a small but diverse group of developers. The major problem that has been holding us back for some time was lack of diversity. At this point we have a number of developers from diverse companies and I don't think that's really an issue anymore. It really seems like the project is ready to move on from the incubator, keeping it here doesn't seem to serve any purpose at this point, at least as far as I can tell. Any thoughts? -garrett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Abdera 0.4.0-incubating Take 7
On Mon, Apr 7, 2008 at 1:10 PM, James M Snell [EMAIL PROTECTED] wrote: Ok, we've updated the release candidate... please review Take 7 of the vote to release Apache Abdera 0.4.0-incubating. The following things have changed: - All necessary files now include ASL headers - LICENSE file now includes pointers to non-ASL licenses and Mark Pilgrim's license - NOTICE files in the jars are much cleaner thanks to the new maven-remote-resource plugin. - Information about a jar's dependencies and their licenses are now included in META-INF/DEPENDENCIES instead of the NOTICE file. - The NOTICE file in the distributions contains all the stuff not in lib/*-LICENSE.txt and provides a pointer to the lib directory for the additional stuff. - Everything is signed Binary distributions: http://people.apache.org/~dandiep/abdera-take7/org/apache/abdera/apache-abdera/0.4.0-incubating/apache-abdera-0.4.0-incubating.zip http://people.apache.org/~dandiep/abdera-take7/org/apache/abdera/apache-abdera/0.4.0-incubating/apache-abdera-0.4.0-incubating.tar.gz Source distributions: http://people.apache.org/~dandiep/abdera-take7/org/apache/abdera/apache-abdera/0.4.0-incubating/apache-abdera-0.4.0-incubating-src.zip http://people.apache.org/~dandiep/abdera-take7/org/apache/abdera/apache-abdera/0.4.0-incubating/apache-abdera-0.4.0-incubating-src.tar.gz Maven Repository: http://people.apache.org/~dandiep/abdera-take7/ +1 -garrett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Approve the release of Apache Abdera 0.4.0-incubating (updated)
On Mon, Mar 31, 2008 at 5:56 PM, sebb [EMAIL PROTECTED] wrote: Probably. Though if the AL header affects the parsing, then there may well be a problem with the parsing... Please. Are you actually suggesting that it's a good idea to make all of our test cases demonstrably different from the content that you actually see in the wild? Should we be able to parse a comment at the top? Sure. Should that be the default case we're testing just to satisfy pointless arguments about who can be more pedantically correct about where license headers go? No. -garrett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Approve the release of Apache Abdera 0.4.0-incubating (updated)
On Mon, Mar 31, 2008 at 5:52 PM, Luciano Resende [EMAIL PROTECTED] wrote: I'd probably error on the side of caution here, and add license headers in all files, unless it breakes something. Most if not all projects does add the license headers in maven pom files, property files, etc. I'd suggest you to fix at least in trunk, but as you mentioned you need to fix the the file below [1], I'd then recommend fixing as much as possible from the list you have. [1] core/src/main/resources/abderamessages.properties For crying out loud, we've had this freaking argument every single time abdera has released. There is zero reason to add license headers to two line properties files, test data that is explicitly testing atom content as it exists in the real world (where it would NOT have any license headers), or any number of other cases in that list. If you have specific examples of things you do think need licenses, cite them. Saying everything that you can slap a license header on without breaking something is not helpful, see the archives of this list for details. -garrett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Abdera 0.3.0-incubating
On 9/27/07, James M Snell [EMAIL PROTECTED] wrote: Ok, we have made a couple of bug fixes and, more importantly, we have softened the bouncy castle dependency and will no longer ship that jar. This release has been well tested and reviewed and has received the requisite number of +1's from the committers. The release candidate can be found here: http://people.apache.org/~jmsnell/abdera/0.3.0 High level change summary for this release: * Support for the Atompub final draft * Refactored and simplified Server framework * Refactored and simplified AbderaClient * Spring integration support * ExtensionFactory can now provide the mime type for extension elements * Improved extensibility * Updated dependencies * XPath support improvements * Geotagging extensions * Simple Sharing extensions * WSSE Authentication * Bidi extensions (experimental) * Atompub features extensions (experimental) * Feed paging extensions * Feed license extensions * XML Encryption with Diffie-Hellman key exchange * Extensions now packaged in separate jars for modular distribution * Improved error handling * More examples * Less bugs * Lots of other improvements +1 from me (with my IPMC hat on) -garrett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Abdera 0.3.0-incubating
On 9/27/07, Kevan Miller [EMAIL PROTECTED] wrote: 2. No ASF Copyright in your NOTICE files. As described here -- http:// www.apache.org/legal/src-headers.html#notice. There should be a copyright notice for the work that's occurring within the Abdera project, itself. Umm, yes it is. It's on line 6 and 7 of the file: This product includes software developed by The Apache Software Foundation (http://www.apache.org/). 4. Missing Apache source license headers. RAT is noting the following files from your source are missing license headers. IMO, a number of these files could and should have an Apache source license header. !? ./client/src/main/java/log4j.properties !? ./contrib/rss/src/main/resources/META-INF/services/ org.apache.abdera.factory.ExtensionFactory !? ./contrib/rss/src/test/resources/rss1.rdf !? ./core/src/main/java/org/apache/abdera/util/ XmlRestrictedCharReader.java !? ./core/src/main/resources/abdera.properties.example !? ./core/src/main/resources/abderamessages.properties !? ./core/src/main/resources/META-INF/services/ org.apache.abdera.factory.ExtensionFactory.example !? ./dependencies/deps.properties !? ./dependencies/i18n/build.properties !? ./dependencies/i18n/src/main/resources/org/apache/abdera/i18n/ unicode/data/ucd.res !? ./dependencies/legal/axiom-NOTICE.txt !? ./dependencies/legal/retroweaver-LICENSE.txt !? ./dependencies/legal/wstx-asl-NOTICE.txt !? ./dependencies/legal/xmlsec-NOTICE.txt !? ./docs/knownissues.txt !? ./examples/src/main/resources/content.xslt !? ./examples/src/main/resources/log4j.properties !? ./examples/src/main/resources/simple.xml !? ./examples/src/main/resources/test.xslt !? ./examples/src/main/resources/xmlcontent.xml !? ./examples/src/main/resources/META-INF/services/ org.apache.abdera.factory.ExtensionFactory !? ./examples/src/main/resources/org/apache/abdera/examples/ appserver/web.xml !? ./extensions/json/src/main/resources/META-INF/services/ org.apache.abdera.writer.NamedWriter !? ./extensions/main/src/main/resources/META-INF/services/ org.apache.abdera.factory.ExtensionFactory !? ./extensions/media/src/main/resources/META-INF/services/ org.apache.abdera.factory.ExtensionFactory !? ./extensions/opensearch/src/main/resources/META-INF/services/ org.apache.abdera.factory.ExtensionFactory !? ./extensions/opensearch/src/test/resources/opensearch.xml !? ./extensions/sharing/src/main/resources/META-INF/services/ org.apache.abdera.factory.ExtensionFactory !? ./parser/src/main/resources/META-INF/services/ org.apache.abdera.writer.NamedWriter !? ./parser/src/test/resources/complete.xml !? ./parser/src/test/resources/content.xslt !? ./parser/src/test/resources/entry.xml !? ./parser/src/test/resources/feed.xml !? ./parser/src/test/resources/simple.xml !? ./parser/src/test/resources/simpleEntry.xml !? ./parser/src/test/resources/simpleFeed.xml !? ./parser/src/test/resources/simpleService.xml !? ./parser/src/test/resources/test.xslt !? ./parser/src/test/resources/xmlcontent.xml !? ./parser/src/test/resources/www.feedparser.org/tests/ wellformed/atom10/atom10_namespace.xml !? ./parser/src/test/resources/www.feedparser.org/tests/ wellformed/atom10/entry_author_email.xml !? ./parser/src/test/resources/www.feedparser.org/tests/ wellformed/atom10/entry_author_name.xml !? ./parser/src/test/resources/www.feedparser.org/tests/ wellformed/atom10/entry_content_base64.xml !? ./parser/src/test/resources/www.feedparser.org/tests/ wellformed/atom10/entry_content_base64_2.xml !? ./parser/src/test/resources/www.snellspace.com/public/ contentsummary.xml !? ./parser/src/test/resources/www.snellspace.com/public/ linktests.xml !? ./parser/src/test/resources/www.snellspace.com/public/ nondefaultnamespace.xml !? ./parser/src/test/resources/www.snellspace.com/public/ nondefaultnamespace2.xml !? ./parser/src/test/resources/www.snellspace.com/public/ nondefaultnamespace3.xml !? ./parser/src/test/resources/www.snellspace.com/public/ ordertest.xml !? ./parser/src/test/resources/www.snellspace.com/public/xmlbase.xml !? ./protocol/src/main/resources/META-INF/services/ org.apache.abdera.factory.ExtensionFactory !? ./security/src/test/resources/log4j.properties !? ./spring/src/test/java/org/apache/abdera/spring/TestProvider.java !? ./spring/src/test/resources/org/apache/abdera/spring/beans.xml If you're going to paste RAT output into an email, at least filter it for sanity. There are a few files in here that legitimately need fixing (most of them end in .java), but test files that contain representative XML that's being parsed for test purposes shouldn't have big license headers that are unlikely to show up in the real world, and properties files that are two lines long and parsed at runtime
Re: [VOTE] accept Pig into Incubator
On 9/25/07, Doug Cutting [EMAIL PROTECTED] wrote: I would like to call the Incubator PMC to vote to incubate the proposed Pig project. Discussion on this list evidenced broad interest in this project, which bodes well for its ability to build a diverse developer community. http://wiki.apache.org/incubator/PigProposal +1 -garrett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Incubator Proposal: Pig
On 9/18/07, Lawrence Mandel [EMAIL PROTECTED] wrote: Is there any particular reason you want this podling to be sponsored by the Incubator PMC (which is generally done for projects that intend to turn into their own top level project) Is this true? I thought all new projects had to go through the incubator. Woden [1] is an incubator project that plans to graduate and join the WS PMC. [1] http://incubator.apache.org/woden/ All projects need to go through the incubation process, but not all are sponsored by the incubator PMC, many are sponsored by an existing PMC outside the incubator. I don't recall for sure, but I'd expect that woden entered the incubator after being sponsored by the WS PMC (at least, that's how things tend to work today if I understand correctly, it's quite possible that woden predates that practice, I'm really not sure). -garrett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Incubator Proposal: Pig
On 9/18/07, Olga Natkovich [EMAIL PROTECTED] wrote: Hi, Yahoo! research and development teams have developed a proposal below. The proposal is also available on wiki at http://wiki.apache.org/incubator/PigProposal http://wiki.apache.org/incubator/PigProposal. We would like to ask that the ASF consider forming a podling according to the proposal. Is there any particular reason you want this podling to be sponsored by the Incubator PMC (which is generally done for projects that intend to turn into their own top level project) rather than having it sponsored by the Lucene PMC (where Hadoop currently resides)? It seems to me that the close relationship between Pig and Hadoop implies that they very well might best be served under the same roof. -garrett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Incubator Proposal: Pig
On 9/18/07, Doug Cutting [EMAIL PROTECTED] wrote: Garrett Rooney wrote: Is there any particular reason you want this podling to be sponsored by the Incubator PMC (which is generally done for projects that intend to turn into their own top level project) rather than having it sponsored by the Lucene PMC (where Hadoop currently resides)? It seems to me that the close relationship between Pig and Hadoop implies that they very well might best be served under the same roof. The existing contributor base is largely disjoint from the Hadoop contributor base, and they expect that to mostly remain the case. Nigel, Owen I, Hadoop committers, will mostly just help the Pig crew out with Apache ways, and don't expect to become significant contributors to Pig. Pig builds on Hadoop, and the communities may overlap a bit, but, to the primary folks involved, it feels like a separate community and they'd prefer to aim for a TLP. Well, it seems a little odd to me (if anything it seems like a new TLP associated with hadoop and generic distributed computing tools like pig that are built on top of hadoop seems like it would make more sense than just a pig TLP), but if that's what the people involved want I don't see anything wrong with it. I mean it's not like a decision on a final home for the project has to happen now anyway. In any event, +1 from me, this is a neat project and I'd be happy to see it here. -garrett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] JSPWiki
On 9/6/07, Martin Cooper [EMAIL PROTECTED] wrote: On 9/6/07, Gwyn Evans [EMAIL PROTECTED] wrote: While agreeing that it's something that needs looking at closely, I'm not I'm not sure it's downbeat as I think you're suggesting. The 3rd-party licencing policy at http://www.apache.org/legal/3party.html redirects to the draft at http://people.apache.org/~rubys/3party.html, but that suggests that, especially for use in binary form, licences such as CDDL or CPL aren't necessarily incompatible... Right. However, as you noted, that's a draft, so it may change. I hope it does. So you're expecting JSPWIki to be held to a standard that doesn't exist even in the draft documentation that we have for such things? That seems rather extreme. I'd suggest that such discussion belongs on the legal discuss mailing list, as opposed to on the incubator list. -garrett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: counting downloads
On 5/5/07, Marshall Schor [EMAIL PROTECTED] wrote: One confusion I have: If we count clicks on the download link, it seems that even if that link led to a mirror page, it would count pretty accurately (except of course if a person clicked to download, and then didn't bother going through with it). I guess it would also miss the case where people somehow found their way to a download mirror *without* going through the project download page. Did I miss something, or would this give a reasonable estimate of downloads? Unless they don't download it via your link, or they download more than once (getting copies on multiple machines?), or any number of other things that can throw your numbers off. It's a losing battle for statistics that IMO aren't very useful anyway. All download counts are good for is ego stroking, there are better ways to spend time and energy. -garrett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: counting downloads
On 5/2/07, Marshall Schor [EMAIL PROTECTED] wrote: We're curious to see how many downloads we're getting, perhaps sorted by ip number or who's downloading (I realize that would need be volunteered information). Do other projects have a good way to track this? I know we could pull the logs for the p.a.o webserver and grep through them looking for things, but I'm wondering if there's something we can put on our download page that users would click on that would count things? The mirror system makes this an essentially unsolvable problem. Not to mention the fact that you have no clue if people are actually getting the code from one of our mirrors at all, they could get it from a linux distribution, or any number of other repackagers. On top of that, you can't correlate back to an individual person, so you don't know if you're getting one guy downloading it more than once because he's accidentally deleted it... Get used to the idea that counting downloads is an inherently poor way to judge if your software is being used. More interesting metrics might be numbers of posts on mailing lists, bugs filed, etc. -garrett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Vote] Abdera v0.2.2
On 2/19/07, Noel J. Bergman [EMAIL PROTECTED] wrote: Garrett Rooney wrote: Noel J. Bergman wrote: Your quarterly report mentions possibly legal issues related to crypto. What are the issues? We need to file a export notification for use of crypto code (not our code, third party, bouncy castle, I believe) in one of the abdera modules. That's fine. I suspected that it might be something like that. HOWEVER, those things need to be done before the release, not after it. :-) Well, they have been done now, although I will point out the fact that we're being rather hypocritical about that particular requirement, considering that there are a number of other ASF projects who make use of crypto code but have not jumped through these particular hoops yet. -garrett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Vote] Abdera v0.2.2
On 2/17/07, Noel J. Bergman [EMAIL PROTECTED] wrote: Your quarterly report mentions possibly legal issues related to crypto. What are the issues? We need to file a export notification for use of crypto code (not our code, third party, bouncy castle, I believe) in one of the abdera modules. -garrett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] mod_wombat ip clearance
On 2/13/07, Brian McCallister [EMAIL PROTECTED] wrote: The last code grant for the mod_wombat codebase ( http:// incubator.apache.org/ip-clearance/httpd-wombat.html ) has been recorded and I would like to move forward with the import. Code grants and CLA's have been recorded from each person who has contributed code. This is a lazy-consensus approval vote. +1 -garrett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Vote] Abdera v0.2.2
On 2/8/07, James M Snell [EMAIL PROTECTED] wrote: The Abdera team is ready to release version v0.2.2. This is a bug fix release that addresses a number of critical issues. There are no new features. We would appreciate if folks could take a look and weigh in. // JDK 1.5 http://people.apache.org/~jmsnell/abdera.0.2.2-incubating.zip http://people.apache.org/~jmsnell/abdera.0.2.2-incubating.zip.md5 // JDK 1.4.2 http://people.apache.org/~jmsnell/abdera.0.2.2-incubating.jdk142.zip http://people.apache.org/~jmsnell/abdera.0.2.2-incubating.jdk142.zip.md5 // Source http://people.apache.org/~jmsnell/abdera.0.2.2-incubating.src.zip http://people.apache.org/~jmsnell/abdera.0.2.2-incubating.src.zip.md5 +1 -garrett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] TripleSoup - a SPARQL endpoint for httpd
On 2/2/07, Leo Simons [EMAIL PROTECTED] wrote: Hi all, This is a vote on a previously posted proposal to start a rdf database server project at apache. The entire proposal text is included below. There is only one change from the one posted to the [proposal] thread -- we will start without a triplesoup-users@ mailing list. Please place your votes! +1 -garrett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] TripleSoup - a SPARQL endpoint for httpd
On 1/29/07, Leo Simons [EMAIL PROTECTED] wrote: What do you think? +1 (Full disclosure, I work at Joost, but not on anything related to this stuff, I just think it's a neat project.) One comment on the proposal itself though: Mailing lists: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] I would avoid creating a -user list until it's actually proven necessary. In the beginning keeping user questions on the dev list makes sense to me. -garrett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: REMINDER January 2007 Board Reports
On 1/15/07, Noel J. Bergman [EMAIL PROTECTED] wrote: C'mon, Folks! The reports are overdue again. Yoav did the grunt work, preparing http://wiki.apache.org/incubator/January2007 and the rest of the initial 2007 reporting pages. Felix, UIMA, NMaven and Graffito have reported. Agila and AltRMI are going formally dormant. Where are Ivy, Wicket, CXF, FtpServer, Heraldry, JuICE (another dormancy candidate?), Lucene4c, Lucene.Net, Qpid, and Roller? Lucene4c was closed down months ago, I imagine it should no longer be on the list. -garrett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Retiring a project [Was: Retiring Agila?]
On 1/2/07, Henri Yandell [EMAIL PROTECTED] wrote: Agila's now on step 8 of http://wiki.apache.org/incubator/RetiringPodlings . Previous shutdown podlings have had different solutions: Axion - No issue, source didn't arrive. Depot - Made read only. Emails will still goto [EMAIL PROTECTED] Lucene4c - Remains read/write. Emails will still goto [EMAIL PROTECTED] What should the correct solution be? For emails - I'm not sure if depot-commits and lucene4c-commits still exist or not. If commits happened, I imagine the emails should be going to [EMAIL PROTECTED], so possibly a sym link on the mail server can easily do that. lucene4c-commits does still exist, as do the rest of the lists for lucene4c, for that matter. I'd like to get rid of them though, so a consensus on where commits for those areas in svn should go would be nice to have. Both depot and lucene4c kept their svn groups. Should these be removed? Should the svn be r or rw, or should it just be removed and automatically go over to incubator-pmc rw? ENOCARE, so long as the commit mails go someplace. -garrett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Incubator Releases
On 12/13/06, Martin Ritchie [EMAIL PROTECTED] wrote: Hey, I'm just trying to familiarise myself what it really means to be an incubated project and came across this: http://wiki.apache.org/incubator/ExitingIncubator * Note: incubator projects are not permitted to issue an official Release. Test snapshots (however good the quality) and Release plans are OK. How does official Relase differ to what incubated projects release just now? Is it the inclusion of the disclaimer that make them ok? Is this just old text? It sounds like no releases only snapshots. Would that mean we could only deploy maven snapshots not releases? I believe that's old text. Incubator projects can release software, if it's approved by the incubator PMC and is branded in such a way to make it clear that it's from an incubating project. -garrett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: import of ivy's code in SVN
On 12/6/06, Antoine Levy-Lambert [EMAIL PROTECTED] wrote: Hello, Xavier Hanin has created this issue on 23/Nov/06 12:15 AM. https://issues.apache.org/jira/browse/INFRA-1047 This is currently the limiting factor to start working on ivy here at the incubator. Can someone of infrastructure take care of it ? I've been meaning to get to it, but haven't had a chance yet. Hopefully I'll be able to within the next day or two. -garrett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JIRA and mentors
On 12/4/06, Martijn Dashorst [EMAIL PROTECTED] wrote: Recently I encountered something (a task) that I wanted to assign to one of our Wicket mentors. These things can be done through email of course, but email is not very good with tracking. In our case, the mentors are not added to the podlings JIRA tracker. Currently there is no mentor JIRA group for incubating projects. There are projectname-developers groups available, but no projectname-mentor groups. Wouldn't it be something to create for each incubating project not only a JIRA developers group but also a mentors group? Or should the podlings mentors be added as developers? Most groups just add the mentors as developers. -garrett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Abdera 0.2.0-incubating Release
On 12/4/06, James M Snell [EMAIL PROTECTED] wrote: The Abdera PPMC is ready to go with our 0.2.0-incubating release. This drop delivers a number of important updates and fixes: * A reworked API that improves usability * Decoupled extensions from the underlying parser implementation * A Atom Publishing Protocol client implementation * Updated support for the current Atom Publishing Protocol draft specification * Added support for Internationalized Resource Identifiers (IRIs) * Improved Thread Safety * Fixed a number of classloader issues that kept Abdera from working properly in application server environments. * Improved Javadocs * Added test cases and sample code * Added experimental Bidirectional Text support * Improved implementation of OpenSearch v1.0 and v1.1 extensions * Implementation of MediaRSS extensions * Implementation of Feed Paging and Archiving extensions * GoogleLogin Authentication Support Release Candidate: JDK 1.5: http://people.apache.org/~jmsnell/abdera.0.2.0-incubating.zip http://people.apache.org/~jmsnell/abdera.0.2.0-incubating.zip.md5 JDK 1.4.2: http://people.apache.org/~jmsnell/abdera.0.2.0-incubating.jdk142.zip http://people.apache.org/~jmsnell/abdera.0.2.0-incubating.jdk142.zip.md5 Source: http://people.apache.org/~jmsnell/abdera.0.2.0-incubating.src.zip http://people.apache.org/~jmsnell/abdera.0.2.0-incubating.src.zip.md5 We'd like to go ahead with the release. It would be excellent if y'all could weigh in. +1 -garrett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release ActiveMQ CPP 1.0
On 11/15/06, robert burrell donkin [EMAIL PROTECTED] wrote: i'm guessing that *.vcproj are visual C++ project files (right?). they lack license headers. does the format support comments? The files are `XML, but Visual Studio is notoriously picky about what's in them. I've never tried to stick comments in one, but I wouldn't be all that surprised if it broke something... -garrett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] incubator voting process
On 11/12/06, Noel J. Bergman [EMAIL PROTECTED] wrote: That may be true, but as ASF Members (which most are), I would expect (and have observed) that they have an overall concern regarding events that effect the ASF. Sure, but having an overall concern about events that effect the ASF is different from having the time to make sure that $RANDOM_PODLING's latest release happens in a timely manner. For example, I don't personally care all that much about quite a few of our current podlings (just not interested in them from a technical point of view), so I probably wouldn't go out of my way to review their releases. That said, if I noticed something particularly wrong and didn't see someone else speaking up about it, I'd do something, because like you say, I'm a member and I care about the ASF in general. -garrett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] incubator voting process
On 11/10/06, Sam Ruby [EMAIL PROTECTED] wrote: There seems to be a persistent delusion that [EMAIL PROTECTED] is where incubation happens. The reality is that all the real incubating happens on the PPMC private and dev lists. We can correct this in one of two ways: recognize what actually is happening, or make what we say is happening actually work. If we go the first route, then we should treat this list as an announcements list. Results of votes for releases and graduation are posted here, and incubator PMC members will be given 72 hours to raise an issue. If we go the second route, then we need to set the expectation that most PMC members participate in most votes. I think it's unrealistic to expect that the majority of the members of the incubator PMC will be involved in most votes. I mean heck, I've rarely seen the majority of PMC members of any project be involved in ANY release vote, let alone in a situation like the incubator where many PMC members have little personal interest in the majority of the releases. As far as I can tell, most people who are on the incubator PMC joined so they could help to shepherd a specific project through the process by serving as a mentor. They don't have the time or the inclination to police the releases of each and every project in incubation, and requiring them to do so seems like a great way to just get them to say the hell with it and leave the PMC entirely, which doesn't solve anything. I mean before at least they were helping to police the releases of at least the podling they were involved in, which is better than nothing. Honestly though, if podlings are having trouble getting people on the PMC to review and vote on their releases I wonder if that says something in and of itself. I mean at the very least I would expect to see +1 votes from the project mentors as soon as the vote thread starts on [EMAIL PROTECTED], since at least in theory if there was anything that would keep them from voting +1 they would have raised it on the project's dev list before it got anywhere near asking for the incubator's blessing. Right there that's at least one or two votes, if the project has trouble getting the remaining votes, well, maybe that says something about the level of interest in the rest of the foundation about the project itself. If we can't get three people on the incubator PMC motivated enough to say yes, this release looks legally and procedurally sound then maybe we shouldn't have the project at the ASF at all. (Note, please don't take this as me pointing at any particular project and saying nobody cares about your stuff, take a hike, I'm not interested in having that argument right now, but I am interested in the bigger picture.) -garrett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] incubator voting process
On 11/10/06, Rodent of Unusual Size [EMAIL PROTECTED] wrote: Garrett raises a point about which I want to ask. What criteria should a mentor use when it comes to voting on a release? I for one can't make any judgement of its technical worth.. Personally, when I'm voting with my Incubator PMC hat on, I'm voting based on the fact that the project has followed the ASF guidelines for how to prepare and vote on a release, and that we've legally speaking got all our ducks in a row (i.e. CLAs are in, all the appropriate license files and headers are in place, etc). When I'm voting as a committer on the project that's when I take into account technical merit of the release, although at that phase (before it gets to the incubator PMC) I would also bring up any problems that I'm aware of that would convince me to not +1 it with my Incubator PMC hat on. -garrett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] incubator voting process
On 11/10/06, Rodent of Unusual Size [EMAIL PROTECTED] wrote: 1. Abdera: Mentors:Garrett Rooney, Paul Querna Started:July 2006 Incomplete: Identification, Interim Responsibility, Copyright Diversity: Unknown Releases: Unknown FWIW, when Ken pointed out to me that it was pretty incomplete I went in and updated the status page. I believe everything on the default status list is complete. I didn't list releases (didn't occur to me, I'll go add them to the news section soon), and diversity is ok, but not perfect (we've got at least three independent committers, but the majority of the coding still comes from IBM, although not all of it). Other than that the only thing left to deal with that I'm aware of is we need to do the crypto notification stuff for our use of Bouncy Castle in the security component. -garrett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Weirdness with the web site
So, I'm trying to finish off the job of removing lucene4c from the web site, since it's been retired it shouldn't be showing up in the list of podlings and what not, and when I'm generating the site I can't help but notice lots of changes in there that are totally unrelated to what I just changed. Are people just not checking in the generated files when they make changes? I mean is there some reason that the recent changes in guides/releasemanagement.html hasn't been pushed out yet? Similarly, I'm seeing a number of files that show up with every single line changed, when AFAICT all that should change is the removal of a single line from the list of projects. What's up with that? Anyway, I'm kind of hesitant to check this stuff in, but at the same time it would be nice to get my changes pushed out there... -garrett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] incubator voting process
On 11/10/06, Rodent of Unusual Size [EMAIL PROTECTED] wrote: 18. Lucene4c: Mentors:Erik Hatcher Started:Unknown Incomplete: All Diversity: Unknown Releases: Unknown Also FWIW, this one has been retired, I just hadn't updated its status page to note that fact. Checked in that change, but haven't pushed it out due to other weirdness with the web site... -garrett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: wikis
On 11/9/06, Gwyn Evans [EMAIL PROTECTED] wrote: Conspiracy or cock-up? Is this a case of 'not-invented-here', a objection to the use of non-Apache-licenced software or just a misunderstanding - it's hard to believe anyone would put in a Wiki without ensuring it's data is automatically backed up regularly. Uhh, it has nothing to do with conspiracy, note that Moin Moin isn't Apache Licensed either. It has everything to do with infrastructure at the ASF being volunteer maintained, so if the volunteers slack off stuff doesn't get fixed. Just to pick up on the primary point, where do we find the state of what's backed up? Being new to Apache, I suppose we've so far assumed that they know what they're doing, but in actual fact, I've not actually /checked/ that they back anything up (svn or wiki)... Actually, IIRC confluence is backed up the same way Jira is, at least I think that's what Jeff said when I asked him before the move. And yes, svn is definately backed up ;-) On the original subject, CWiki does seem to be partially 'hidden' at Apache - I've tried to help, in terms of a patch to add it to the list of services documented at http://www.apache.org/dev/services.html#wiki (still waiting to be looked at, but it's only been a few weeks so far). An issue issue requesting it be added to the monitored list of services was closed as there's been a generic issue open on the subject since July, although with no action since then... If the cwiki maintainers want to fix those things, they'll get fixed. -garrett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Retiring a project [Was: Retiring Agila?]
On 11/6/06, Henri Yandell [EMAIL PROTECTED] wrote: So how do we retire a project? My checklist so far is: * move Agila to the Retired section of the Incubator site, * inform -dev/-user mailing lists (earlier than the rest) * ask that the mailing lists be shutdown, * update the wiki, * update the website, * move the JIRA project to a Retired category(?), (what if Bugzilla?) * make the SVN read-only, * what else? That sounds about right. I did most of that for Lucene4c, only thing missing is the JIRA and mailing list bits. -garrett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [IVY] setup of infrastructure
On 11/2/06, Xavier Hanin [EMAIL PROTECTED] wrote: How can I know that the paperwork is ok? I've already sent my ICLA and the software grant, but I don't know if they were properly received and processed. One of your mentors should be able to watch the files in the private repos where those get recorded. It sometimes takes the ASF secretary a few days to get around to processing them, but if they don't get recorded fairly soon it's often a good idea to resend. -garrett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [IVY] setup of infrastructure
On 11/1/06, Brett Porter [EMAIL PROTECTED] wrote: Usually, a dumpfile is used rather than a zipped up repository, I think. I would suggest locating an svn admin who can work with you to do a test now - so you'd dump the repository without locking it out, load it up into the test repository, check it works, so that you know what to do and minimise downtime of your commit access when you are ready to do the real thing. I'm not an svn admin either, though - so best to get in touch with them and see how they usually do it :) A zipped up repository (assuming it's in fsfs format, not bdb) is just as easy for us to work with as a dumpfile, just means there's one more step for the infra person doing the job (usually me). The other thing we need is a list of the committers who have committed to the repos in question and the mapping from their old username to their ASF username so we can convert the old svn:author revprops to match the new ASF usernames, for consistency. Once both of those are available, and all the paperwork (CLAs, software grants, etc) are sent in and acknowledged by the ASF secretary just file an INFRA Jira ticket to schedule things and we'll get it moving. -garrett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [IVY] setup of infrastructure
On 10/30/06, Antoine Levy-Lambert [EMAIL PROTECTED] wrote: Some projects call their ppmc list private (for instance would be ivy-private). Do we have to obey to this convention ? All the PMC and PPMC mailing lists are now known as -private, to stress the fact that they're supposed to be used just for conversations that can't be held in public. It was a global ASF wide change, for older lists there are aliases in place so the old -pmc version works, but the cannonical list name is now -private. -garrett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Request to join in development of lucene4c
On 10/27/06, Yoav Shapira [EMAIL PROTECTED] wrote: And more generally: you don't need to ask permission to join the development of any Apache project. Your help is welcome. Start by reading the general guidelines at http://www.apache.org/dev/contributors.html Simply join the mailing list(s) for the project, start participating in the discussion, look at the project's issue tracker for open issues and submit patches to them, and so on. Typically each project has directions on how to get involved. Well, I suspect he's asking on this list because in the process of shutting down lucene4c I put a hey, ask on [EMAIL PROTECTED] if you want to get this project started again notice on the project's web site, mainly because I was planning on turning off the lucene4c mailing lists because at this point all they do is generate moderation requests for spam. As for contributing to it, the lists are still there (haven't gotten around to killing them off yet), so if you want to start sending in patches I may be able to find time to review and apply them. If you can do that a few times you'll likely get commit access, and then you can keep the project going. I do warn you though, there are literally no other people working on the project right now, and I have limited time to review and apply changes. You might have better luck investigating the Lucy project, as it has somewhat similar goals and is more active. -garrett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RE: [PROPOSAL] Ivy
On 10/25/06, Antoine Levy-Lambert [EMAIL PROTECTED] wrote: Understood. Actually, I do not need to become a member of the incubator PMC either, but I would very much like to have the svn and UNIX karma to edit and publish elements of the web site of ivy. Ok, slow down a bit. I'm all for enthusiasm, but this stuff does take a little time. First we vote on accepting the project. Once that happens the initial committers send in their CLAs. Once the CLAs are in the project's mentors request accounts on the ASF infrastructure (unix machines, svn, etc). Once root@ creates the accounts the mentors (or someone else if the mentors don't have the right access) grants you the appropriate karma to make changes to this kind of thing in svn. You're on step 1, AFAICT, and you're all set to jump to step 6. It'll happen, it just takes a little time ;-) -garrett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RE: [PROPOSAL] Ivy
On 10/25/06, Antoine Levy-Lambert [EMAIL PROTECTED] wrote: Hello Garrett, I am not an Ivy contributor, but an ASF member and an ANT PMC member who has volunteered as champion and mentor for Ivy. I do not want to start checking in code, I just would like the possibility to start creating an ivy folder on the incubator web site. Ahh, sorry, my bad. If you're already an ASF Member you should have write access to the appropriate places in the incubator tree. The web pages are all under /incubator/public, and the members group has write access there. Leo wrote that the fact that the Ant PMC sponsors Ivy is already enough to start incubation. If this is true, we can start taking care of these issues. We will soon stumble on people.apache.org being dead which does not help to do web site updates. Yeah, not much you can do about that other than wait. It should be back up later today. -garrett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Comment - (Was [Fwd: [VOTE] REVISED Policy on Initial Committer and PPMC members])
On 10/25/06, Noel J. Bergman [EMAIL PROTECTED] wrote: Geir Magnusson Jr. wrote: Should this really be Shall? We've been successful in Harmony with a slightly different model, where we didn't just sweep committers in except for the mentors and champion, because we didnt' start with any code. Yes, it should be a Shall, since it has been made quite clear that the majority of people want a binding list. The work you did on Harmony: We treated the Initial Committer list as an indication of interest, and just looked for people that followed through once the project got started. would have to be done PRIOR to the vote. I'm not sure how this would prevent what was done with harmony. Just have the initial proposal come with no list of committers. The champion has a very easy job to do in validating that list ;-) -garrett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[RESULT] Mark lucene4c as dormant (was Re: [VOTE] Mark lucene4c as dormant)
On 10/9/06, Garrett Rooney [EMAIL PROTECTED] wrote: Since there hasn't been any significant work on Lucene4c in quite some time, I'd like to officially mark it as dormant so I don't have to keep writing board reports that just say there has been no progress in the last 3 months. So, cast your votes now: [ ] +1 - Mark Lucene4c as dormant. [ ] 0 - I have no opinion. [ ] -1 - No, please keep it! [include reason] FYI, we had 8 +1 votes, and no objections, so I've begun the process of shutting the project down. -garrett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [doc] How to add a PPMC member
On 10/12/06, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: Garrett Rooney wrote: On a sort of related note, are the membership lists of the various PPMCs actually documented anywhere? I mean is there a PPMC version of committee-info.txt like there is for PMCs? Hopefully projects are maintaining their root status files with this info http://incubator.apache.org/projects/.html Every project I've looked at there lists committers and mentors, but not PPMC members. Now considering that we've been saying just recently that not every committer starts out on the PPMC, doesn't that indicate that we should have a specific list someplace for that? Or is it just that we should have such a thing, but none of the podlings (abdera, lokahi, cxf, cayenne) I happened to look at have one? -garrett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Mark lucene4c as dormant
On 10/10/06, Leo Simons [EMAIL PROTECTED] wrote: On Oct 9, 2006, at 5:34 PM, Garrett Rooney wrote: Since there hasn't been any significant work on Lucene4c in quite some time, I'd like to officially mark it as dormant so I don't have to keep writing board reports that just say there has been no progress in the last 3 months. does I here means lucene4c community? So, cast your votes now: [ ] +1 - Mark Lucene4c as dormant. [ ] 0 - I have no opinion. [ ] -1 - No, please keep it! [include reason] +1, assuming the lucene4c people (whoever that are) are happy with this too. The lucene4c people basically means me, and Paul to some extent, although he never realy got around to doing anything ;-) -garrett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] Mark lucene4c as dormant
Since there hasn't been any significant work on Lucene4c in quite some time, I'd like to officially mark it as dormant so I don't have to keep writing board reports that just say there has been no progress in the last 3 months. So, cast your votes now: [ ] +1 - Mark Lucene4c as dormant. [ ] 0 - I have no opinion. [ ] -1 - No, please keep it! [include reason] -garrett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Mark lucene4c as dormant
On 10/9/06, Garrett Rooney [EMAIL PROTECTED] wrote: Since there hasn't been any significant work on Lucene4c in quite some time, I'd like to officially mark it as dormant so I don't have to keep writing board reports that just say there has been no progress in the last 3 months. So, cast your votes now: [ ] +1 - Mark Lucene4c as dormant. [ ] 0 - I have no opinion. [ ] -1 - No, please keep it! [include reason] +1 from me, FWIW. -garrett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Mark lucene4c as dormant
On 10/9/06, Yoav Shapira [EMAIL PROTECTED] wrote: Hi, On 10/9/06, Garrett Rooney [EMAIL PROTECTED] wrote: [ X ] +1 - Mark Lucene4c as dormant. [ ] 0 - I have no opinion. [ ] -1 - No, please keep it! [include reason] Will people have a post-ApacheCon todo / done list as well? I saw this item on your preconference todo list ;) I was thinking of posting a here's what I actually got done list ;-) -garrett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Policy on Initial Committership
On 10/9/06, Mads Toftum [EMAIL PROTECTED] wrote: If you _really_ want to add this extra backdoor, then at least make it a requirement that every bloody name has to be on the proposal and make this backdoor expire at the end of incubation. No argument on the every bloody name has to be on the proposal bit, but I see no reason to make it expire at the end of incubation. -garrett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Policy on Initial Committership
On 10/8/06, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: Garrett Rooney wrote: I disagree with filtering even inactive old contributors to an incoming project (at least for open source projects, I'm not sure how I feel with regard to inactive contributors to proprietary code that's being contributed). I think it would be quite wrong if a former contributor were to show up 6 months after the project moved to the ASF and had to jump through all sorts of hoops to gain access to the code again. At the very least we should have some provision for preemptively marking inactive people as emeritus committers, who can come back at any time. Uhm there is, no? * join committers by following the instructions * introduce yourself * declare yourself emeritus/temporarily (at least) retired Otherwise * join the dicussion * introduce yourself as the folk who wrote the Xxxx components * ask to participate If you can't do the first over the course of 2 mos, 3 mos, 6 mos or the year it takes to graduate, follow the second course? Somewhere in this scheme common sense needs to be re-introduced :) Ok, so I'm mostly using my experience from Subversion as an example here, since it's the largest non-ASF project I'm involved in. We've got a large number of formerly very active but currently dormant committers. Every so often one of them will become active again, and contribute either a small useful bug fix, or a large new feature (usually by becoming active again for a period of time, because they no better than to drop a code bomb on us). I'd hate for there to be any impediment to such a thing just because a project moved to the ASF. The fact that the committer would have to send in the CLA and wait for an account is already an impediment enough, it gets even worse if they have to potentially fall into a debate with the younger generation of developers over their right to commit access. -garrett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Outside view on incubator policy to initial committer list
On 10/3/06, Martijn Dashorst [EMAIL PROTECTED] wrote: All, Just to pose an outsider view, being new to the ASF and not to hijack the discussion on the CFX/CeltiXFire, I would like to share my views on the policy of the incubator. From the documents I have read on the policy for entering, being inside and graduating from the incubator there is a lot of talk on process, but not a lot of explanation on *why* the process is in place, nor on how things are done. I can understand all the gripes you bring up, and I'll try to address each of them in turn... The first 'gripe' is the uncertainty for existing open source projects that want to join the ASF that their current contributors will be allowed to work on the project at Apache. The documents clearly state that such karma needs to be earned based on merit. It never states that merit earned in the past for the project can and *WILL* be used. This can only be found in heated discussions on this list. Ok, so for the record, I don't think anyone involved in the incubator thinks that ANY committer on an existing open source project that moves to the ASF should lose that status in the process. Unless there's some sort of legal situation where the person can't sign the CLA there should be NO reason that sort of thing should ever happen. The reason there have been recent discussions about who gets commit and who doesn't is rooted in a totally different situation (people who were not formerly developers on the codebase in question being granted commit as part of bringing the project to the ASF, without having done anything to earn it). You will find in such discussions a variety of views, but the most restrictive, and in my opinion negative for existing projects is the one that wants only the mentors being on the initial PPMC/committers list, and have the incubating community earn their merit on apache ground using patches, mailinglist activity and whatnot, without giving the originating developers the karma to commit directly in Apache incubator SVN for the project. This is very damaging for a project that is already active outside the ASF and will grind it to a halt. I don't think that anyone feels that this sort of precedure should be followed for an existing open source project. I certainly don't. If the prevailing opinion is that previously gained merit outside the ASF is taken into account, the policy should note that explicitly. I believe that is the case, and I believe that it should be noted explicitly in the policy. There really should be two sets of guidelines, one for existing open source projects, and one for projects that are just becoming open source, IMO. The second gripe is the fact that only the Incubator PMC members of the PPMC have binding votes. I think I understand the reasoning for this, but it is not clear how the PMC members will excercise their binding votes. Will they affect the average day-to-day affairs within a community where the mentors have no direct affiliation with? Or is this only a guiding vote, for things such as: - withholding a release when the podling is not considered ready - not granting karma (with good backing reasoning) - not taking in external code bases without the correct grant - etc. The policy should make it clear that the PPMC chairs with the binding votes, only have that executive power to vote on such things regarding process. I believe the problem here is a misunderstanding about how binding votes are actually used in ASF projects. In a normal ASF project, who has a binding vote and who does not is almost never spoken of. It's just not an issue. When talking about applying a new patch or ways to best fix a bug, an informal +1 from a new contributor or committer who is not on the PMC is just as welcome as one from a seasoned PMC member. It's NEVER been the case in my experience that people would be held off from committing a change until enough binding votes were gathered, that would be insane, and projects would grind to a halt in that situation. The only time that people need to care about making sure there are enough binding votes are for things like releases, granting commit access, adding people to the PMC, importing new codebases, stuff like that. The third gripe is that graduation has two components: a measurable component (active community, diverse, all legal matters resolved, no violating code, etc) and a non-measurable component (mature enough to be an 'apache' project). Given the sometimes extreme views expressed here (a nice read though :-), it is for an existing project really hard to trust such a process when you already have a healthy community which is basically put on hold whilst incubating, if you follow the incubator policy (and some egos) to the letter. Yes, it is definately unfortunate that some components in graduation are difficult to quantify, but there really isn't much of a way around that. Note that I understand the opposite views presented in the
Re: Policy on Initial Committership
On 10/2/06, Newcomer, Eric [EMAIL PROTECTED] wrote: How could they contribute when they were not given access? These guys have been asking for two weeks or more to be allowed to contribute, and in some cases did not even receive a reply. Uhh, what kind of world are you living in where the only way to contribute to an open source project is if you already have commit access? Commit needs to be earned, you earn it by sending in patches, fixing bugs, filing bugs, etc. None of those things require commit access, if they did then no open source project would ever get a new contributor. -garrett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Policy on Initial Committership
On 10/2/06, Mark Little [EMAIL PROTECTED] wrote: Without wanting to open up flames about what constitutes a true open source project: if you're trying to build up a community then not erecting artificial barriers to entry is a good start. I've used the Redhat/JBoss example already, but there are others where the communities thrive and grow because of a more enlightened approach! Plus, sticking with what was agreed collectively prior to the start of the project is another good community building act: or at least if you're going to change it, do it publicly and with the involvement of EVERYONE who was involved with the formation of the project. I'm not arguing that removing people from the list of committers was correct, I don't have the insight into the particular situation here, so I'll leave that to the mentors. I'm just objecting to the idea that it's impossible to contribute without commit access. If these people were really anxious to start helping out I would have expected to see more than when's my commit coming from them. -garrett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Policy on Initial Committership
On 10/2/06, Mark Little [EMAIL PROTECTED] wrote: That kind of depends what you're used to now doesn't it? In some circles really getting involved actively can best be done (can only be done) with committer rights. If that was the impression people were under, then they should break themselves of it right now, because it's not the way a succesful ASF project operates. If it's impossible to contribute without commit access then you've essentially decided that you don't ever need any new contributors, choking off any chance at a successful, diverse community before it even begins. -garrett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Policy on Initial Committership
On 10/2/06, Mark Little [EMAIL PROTECTED] wrote: Like I said before: Without wanting to open up flames about what constitutes a true open source project. Your statements are subjective. I said nothing about what constitutes a true open source project, simply about what constitutes a successful ASF project in my experience. Since you're trying to create a new ASF project, that seems like rather useful information for you to have. -garrett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PPMCs [was Re: what are required for contributing to release management]
On 10/1/06, Justin Erenkrantz [EMAIL PROTECTED] wrote: For example, if I were to work on a project for many months at Google Code and then propose it to come here, why shouldn't I continue to have a say in what the project does? Why do I need to justify myself all over again? Why aren't my past contributions enough to merit a seat on the PPMC? What gives the mentors the power to 'reset' the community and block me from participating until I jump through their vague and ill-defined hoops? Personally, I think the bar on commit to incoming projects should be simple, if you've made a contribution (code, docs, whatever) that's significant enough that it would justify commit access here, you should get it. For projects that are coming from the open source world, that just means If you've got commit on it before it's at the ASF, you still do when it moves to the ASF, if it's corporate then obviously some due diligence needs to be done, but I think that's probably important in order to prevent the problem of providing a backdoor that avoids the whole meritocracy thing. Specifically though, I'd like to be clear that I don't think you should have to be an active participant in the project at the time it moves to the ASF in order to get commit/PPMC membership. As long as you're paying attention enough to sign the paperwork, the fact that you at one point qualified for this sort of access should be enough IMO. I know personally, when I have earned commit access to a project I expect that to still be there in the future, even if I fall off the planet for a while and don't have time to work on it. If the project had moved to the ASF in the meantime and all of a sudden I had to fight my way back to the same level of access I had in the past, I'd be pissed. -garrett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PPMCs [was Re: what are required for contributing to release management]
On 9/28/06, Dan Diephouse [EMAIL PROTECTED] wrote: robert burrell donkin wrote: thinking about whether there's a need to wait to release until the PPMC is fully formed and representation of the podling committers. PPMCs are typically filled up relatively late in the process - towards graduation. (whether this is a good idea, i'm not sure.) if there are just mentors on the PPMC then i see no benefit in waiting until the PPMC is composed of a representation cross-section of committers before creating a release. - robert Hiya, Pardon my ignorance here, but can you elaborate or point me to docs on how exactly the PMCs are formed? I know that the mentors from a project are on it, but as for the rest of the committers I have heard conflicting things. I have heard that you need to be voted on and I have also heard that the all of initial committers ends up on the PPMC. Obviously it can't be both and I can't find any real docs on it (http://incubator.apache.org/guides/ppmc.html is silent) either. Well, PMCs are formed by the board when a project moves to top level status. PPMCs are formed for an incubating project, and exactly how that works tends to differ a bit between projects. Some mentors start off with just the mentors on the PPMC, and then invite project members as time goes on (or that's the impression I've gotten). Others just start with the whole group of committers plus the mentors on the PPMC (that's what we did with Abdera). -garrett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PPMCs [was Re: what are required for contributing to release management]
On 9/28/06, robert burrell donkin [EMAIL PROTECTED] wrote: On 9/28/06, Dan Diephouse [EMAIL PROTECTED] wrote: Garrett Rooney wrote: snip PPMCs are formed for an incubating project, and exactly how that works tends to differ a bit between projects. Some mentors start off with just the mentors on the PPMC, and then invite project members as time goes on (or that's the impression I've gotten). Others just start with the whole group of committers plus the mentors on the PPMC (that's what we did with Abdera). Well that explains my utter confusion. Thanks for the clarification. So this is up to the mentors to decide then? i think so (hopefully someone will jump in with a correction if i have this wrong) it would probably be a good idea to record any election as a VOTE of the mentors on the private list Makes sense to me. -garrett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Publish the Woden Milestone 6 release
On 9/26/06, John Kaputin (gmail) [EMAIL PROTECTED] wrote: We would now like to request the permission of the Incubator PMC to publish the Woden M6 archives on the Woden Download page at [2]. Please vote by 1pm EST, Friday September 29th 2006. [1] Proposal, http://mail-archives.apache.org/mod_mbox/ws-woden-dev/200609.mbox/[EMAIL PROTECTED] [2] Download, http://people.apache.org/dist/ws/woden/milestones/1.0.0M6-incubating/ Umm, maybe it's just me, but the fact that it's already in the dist directory implies that you're already distributing it. Or was that done sometime between this message showing up and me waking up and reading it? In all the releases I've ever been a part of you stick the files in someone's home directory on people, or some other place where it won't be mirrored, then vote, then move it into dist. -garrett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [doc] call for feedback for http://incubator.apache.org/guides/proposal.html
On 9/18/06, robert burrell donkin [EMAIL PROTECTED] wrote: http://incubator.apache.org/guides/proposal.html is currently a draft document. i think that it's strong enough to push towards promoting it (and putting it in the indexes). +1 to marking it as a non-draft document, it seems quite reasonable to me, and nothing jumped out as requiring changes. -garrett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] accept UIMA as a podling
On 9/19/06, Thilo Goetz [EMAIL PROTECTED] wrote: Garrett Rooney wrote: snip I'm sorry, but I have to vote -1 based on my new policy of rejecting any potential podling that can't explain what it is that they do within the first paragraph of the proposal. I'm a fairly intelligent person, but honestly I have no clue what an architecture and software framework for creating, discovering, composing and deploying a broad range of multi-modal analysis capabilities actually is, and I see little potential for any project that's so bad at selling themselves to actually grow a useful community. snip Garrett, you're right. Others have noted that our opening paragraphs are not very clear. We did however follow up with more explanation that satisfied others on the list. Are you saying that these further explanations are still not clear, or that those explanations should go into the proposal itself (as opposed to a link from the Wiki)? Yes, they should absolutely go into the proposal. You're asking us to vote on the proposal, not on some conversation on the mailing list. Of course, the fact that you had to be explicitly asked to explain what the project does in the mailing list discussion doesn't bode well in and of itself. My objection isn't just your proposal is unclear, it's also in part that you showed up at the incubator with a proposal that was incomprehensible to anyone who didn't already know what your project did. If that's how you're marketing yourselves to a group that you want to be a part of, how are you going to market yourself to the rest of the world. A big part of becoming an ASF project is attracting other developers who want to work with you, building a community, and that's hard to do when your basic introduction isn't comprehensible to someone new. We already have too many projects at the ASF who can't seem to explain what it is they do without a maze of incomprehensible acronyms, I see little benefit in adding something that does away with the acronyms yet still manages to be say very little about what it actually does. -garrett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] accept UIMA as a podling
On 9/19/06, Justin Erenkrantz [EMAIL PROTECTED] wrote: On Tue, Sep 19, 2006 at 02:07:33PM -0400, Garrett Rooney wrote: Of course, the fact that you had to be explicitly asked to explain what the project does in the mailing list discussion doesn't bode well in and of itself. My objection isn't just your proposal is unclear, it's also in part that you showed up at the incubator with a proposal that was incomprehensible to anyone who didn't already know what your project did. If that's how you're marketing yourselves to a group ...snip, snip, snip... Well, I think that's a little unfair. Your criticisms should be aimed at the mentors (Ian, Sam, Ken) - but I don't think it's fair to expect that people who are new to our community to understand how we work. That's what the mentors are for. If the mentor isn't doing their job, then take it up with them - not the people who are just learning who we are and how things work. You can place the blame wherever you like, but it seems to me that basic stuff like A proposal should explain what the project is used for isn't too high a bar to expect when people walk in the door. If a mentor is required to explain that, then that seems like a warning sign to me in and of itself. -garrett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] accept UIMA as a podling
On 9/19/06, Ian Holsman [EMAIL PROTECTED] wrote: Personally I look at some of the enterprise java proposals and have no clue about them either as i don't track the SOA/WS specs that closely. Yes, and that's a BAD thing. If this proposal was for some j2ee/WS/SOA related monstrosity with 98 different acronyms in the first paragraph it would be getting exactly the same -1 from me. -garrett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] accept UIMA as a podling
On 9/18/06, Ian Holsman [EMAIL PROTECTED] wrote: Hi, There has been some discussion around the UIMA proposal, we feel that all the issues forwarded have been addressed, and we would now like to officially propose UIMA to the Incubator for consideration. The proposal can be found in the Incubator wiki here: http://wiki.apache.org/incubator/UIMA Uhh, no it can't. That page doesn't exist. -garrett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] accept UIMA as a podling
On 9/18/06, Ian Holsman [EMAIL PROTECTED] wrote: [ ] +1 Accept UIMA as an Incubator podling [ ] 0 Don't care [X] -1 Reject this proposal for the following reason: I'm sorry, but I have to vote -1 based on my new policy of rejecting any potential podling that can't explain what it is that they do within the first paragraph of the proposal. I'm a fairly intelligent person, but honestly I have no clue what an architecture and software framework for creating, discovering, composing and deploying a broad range of multi-modal analysis capabilities actually is, and I see little potential for any project that's so bad at selling themselves to actually grow a useful community. Additionally, I believe we decided that having the final vote thread point to a Wiki page was a bad idea. It would be good to resend this with the actual proposal content inline so everyone can be sure what they're actually voting on. -garrett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RELEASES] any interest in a source audit tool?
On 9/14/06, robert burrell donkin [EMAIL PROTECTED] wrote: i have a basic tool that i've been running against the source releases recently. it's simple but helps to track down some basic issues. no documentation. would this tool be useful for podlings (mentors and release managers in particular)? if so, would it be appropriate to check the source in somewhere in the incubator public tree? I'd definately like to see it checked in somewhere. It would be very nice if release managers could find the type of issues you tend to point out before they cut an actual release. -garrett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Vote] Re: Abdera 0.1.0 Release Candidate
On 8/15/06, robert burrell donkin [EMAIL PROTECTED] wrote: i'm +1 Ok, that's one from Robert and one from me, does anyone else on the PMC care to chime in? -garrett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jini : Separate Governance and Implementation Projects
On 8/15/06, Bob Scheifler [EMAIL PROTECTED] wrote: Geir Magnusson Jr wrote: We have a tradition, for good reason, for not giving our projects technology domain ownership for implementations. I'd never support Apache EMail or Apache Web. It would help me if you could explain how these existing TLP names are different/OK: DB, Directory, Logging, Web Services, XML. Just because we did things in the past does not mean it was a good idea. -garrett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Vote] Re: Abdera 0.1.0 Release Candidate
On 8/14/06, James M Snell [EMAIL PROTECTED] wrote: Ok, so we've addressed most of the issues raised in the note below and believe we are ready to move forward with 0.1.0. The new zips are available at http://people.apache.org/~jmsnell +1 from me (binding) -garrett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Vote] Re: Abdera 0.1.0 Release Candidate
On 8/14/06, Garrett Rooney [EMAIL PROTECTED] wrote: On 8/14/06, James M Snell [EMAIL PROTECTED] wrote: Ok, so we've addressed most of the issues raised in the note below and believe we are ready to move forward with 0.1.0. The new zips are available at http://people.apache.org/~jmsnell +1 from me (binding) Actually, hold that... James, I just noticed that there are some jetty jars in the abdera.0.1.0-incubating.zip file. We didn't start using jetty for the tests until recently, after that branch was cut. what are they doing in there? -garrett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Accept Glasgow into Incubator
On 8/4/06, Gordon Sim [EMAIL PROTECTED] wrote: Danny Angus wrote: I think it is about time that we grew up and introduced a rule which prevents words already used as proper nouns from being proposed as project names unless there is some real and relevant on-topic connection. Just by way of explanation, this name was proposed as (a) it is where the project began and (b) it is a port, which was felt to have a loose association with messaging. As a connection (a) is certainly real, though I can understand that the relevance of (b) might be viewed as rather tenuous. Note that these reasons would have been obvious if the discussion on what to change the name to had happened in public... -garrett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Accept Glasgow into Incubator
On 8/4/06, J Aaron Farr [EMAIL PROTECTED] wrote: On 8/3/06, Mads Toftum [EMAIL PROTECTED] wrote: On Thu, Aug 03, 2006 at 05:54:14PM -0400, Garrett Rooney wrote: I'm sorry, but I have to vote -1 (binding). I very much agree with Garretts concerns - and would be much in favor of not bringing the project into incubation before they have proven an actual community and that they can work the standard the apache way. I feel it would look very much as an ASF endorsement of a standard that we may not have any influence on at all - maybe things will look different in a few months time, but right now I'm far from convinced. I understand that there are some specific circumstances in this case, but in general I believe this sort of criteria is why we get complaints that it's impossible to innovate at Apache any more. We require all the grunt work of innovation to occur outside of Apache. The issues of an open specification is one thing. But aren't proven an actual community and work the standard 'apache way' graduation requirements, not entry requirements? If we expect something coming into the incubator to already have a fully functioning, health Apache-style community, then the only point of the Incubator is for handling licensing issues. For what it's worth, I don't have any intrinsic problem with a group bringing some code to the ASF in an attempt to start a community around it, as long as that's what's actually happening. The general feeling I got from reading the mail around this proposal wasn't leaning in that direction, now that could just be a missunderstanding on my part, but it is part of what convinced me to vote -1. -garrett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Accept Glasgow into Incubator
On 8/4/06, Cliff Schmidt [EMAIL PROTECTED] wrote: Of course everyone should make their own minds about this after a careful reading of the threads (and may see things differently), but I wouldn't have agreed to champion the proposal if I had the sense there was not a commitment to create an open/transparent/meritocratic community around the project; I'm certainly not going to argue with Cliff on this point, I'm sure he has seen that commitment and thus can say that's what the people bringing this proposal to us want to do, but personally, I don't have that sort of insight into the situation at hand, I haven't had the sort of interaction with the people involved that Cliff has, so all I can base my opinion on is what's happened on this mailing list. In any event, any questions I have about intentions regarding forming open, meritocratic communities are only being raised because of the relationship they have with the ability of new contributors to participate in driving this specification. The issues are interconnected. nor would I, as a mentor, ever allow any project to move through incubation without actively working to create such a community. I have no doubt that this is the case, and if I said anything that implies otherwise I'm sorry. I have a great deal of faith in Cliff as a mentor, and I trust him to do the right thing with regard to building communities at the ASF. -garrett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Accept Glasgow into Incubator
I'm sorry, but I have to vote -1 (binding). I'm not in favor of the ASF endorsing a specification that seems to be completely under the control of a small number of companies with no way for new developers to participate in its development. The fact that we have done this in the past is unfortunate, but it doesn't change things in my opinion. AMQP seems to be moving in this direction, they've got some sort of agreement you can sign in order to provide them feedback, that's a step, but I don't see any mailing lists, I don't see any way for someone who doesn't work for one of the companies in question to join as an equal member, and in general I think it's premature for the ASF to get involved, and accepting an incubator project is getting involved. Additionally, since we've already decided that we need to do something about the open/closed specification question with regard to incubator projects, I think it's unfair to bring a new project into the incubator when it's possible that our decision could result in that project not being able to graduate. If we know we're going to have that debate eventually we should do so now, to wait until after the project is in incubation seems unfair to them. Finally, and I hate to say this because it may very well be just a cultural difference between projects the Glasgow developers have worked on and the way things work in ASF projects I'm familiar with, I think it's disturbing that all answers to questions concerning this proposal have been discussed in private and fed back to us through a single person. I don't see a community of individuals here, I see a collection of companies working to bring a new project to the ASF because they can benefit from the brand, and while that can certainly change with time its combination with the other problems means I can't vote in favor of the proposal. -garrett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: horses and carts; was: Accept Glasgow into Incubator
On 8/3/06, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: Mads, I'm not sure if you meant to vote, but it raises a dialog so I'm forking the subject. Mads Toftum wrote: I very much agree with Garretts concerns - and would be much in favor of not bringing the project into incubation before they have proven an actual community and that they can work the standard the apache way. Which is the cart and which is the horse? Code like stdcxx, derby, etc don't come from apache way communities. Working in an OSS community is a learned skill. These projects come to us with good code, and they come asking to learn how to operate as a community, rather than the traditional commercial development models. And what's the role of the incubator if not to teach those skills? FWIW, I don't have any problem with people showing up at the incubator with some code and wanting to build a community around it, that's just fine. I just want it to actually feel like that's the goal, and in this case that wasn't the feeling I was getting. Now it's perfectly possible that I was just getting the wrong impression, I could certainly be wrong, and it's quite hard to tell for sure when everything the people bringing this proposal to us says is behind closed doors except their conclusions. -garrett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: question about naming
On 7/31/06, sophitia que [EMAIL PROTECTED] wrote: On 7/31/06, Martin Sebor [EMAIL PROTECTED] wrote: Is it intended that either of the two mentions (specifically just the URL) satisfy this requirement? I.e., that something like this be sufficient on a third party web page that discusses the project: a href=http://incubator.apache.org/podling-name; Apache Podling-Name /a Hello Martin: From my perspective, the above is insufficient because it presumes that people understand that http://incubator.apache.org/ refers to a project in incubation. Perhaps this is a failure on our part, to do the sufficient branding of what the Apache Incubator is, but I'd say that until such time that the Apache Incubator has become better understood as an entity and process through the industry, that explicit mention of a project in incubation/in the Apache Incubator is necessary. If that's the case then someone should change the docs, since that's totally not how I read it. Judging from what's there now, just using the link to incubator.a.o seems like it should be totally sufficient. -garrett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Abdera 0.1.0 Release Candidate (please review)
On 7/26/06, James M Snell [EMAIL PROTECTED] wrote: The Abdera podling has reached a point where the committers feel we're ready to cut a 0.1.0 developer preview / developer milestone release. We have +1's from all committers [1] and zero -1's. The release candidate is available at: http://people.apache.org/~jmsnell Java5 and JDK 1.4.2 versions are available, as well as a source distribution. All source contains appropriate copyright statements and, as far as I know, all dependency requirements have been met. Ant and Maven build options are available. Given that this is the first release, please forgive me if I have missed a step in here somewhere, but from what I understand, the next step is to ask y'all to review and approve the release candidate. +1 from me. Sorry I didn't get to this sooner, OSCON made the last week or so rather chaotic... -garrett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Abdera 0.1.0 Release Candidate (please review)
On 7/30/06, robert burrell donkin [EMAIL PROTECTED] wrote: On 7/26/06, James M Snell [EMAIL PROTECTED] wrote: The Abdera podling has reached a point where the committers feel we're ready to cut a 0.1.0 developer preview / developer milestone release. We have +1's from all committers [1] and zero -1's. The release candidate is available at: http://people.apache.org/~jmsnell Java5 and JDK 1.4.2 versions are available, as well as a source distribution. All source contains appropriate copyright statements and, as far as I know, all dependency requirements have been met. Ant and Maven build options are available. Given that this is the first release, please forgive me if I have missed a step in here somewhere, there's a lot of documentation that hasn't been written up yet do i'll certainly do that :-) but from what I understand, the next step is to ask y'all to review and approve the release candidate. i note that you haven't included sample MD5 sums and signatures. that's fine if you're confident. a few notes on best practice for future reference: * the binary and source distributions should unpack to directories with different names. this makes things more convenient for people who download both source and binary versions. also makes it more obvious when the source is downloaded. conventionally the source would unpack to abdera-x.y.z-incubator-src. This would be nice. Will look into it. * list supported build tool versions (ant and maven) in the build README (doesn't work with installation of maven 1.0.2) Good point, will tweak. * the MANIFEST files should comply with the various java standards on this matter. these are really a long way away so i can't list just a few corrections. creating complient releases should be included in the release management guide very soon but for now see http://jakarta.apache.org/commons/releases/prepare.html#checkjarmanifest This is one of those areas I'm pretty ignorant on, but I'll try and take a look if nobody beats me to it. important notes * there are no license or notice files in the jars distributed in the binary. though this is not necessarily a blocking issue, these artifacts cannot be distributed as raw jars without them. therefore these jars cannot be distributed through maven. if you want to do this, you must include LICENSE and NOTICE files in the jars. This does seem like something we should fix, I'll look into it soon. blocking issues * copyright headers missing from too many source files (pom.xmls, build.xmls, numerous xml and xslt files, docs/*.html). not all of these files will be substantial enough for copyright to exist in them but IMHO there are so many that this should be addressed before releasing. IMO the license headers should be addressed before this release I've added copyright headers to the docs, pom files, build.xml, and a few java files that slipped in without them. So far I haven't added them to the various .xml files in the test suites since, well, the average feed you parse off of the net doesn't have a big honking comment at the top, so it seems like we'd be deviating a bit from what we intend to test. There are numerous files in numerous ASF projects that don't contain embedded licenses (images, for example), I'm not sure if this fits the same category, but I suspect it might. Similarly I haven't added them to the properties files we parse at runtime, since it seems silly to increase the size of the file by more than an order of magnitude if all that data is just going to be run over by the parser when it's looking for the data it needs. Haven't merged this into the release branch yet, but it'll happen before the release is rerolled. I'd also be curious what people think about the test case xml files issue. -garrett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Blaze and Openness of Standards (was Re: [Proposal] Blaze)
On 7/27/06, Carl Trieloff [EMAIL PROTECTED] wrote: After debate, and many trademark searches we have selected new name that is free of any trademarks in the software space. ( not that easy) The new name for Blaze is Glasgow. I will update the wiki. How about the Glasgow Haskell Compiler? http://www.haskell.org/ghc/ -garrett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Blaze and Openness of Standards (was Re: [Proposal] Blaze)
On 7/27/06, Carl Trieloff [EMAIL PROTECTED] wrote: Garrett Some of us spoke about this at lunch. As Glasgow is part of the university name, Glasgow Haskell it should not present a conflict. In addition, our legal department has conducted a trademark search of the word Glasgow and come up with no software-related registrations. I don't know, it still seems awfully close to me, when I hear the word Glasgow in a software context that's the first thing I think of. -garrett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: piling on
On 7/19/06, Ian Holsman [EMAIL PROTECTED] wrote: are you referring to mentors as well? Personally, yes, I feel this should apply to mentors as well. While there are cases where a mentor needs commit access for some sort of procedural issues (maintaining STATUS files, helping to fix up licensing issues, and whatnot), they should absolutely not have general commit access to the codebase until they have earned it like any other developer. Note that this is exactly what I did with the Abdera podling, despite the fact that I'm acting as a mentor I sent in patches and waited for them to be applied like any other contributor would have to. -garrett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: piling on
On 7/19/06, Andrus Adamchik [EMAIL PROTECTED] wrote: +1. As a member of an incubating project I totally agree with this. What I didn't know is that there was a policy that allowed anyone to just declare themselves committers without consensus of the existing project participants? I don't believe there's actually a policy that actively allows it, but I have seen it happen with several projects, and it certainly seemed odd to me. -garrett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: piling on
On 7/19/06, Noel J. Bergman [EMAIL PROTECTED] wrote: Garrett Rooney wrote: Personally, yes, I feel this should apply to mentors as well. The Mentors are all Incubator PMC members, and the Incubator PMC as a whole oversees all Incubator projects. Every Incubator PMC member has an equal binding vote on every Incubator matter, and ought to be able to act in an appropriate and responsible manner. Yes, if we create our own discord, we'll have to deal with it amongst ourselves, but we're not going to start by limiting the scope of our PMC members. Especially not without some justification that it is necessary. Sure, but I think it should be made clear to mentors that the fact that nothing is preventing them from committing changes to the project they mentor doesn't mean that they should do so with abandon. If they want to contribute as a committer they should earn that right as any other contributor would. Of course, if they need to change something because the podling has screwed something up from a legal/procedural/whatever standpoint, that's another issue entirely, and they shouldn't hesitate to do so. -garrett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: piling on
On 7/19/06, Noel J. Bergman [EMAIL PROTECTED] wrote: Garrett Rooney wrote: Sure, but I think it should be made clear to mentors that the fact that nothing is preventing them from committing changes to the project they mentor doesn't mean that they should do so with abandon. Does my response to Martin sufficiently reflect your view? Yes, we are 100% in agreement as far as I can tell. -garrett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Dormancy
On 7/17/06, Noel J. Bergman [EMAIL PROTECTED] wrote: We have several projects that appear to be dormant, so let's discuss what that means in terms of operational mechanics. FWIW, It's merely the lack of a clue as to what needs to be changed that's kept me from closing down lucene4c. Well, that and being busy on other stuff ;-) I'd suggest that the PMC declare a project as dormant, with the effect being that we set the SVN ACL to read-only. If people want to wake the project up, we can change the ACL. I'm not sure what would be best for the mailing list. If we make make them subscriber only, we would need people watching the lists, anyway. Leave them ostensibly place, but forward them to [EMAIL PROTECTED] Or do we just turn them off, with a bounce notice that people interested in resurrecting the project contact us on [EMAIL PROTECTED] And we can add a dormant section to the project index. Personally, I'd be in favor of closing the lists down, mainly because a large percentage of the moderator spam I get is from lucene4c lists ;-) -garrett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Dormancy
On 7/17/06, Noel J. Bergman [EMAIL PROTECTED] wrote: Garrett Rooney wrote: FWIW, It's merely the lack of a clue as to what needs to be changed that's kept me from closing down lucene4c. That, and Agila and a couple of others, prompted my e-mail. I'd suggest that the PMC declare a project as dormant, with the effect being that we set the SVN ACL to read-only. If people want to wake the project up, we can change the ACL. So no debate on this? That seems fine. I'm not sure what would be best for the mailing list. ... Or do we just turn them off, with a bounce notice that people interested in resurrecting the project contact us on [EMAIL PROTECTED] Personally, I'd be in favor of closing the lists down So along the lines of above? Yep. -garrett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
