Re: [VOTE] Recommend graduating Apache Bean-Validation (BVAL) as a TLP
+1 2012/1/8 Mark Struberg strub...@yahoo.de: Dear IPMC, dear Community! The Apache Bean-Validation project provides an ALv2 licensed implementation of the JSR-303 Bean Validation Specification and would like to start a VOTE on graduating as a TLP. The podling is in the incubator since 2010 and successfully shipped 3 releases and established an active community. The internal PPMC VOTE has decided with 11 +1 (see [1]) that we would like to propose graduation as a TLP. We also went through the graduation checklist and made sure that we fulfilled all requirements. We would like to thank our Mentors and the board for their continued support and also Roman Stumm and his team for contributing this project to the ASF! We are happy to finally start the VOTE about the recommendation to the board about graduating BVAL to a TLP with the Board Resolution Report attached below. For better readability, the Resolution text is also available in our WIKI [2] Please VOTE on recommending BVAL as a TLP [+1] graduate BVAL as a TLP [+0] don't care [-1] nope, because (fill in) The VOTE is open for 72h. Incubator Page : http://incubator.apache.org/bval Status Page : http://incubator.apache.org/projects/beanvalidation.html thanks, the BVAL PPMC Board Resolution Report -- 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 creating an implementation compliant with JSR-303 and a library of pre-developed validators and extensions for distribution at no charge to the public. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the Apache Bean Validation Project, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache Bean Validation Project be and hereby is responsible for the creation and maintenance of software related to creating an implementation compliant with JSR-303 and a library of pre-developed validators and extensions; and be it further RESOLVED, that the office of Vice President, Apache Bean Validation 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 Bean Validation Project, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache Bean Validation 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 Bean Validation Project: * Albert Lee allee8...@apache.org * Carlos Vara Callau carlosv...@apache.org * David Jencks djen...@apache.org * Donald Woods dwo...@apache.org * Gerhard Petracek gpetra...@apache.org * Jeremy Bauer jrba...@apache.org * Kevan Lee Miller ke...@apache.org * Luciano Resende lrese...@apache.org * Matthias Wessendorf mat...@apache.org * Matthew Jason Benson mben...@apache.org * Mohammad Nour El-Din mn...@apache.org * Niall Pemberton nia...@apache.org * Roman Stumm romanst...@apache.org * Simone Tripodi simonetrip...@apache.org * Mark Struberg strub...@apache.org NOW, THEREFORE, BE IT FURTHER RESOLVED, that Matthew Jason Benson be appointed to the office of Vice President, Apache Bean Validation, 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 Bean Validation 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 Bean Validation Project; and be it further RESOLVED, that the Apache Bean Validation Project be and hereby is tasked with the migration and rationalization of the Apache Incubator Bean Validation podling; and be it further RESOLVED, that all responsibilities pertaining to the Apache Incubator Bean Validation podling encumbered upon the Apache Incubator Project are hereafter discharged. [1] http://mail-archives.apache.org/mod_mbox/incubator-bval-dev/20.mbox/%3CCAOvkMoZ6EVNDZ2SNq44L992JTr_oquoJV2Oun-fKhpYX03DPiQ%40mail.gmail.com%3E [2] https://cwiki.apache.org/confluence/display/BeanValidation/Graduation+Proposal - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy
Re: [VOTE] Recommend graduating Apache Bean-Validation (BVAL) as a TLP
+1 Regards JB On 01/09/2012 09:04 AM, Olivier Lamy wrote: +1 2012/1/8 Mark Strubergstrub...@yahoo.de: Dear IPMC, dear Community! The Apache Bean-Validation project provides an ALv2 licensed implementation of the JSR-303 Bean Validation Specification and would like to start a VOTE on graduating as a TLP. The podling is in the incubator since 2010 and successfully shipped 3 releases and established an active community. The internal PPMC VOTE has decided with 11 +1 (see [1]) that we would like to propose graduation as a TLP. We also went through the graduation checklist and made sure that we fulfilled all requirements. We would like to thank our Mentors and the board for their continued support and also Roman Stumm and his team for contributing this project to the ASF! We are happy to finally start the VOTE about the recommendation to the board about graduating BVAL to a TLP with the Board Resolution Report attached below. For better readability, the Resolution text is also available in our WIKI [2] Please VOTE on recommending BVAL as a TLP [+1] graduate BVAL as a TLP [+0] don't care [-1] nope, because (fill in) The VOTE is open for 72h. Incubator Page : http://incubator.apache.org/bval Status Page: http://incubator.apache.org/projects/beanvalidation.html thanks, the BVAL PPMC Board Resolution Report -- 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 creating an implementation compliant with JSR-303 and a library of pre-developed validators and extensions for distribution at no charge to the public. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the Apache Bean Validation Project, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache Bean Validation Project be and hereby is responsible for the creation and maintenance of software related to creating an implementation compliant with JSR-303 and a library of pre-developed validators and extensions; and be it further RESOLVED, that the office of Vice President, Apache Bean Validation 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 Bean Validation Project, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache Bean Validation 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 Bean Validation Project: * Albert Leeallee8...@apache.org * Carlos Vara Callaucarlosv...@apache.org * David Jencksdjen...@apache.org * Donald Woodsdwo...@apache.org * Gerhard Petracekgpetra...@apache.org * Jeremy Bauerjrba...@apache.org * Kevan Lee Millerke...@apache.org * Luciano Resendelrese...@apache.org * Matthias Wessendorfmat...@apache.org * Matthew Jason Bensonmben...@apache.org * Mohammad Nour El-Dinmn...@apache.org * Niall Pembertonnia...@apache.org * Roman Stummromanst...@apache.org * Simone Tripodisimonetrip...@apache.org * Mark Strubergstrub...@apache.org NOW, THEREFORE, BE IT FURTHER RESOLVED, that Matthew Jason Benson be appointed to the office of Vice President, Apache Bean Validation, 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 Bean Validation 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 Bean Validation Project; and be it further RESOLVED, that the Apache Bean Validation Project be and hereby is tasked with the migration and rationalization of the Apache Incubator Bean Validation podling; and be it further RESOLVED, that all responsibilities pertaining to the Apache Incubator Bean Validation podling encumbered upon the Apache Incubator Project are hereafter discharged. [1] http://mail-archives.apache.org/mod_mbox/incubator-bval-dev/20.mbox/%3CCAOvkMoZ6EVNDZ2SNq44L992JTr_oquoJV2Oun-fKhpYX03DPiQ%40mail.gmail.com%3E [2] https://cwiki.apache.org/confluence/display/BeanValidation/Graduation+Proposal - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com
On Etch status
Etch is a cross-platform, language- and transport-independent framework for building and consuming network services. The Etch toolset includes a network service description language, a compiler, and binding libraries for a variety of programming languages. It currently supports C, C# and Java. Support for Go, JavaScript and Python is deemed alpha status. Etch has 4 mentors listed: Yonik, Doug, Niclas and myself. Currently it seems I am the only mentor active. The facts: - We have roughly 4 active contributors: 3 committers and 1 person responding to messages on the dev/user lists. - We know how to add committers: the 3 currently active committers were all not part of the team when incubation started. One of them was voted in in the last half year. - The community is diverse, or as diverse you can get in a 4 person group. - We know how to cut releases. - Reporting has been on schedule. The podling is IMO ready to graduate, but lacks a sustainable community (as noted elsewhere). The podling started out as a project of Cisco, and had an active group of committers, but when the economy happened, the team was disbanded and effectively left the podling stranded. When I think of the reasons why people are reluctant to join Etch, I think that: - being in incubation hinders adoption of the code base - its use is not advertised well (e.g. BMW uses it in their Minis) - competition in the networking library space is fierce (though not too many libs exist) The project can address 2, 3 is something external and the IPMC can address 1. Now the big question: is Etch a candidate for graduating to TLP? I think it is, given the facts. It will be a TLP with issues of activity, but so far user questions, development questions are answered and releases are cut. The website has been updated recently, so I don't see an immediate danger of the project going south. I think that graduation of the podling will be a good thing and might give the project a bit of renewed energy. So... What to do? Martijn - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: On Etch status
Just as an aside: I intend on staying with the PMC to provide oversight as a Member (and being a familiar Mentor), provided the Etch community wants me to tag along. Martijn On Mon, Jan 9, 2012 at 9:39 AM, Martijn Dashorst martijn.dasho...@gmail.com wrote: Etch is a cross-platform, language- and transport-independent framework for building and consuming network services. The Etch toolset includes a network service description language, a compiler, and binding libraries for a variety of programming languages. It currently supports C, C# and Java. Support for Go, JavaScript and Python is deemed alpha status. Etch has 4 mentors listed: Yonik, Doug, Niclas and myself. Currently it seems I am the only mentor active. The facts: - We have roughly 4 active contributors: 3 committers and 1 person responding to messages on the dev/user lists. - We know how to add committers: the 3 currently active committers were all not part of the team when incubation started. One of them was voted in in the last half year. - The community is diverse, or as diverse you can get in a 4 person group. - We know how to cut releases. - Reporting has been on schedule. The podling is IMO ready to graduate, but lacks a sustainable community (as noted elsewhere). The podling started out as a project of Cisco, and had an active group of committers, but when the economy happened, the team was disbanded and effectively left the podling stranded. When I think of the reasons why people are reluctant to join Etch, I think that: - being in incubation hinders adoption of the code base - its use is not advertised well (e.g. BMW uses it in their Minis) - competition in the networking library space is fierce (though not too many libs exist) The project can address 2, 3 is something external and the IPMC can address 1. Now the big question: is Etch a candidate for graduating to TLP? I think it is, given the facts. It will be a TLP with issues of activity, but so far user questions, development questions are answered and releases are cut. The website has been updated recently, so I don't see an immediate danger of the project going south. I think that graduation of the podling will be a good thing and might give the project a bit of renewed energy. So... What to do? Martijn -- Become a Wicket expert, learn from the best: http://wicketinaction.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Small but otherwise happy podlings
Benson, I dint have time for a full response. However, I have a couple podlings that are in a similar position to Isis. That is, reasonably healthy, but small community. The ASF is about communities, if there is no community there is no TLP. Without having a concrete proposal from you regardunf your special case we can't comment on your suggestion. For my podlings I'll take responsibility for discussing with the committers and other mentors and representing them here in the IPMC. I will ensure those that have a chance of becoming TLPs stay here. As a result I don't think any of them are threatened by this exercise and thus I don't see any urgent need for policy change. However, if you have a concrete proposal, I'm all ears. Ross Sent from my mobile device, please forgive errors and brevity. On Jan 9, 2012 2:56 AM, Benson Margulies bimargul...@gmail.com wrote:
Re: Small but otherwise happy podlings
On Mon, Jan 9, 2012 at 2:55 AM, Benson Margulies bimargul...@gmail.com wrote: On Sun, Jan 8, 2012 at 7:37 PM, Sam Ruby ru...@intertwingly.net wrote: On Sun, Jan 8, 2012 at 7:00 PM, Benson Margulies bimargul...@gmail.com wrote: Sam, Rather than argue about the existence and interpretation of messages about squashing stale podlings, how about this adjustment to my presentation: 1. OK, let's forget about dumping aged podlings We have quite a number of aged podlings with no activity and AWOL mentors. I don't want to forget about that. I continue to want to focus on that. Not on tossing, or allowing to continue indefinitely, or graduating prematurely. Instead I want to verify that the people who signed on as mentors, presumably in good faith at that time, are still on board. Sam, I started this separate thread because I view this situation as distinctive from the problem you are referring to here. I take that situation just as seriously as you do, I think. If you'd prefer that I drop this (less urgent) problem until that one is under control. I'm happy to do so. 2. The third option I presented was 'graduate with an asterix'. However, I didn't really intend to claim that no other possibilities existed. Another possibility is 'remain under the supervision of the incubator PMC but with more autonomy.' I could elaborate, but I'd rather see if there is a remote consensus to go in any direction like this. You want to see if people will agree to sign a blank check? My suggestion is that you present a more concrete proposal than more autonomy if you want people to agree to it. No, I'm not asking for a blank check. I'm asking you and the other more experienced people if you think that the idea of treating Isis-like podlings differently from other podlings by giving them more autonomy and less oversight makes any sense to you. If you all say, 'no, we don't want to change anything,' I'll drop it. If you say 'hmm, let's talk details,' then I'll attempt to flesh out details. However, since your bottom line is 'make a more concrete proposal,' then I will, but I will wait a bit to see if this thread attracts any other thoughts about the overall concept first. Hi Benson, I don't know about the more autonomy proposal but I had a quick look at Isis. If they've never added any new committers thats a worry but other than that they seem to meet all the other graduation requirements. Do you or the other mentors have any feel for why they've not added any new committers - are they over protective of their code or have they really just had no one ever come along offering patches or anything? ...ant - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Recommend graduating Apache Bean-Validation (BVAL) as a TLP
On Mon, Jan 9, 2012 at 4:11 AM, sebb seb...@gmail.com wrote: On 8 January 2012 21:04, Mark Struberg strub...@yahoo.de wrote: Dear IPMC, dear Community! The Apache Bean-Validation project provides an ALv2 licensed implementation of the JSR-303 Bean Validation Specification and would like to start a VOTE on graduating as a TLP. The podling is in the incubator since 2010 and successfully shipped 3 releases and established an active community. The internal PPMC VOTE has decided with 11 +1 (see [1]) that we would like to propose graduation as a TLP. We also went through the graduation checklist and made sure that we fulfilled all requirements. We would like to thank our Mentors and the board for their continued support and also Roman Stumm and his team for contributing this project to the ASF! We are happy to finally start the VOTE about the recommendation to the board about graduating BVAL to a TLP with the Board Resolution Report attached below. For better readability, the Resolution text is also available in our WIKI [2] Please VOTE on recommending BVAL as a TLP [+1] graduate BVAL as a TLP [+0] don't care [-1] nope, because (fill in) The VOTE is open for 72h. Incubator Page : http://incubator.apache.org/bval Status Page : http://incubator.apache.org/projects/beanvalidation.html thanks, the BVAL PPMC Board Resolution Report -- 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 creating an implementation compliant with JSR-303 and a library of pre-developed validators and extensions for distribution at no charge to the public. I'm not sure I follow the sentence after related to. implementation of what? Do the validators and extensions relate to JSR-303? Or are they independent? Is this Java-only software, or could other languages be used? I agree that the project description words don't seem perfect and if you go with this i think the board may ask you to refine them, but +1 to the principle of graduating bval. ...ant - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Recommend graduating Apache Bean-Validation (BVAL) as a TLP
Hi, +1 to graduate, with the following note: On Sun, Jan 8, 2012 at 10:04 PM, Mark Struberg strub...@yahoo.de wrote: 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 creating an implementation compliant with JSR-303 and a library of pre-developed validators and extensions for distribution at no charge to the public. As noted by others, the project scope could use some clarification. Also, rather than referring specifically to JSR-303, it would probably be better to refer to the Bean Validation API to avoid tying the project to a specific version of the API. For example the Apache Jackrabbit resolution [1] referred to the Content Repository for Java Technology API instead of JSR-170 which would by now (with JSR-283 and JSR-333 defining updated API versions) be outdated. [1] http://www.apache.org/foundation/records/minutes/2006/board_minutes_2006_03_15.txt BR, Jukka Zitting - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Actively retiring projects (was: Incubator Board Report November 2011)
Just an FYI: I have posted a status update on Etch on general@, hoping it doesn't fall on deaf ears with all the discussions going on: http://mail-archives.apache.org/mod_mbox/incubator-general/201201.mbox/%3ccab63y-dsjkbkeljkhuvkbdlmsjwvfvixo0fnxexofhq1v4m...@mail.gmail.com%3e Martijn On Sun, Jan 8, 2012 at 1:46 PM, Jukka Zitting jukka.zitt...@gmail.com wrote: Hi, What's the status of this effort? I went through all the older-than-year podlings identified by Sam for a quick (i.e. incomplete) review of the project status. See below for my summary (S) and subjective recommendation (R) for each project. Please branch any followup discussion about specific podlings to separate threads. On Wed, Nov 16, 2011 at 9:36 PM, Sam Ruby ru...@intertwingly.net wrote: 2007-09-17 JSPWiki S: Actively discussing leaving the Incubator (http://markmail.org/message/etgsawr7mtjggppt). R: Ask for an exit or graduation plan in next report (if not executed sooner). 2008-01-06 RAT S: Looking to graduate but stuck with (self-inflicted?) bureacracy. R: Push to graduate within Q1. 2008-05-20 Hama S: Active but not too diverse (?) community. R: Ask for a graduation plan in next report. 2008-07-08 Empire-db S: Graduating in January. R: Congratulations! 2008-08-19 PhotArk S: Zero recent activity. R: Terminate. 2008-09-02 Etch S: Too small to graduate yet (http://markmail.org/message/ihkdh4rfunwzkjs7). Martijn is helping them. R: More mentors needed? 2008-09-04 Tashi S: Commit activity by two committers but near-zero public discussion. No active mentors. R: Mentors needed. 2008-09-29 Olio S: Retired. R: RIP. 2008-10-06 VCL S: Fairly active but not diverse enough community. R: More mentor help needed for the community solve the diversity issue? 2008-10-09 Droids S: Somewhat active, still not enough for a TLP. Last report mentions IP clearance issues? R: Ask for a graduation plan in next report. 2008-11-06 Kato S: Zero activity. R: Terminate. 2008-11-19 Stonehenge S: Zero activity. R: Terminate. 2009-04-24 Ace S: Graduated. R: Congratulations! 2009-05-27 Wink S: Pretty low but steady activity. Too small to graduate. R: Ask for a graduation plan in next report. 2009-07-06 VXQuery S: Zero recent activity. R: Terminate. 2009-07-17 Wookie S: Somewhat active, not enough for a TLP. R: Ask for a graduation plan in next report. 2009-11-05 HISE S: Zero recent activity. R: Terminate. 2009-11-27 Clerezza S: Fairly active but not diverse enough community. R: More mentor help needed for the community solve the diversity issue? 2010-01-10 Manifold Connector Framework (ManifoldCF) S: Fairly active but not diverse enough community. R: More mentor help needed for the community solve the diversity issue. 2010-02-21 SIS S: Last activity in November (http://mail-archives.apache.org/mod_mbox/incubator-sis-dev/20.mbox/browser) R: Retire unless activity picks up in Q1. 2010-03-01 Bean Validation S: Just about to graduate. R: Congratulations! 2010-05-09 Amber S: Somewhat active, not enough for a TLP. R: Ask for a graduation plan in next report. 2010-05-19 Deltacloud S: Graduated. R: Congratulations! 2010-05-21 Zeta Components S: Fairly active but not diverse enough community. Looking for a new mentor. R: More mentor help needed for the community solve the diversity issue. 2010-06-24 Nuvem S: Last activity in November (http://mail-archives.apache.org/mod_mbox/incubator-nuvem-dev/20.mbox/browser) R: Retire unless activity picks up in Q1. 2010-07-14 Chukwa S: Fairly active but not diverse enough community. R: More mentor help needed for the community solve the diversity issue? 2010-07-22 Lucy S: Active and apparently pretty diverse community. Why not already graduated? R: Ask for a graduation plan in next report. 2010-08-13 NPanday S: Active and apparently pretty diverse community. Why not already graduated? R: Ask for a graduation plan in next report. 2010-09-07 Isis S: Active and apparently pretty diverse community. Why not already graduated? R: Ask for a graduation plan in next report. 2010-09-26 Gora S: Graduating in January. R: Congratulations! 2010-10-03 Kitty S: Last activity in November (http://mail-archives.apache.org/mod_mbox/incubator-kitty-dev/20.mbox/browser) R: Retire unless activity picks up in Q1. 2010-11-02 Celix S: Somewhat active, not enough for a TLP. R: Ask for a graduation plan in next report. 2010-11-15 Stanbol S: Fairly active and apparently diverse community. No release yet. R: Ask for a graduation plan in next report. BR, Jukka Zitting - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- Become a Wicket expert, learn from the best: http://wicketinaction.com
Re: On Etch status
On Mon, Jan 9, 2012 at 8:39 AM, Martijn Dashorst martijn.dasho...@gmail.com wrote: Etch is a cross-platform, language- and transport-independent framework for building and consuming network services. The Etch toolset includes a network service description language, a compiler, and binding libraries for a variety of programming languages. It currently supports C, C# and Java. Support for Go, JavaScript and Python is deemed alpha status. Etch has 4 mentors listed: Yonik, Doug, Niclas and myself. Currently it seems I am the only mentor active. The facts: - We have roughly 4 active contributors: 3 committers and 1 person responding to messages on the dev/user lists. - We know how to add committers: the 3 currently active committers were all not part of the team when incubation started. One of them was voted in in the last half year. - The community is diverse, or as diverse you can get in a 4 person group. - We know how to cut releases. - Reporting has been on schedule. The podling is IMO ready to graduate, but lacks a sustainable community (as noted elsewhere). The podling started out as a project of Cisco, and had an active group of committers, but when the economy happened, the team was disbanded and effectively left the podling stranded. When I think of the reasons why people are reluctant to join Etch, I think that: - being in incubation hinders adoption of the code base - its use is not advertised well (e.g. BMW uses it in their Minis) - competition in the networking library space is fierce (though not too many libs exist) The project can address 2, 3 is something external and the IPMC can address 1. Now the big question: is Etch a candidate for graduating to TLP? I think it is, given the facts. It will be a TLP with issues of activity, but so far user questions, development questions are answered and releases are cut. The website has been updated recently, so I don't see an immediate danger of the project going south. I think that graduation of the podling will be a good thing and might give the project a bit of renewed energy. So... What to do? Looking at commits in the last three months shows only two active committers [1] extending that to six months shows three committers and looking in the mail archives i see that extra committer has emailed the dev list last month so is still around. So i think it could be argued that there are three active committers and assuming they're independent of each other then technically that meets that aspect of the minimum graduation requirements. Seems like a borderline case but there are other existing TLPs with few active committers. I did a bit of digging about in the project and i guess my gut feel would be if the mentors are recommending graduation is the best thing for them now and are going to be helping out by being on the PMC then i'd vote +1 for graduation too. ..ant [1] http://svnsearch.org/svnsearch/repos/ASF/search?from=20111001path=%2Fincubator%2Fetch - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Small but otherwise happy podlings
On Mon, Jan 9, 2012 at 5:28 AM, ant elder ant.el...@gmail.com wrote: On Mon, Jan 9, 2012 at 2:55 AM, Benson Margulies bimargul...@gmail.com wrote: On Sun, Jan 8, 2012 at 7:37 PM, Sam Ruby ru...@intertwingly.net wrote: On Sun, Jan 8, 2012 at 7:00 PM, Benson Margulies bimargul...@gmail.com wrote: Sam, Rather than argue about the existence and interpretation of messages about squashing stale podlings, how about this adjustment to my presentation: 1. OK, let's forget about dumping aged podlings We have quite a number of aged podlings with no activity and AWOL mentors. I don't want to forget about that. I continue to want to focus on that. Not on tossing, or allowing to continue indefinitely, or graduating prematurely. Instead I want to verify that the people who signed on as mentors, presumably in good faith at that time, are still on board. Sam, I started this separate thread because I view this situation as distinctive from the problem you are referring to here. I take that situation just as seriously as you do, I think. If you'd prefer that I drop this (less urgent) problem until that one is under control. I'm happy to do so. 2. The third option I presented was 'graduate with an asterix'. However, I didn't really intend to claim that no other possibilities existed. Another possibility is 'remain under the supervision of the incubator PMC but with more autonomy.' I could elaborate, but I'd rather see if there is a remote consensus to go in any direction like this. You want to see if people will agree to sign a blank check? My suggestion is that you present a more concrete proposal than more autonomy if you want people to agree to it. No, I'm not asking for a blank check. I'm asking you and the other more experienced people if you think that the idea of treating Isis-like podlings differently from other podlings by giving them more autonomy and less oversight makes any sense to you. If you all say, 'no, we don't want to change anything,' I'll drop it. If you say 'hmm, let's talk details,' then I'll attempt to flesh out details. However, since your bottom line is 'make a more concrete proposal,' then I will, but I will wait a bit to see if this thread attracts any other thoughts about the overall concept first. Hi Benson, I don't know about the more autonomy proposal but I had a quick look at Isis. If they've never added any new committers thats a worry but other than that they seem to meet all the other graduation requirements. Do you or the other mentors have any feel for why they've not added any new committers - are they over protective of their code or have they really just had no one ever come along offering patches or anything? As far as I've been able to determine, no one has come along. ...ant - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Small but otherwise happy podlings
On 9 January 2012 04:41, Kalle Korhonen kalle.o.korho...@gmail.com wrote: On Sun, Jan 8, 2012 at 10:23 AM, Benson Margulies bimargul...@gmail.com wrote: This has been the subject of prior conversations, but I'm opening a thread in some hope of reaching a definitive resolution. Some of our non-graduating podlings have a common problem. They look good in all ways except growth. This inhibits graduation from 2.5 standpoints: 1) they are dubiously large enough to sustain as a TLP. 2) they don't have much (or any) track record in incorporating new contributors. 2.5) they might not be very diverse. I list this as a .5 because I think that we've established that diversity is a lower priority. There are some possible responses to this situation. a) toss them out of the incubator. b) keep them in the incubator indefinitely. c) graduate them, but with some conditions. Should smaller incubator projects be encouraged to graduate as sub-projects of existing projects or is that not an option anymore? Specifically, I was thinking about Amber, which might just work as a sub-project of Apache Shiro if they are too small to make it on their own. However, we (the Shiro PMC) haven't suggested this to them and they haven't contacted us. Since Jakarta, my understanding is that the incubator would rather see the projects graduating as TLPs, not sub-projects, is that correct? I don't think so. It's just umbrella TLPs are discouraged. If the podling fits well with an existing TLP, and that TLP agrees to take it on, then it can graduate as a sub-project of that TLP. For example, Sanselan graduated into Commons, because it fits well with the Commons scope. Kalle - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Small but otherwise happy podlings
On 9 January 2012 12:46, Benson Margulies bimargul...@gmail.com wrote: On Mon, Jan 9, 2012 at 5:28 AM, ant elder ant.el...@gmail.com wrote: ... I don't know about the more autonomy proposal but I had a quick look at Isis. If they've never added any new committers thats a worry but other than that they seem to meet all the other graduation requirements. Do you or the other mentors have any feel for why they've not added any new committers - are they over protective of their code or have they really just had no one ever come along offering patches or anything? As far as I've been able to determine, no one has come along. OK, this is the same problem I have in one of my podlings (Wookie). The issue is how do we get them to come along. If potential contributors just do not exist then then sufficient diversity is not possible and being in the Incubator will therefore be indefinite. On the other hand if they are not coming for some other reason is being in the incubator a contributing factor? Do we want to allow projects that have little chance of reaching the diversity requirements? Do we want to help projects that find the incubator limits their ability to build diversity? For example, in the case of Wookie the code is serviceable. We are aware of a number of people who are using Wookie, but they are all in the RD rather than product spaces. Some of them have local forks with features we want from them. In most cases they are for some, often unknown, reason reticent to contribute. In one case we had a contribution but once that particular feature is included they are happy and engage no more. Of course, this is all perfectly normal for an open source project. In TLPs appropriate drive by contributions are not a problem as there is a community to maintain them. I don't know about Isis but the issue for Wookie, I think, is that it is building on a W3C standard that has yet to prove itself. Wookie is one of only a small number of fully compliant implementations of the standard. Its an interesting project from an RD perspective, but not one that people are likely to bet their future on (yet?). As an incubating project implementing a yet to be proved standard the risks are just too high. I don't think Wookie should graduate, but it certainly shouldn't be kicked out (and I don't think it will be). However, as I not above incubation may be holding it back. The question for me is, can we do more for projects that are in this position? I'm thinking about this from a Wookie perspective and will (I hope) have something concrete to suggest soon(ish), in the meantime does anyone have any ideas of how we can help projects like Isis and Wookie? Ross - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: [VOTE] Release Apache Rave 0.6-incubating
Does my answer below suffice? It would be nice to close this vote out one way or another -Original Message- From: Franklin, Matthew B. [mailto:mfrank...@mitre.org] Sent: Tuesday, January 03, 2012 12:19 PM To: general@incubator.apache.org Subject: RE: [VOTE] Release Apache Rave 0.6-incubating -Original Message- From: sebb [mailto:seb...@gmail.com] Sent: Tuesday, January 03, 2012 7:06 AM To: general@incubator.apache.org Subject: Re: [VOTE] Release Apache Rave 0.6-incubating On 28 December 2011 19:15, Franklin, Matthew B. mfrank...@mitre.org wrote: This is the fifth incubator release for Apache Rave, with the artifacts being versioned as 0.6-incubating. We are requesting at least one additional IPMC member vote, as we have received 2 binding IPMC +1 votes during the release voting on rave-dev - VOTE: http://s.apache.org/Czr RESULT: http://s.apache.org/yIQ IPMC member votes from the rave-dev list: Ate Douma: +1 Ross Gardler: +1 Release notes: http://svn.apache.org/repos/asf/incubator/rave/tags/0.6- incubating/CHANGELOG Apparently, I didn't commit back the CHANGELOG for 0.6 . Here is the issue list from JIRA https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311290 version=12317563 which says: Release Notes - Rave - Version 0.5-INCUBATING So what was changed for 0.6? SVN source tag (r1208867): https://svn.apache.org/repos/asf/incubator/rave/tags/0.6-incubating/ Maven staging repos: https://repository.apache.org/content/repositories/orgapacherave-278/ https://repository.apache.org/content/repositories/orgapacherave-279/ Source release: https://repository.apache.org/content/repositories/orgapacherave- 278/org/apache/rave/rave-project/0.6-incubating/rave-project-0.6- incubating-source-release.zip Binary releases http://people.apache.org/builds/incubator/rave/0.6-incubating/apache- rave-0.6-incubating-bin.tar.gz http://people.apache.org/builds/incubator/rave/0.6-incubating/apache- rave-0.6-incubating-bin.zip PGP release keys: https://svn.apache.org/repos/asf/incubator/rave/KEYS Vote open for 72 hours. [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Small but otherwise happy podlings
On Sun, Jan 8, 2012 at 9:55 PM, Benson Margulies bimargul...@gmail.com wrote: Sam, I started this separate thread because I view this situation as distinctive from the problem you are referring to here. I take that situation just as seriously as you do, I think. If you'd prefer that I drop this (less urgent) problem until that one is under control. I'm happy to do so. It is fair enough statement that not all of us need to work on what I happen to think is most urgent. This statement is true even if we might happen to agree on the relative priorities. I will merely point out that your suggestion is at least mildly at cross purposes to the issue that I want addressed. One of my concerns is that there are a number of podlings that are comfortably nestled in with no need to graduate. However, that is by no means my biggest concern, which is the silent attrition rate of mentors. In the case of Isis, I am fully prepared to accept that that podling has at least one active mentor. No, I'm not asking for a blank check. I'm asking you and the other more experienced people if you think that the idea of treating Isis-like podlings differently from other podlings by giving them more autonomy and less oversight makes any sense to you. If you all say, 'no, we don't want to change anything,' I'll drop it. If you say 'hmm, let's talk details,' then I'll attempt to flesh out details. However, since your bottom line is 'make a more concrete proposal,' then I will, but I will wait a bit to see if this thread attracts any other thoughts about the overall concept first. You previously mentioned that there might be incubator requirements that are burdensome on mentors. Identifying those and ways to address them are things that I could definitely support. Looking specifically at Isis, the last report[1] to the board contained: Top 3 Issues to address in move towards graduation * More blogging/publicity from existing community... * More users of the framework... * More committers to the framework The latter might be a concern. The first two however are not direct concerns. At most, they are indirect: i.e., ways to attract committers. Looking at the incubator page[2], I see more than three committers, and in fact four of them are ASF members. If at least one of these ASF members intends is willing to continue on the PMC, and the lack of committers were the only issue, then I would be comfortable with this podling graduating. - Sam Ruby [1] http://apache.org/foundation/records/minutes/2011/board_minutes_2011_10_26.txt [2] http://incubator.apache.org/projects/isis.html - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Apache Rave 0.6-incubating
On 9 January 2012 13:09, Franklin, Matthew B. mfrank...@mitre.org wrote: Does my answer below suffice? It would be nice to close this vote out one way or another The answer describes what happened. However, it does not fix the problem, which is that the end-user sees a file with conflicting information. Not a blocker, but you may find it takes less time overall to fix the issue before release rather than dealing with user queries afterwards. It may also lessen confidence in the release: if there is such an obvious error, what other errors are lurking? -Original Message- From: Franklin, Matthew B. [mailto:mfrank...@mitre.org] Sent: Tuesday, January 03, 2012 12:19 PM To: general@incubator.apache.org Subject: RE: [VOTE] Release Apache Rave 0.6-incubating -Original Message- From: sebb [mailto:seb...@gmail.com] Sent: Tuesday, January 03, 2012 7:06 AM To: general@incubator.apache.org Subject: Re: [VOTE] Release Apache Rave 0.6-incubating On 28 December 2011 19:15, Franklin, Matthew B. mfrank...@mitre.org wrote: This is the fifth incubator release for Apache Rave, with the artifacts being versioned as 0.6-incubating. We are requesting at least one additional IPMC member vote, as we have received 2 binding IPMC +1 votes during the release voting on rave-dev - VOTE: http://s.apache.org/Czr RESULT: http://s.apache.org/yIQ IPMC member votes from the rave-dev list: Ate Douma: +1 Ross Gardler: +1 Release notes: http://svn.apache.org/repos/asf/incubator/rave/tags/0.6- incubating/CHANGELOG Apparently, I didn't commit back the CHANGELOG for 0.6 . Here is the issue list from JIRA https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311290 version=12317563 which says: Release Notes - Rave - Version 0.5-INCUBATING So what was changed for 0.6? SVN source tag (r1208867): https://svn.apache.org/repos/asf/incubator/rave/tags/0.6-incubating/ Maven staging repos: https://repository.apache.org/content/repositories/orgapacherave-278/ https://repository.apache.org/content/repositories/orgapacherave-279/ Source release: https://repository.apache.org/content/repositories/orgapacherave- 278/org/apache/rave/rave-project/0.6-incubating/rave-project-0.6- incubating-source-release.zip Binary releases http://people.apache.org/builds/incubator/rave/0.6-incubating/apache- rave-0.6-incubating-bin.tar.gz http://people.apache.org/builds/incubator/rave/0.6-incubating/apache- rave-0.6-incubating-bin.zip PGP release keys: https://svn.apache.org/repos/asf/incubator/rave/KEYS Vote open for 72 hours. [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: [VOTE] Release Apache Rave 0.6-incubating
-Original Message- From: sebb [mailto:seb...@gmail.com] Sent: Monday, January 09, 2012 8:21 AM To: general@incubator.apache.org Subject: Re: [VOTE] Release Apache Rave 0.6-incubating On 9 January 2012 13:09, Franklin, Matthew B. mfrank...@mitre.org wrote: Does my answer below suffice? It would be nice to close this vote out one way or another The answer describes what happened. However, it does not fix the problem, which is that the end-user sees a file with conflicting information. Thanks. This is what I was looking for, so that we can have the discussion as to whether or not to cancel the release (we won't do a re-release). Not a blocker, but you may find it takes less time overall to fix the issue before release rather than dealing with user queries afterwards. It may also lessen confidence in the release: if there is such an obvious error, what other errors are lurking? While I agree that it doesn't look great, the CHANGELOG is distributed with the source release and is probably not viewed as much as the release notes sent out with the announcement (which will be the JIRA list I linked). I will take this back to our dev list, but if they don't see it as a blocker, would you be comfortable voting +1? -Original Message- From: Franklin, Matthew B. [mailto:mfrank...@mitre.org] Sent: Tuesday, January 03, 2012 12:19 PM To: general@incubator.apache.org Subject: RE: [VOTE] Release Apache Rave 0.6-incubating -Original Message- From: sebb [mailto:seb...@gmail.com] Sent: Tuesday, January 03, 2012 7:06 AM To: general@incubator.apache.org Subject: Re: [VOTE] Release Apache Rave 0.6-incubating On 28 December 2011 19:15, Franklin, Matthew B. mfrank...@mitre.org wrote: This is the fifth incubator release for Apache Rave, with the artifacts being versioned as 0.6-incubating. We are requesting at least one additional IPMC member vote, as we have received 2 binding IPMC +1 votes during the release voting on rave-dev - VOTE: http://s.apache.org/Czr RESULT: http://s.apache.org/yIQ IPMC member votes from the rave-dev list: Ate Douma: +1 Ross Gardler: +1 Release notes: http://svn.apache.org/repos/asf/incubator/rave/tags/0.6- incubating/CHANGELOG Apparently, I didn't commit back the CHANGELOG for 0.6 . Here is the issue list from JIRA https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=123112 90 version=12317563 which says: Release Notes - Rave - Version 0.5-INCUBATING So what was changed for 0.6? SVN source tag (r1208867): https://svn.apache.org/repos/asf/incubator/rave/tags/0.6-incubating/ Maven staging repos: https://repository.apache.org/content/repositories/orgapacherave- 278/ https://repository.apache.org/content/repositories/orgapacherave- 279/ Source release: https://repository.apache.org/content/repositories/orgapacherave- 278/org/apache/rave/rave-project/0.6-incubating/rave-project-0.6- incubating-source-release.zip Binary releases http://people.apache.org/builds/incubator/rave/0.6- incubating/apache- rave-0.6-incubating-bin.tar.gz http://people.apache.org/builds/incubator/rave/0.6- incubating/apache- rave-0.6-incubating-bin.zip PGP release keys: https://svn.apache.org/repos/asf/incubator/rave/KEYS Vote open for 72 hours. [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Small but otherwise happy podlings
I'm actively mentoring Isis. With having bval out of incubation I will also find a bit more time to review the bits and pieces a bit better. Isis really has a pretty active community and we have quite some users coming along. It would maybe make sense to shift direction a bit from a pure NakedObjects framework to a more EE6 extensible framework. That might attract new interest. Being kind of a 4GL framework might not be that sexy nowadays, so we might spice this up with EE6 extensibility. Will discuss this with the project in the coming days. LieGrue, strub - Original Message - From: Sam Ruby ru...@intertwingly.net To: general@incubator.apache.org Cc: Sent: Monday, January 9, 2012 2:10 PM Subject: Re: Small but otherwise happy podlings On Sun, Jan 8, 2012 at 9:55 PM, Benson Margulies bimargul...@gmail.com wrote: Sam, I started this separate thread because I view this situation as distinctive from the problem you are referring to here. I take that situation just as seriously as you do, I think. If you'd prefer that I drop this (less urgent) problem until that one is under control. I'm happy to do so. It is fair enough statement that not all of us need to work on what I happen to think is most urgent. This statement is true even if we might happen to agree on the relative priorities. I will merely point out that your suggestion is at least mildly at cross purposes to the issue that I want addressed. One of my concerns is that there are a number of podlings that are comfortably nestled in with no need to graduate. However, that is by no means my biggest concern, which is the silent attrition rate of mentors. In the case of Isis, I am fully prepared to accept that that podling has at least one active mentor. No, I'm not asking for a blank check. I'm asking you and the other more experienced people if you think that the idea of treating Isis-like podlings differently from other podlings by giving them more autonomy and less oversight makes any sense to you. If you all say, 'no, we don't want to change anything,' I'll drop it. If you say 'hmm, let's talk details,' then I'll attempt to flesh out details. However, since your bottom line is 'make a more concrete proposal,' then I will, but I will wait a bit to see if this thread attracts any other thoughts about the overall concept first. You previously mentioned that there might be incubator requirements that are burdensome on mentors. Identifying those and ways to address them are things that I could definitely support. Looking specifically at Isis, the last report[1] to the board contained: Top 3 Issues to address in move towards graduation * More blogging/publicity from existing community... * More users of the framework... * More committers to the framework The latter might be a concern. The first two however are not direct concerns. At most, they are indirect: i.e., ways to attract committers. Looking at the incubator page[2], I see more than three committers, and in fact four of them are ASF members. If at least one of these ASF members intends is willing to continue on the PMC, and the lack of committers were the only issue, then I would be comfortable with this podling graduating. - Sam Ruby [1] http://apache.org/foundation/records/minutes/2011/board_minutes_2011_10_26.txt [2] http://incubator.apache.org/projects/isis.html - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Recommend graduating Apache Bean-Validation (BVAL) as a TLP
On Mon, Jan 9, 2012 at 5:08 AM, Jukka Zitting jukka.zitt...@gmail.com wrote: Hi, +1 to graduate, with the following note: On Sun, Jan 8, 2012 at 10:04 PM, Mark Struberg strub...@yahoo.de wrote: 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 creating an implementation compliant with JSR-303 and a library of pre-developed validators and extensions for distribution at no charge to the public. As noted by others, the project scope could use some clarification. Also, rather than referring specifically to JSR-303, it would probably be better to refer to the Bean Validation API to avoid tying the project to a specific version of the API. For example the Apache Jackrabbit resolution [1] referred to the Content Repository for Java Technology API instead of JSR-170 which would by now (with JSR-283 and JSR-333 defining updated API versions) be outdated. What are the formal mechanics of refining the project description as suggested here and elsewhere, mid-vote? Or would a new vote be required? Matt [1] http://www.apache.org/foundation/records/minutes/2006/board_minutes_2006_03_15.txt BR, Jukka Zitting - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Gora Incubator Graduation Resolution
Hey Board@, Ferdy Galema accepted our invite for the Gora PPMC + committership so I just updated the Gora resolution in r32841 to include his name. Cheers, Chris On Jan 3, 2012, at 7:40 AM, Mattmann, Chris A (388J) wrote: Okey dok, I added it in r32707 now that Doug created the agenda. Thanks! Cheers, Chris On Dec 28, 2011, at 8:23 AM, Mattmann, Chris A (388J) wrote: Hey Board@, The Incubator PMC has VOTEd to recommend graduating Apache Gora. Here's the resolution: X. Establish the Apache Gora Project WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software for mapping objects to NoSQL databases for distribution at no charge to the public. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the Apache Gora Project, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache Gora Project be and hereby is responsible for the creation and maintenance of software related to open-source software for mapping objects to NoSQL databases; and be it further RESOLVED, that the office of Vice President, Apache Gora 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 Gora Project, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache Gora 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 Gora Project: * Sertan Alkan sertan@... * Andrzej Bialecki ab@... * Ioannis Canellos iocanel@... * Dogacan Guney dogacan@... * Andrew Hart ahart@... * Chris Mattmann mattmann@... * Lewis John McGibbney lewismc@... * Julien Nioche jnioche@... * Henry Saputra hsaputra@... * Enis Soztutar enis@... * David Woollard woollard@... RESOLVED, that the Apache Gora Project be and hereby is tasked with the migration and rationalization of the Apache Incubator Gora sub-project; and be it further RESOLVED, that all responsibilities pertaining to the Apache Incubator Gora sub-project encumbered upon the Apache Incubator Project are hereafter discharged. NOW, THEREFORE, BE IT FURTHER RESOLVED, that Lewis John McGibbney be appointed to the office of Vice President, Apache Gora, 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. Please add it to the January 2012 meeting agenda (or I'll do it myself if no one beats me to it after it's created). Thanks! Cheers Chris ++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: chris.a.mattm...@nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org ++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: chris.a.mattm...@nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++ ++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: chris.a.mattm...@nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail:
Re: Actively retiring projects (was: Incubator Board Report November 2011)
Since this thread has come back to life, I read through it and have one comment to add: On Wed, Nov 16, 2011 at 20:27, Benson Margulies bimargul...@gmail.com wrote: ... I can see two problems with this view to begin with. One is IP management. The more people participate in a project and the longer they do so, the messier it becomes to track provenance and get ICLAs from all of the contributors. One almost wishes that the ASF could accept ICLAs and code grants for code that is in fact living somewhere else. I'm sure someone will tell me why that idea is nuts. Actually, the ASF doesn't vette *why* an ICLA is being filed. It simply takes it and records it. The serf project[*] requires all committers to sign an ICLA with the ASF before receiving access. This way, should we ever want to move the project to the ASF, we have all commits already covered under an ICLA. While the project would still hit the Incubator, its IP clearance would be done on Day One. Cheers, -g [*] http://code.google.com/p/serf/ ... serf/ASF history at http://s.apache.org/jz - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Small but otherwise happy podlings
Regarding attrition of mentors, it was discussed having mentors 'sign' the board report for their podling. Could that be encouraged, and used as a sign of minimum 'activity' for a mentor? Upayavira On Mon, Jan 9, 2012, at 08:10 AM, Sam Ruby wrote: On Sun, Jan 8, 2012 at 9:55 PM, Benson Margulies bimargul...@gmail.com wrote: Sam, I started this separate thread because I view this situation as distinctive from the problem you are referring to here. I take that situation just as seriously as you do, I think. If you'd prefer that I drop this (less urgent) problem until that one is under control. I'm happy to do so. It is fair enough statement that not all of us need to work on what I happen to think is most urgent. This statement is true even if we might happen to agree on the relative priorities. I will merely point out that your suggestion is at least mildly at cross purposes to the issue that I want addressed. One of my concerns is that there are a number of podlings that are comfortably nestled in with no need to graduate. However, that is by no means my biggest concern, which is the silent attrition rate of mentors. In the case of Isis, I am fully prepared to accept that that podling has at least one active mentor. No, I'm not asking for a blank check. I'm asking you and the other more experienced people if you think that the idea of treating Isis-like podlings differently from other podlings by giving them more autonomy and less oversight makes any sense to you. If you all say, 'no, we don't want to change anything,' I'll drop it. If you say 'hmm, let's talk details,' then I'll attempt to flesh out details. However, since your bottom line is 'make a more concrete proposal,' then I will, but I will wait a bit to see if this thread attracts any other thoughts about the overall concept first. You previously mentioned that there might be incubator requirements that are burdensome on mentors. Identifying those and ways to address them are things that I could definitely support. Looking specifically at Isis, the last report[1] to the board contained: Top 3 Issues to address in move towards graduation * More blogging/publicity from existing community... * More users of the framework... * More committers to the framework The latter might be a concern. The first two however are not direct concerns. At most, they are indirect: i.e., ways to attract committers. Looking at the incubator page[2], I see more than three committers, and in fact four of them are ASF members. If at least one of these ASF members intends is willing to continue on the PMC, and the lack of committers were the only issue, then I would be comfortable with this podling graduating. - Sam Ruby [1] http://apache.org/foundation/records/minutes/2011/board_minutes_2011_10_26.txt [2] http://incubator.apache.org/projects/isis.html - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Q. Forks without concensus?; A. anytime / depends / never without agreement
On Sat, Jan 7, 2012 at 4:10 PM, Roy T. Fielding field...@gbiv.com wrote: On Jan 7, 2012, at 1:49 PM, Greg Stein wrote: On Jan 7, 2012 4:24 PM, Roy T. Fielding field...@gbiv.com wrote: ... The original developers are not ambivalent to this fork. Untrue. Christian and Remy are, and always have been, supportive. They were the ones to suggest the fork, rather than trying to make the changes in trunk. I read the trac-dev mailing list. To say that they are supportive is a huge stretch of the imagination. They are sadly resigned to see a potential contributor decide to fork the code instead of working with them directly. And the rest of the community (which is far larger than the core) thinks the idea stinks. If you read trac-dev, you will also notice that the discussion about the so-called fork has more responses than all other threads in the last three months *combined*. Lots of navel gazing, not much work. (Though surprisingly, discussion *has* picked up in the past couple of weeks, so maybe this is a Good Thing all around.) What you have is a vocal minority that disagree. Ethan is not even a core committer, as far as I can tell. Edgewall, the copyright holder, is a defunct shell. That is a primary reason WANdisco wanted to move to the ASF: a home with actual backing and longevity. Then we should be able to convince Christian and Remy to join the initial committers list and bring the rest of the TRAC community with them. Why has that not been done? It has been. They have essentially said we've moved on, best of luck. WANdisco has definite problems in how they approach and work with open source communities. They discussed this stuff with the Trac principals privately, rather than with the broader community. But my read is that the Trac leads are supportive of Bloodhound. They are supportive of people doing work on Trac. They did not support a fork at the ASF. What they told WANdisco was that, rather than come to some artificial agreement on how they should work together before WANdisco had contributed anything, that WANdisco should fork the code and start by making contributions. That's it. The only reason that Christian has not directly opposed Bloodhound is because he believes the BSD license gives permission to fork the code. My interest here is seeing Trac revitalized, improved, and delivered as an awesome open source issue tracker. I'm tired of Bugzilla and (non-OSS) Jira. I like the Google Code tracker, but I'm biased there :-P There is no evidence to suggest that cannot be done on trac-dev. I'm not sure I agree with this statement. Trac has a singular and well-defined philosophy built around a small core and an environment of plugins. This isn't the place to debate the merits of that architecture, but suffice it to say that such a system can often require a lot of work to get to a usable state. The goals of Bloodhound are separate from that: create a full-featured issue tracker which is easy to deploy and use for end users and administrators both. Honestly, Trac is a good product, and is an excellent choice as the core for Bloodhound, but the community goals differ. Significantly. Bloodhound won't happen on trac-dev because the Trac community is philosophically opposed to the direction the nascent Bloodhound community wants to take. That's okay: people are allowed to have different goals. And the great part about open source is we all don't have to reinvent the wheel to implement those different views of the world. Bloodhound can be a derivative of Trac with its own community and goals [1]. There's room enough in the world for them both. I think the Trac community sees this as a zero-sum game: if people are contributing to Bloodhound, they *aren't* contributing to Trac. Instead, we should try to convince the Bloodhound people that our philosophy is best, and they should just come over here. Resolving such philosophical differences and technical goals is difficult at best, and I don't see it happening soon. But that's okay, there isn't a globally optimal solution to issue tracking, and we can agree to experiment with different paths. But I've probably said too much already. There isn't much more I can add here, and the last think I want to do at this point is prolong the agony of this discussion. -Hyrum [1] Indeed, I know of at least one private proprietary derivative of Trac, but since it's proprietary, nobody knows about it and nobody complains. It's the fact that Bloodhound is proposed as open source which is causing the hullaballoo in the first place. -- uberSVN: Apache Subversion Made Easy http://www.uberSVN.com/ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Small but otherwise happy podlings
On Mon, Jan 9, 2012 at 12:40 PM, Upayavira u...@odoko.co.uk wrote: Regarding attrition of mentors, it was discussed having mentors 'sign' the board report for their podling. Could that be encouraged, and used as a sign of minimum 'activity' for a mentor? I feel that what I am learning here is that my topic needs to go take a rest until the topic of non-responsible mentors is under control. Upayavira On Mon, Jan 9, 2012, at 08:10 AM, Sam Ruby wrote: On Sun, Jan 8, 2012 at 9:55 PM, Benson Margulies bimargul...@gmail.com wrote: Sam, I started this separate thread because I view this situation as distinctive from the problem you are referring to here. I take that situation just as seriously as you do, I think. If you'd prefer that I drop this (less urgent) problem until that one is under control. I'm happy to do so. It is fair enough statement that not all of us need to work on what I happen to think is most urgent. This statement is true even if we might happen to agree on the relative priorities. I will merely point out that your suggestion is at least mildly at cross purposes to the issue that I want addressed. One of my concerns is that there are a number of podlings that are comfortably nestled in with no need to graduate. However, that is by no means my biggest concern, which is the silent attrition rate of mentors. In the case of Isis, I am fully prepared to accept that that podling has at least one active mentor. No, I'm not asking for a blank check. I'm asking you and the other more experienced people if you think that the idea of treating Isis-like podlings differently from other podlings by giving them more autonomy and less oversight makes any sense to you. If you all say, 'no, we don't want to change anything,' I'll drop it. If you say 'hmm, let's talk details,' then I'll attempt to flesh out details. However, since your bottom line is 'make a more concrete proposal,' then I will, but I will wait a bit to see if this thread attracts any other thoughts about the overall concept first. You previously mentioned that there might be incubator requirements that are burdensome on mentors. Identifying those and ways to address them are things that I could definitely support. Looking specifically at Isis, the last report[1] to the board contained: Top 3 Issues to address in move towards graduation * More blogging/publicity from existing community... * More users of the framework... * More committers to the framework The latter might be a concern. The first two however are not direct concerns. At most, they are indirect: i.e., ways to attract committers. Looking at the incubator page[2], I see more than three committers, and in fact four of them are ASF members. If at least one of these ASF members intends is willing to continue on the PMC, and the lack of committers were the only issue, then I would be comfortable with this podling graduating. - Sam Ruby [1] http://apache.org/foundation/records/minutes/2011/board_minutes_2011_10_26.txt [2] http://incubator.apache.org/projects/isis.html - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Small but otherwise happy podlings
On 1/9/2012 7:04 AM, Ross Gardler wrote: I don't think Wookie should graduate, but it certainly shouldn't be kicked out (and I don't think it will be). However, as I not above incubation may be holding it back. The question for me is, can we do more for projects that are in this position? What if we had a generic five para pledged/statement on accepting new contributors and pmc members? Have the podling's PMC members go on record, on the dev@ list, confirming they are committed to that policy. Totally voluntary, but if they do so, trust and verify later on after graduating them. Any project which fails to bring in new committers dies of atrophy eventually, and the board is more than willing to flush and reconstitute a fair and functional PMC when the existing one isn't functioning correctly. Presuming there is a large enough base PMC, we could promote a number of podlings which suffer under the incubation 'almost ready' cloud. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Small but otherwise happy podlings
On 1/9/2012 11:40 AM, Upayavira wrote: Regarding attrition of mentors, it was discussed having mentors 'sign' the board report for their podling. Could that be encouraged, and used as a sign of minimum 'activity' for a mentor? How about simply sign off on podling-dev@? Even if it is Thanks for drafting this! No edits from me. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Small but otherwise happy podlings
Lame. I would actually like to see mentors WRITING the reports at least for the first 6 months to a year, then going to sign-off on the wiki. - Original Message - From: William A. Rowe Jr. wr...@rowe-clan.net To: general@incubator.apache.org Cc: Upayavira u...@odoko.co.uk Sent: Monday, January 9, 2012 1:23 PM Subject: Re: Small but otherwise happy podlings On 1/9/2012 11:40 AM, Upayavira wrote: Regarding attrition of mentors, it was discussed having mentors 'sign' the board report for their podling. Could that be encouraged, and used as a sign of minimum 'activity' for a mentor? How about simply sign off on podling-dev@? Even if it is Thanks for drafting this! No edits from me. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Small but otherwise happy podlings
Frankly, I don't see that much use. Of course reports are very important, but they most of the times are just copied over from the previous month + a few adoptions. And most of the times it's fine. What I really expect from a mentor is to look at the code a bit, check if the code style is consistent, give advise on NOTICE and LICENSE questions etc.A mentor doesn't necessarily need to touch the codebase heavily, but he should at least be aware which parts exist and should pick a few sources sometimes. Just to check if the quality is sufficient. Actively reading the mailing list is imo important as well. LieGrue, strub - Original Message - From: Joe Schaefer joe_schae...@yahoo.com To: general@incubator.apache.org general@incubator.apache.org Cc: Upayavira u...@odoko.co.uk Sent: Monday, January 9, 2012 7:27 PM Subject: Re: Small but otherwise happy podlings Lame. I would actually like to see mentors WRITING the reports at least for the first 6 months to a year, then going to sign-off on the wiki. - Original Message - From: William A. Rowe Jr. wr...@rowe-clan.net To: general@incubator.apache.org Cc: Upayavira u...@odoko.co.uk Sent: Monday, January 9, 2012 1:23 PM Subject: Re: Small but otherwise happy podlings On 1/9/2012 11:40 AM, Upayavira wrote: Regarding attrition of mentors, it was discussed having mentors 'sign' the board report for their podling. Could that be encouraged, and used as a sign of minimum 'activity' for a mentor? How about simply sign off on podling-dev@? Even if it is Thanks for drafting this! No edits from me. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Small but otherwise happy podlings
On 1/9/2012 12:27 PM, Joe Schaefer wrote: Lame. I would actually like to see mentors WRITING the reports at least for the first 6 months to a year, then going to sign-off on the wiki. My point was, all mentors need to reply to the draft. -One- of them, or a leader in the community would still draft it. But if the mentors don't take the time to read and acknowledge the report, and offer any edits that are needed, they can be considered AWOL which Upayavira was getting at. The board indicated many times that PMC reports aren't signed. Don't see a point in going there. Everything should be - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Q. Forks without concensus?; A. anytime / depends / never without agreement
On Mon, Jan 9, 2012 at 9:42 AM, Hyrum K Wright hyrum.wri...@wandisco.com wrote: I think the Trac community sees this as a zero-sum game: if people are contributing to Bloodhound, they *aren't* contributing to Trac. Instead, we should try to convince the Bloodhound people that our philosophy is best, and they should just come over here. Resolving such philosophical differences and technical goals is difficult at best, and I don't see it happening soon. But that's okay, there isn't a globally optimal solution to issue tracking, and we can agree to experiment with different paths. But I've probably said too much already. There isn't much more I can add here, and the last think I want to do at this point is prolong the agony of this discussion. Where's the agony? I see the general discussion about forks without consensus as very healthy, and I think it should continue to be discussed till all voices are heard. [1] Indeed, I know of at least one private proprietary derivative of Trac, but since it's proprietary, nobody knows about it and nobody complains. It's the fact that Bloodhound is proposed as open source which is causing the hullaballoo in the first place. But dear Sir, I don't believe that to be true if I may say so. Had the original proposal been worded as a derivative intended to keep Trac as the foundation, rather than a take-over there wouldn't have been any hullaballoo. I still don't understand why Bloodhound needs to start by forking Trac, without a single line written yet. The architecture with a small core and many plugins versus a complete installable package are not contradicting in any way. Kalle - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Chukwa 0.5.0 release candidate 1
On Fri, Jan 6, 2012 at 3:04 PM, sebb seb...@gmail.com wrote: There are quite a few files without any licenses at all, e.g. conf/aggregator.sql conf/database_create_tables.sql src/main/web/hicc/css/default.css The NOTICE file should only contain *required* notices. In particular, the following paragraph is not required: Chukwa incorporates a number of components, not copyright by the Apache Foundation, and under permissive licenses. The YUI license appears to require a notice, but there is none. There are probably other issues; did not check them all. The LICENSE file contains quite a few non-ASCII characters that don't display properly. There's no point repeating AL 2.0 for the components that use it; just state which components use the AL 2.0. Thanks for the audit. I have fixed the errors over the weekend and will start rc 2 vote shortly. regards, Eric - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[VOTE] Chukwa 0.5.0 release candidate 2
Hi all, Chukwa 0.5.0 is ready for release. This will be the first incubator release for Chukwa. The source tarball artifact is available at: http://people.apache.org/~eyang/chukwa-0.5.0-rc2/ Documents are available at: http://people.apache.org/~eyang/chukwa-0.5.0-docs/ The SVN tag to be voted upon: https://svn.apache.org/repos/asf/incubator/chukwa/tags/chukwa-0.5.0-rc2/ Chukwa's KEYS file containing PGP keys we use to sign the release: http://people.apache.org/~eyang/chukwa-0.5.0-rc2/KEYS Please download, evaluate, and vote on general@incubator. The PPMC vote thread is in progress at the same time as general@incubator. Changes since rc1: - Updated LICENSE and NOTICE files to reflect changes base on ipmc feedback. - Updated Hadoop dependency to Hadoop 1.0.0. The vote will close at 12:30pm PST on Thursday January 12, 2012. Thanks regards, Eric - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Small but otherwise happy podlings
I was even thinking something like 'miss two reports, you're no longer a mentor', but that might be a bit draconian :-) I know I would fail according to the above criteria. But I suspect a clear minimum would help keep me at least minimally connected. Upayavira On Mon, Jan 9, 2012, at 10:27 AM, Joe Schaefer wrote: Lame. I would actually like to see mentors WRITING the reports at least for the first 6 months to a year, then going to sign-off on the wiki. - Original Message - From: William A. Rowe Jr. wr...@rowe-clan.net To: general@incubator.apache.org Cc: Upayavira u...@odoko.co.uk Sent: Monday, January 9, 2012 1:23 PM Subject: Re: Small but otherwise happy podlings On 1/9/2012 11:40 AM, Upayavira wrote: Regarding attrition of mentors, it was discussed having mentors 'sign' the board report for their podling. Could that be encouraged, and used as a sign of minimum 'activity' for a mentor? How about simply sign off on podling-dev@? Even if it is Thanks for drafting this! No edits from me. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Small but otherwise happy podlings
I would like to see the Incubator someday reach the point where we could DISTRIBUTE our oversight across the podling lists, where graduation votes are largely ceremonial other than vetting the language, where release votes happen solely on dev lists, etc. But we will NEVER get there and still do a responsible job of oversight until we can get to the point where we can reliably TRUST the word of a podling mentor about the state of affairs of a podling. And if we've never actually read the words of a mentor summarizing a podling's activities, how are we supposed to suddenly start trusting them come graduation time? - Original Message - From: Upayavira u...@odoko.co.uk To: general@incubator.apache.org Cc: Sent: Monday, January 9, 2012 2:42 PM Subject: Re: Small but otherwise happy podlings I was even thinking something like 'miss two reports, you're no longer a mentor', but that might be a bit draconian :-) I know I would fail according to the above criteria. But I suspect a clear minimum would help keep me at least minimally connected. Upayavira On Mon, Jan 9, 2012, at 10:27 AM, Joe Schaefer wrote: Lame. I would actually like to see mentors WRITING the reports at least for the first 6 months to a year, then going to sign-off on the wiki. - Original Message - From: William A. Rowe Jr. wr...@rowe-clan.net To: general@incubator.apache.org Cc: Upayavira u...@odoko.co.uk Sent: Monday, January 9, 2012 1:23 PM Subject: Re: Small but otherwise happy podlings On 1/9/2012 11:40 AM, Upayavira wrote: Regarding attrition of mentors, it was discussed having mentors 'sign' the board report for their podling. Could that be encouraged, and used as a sign of minimum 'activity' for a mentor? How about simply sign off on podling-dev@? Even if it is Thanks for drafting this! No edits from me. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Maven coordinate for incubating podlings
It's my understanding that the group and artifact id do not include the token incubating or incubator but that -incubating is suffixed to the version number. Do I understand the requirements correctly? Regards, Alan - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: Maven coordinate for incubating podlings
-Original Message- From: Alan D.Cabrera [mailto:l...@toolazydogs.com] Sent: Monday, January 09, 2012 3:47 PM To: general@incubator.apache.org Subject: Maven coordinate for incubating podlings It's my understanding that the group and artifact id do not include the token incubating or incubator but that -incubating is suffixed to the version number. Do I understand the requirements correctly? That is how we do it in Rave at the guidance of our mentors. Regards, Alan - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Recommend graduating Apache Bean-Validation (BVAL) as a TLP
Hi Jukka! Thanks for this very constructive post! I'm not a native english speaker, but even I understand the point with not using JSR-330 but a more 'descriptive' wording :) What about the following? 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 the Content Bean Validation Specification and its implementation as Apache BeanValidation and extensions for distribution at no charge to the public. Which leads me to another point which lets me think that we should cancel the vote and restart after we cleaned up the wording. The current proposal erroneous had Apache Bean Validation as project name. This is a failure as the projects name always have been Apache BeanValidation (without a space) or short Apache BVAL. I really like to change this in the proposal and restart the vote. Neither Bean Validation nor BeanValidation nor BVAL are trademarked yet, but Bean Validation (with space) might be hard to defend as trademark (as it's also the name of the spec itself [1]) WDYT? We should Cancel the vote and fix those issues, right? txs and LieGrue, strub [1] http://jcp.org/en/jsr/summary?id=303 - Original Message - From: Jukka Zitting jukka.zitt...@gmail.com To: general general@incubator.apache.org Cc: Sent: Monday, January 9, 2012 12:08 PM Subject: Re: [VOTE] Recommend graduating Apache Bean-Validation (BVAL) as a TLP Hi, +1 to graduate, with the following note: On Sun, Jan 8, 2012 at 10:04 PM, Mark Struberg strub...@yahoo.de wrote: 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 creating an implementation compliant with JSR-303 and a library of pre-developed validators and extensions for distribution at no charge to the public. As noted by others, the project scope could use some clarification. Also, rather than referring specifically to JSR-303, it would probably be better to refer to the Bean Validation API to avoid tying the project to a specific version of the API. For example the Apache Jackrabbit resolution [1] referred to the Content Repository for Java Technology API instead of JSR-170 which would by now (with JSR-283 and JSR-333 defining updated API versions) be outdated. [1] http://www.apache.org/foundation/records/minutes/2006/board_minutes_2006_03_15.txt BR, Jukka Zitting - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Small but otherwise happy podlings
On Jan 9, 2012, at 10:27 AM, Joe Schaefer wrote: Lame. I would actually like to see mentors WRITING the reports at least for the first 6 months to a year, then going to sign-off on the wiki. +1 on the mentors WRITING the reports part. I always try to do that until my podlings beat me to it (at which point I seriously consider checking off the self managing pseudo-requirement for graduation). Cheers, Chris ++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: chris.a.mattm...@nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Small but otherwise happy podlings
+1, I couldn't have said it any better myself, Joe. Cheers, Chris On Jan 9, 2012, at 12:00 PM, Joe Schaefer wrote: I would like to see the Incubator someday reach the point where we could DISTRIBUTE our oversight across the podling lists, where graduation votes are largely ceremonial other than vetting the language, where release votes happen solely on dev lists, etc. But we will NEVER get there and still do a responsible job of oversight until we can get to the point where we can reliably TRUST the word of a podling mentor about the state of affairs of a podling. And if we've never actually read the words of a mentor summarizing a podling's activities, how are we supposed to suddenly start trusting them come graduation time? - Original Message - From: Upayavira u...@odoko.co.uk To: general@incubator.apache.org Cc: Sent: Monday, January 9, 2012 2:42 PM Subject: Re: Small but otherwise happy podlings I was even thinking something like 'miss two reports, you're no longer a mentor', but that might be a bit draconian :-) I know I would fail according to the above criteria. But I suspect a clear minimum would help keep me at least minimally connected. Upayavira On Mon, Jan 9, 2012, at 10:27 AM, Joe Schaefer wrote: Lame. I would actually like to see mentors WRITING the reports at least for the first 6 months to a year, then going to sign-off on the wiki. - Original Message - From: William A. Rowe Jr. wr...@rowe-clan.net To: general@incubator.apache.org Cc: Upayavira u...@odoko.co.uk Sent: Monday, January 9, 2012 1:23 PM Subject: Re: Small but otherwise happy podlings On 1/9/2012 11:40 AM, Upayavira wrote: Regarding attrition of mentors, it was discussed having mentors 'sign' the board report for their podling. Could that be encouraged, and used as a sign of minimum 'activity' for a mentor? How about simply sign off on podling-dev@? Even if it is Thanks for drafting this! No edits from me. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org ++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: chris.a.mattm...@nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Maven coordinate for incubating podlings
On Mon, Jan 9, 2012 at 3:56 PM, Franklin, Matthew B. mfrank...@mitre.org wrote: -Original Message- From: Alan D.Cabrera [mailto:l...@toolazydogs.com] Sent: Monday, January 09, 2012 3:47 PM To: general@incubator.apache.org Subject: Maven coordinate for incubating podlings It's my understanding that the group and artifact id do not include the token incubating or incubator but that -incubating is suffixed to the version number. Do I understand the requirements correctly? That is how we do it in Rave at the guidance of our mentors. Yes this is correct. Regards, Alan - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Chukwa 0.5.0 release candidate 2
On 9 January 2012 19:40, Eric Yang eric...@gmail.com wrote: Hi all, Chukwa 0.5.0 is ready for release. This will be the first incubator release for Chukwa. The source tarball artifact is available at: http://people.apache.org/~eyang/chukwa-0.5.0-rc2/ Documents are available at: http://people.apache.org/~eyang/chukwa-0.5.0-docs/ The SVN tag to be voted upon: https://svn.apache.org/repos/asf/incubator/chukwa/tags/chukwa-0.5.0-rc2/ The Script.aculo.us license has the following copyright notice: Copyright (c) 2005-2008 Thomas Fuchs (http://script.aculo.us, http://mir.aculo.us) However, this does not appear in NOTICE.txt. I would expect to see something like the following 2 lines in NOTICE.txt: This product includes Script.aculo.us Copyright (c) 2005-2008 Thomas Fuchs (http://script.aculo.us, http://mir.aculo.us) Similarly for any other included products that have a notice requirement, i.e. This product includes YUI Copyright Yahoo inc, 2009 This product includes IUI Copyright (c) 2007-2009, iUI Project Members etc. for any other included products that have a notice requirement. The entries in the NOTICE file need to be the minimum required. Chukwa's KEYS file containing PGP keys we use to sign the release: http://people.apache.org/~eyang/chukwa-0.5.0-rc2/KEYS Please download, evaluate, and vote on general@incubator. The PPMC vote thread is in progress at the same time as general@incubator. Changes since rc1: - Updated LICENSE and NOTICE files to reflect changes base on ipmc feedback. - Updated Hadoop dependency to Hadoop 1.0.0. The vote will close at 12:30pm PST on Thursday January 12, 2012. Thanks regards, Eric - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Podling rename, vote needed?
Hi, [to: general@, cc: callback-dev@] As discussed during the Callback proposal phase [1], the podling community wasn't too certain about the Callback name and thus after some discussion they recently voted [2] on adopting the new name Apache Cordova. The vote and its result was mentioned in the December status report [3]. Now the question came up [4] about whether such a rename needs to be explicitly approved by a vote of the IPCM. Personally I don't think one is needed, as the possible need for such a rename was already discussed on general@, and as the community vote itself and the related name selection process was monitored by us mentors. A similar process was followed when the Lucene Connector Framework podling changed it's name to ManifoldCF [5]. Thus we never asked the podling to bring the matter to the IPMC for a formal vote. However, if people feel that an IPMC vote on this is needed, we'll happily comply. [1] http://markmail.org/message/i6d2nrwdbqse3rqs [2] http://markmail.org/message/kq3oa7wewl5ltvic [3] http://wiki.apache.org/incubator/December2011 [4] https://issues.apache.org/jira/browse/INFRA-4306?focusedCommentId=13182966page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13182966 [5] http://wiki.apache.org/incubator/December2010 BR, Jukka Zitting - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Podling rename, vote needed?
On 10 January 2012 02:29, Jukka Zitting jukka.zitt...@gmail.com wrote: Hi, [to: general@, cc: callback-dev@] As discussed during the Callback proposal phase [1], the podling community wasn't too certain about the Callback name and thus after some discussion they recently voted [2] on adopting the new name Apache Cordova. The vote and its result was mentioned in the December status report [3]. Now the question came up [4] about whether such a rename needs to be explicitly approved by a vote of the IPCM. Personally I don't think one is needed, as the possible need for such a rename was already discussed on general@, and as the community vote itself and the related name selection process was monitored by us mentors. A similar process was followed when the Lucene Connector Framework podling changed it's name to ManifoldCF [5]. Thus we never asked the podling to bring the matter to the IPMC for a formal vote. However, if people feel that an IPMC vote on this is needed, we'll happily comply. On a related matter, how is the rename being handled for the various incubator data files, web-pages, mailing lists etc.? People need to be able to find the podling under its new name, and clutch etc. need to be able to keep track of the podling status. There need to be redirects added for web-pages if/when the old pages are renamed. [1] http://markmail.org/message/i6d2nrwdbqse3rqs [2] http://markmail.org/message/kq3oa7wewl5ltvic [3] http://wiki.apache.org/incubator/December2011 [4] https://issues.apache.org/jira/browse/INFRA-4306?focusedCommentId=13182966page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13182966 [5] http://wiki.apache.org/incubator/December2010 BR, Jukka Zitting - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Q. Forks without concensus?; A. anytime / depends / never without agreement
On Jan 9, 2012, at 9:42 AM, Hyrum K Wright wrote: On Sat, Jan 7, 2012 at 4:10 PM, Roy T. Fielding field...@gbiv.com wrote: On Jan 7, 2012, at 1:49 PM, Greg Stein wrote: On Jan 7, 2012 4:24 PM, Roy T. Fielding field...@gbiv.com wrote: ... The original developers are not ambivalent to this fork. Untrue. Christian and Remy are, and always have been, supportive. They were the ones to suggest the fork, rather than trying to make the changes in trunk. I read the trac-dev mailing list. To say that they are supportive is a huge stretch of the imagination. They are sadly resigned to see a potential contributor decide to fork the code instead of working with them directly. And the rest of the community (which is far larger than the core) thinks the idea stinks. If you read trac-dev, you will also notice that the discussion about the so-called fork has more responses than all other threads in the last three months *combined*. Lots of navel gazing, not much work. (Though surprisingly, discussion *has* picked up in the past couple of weeks, so maybe this is a Good Thing all around.) Yes, that is a common side-effect of introducing a sense of awareness to a project that is otherwise in stasis. I have no doubt that Trac needs new blood and a driving force capable of energizing the community that developed on top of it. What you have is a vocal minority that disagree. Ethan is not even a core committer, as far as I can tell. It isn't a vocal minority. Not a single person outside of WANdisco considered it a good idea. Not one. Yes, most of the people commenting were the implementers of plug-ins, but they are also supposed to be part of the Bloodhound proposal. Edgewall, the copyright holder, is a defunct shell. That is a primary reason WANdisco wanted to move to the ASF: a home with actual backing and longevity. Then we should be able to convince Christian and Remy to join the initial committers list and bring the rest of the TRAC community with them. Why has that not been done? It has been. They have essentially said we've moved on, best of luck. I don't follow that. Is Edgewall still a formal organization capable of owning copyright? If not, who owns the copyright? Have Christian and Remy stopped all work on Trac, or are they just busy with their $jobs? And, no, the discussion has not been with the Trac community -- it was in private with a few individuals; as far as Apache is concerned, it never happened. Yes, there are many reasons to prefer that it is under the ASF. Many, many, many reasons. That doesn't change the fact that Apache only accepts voluntary contributions. Before you import code to the ASF, you have to get some indication from the authors that they either *want* us to maintain that code or that they have completely abandoned it. Not just a sigh and a statement that the BSD license is forkable -- they have to want Apache to build a community for maintaining that code. Otherwise, we don't, for social reasons that have little to do with licensing. WANdisco has definite problems in how they approach and work with open source communities. They discussed this stuff with the Trac principals privately, rather than with the broader community. But my read is that the Trac leads are supportive of Bloodhound. They are supportive of people doing work on Trac. They did not support a fork at the ASF. What they told WANdisco was that, rather than come to some artificial agreement on how they should work together before WANdisco had contributed anything, that WANdisco should fork the code and start by making contributions. That's it. The only reason that Christian has not directly opposed Bloodhound is because he believes the BSD license gives permission to fork the code. My interest here is seeing Trac revitalized, improved, and delivered as an awesome open source issue tracker. I'm tired of Bugzilla and (non-OSS) Jira. I like the Google Code tracker, but I'm biased there :-P There is no evidence to suggest that cannot be done on trac-dev. I'm not sure I agree with this statement. Trac has a singular and well-defined philosophy built around a small core and an environment of plugins. This isn't the place to debate the merits of that architecture, but suffice it to say that such a system can often require a lot of work to get to a usable state. The goals of Bloodhound are separate from that: create a full-featured issue tracker which is easy to deploy and use for end users and administrators both. Honestly, Trac is a good product, and is an excellent choice as the core for Bloodhound, but the community goals differ. Significantly. Those sound like the goals for a commercial distribution of an open source project. In any case, there is no evidence that it cannot be done on trac-dev because it wasn't attempted. Bloodhound won't happen on trac-dev because the Trac community is philosophically opposed to the
Re: Q. Forks without concensus?; A. anytime / depends / never without agreement
On Mon, Jan 9, 2012 at 10:02 PM, Roy T. Fielding field...@gbiv.com wrote: I don't follow that. Is Edgewall still a formal organization capable of owning copyright? If not, who owns the copyright? Have Christian and Remy stopped all work on Trac, or are they just busy with their $jobs? Yes, Edgewall is still a formal organization capable of owning copyright. (Aside: it's not entirely clear to me at the moment how much copyright Edgewall owns over the Trac codebase, vs. whether individual Trac contributors retain the copyright to their own contributions[1].) Christian and Remy have not stopped all work on Trac. They are still, at least, reviewing and merging patches. Other core committers (newer contributors, and contributors with partial repository access) are also committing changes[2]. Separately, I do want to point out that the most recent statements from WANdisco's David Richards and Gary Martin on trac-dev and bloodhound-dev are encouraging, and clearly indicate an interest in developing Bloodhound as a downstream Trac distribution with patches maintained separately (presumably without official Apache copyright and licensing) and submitted upstream. As far as I've seen, everybody in the Trac community is fully supportive of this, as well as appreciative. That said, it would probably be best if the official Bloodhound proposal were modified to correct the mischaracterizations about the Trac community, and to replace the explicit plans for a Trac fork (Migrate the existing BSD-licensed Trac code base to the ASF etc) with a clear description of the new approach including how the upstream patches, plus their copyright and licensing, will be managed. (As an Apache newcomer I have no idea whether this would require or merit a new VOTE.) I think that if/when these details are clearly ironed out, all the fundamental short-term issues will be resolved. Longer-term concerns expressed by WANdisco (copyright protection, non-conflicting visions, a core velocity that does not impede downstream development) and the Trac community (upstream contributions, symbiotic communities, increased burdens of knowledge management for core devs // plugin authors // users) can then hopefully be tackled and reevaluated during the incubation process. -Ethan [1] https://groups.google.com/group/trac-dev/msg/cfbf54981ad64138 [2] http://trac.edgewall.org/timeline?from=Jan+10%2C+2012daysback=30authors=changeset=onupdate=Update
Re: Q. Forks without concensus?; A. anytime / depends / never without agreement
On Jan 9, 2012 10:03 PM, Roy T. Fielding field...@gbiv.com wrote: ... And, no, the discussion has not been with the Trac community -- it was in private with a few individuals; as far as Apache is concerned, it never happened. And Oracle's private conversations, and their decisions regarding OOo contrary to the community, were somehow acceptable? ... There is no fork in the current plan, so this discussion is moot anyways. -g
Re: [VOTE] Chukwa 0.5.0 release candidate 2
Thank you for the multiple examples. I think I finally understand what you are saying, and the information on LEGAL-59, and LEGAL-62. I will re-spin rc3 with a new svn tag with required changes in NOTICE file. Thanks regards, Eric On Mon, Jan 9, 2012 at 5:33 PM, sebb seb...@gmail.com wrote: On 9 January 2012 19:40, Eric Yang eric...@gmail.com wrote: Hi all, Chukwa 0.5.0 is ready for release. This will be the first incubator release for Chukwa. The source tarball artifact is available at: http://people.apache.org/~eyang/chukwa-0.5.0-rc2/ Documents are available at: http://people.apache.org/~eyang/chukwa-0.5.0-docs/ The SVN tag to be voted upon: https://svn.apache.org/repos/asf/incubator/chukwa/tags/chukwa-0.5.0-rc2/ The Script.aculo.us license has the following copyright notice: Copyright (c) 2005-2008 Thomas Fuchs (http://script.aculo.us, http://mir.aculo.us) However, this does not appear in NOTICE.txt. I would expect to see something like the following 2 lines in NOTICE.txt: This product includes Script.aculo.us Copyright (c) 2005-2008 Thomas Fuchs (http://script.aculo.us, http://mir.aculo.us) Similarly for any other included products that have a notice requirement, i.e. This product includes YUI Copyright Yahoo inc, 2009 This product includes IUI Copyright (c) 2007-2009, iUI Project Members etc. for any other included products that have a notice requirement. The entries in the NOTICE file need to be the minimum required. Chukwa's KEYS file containing PGP keys we use to sign the release: http://people.apache.org/~eyang/chukwa-0.5.0-rc2/KEYS Please download, evaluate, and vote on general@incubator. The PPMC vote thread is in progress at the same time as general@incubator. Changes since rc1: - Updated LICENSE and NOTICE files to reflect changes base on ipmc feedback. - Updated Hadoop dependency to Hadoop 1.0.0. The vote will close at 12:30pm PST on Thursday January 12, 2012. Thanks regards, Eric - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[VOTE] Chukwa 0.5.0 Release Candidate 3
Hi all, Chukwa 0.5.0 is ready for release. This will be the first incubator release for Chukwa. The source tarball artifact is available at: http://people.apache.org/~eyang/chukwa-0.5.0-rc3/ Documents are available at: http://people.apache.org/~eyang/chukwa-0.5.0-docs/ The SVN tag to be voted upon: https://svn.apache.org/repos/asf/incubator/chukwa/tags/chukwa-0.5.0-rc3/ Chukwa's KEYS file containing PGP keys we use to sign the release: http://people.apache.org/~eyang/chukwa-0.5.0-rc3/KEYS Please download, evaluate, and vote on general@incubator. The PPMC vote thread is in progress at the same time as general@incubator. Changes since rc2: - Updated LICENSE and NOTICE files to reflect changes base on Sebb's examples. The vote will close at 12:30pm PST on Saturday January 14, 2012. Thanks regards, Eric - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
