Re: [Proposal] ALOIS Project
Hi IANAL either. At Apache we encourage the use of dependencies that are licensed with an Apache-compatible license but we are not strict about it. We have projects with dependencies on such things as Microsoft Windows. We have had projects with hard dependencies on Java before Java was open source. Since we have learned that MySQL is not the best solution for our purpose - i.e. tools with other backends get a better performance on standard hardware -, the replacement of MySQL is on our roadmap. Since ALOIS is written in Ruby, it might be easy enough to add a database-independence layer to remove the hard dependency on MySQL. Craig, I too think it is a very good idea to implement a database-independent layer. Even more, it is my designated goal to add APIs to all of the five moduls, so we get more flexibility. Not a reason to turn away the project. Happy to hear that! Best regards Urs signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Incubator PMC/Board report for August 2010 (bval-...@incubator.apache.org)
Sorry for the lateness, but our BVAL report for August has been posted to the Incubator wiki. Apache Bean Validation will deliver an implementation of the JSR303 Bean Validation 1.0 specification. BVAL entered incubation on March 1, 2010. A list of the three most important issues to address in the move towards graduation. * First release of artifacts - Done * Grow the community and committer base - ongoing * Decide on graduation target of TLP or subproject - TBD Any issues that the Incubator PMC or ASF Board might wish/need to be aware of? * None at this time. How has the community developed since the last report? * Committer offer was extended and accepted by Matt Benson. * A couple of new users on the dev list. How has the project developed since the last report? * Currently a 0.2-incubating RC2 release vote is underway. -Donald On 8/1/10 10:00 AM, no-re...@apache.org wrote: Dear BeanValidation Developers, This email was sent by an automated system on behalf of the Apache Incubator PMC. It is an initial reminder to give you plenty of time to prepare your quarterly board report. The board meeting is scheduled for . The report for your podling will form a part of the Incubator PMC report. The Incubator PMC requires your report to be submitted one week before the board meeting, to allow sufficient time for review. Please submit your report with sufficient time to allow the incubator PMC, and subsequently board members to review and digest. Again, the very latest you should submit your report is one week prior to the board meeting. Thanks, The Apache Incubator PMC Submitting your Report -- Your report should contain the following: * Your project name * A brief description of your project, which assumes no knowledge of the project or necessarily of its field * A list of the three most important issues to address in the move towards graduation. * Any issues that the Incubator PMC or ASF Board might wish/need to be aware of * How has the community developed since the last report * How has the project developed since the last report. This should be appended to the Incubator Wiki page at: http://wiki.apache.org/incubator/August2010 Note: This manually populated. You may need to wait a little before this page is created from a template. Mentors --- Mentors should review reports for their project(s) and sign them off on the Incubator wiki page. Signing off reports shows that you are following the project - projects that are not signed may raise alarms for the Incubator PMC. Incubator PMC - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
REMINDER: Reports due *NOW* -- HISE and SIS, where are you?
I'm putting together the monthly board report. HISE and SIS are missing (so is Bluesky, but they did provide reports for the past several months running, so I'll cut them some slack). --- Noel - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: REMINDER: Reports due *NOW* -- HISE and SIS, where are you?
Hey Noel, I uploaded an SIS report just now on the wiki. Any SIS mentors lurking around, please check it out and sign off. Thanks! Cheers, Chris On 8/16/10 7:24 AM, Noel J. Bergman n...@devtech.com wrote: I'm putting together the monthly board report. HISE and SIS are missing (so is Bluesky, but they did provide reports for the past several months running, so I'll cut them some slack). --- Noel - 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.mattm...@jpl.nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++
Re: REMINDER: Reports due *NOW* -- HISE and SIS, where are you?
Actually, speaking of which too, Noel, since I'm on the Incubator PMC, please add me as a mentor for SIS now too. I'll add myself as a mentor to the SIS proposal on the wiki as well, but can someone please add me to the other appropriate areas (or tell me how to do it myself)? Also, FWIW, I added myself as an OODT mentor too. Cheers, Chris On 8/16/10 7:24 AM, Noel J. Bergman n...@devtech.com wrote: I'm putting together the monthly board report. HISE and SIS are missing (so is Bluesky, but they did provide reports for the past several months running, so I'll cut them some slack). --- Noel - 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.mattm...@jpl.nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++
Re: REMINDER: Reports due *NOW* -- HISE and SIS, where are you?
On Aug 16, 2010, at 10:33 AM, Mattmann, Chris A (388J) wrote: Hey Noel, I uploaded an SIS report just now on the wiki. Any SIS mentors lurking around, please check it out and sign off. Thanks! Done. Thanks Chris. --kevan - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: REMINDER: Reports due *NOW* -- HISE and SIS, where are you?
Thanks Kevan! On 8/16/10 7:39 AM, Kevan Miller kevan.mil...@gmail.com wrote: On Aug 16, 2010, at 10:33 AM, Mattmann, Chris A (388J) wrote: Hey Noel, I uploaded an SIS report just now on the wiki. Any SIS mentors lurking around, please check it out and sign off. Thanks! Done. Thanks Chris. --kevan - 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.mattm...@jpl.nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++
RE: an experiment
Joe Schaefer wrote: How about requiring at least one mentor on the vote, so there is still some oversight? I'm actually not in favor of that idea because relatively few mentors are active developers in their projects (I'm certainly in that category). Part of what I'm trying to teach is that self-governance requires active participants to be making the critical decisions. They should be participating in the decisions, but the fact remains that they are not PMC members, they are still a provisional community (by definition of being in the Incubator), and the PMC cannot abandon its mandated oversight. The moral of the story is if you (generic, not Joe :-)) want to make decisions, demonstrate that you are making them the ASF Way, and get to graduation as soon as possible. --- Noel - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: an experiment
Again, if the PPMC has 3 or more PMC members, it should be capable of mustering the necessary votes by virtue of those PMC members voting. Have I repeated the every Incubator project should have at least 3 PMC members providing oversight mantra enough, yet? And if the Mentors aren't being active, voting, etc., then *that* is what needs to be addressed. We have one of the largest PMCs in the ASF. If we can't get enough active PMC Members, then that fact alone limits the size of the Incubator. We've also got a nice growth rate, as I'll attest to after I put in the next round of PMC membership approvals (next thing after today's board report). --- Noel - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: an experiment
On Mon, Aug 16, 2010 at 9:36 AM, Noel J. Bergman n...@devtech.com wrote: And if the Mentors aren't being active, voting, etc., then *that* is what needs to be addressed. As I've repeatedly stated before (here and elsewhere), in the podlings I've been recently involved with, having three mentors isn't the issue. It's the PMC members who aren't involved sticking their nose in and trying to poison the community. We have one of the largest PMCs in the ASF. If we I view this as potentially the crux of the problem - people who aren't stakeholders in the community shouldn't have a say. Right now, they feel they do. So, if we want to mandate at least 3 mentors - fine, but that must come at the cost of telling the rest of the IPMC to go away - unless they actively contribute to the community and earn merit...of course. -- justin - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: an experiment
On 08/16/2010 10:36 AM, Noel J. Bergman wrote: Again, if the PPMC has 3 or more PMC members, it should be capable of mustering the necessary votes by virtue of those PMC members voting. Have I repeated the every Incubator project should have at least 3 PMC members providing oversight mantra enough, yet? And if the Mentors aren't being active, voting, etc., then *that* is what needs to be addressed. We have one of the largest PMCs in the ASF. If we can't get enough active PMC Members, then that fact alone limits the size of the Incubator. +1 . Lack of binding votes was seen as the main problem for Traffic Server during incubation, other than that, I think the process mostly just works as it is. Cheers, -- Leif - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: an experiment
- Original Message From: Noel J. Bergman n...@devtech.com To: general@incubator.apache.org Sent: Mon, August 16, 2010 12:18:39 PM Subject: RE: an experiment I'd like to start experimenting with different organizational and procedural approaches to the projects I participate in here. What I want to do is to see how far I can push the envelope on the whole notion of empowerment and self-governance in an incubating project, following the lessons I've learned from httpd's treatment of the subprojects it happens to be responsible for. The reason for the existence of the PPMC is to help foster that self-governance, but we must recognize two things. One, the projects are not yet entitled to full self-governance. That's why they are in the Incubator. Two, the ASF Bylaws name *the* governing body for each project as the PMC, which is required to provide oversight. The first idea should be fairly straightforward: that for the projects I participate in (so far thrift and sis), that the IPMC delegates to the PPMC the decision-making process for voting in new committers -1 The PPMC has no legal or structural standing with the ASF. Decisions are made -- and required to be made -- by each project's PMC, as per the Bylaws. Are you trying to tell me that both jakarta and httpd have been in violation of Apache bylaws all these years? If the PPMC has 3 or more PMC members, it should be capable of mustering the necessary votes by virtue of those PMC members voting. Now, if the ASF Board would like to approve a different behavior, I'd accept that, but I don't believe that a PMC should take it on itself to skirt ASF Bylaws, and we've tried very hard to structure the Incubator within them. Amongst current board members are the ex-chair of Jakarta and an ex-chair of httpd. I would love to see you bring your concerns to the board about their past conduct regarding new committers. The fact that committers have no legal standing in this org means there is no reason a decision made about them needs formal approval by a PMC. Your reading of the corporate structure of this org is needlessly formal. The second idea is more controversial: to hold IPMC votes to admit all significant committers to those projects to the IPMC itself. The purpose of this concept is to allow those who best know the codebase to provide IPMC oversight over it, especially as it pertains to releases. -1 The Incubator PMC, unlike other PMCs, isn't preoccupied with the codebase; it is about community. And even with respect to code, we have far too much experience with projects attempt to put out improper releases to abandon our oversight obligations. I'm actually sugggesting we *enhance* our oversight capabilities, not abandon them. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: an experiment
- Original Message From: Justin Erenkrantz jus...@erenkrantz.com To: general@incubator.apache.org Sent: Mon, August 16, 2010 12:45:17 PM Subject: Re: an experiment On Mon, Aug 16, 2010 at 9:36 AM, Noel J. Bergman n...@devtech.com wrote: And if the Mentors aren't being active, voting, etc., then *that* is what needs to be addressed. As I've repeatedly stated before (here and elsewhere), in the podlings I've been recently involved with, having three mentors isn't the issue. Perhaps that's true for the projects you work on, but it certainly isn't true of Thrift, where mentorship has been a revolving door for years. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: an experiment
On Mon, Aug 16, 2010 at 10:06 AM, Joe Schaefer joe_schae...@yahoo.com wrote: Perhaps that's true for the projects you work on, but it certainly isn't true of Thrift, where mentorship has been a revolving door for years. True. I've never been a big fan of requiring 3 mentors - as I think certain personalities can do the teaching by themselves. However, if accepting that minimum requirement resolves the over-reach by others, I'd accept that tradeoff. Yes, it might kill off Thrift, but harming podlings with 3+ active mentors is even worse behavior. -- justin - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: an experiment
Hi Guys, From my point of view, it would be nice for podlings with active mentors to be able to guide their own decisions, especially if there are 3 active mentors and they approve. For example in our case in OODT, we can achieve consensus and obtain much of the necessary VOTEs and oversight from our mentors like Justin and Ian and myself. Also, I'm not sure that teaching the podlings that once they do a committer VOTE with the PPMC that they then have to do an IPMC vote after that is really teaching them the Apache way b/c this isn't the way it'll work when they graduate. I think so long as there are active mentors shepherding the experienced PMC role on the project, then VOTEs at the PPMC level should be all that's required. If IPMC = collection of all PPMC members (after pruning those that aren't active, etc.), that would be fine with me. My 2 cents, Chris On 8/16/10 9:45 AM, Justin Erenkrantz jus...@erenkrantz.com wrote: On Mon, Aug 16, 2010 at 9:36 AM, Noel J. Bergman n...@devtech.com wrote: And if the Mentors aren't being active, voting, etc., then *that* is what needs to be addressed. As I've repeatedly stated before (here and elsewhere), in the podlings I've been recently involved with, having three mentors isn't the issue. It's the PMC members who aren't involved sticking their nose in and trying to poison the community. We have one of the largest PMCs in the ASF. If we I view this as potentially the crux of the problem - people who aren't stakeholders in the community shouldn't have a say. Right now, they feel they do. So, if we want to mandate at least 3 mentors - fine, but that must come at the cost of telling the rest of the IPMC to go away - unless they actively contribute to the community and earn merit...of course. -- justin - 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.mattm...@jpl.nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++
Name change from Lucene Connectors Framework to Apache Connectors Framework
Hi, The Lucene Connectors Framework committers are voting to rename our project from Lucene Connectors Framework to Apache Connectors Framework, and to cease being a subproject of Lucene. What is the process for doing something like this? Karl
RE: an experiment
Justin Erenkrantz wrote: We have one of the largest PMCs in the ASF. I view this as potentially the crux of the problem - people who aren't stakeholders in the community shouldn't have a say. Right now, they feel they do. So, if we want to mandate at least 3 mentors - fine, but that must come at the cost of telling the rest of the IPMC to go away - unless they actively contribute to the community and earn merit...of course. Where are you seeing this over-reach problem to which you refer? I have heard of a few isolated incidents, and those can be addressed. But by far and way, the biggest complaint is LACK of involvement, e.g., Lack of binding votes was seen as the main problem for Traffic Server during incubation, other than that, I think the process mostly just works as it is. And most cases of PMC members getting involved in projects of which they aren't a Mentor have been with respect to release packaging, where the involvement has generally been valid and valuable, even if bothersome to those whose packages weren't quite up to snuff. But, seriously, if there is systemic overreaching, lets address *that* issue. --- Noel - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: an experiment
On Mon, Aug 16, 2010 at 10:37 AM, Noel J. Bergman n...@devtech.com wrote: Where are you seeing this over-reach problem to which you refer? I have heard of a few isolated incidents, and those can be addressed. But by far and way, the biggest complaint is LACK of involvement, e.g., ... And most cases of PMC members getting involved in projects of which they aren't a Mentor have been with respect to release packaging, where the involvement has generally been valid and valuable, even if bothersome to those whose packages weren't quite up to snuff. But, seriously, if there is systemic overreaching, lets address *that* issue. The cases of overreaching in Subversion and OODT related to adding new committers - not releases. So, I'm definitely in favor of Joe's proposal to let the PPMC have control over who gets to be in the community. -- justin - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[DISCUSS] experimental delegation of new committer votes to PPMC (was Re: [VOTE] experimental delegation of new committer votes to PPMC)
(starting new DISCUSS thread, to not pollute VOTE thread) Hi Joe, Can you do the VOTE for all Incubating projects? I'm sure mentors would put their own projects into the mix, so rather than just a few, let's do it for all of them. Cheers, Chris On 8/16/10 10:44 AM, Joe Schaefer joe_schae...@yahoo.com wrote: I have come to the realization that I'm not going to convince Noel to see things my way any time soon, so I'd like to now ask for a formal majority consensus vote on relaxed rules for the 3 aforementioned projects. Specifically, for thrift, sis, and esme, I wish to remove the current rule that requires 3 votes from IPMC members to approve a vote on a new committer, effectively delegating the decision to the PPMC. Additionally the pre-ack would be removed, but no other process changes are anticipated. Here's my +1. - 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.mattm...@jpl.nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++
Re: an experiment
There is some obvious compromises opportunity here. On releases, the iPMC could decide, by internal convention, to let the involved three mentors (when there are three involved members) be the relevant voice. iPMC members could pledge to defer to the involved mentors unless they feel that there is some overwhelming reason to vote -1. On committers there is a legal / procedural clarification called for. Perhaps I'm just dense, but I got the strong impression from the recent email at members@ that there was much more flexibility possible with committer status than with releases -- that the iPMC could indeed make a one-time, blanket, decision, that PPMC votes were sufficient for committer status. To cite an example to support my position, I'm pretty sure that GSOC students get commit privileges without formal PMC votes. However, if I am dense, and if the foundation requirements do require a real PMC vote for committer access, then the idea of my first paragraph would apply. On Mon, Aug 16, 2010 at 1:43 PM, Justin Erenkrantz jus...@erenkrantz.comwrote: On Mon, Aug 16, 2010 at 10:37 AM, Noel J. Bergman n...@devtech.com wrote: Where are you seeing this over-reach problem to which you refer? I have heard of a few isolated incidents, and those can be addressed. But by far and way, the biggest complaint is LACK of involvement, e.g., ... And most cases of PMC members getting involved in projects of which they aren't a Mentor have been with respect to release packaging, where the involvement has generally been valid and valuable, even if bothersome to those whose packages weren't quite up to snuff. But, seriously, if there is systemic overreaching, lets address *that* issue. The cases of overreaching in Subversion and OODT related to adding new committers - not releases. So, I'm definitely in favor of Joe's proposal to let the PPMC have control over who gets to be in the community. -- justin - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: an experiment
Joe Schaefer wrote: Are you trying to tell me that both jakarta and httpd have been in violation of Apache bylaws all these years? As as matter of fact, YES. I can't speak for the HTTP Server situation, but in the case of Jakarta, that was one of the reasons for breaking it up, along with pushing to make every committer a PMC member. Before that, Jakarta had allowed projects to vote their own releases outside of the PMC, and that finally raised some big red flags. I remember that clearly, as I suspect would Serge and Danny. The fact that committers have no legal standing in this org means there is no reason a decision made about them needs formal approval by a PMC. Your reading of the corporate structure of this org is needlessly formal. Giving them commit access has been deemed an action requiring a vote of the PMC. And sometimes the job description of a PMC Chair is Amongst current board members are the ex-chair of Jakarta and an ex-chair of httpd. I would love to see you bring your concerns to the board about their past conduct regarding new committers. No need. Sam was part of the process of fixing Jakarta, and Roy was one of the one's posting about the problem in Jakarta. --- Noel - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: an experiment
Noel J. Bergman wrote: Your reading of the corporate structure of this org is needlessly formal. And sometimes the job description of a PMC Chair is Sorry, got distracted by the phone, and didn't finish the thought. Part of the job description of a PMC Chair is to look after the Foundation's interests. I hope that no one would say that I take an obstructionist approach to our projects, but if the PMC Chair doesn't look at these issues, who will? --- Noel - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: an experiment
- Original Message From: Noel J. Bergman n...@devtech.com To: general@incubator.apache.org Sent: Mon, August 16, 2010 2:02:15 PM Subject: RE: an experiment Joe Schaefer wrote: Are you trying to tell me that both jakarta and httpd have been in violation of Apache bylaws all these years? As as matter of fact, YES. I can't speak for the HTTP Server situation, but in the case of Jakarta, that was one of the reasons for breaking it up, along with pushing to make every committer a PMC member. Before that, Jakarta had allowed projects to vote their own releases outside of the PMC, and that finally raised some big red flags. I remember that clearly, as I suspect would Serge and Danny. Let's not conflate release votes with committer votes. I'm not challenging IPMC process on releases at this point. I'm challenging the idea that allowing subprojects to vote in new committers all by themselves is somehow taboo in this org, because that does not match my experience with httpd, and it certainly wasn't how jakarta operated prior to the restructuring. The fact that committers have no legal standing in this org means there is no reason a decision made about them needs formal approval by a PMC. Your reading of the corporate structure of this org is needlessly formal. Giving them commit access has been deemed an action requiring a vote of the PMC. And sometimes the job description of a PMC Chair is Are you referring to a board resolution, or just some passed down wisdom that you have received? - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: an experiment
On Mon, Aug 16, 2010 at 10:57 AM, Benson Margulies bimargul...@gmail.com wrote: On committers there is a legal / procedural clarification called for. Perhaps I'm just dense, but I got the strong impression from the recent email at members@ that there was much more flexibility possible with committer status than with releases -- that the iPMC could indeed make a one-time, blanket, decision, that PPMC votes were sufficient for committer status. To cite an example to support my position, I'm pretty sure that GSOC students get commit privileges without formal PMC votes. Could you clarify on what do you mean by your statement around GSoC Students. GSoC students are and should be tread as any other contributors to a project and should earn committer karma via regular channels (discuss/vote/etc). -- Luciano Resende http://people.apache.org/~lresende http://twitter.com/lresende1975 http://lresende.blogspot.com/ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[VOTE] Apache Shiro graduation as TLP
The Apache Shiro community and the mentors of the project think the project is ready to graduate and is asking for IPMC's recommendation to present the project resolution to the board. The community graduation vote was held and resulted in 27 positive votes with no neutral or negatives (see http://mail-archives.apache.org/mod_mbox/incubator-shiro-user/201008.mbox/%3caanlktinqpvrhjxzjhjbyxpyhovzbyl1wqyw=hjln9...@mail.gmail.com%3e). The proposed resolution is attached to the end of this post and is also available at https://cwiki.apache.org/confluence/display/SHIRO/Graduation+Resolution. See the discussion on the project scope and resolution wording at http://mail-archives.apache.org/mod_mbox/incubator-shiro-dev/201008.mbox/browser (linking to the index view, see the [DISCUSS] Graduation Resolution thread). For other supporting information, see all of the completed action items at http://svn.apache.org/repos/asf/incubator/shiro/STATUS and clutch status at http://incubator.apache.org/clutch.html. This is a binding IPMC vote for recommending graduation of Apache Shiro with the proposed resolution. [ ] +1 - Recommend graduation of Apache Shiro as a TLP [ ] -1 - Oppose graduation of Apache Shiro as a TLP (if it's the wording in the resolution, we may refine during the vote) This vote will remain open for at least 72 hours. === Establish Apache Shiro Project WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software related to application security, for distribution at no charge to the public. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the The Apache Shiro Project, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that The Apache Shiro Project be and hereby is responsible for the creation and maintenance of a software project related to application security; and be it further RESOLVED, that the office of Vice President, Shiro 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 Shiro Project, and to have primary responsibility for management of the projects within the scope of responsibility of The Apache Shiro 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 Shiro Project: * Les Hazlewood (lhazlew...@apache.org) * Kalle Korhonen (kao...@apache.org) * Peter Ledbrook (pledbr...@apache.org) * Jeremy Haile(jha...@apache.org) * Craig L Russell (craig.russ...@oracle.com) NOW, THEREFORE, BE IT FURTHER RESOLVED, that Les Hazlewood be and hereby is appointed to the office of Vice President, Shiro, 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 Shiro Project be and hereby is tasked with the migration and rationalization of the Apache Incubator Shiro podling; and be it further RESOLVED, that all responsibility pertaining to the Apache Incubator Shiro podling encumbered upon the Apache Incubator PMC are hereafter discharged. === - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: an experiment
Chris A Mattmann wrote: From my point of view, it would be nice for podlings with active mentors to be able to guide their own decisions, especially if there are 3 active mentors and they approve. For example in our case in OODT, we can achieve consensus and obtain much of the necessary VOTEs and oversight from our mentors like Justin and Ian and myself. Well, that's sufficient, Chris. There should be no nice to have aspect. The only requirement is that the PMC has the ability to oversee. If we can streamline that process, great. I'm not sure that teaching the podlings that once they do a committer VOTE with the PPMC that they then have to do an IPMC vote after that is really teaching them the Apache way b/c this isn't the way it'll work when they graduate. I think so long as there are active mentors shepherding the experienced PMC role on the project, then VOTEs at the PPMC level should be all that's required. The problem is that the PPMC has no standing. I keep telling people to stop using the term IPMC. It is the Incubator PMC. The terms IPMC and PPMC make them look somehow equivalent. Now, because you have 3+ PMC members in the project, those votes have standing, and suffice so long as the rest of the PMC is aware of and has the opportunity to exercise oversight. The PMC need not vote unless someone has a good reason to cast a -1. Again, I'm all for streamlining, as long as it supports oversight. --- Noel - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: [VOTE] experimental delegation of new committer votes to PPMC
Joe Schaefer wrote: I have come to the realization that I'm not going to convince Noel to see things my way any time soon, so I'd like to now ask for a formal majority consensus vote on relaxed rules for [for] thrift, sis, and esme, I wish to remove the current rule that requires 3 votes from [the PMC] to approve a vote on a new committer This isn't a matter of my opinion. The question is whether the ASF Board approves the election of Committers without PMC approval. I am asking them that question in this month's Board Report. --- Noel - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: an experiment
On Monday 16 August 2010 2:15:32 pm Luciano Resende wrote: On Mon, Aug 16, 2010 at 10:57 AM, Benson Margulies bimargul...@gmail.com wrote: On committers there is a legal / procedural clarification called for. Perhaps I'm just dense, but I got the strong impression from the recent email at members@ that there was much more flexibility possible with committer status than with releases -- that the iPMC could indeed make a one-time, blanket, decision, that PPMC votes were sufficient for committer status. To cite an example to support my position, I'm pretty sure that GSOC students get commit privileges without formal PMC votes. Could you clarify on what do you mean by your statement around GSoC Students. GSoC students are and should be tread as any other contributors to a project and should earn committer karma via regular channels (discuss/vote/etc). I think he's confusing getting commit karma on a project and getting an Apache account that would allow commit to a sandbox or similar. For some projects, we had the students submit a ICLA and we had accounts created that gave them a walled off sandbox to commit their work into rather than have them creating forks or something off at GitHub or similar. They don't have project commit karma to commit to trunk or branches or anything, just a very walled off sandbox. -- Daniel Kulp dk...@apache.org http://dankulp.com/blog - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: an experiment
Joe Schaefer wrote: I'm challenging the idea that allowing subprojects to vote in new committers all by themselves is somehow taboo in this org I understand. I am specifically raising that issue with the Board in this month's report. Giving them commit access has been deemed an action requiring a vote of the PMC. Are you referring to a board resolution, or just some passed down wisdom that you have received? I'm not aware of a resolution. Let's see what comes back from the Board. --- Noel - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] experimental delegation of new committer votes to PPMC
- Original Message From: Noel J. Bergman n...@devtech.com To: general@incubator.apache.org Sent: Mon, August 16, 2010 2:22:02 PM Subject: RE: [VOTE] experimental delegation of new committer votes to PPMC Joe Schaefer wrote: I have come to the realization that I'm not going to convince Noel to see things my way any time soon, so I'd like to now ask for a formal majority consensus vote on relaxed rules for [for] thrift, sis, and esme, I wish to remove the current rule that requires 3 votes from [the PMC] to approve a vote on a new committer This isn't a matter of my opinion. The question is whether the ASF Board approves the election of Committers without PMC approval. I am asking them that question in this month's Board Report. Fair enough. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Apache Shiro graduation as TLP
Good job guys. I reviewed the VOTE threads, and your clutch status. Board resolution looks good. My only concern is that it looks like a small PMC, but if you've got this far then I'll trust you guys to move forward. Also looks like solid people on the team too. +1 from me. Cheers, Chris On 8/16/10 11:18 AM, Kalle Korhonen kalle.o.korho...@gmail.com wrote: The Apache Shiro community and the mentors of the project think the project is ready to graduate and is asking for IPMC's recommendation to present the project resolution to the board. The community graduation vote was held and resulted in 27 positive votes with no neutral or negatives (see http://mail-archives.apache.org/mod_mbox/incubator-shiro-user/201008.mbox/%3caanlktinqpvrhjxzjhjbyxpyhovzbyl1wqyw=hjln9...@mail.gmail.com%3e). The proposed resolution is attached to the end of this post and is also available at https://cwiki.apache.org/confluence/display/SHIRO/Graduation+Resolution. See the discussion on the project scope and resolution wording at http://mail-archives.apache.org/mod_mbox/incubator-shiro-dev/201008.mbox/browser (linking to the index view, see the [DISCUSS] Graduation Resolution thread). For other supporting information, see all of the completed action items at http://svn.apache.org/repos/asf/incubator/shiro/STATUS and clutch status at http://incubator.apache.org/clutch.html. This is a binding IPMC vote for recommending graduation of Apache Shiro with the proposed resolution. [ ] +1 - Recommend graduation of Apache Shiro as a TLP [ ] -1 - Oppose graduation of Apache Shiro as a TLP (if it's the wording in the resolution, we may refine during the vote) This vote will remain open for at least 72 hours. === Establish Apache Shiro Project WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software related to application security, for distribution at no charge to the public. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the The Apache Shiro Project, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that The Apache Shiro Project be and hereby is responsible for the creation and maintenance of a software project related to application security; and be it further RESOLVED, that the office of Vice President, Shiro 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 Shiro Project, and to have primary responsibility for management of the projects within the scope of responsibility of The Apache Shiro 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 Shiro Project: * Les Hazlewood (lhazlew...@apache.org) * Kalle Korhonen (kao...@apache.org) * Peter Ledbrook (pledbr...@apache.org) * Jeremy Haile(jha...@apache.org) * Craig L Russell (craig.russ...@oracle.com) NOW, THEREFORE, BE IT FURTHER RESOLVED, that Les Hazlewood be and hereby is appointed to the office of Vice President, Shiro, 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 Shiro Project be and hereby is tasked with the migration and rationalization of the Apache Incubator Shiro podling; and be it further RESOLVED, that all responsibility pertaining to the Apache Incubator Shiro podling encumbered upon the Apache Incubator PMC are hereafter discharged. === - 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.mattm...@jpl.nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++
Re: [VOTE] Apache Shiro graduation as TLP
On 16 August 2010 19:18, Kalle Korhonen kalle.o.korho...@gmail.com wrote: The Apache Shiro community and the mentors of the project think the project is ready to graduate and is asking for IPMC's recommendation to present the project resolution to the board. The community graduation vote was held and resulted in 27 positive votes with no neutral or negatives (see http://mail-archives.apache.org/mod_mbox/incubator-shiro-user/201008.mbox/%3caanlktinqpvrhjxzjhjbyxpyhovzbyl1wqyw=hjln9...@mail.gmail.com%3e). The proposed resolution is attached to the end of this post and is also available at https://cwiki.apache.org/confluence/display/SHIRO/Graduation+Resolution. See the discussion on the project scope and resolution wording at http://mail-archives.apache.org/mod_mbox/incubator-shiro-dev/201008.mbox/browser (linking to the index view, see the [DISCUSS] Graduation Resolution thread). For other supporting information, see all of the completed action items at http://svn.apache.org/repos/asf/incubator/shiro/STATUS and clutch status at http://incubator.apache.org/clutch.html. This is a binding IPMC vote for recommending graduation of Apache Shiro with the proposed resolution. [ ] +1 - Recommend graduation of Apache Shiro as a TLP [ ] -1 - Oppose graduation of Apache Shiro as a TLP (if it's the wording in the resolution, we may refine during the vote) Some of the incubation stages don't seem to have been completed, at least according to the page: http://incubator.apache.org/projects/shiro.html Perhaps these items have been completed, in which case please could the page be updated accordingly? This vote will remain open for at least 72 hours. === Establish Apache Shiro Project WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software related to application security, for distribution at no charge to the public. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the The Apache Shiro Project, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that The Apache Shiro Project be and hereby is responsible for the creation and maintenance of a software project related to application security; and be it further RESOLVED, that the office of Vice President, Shiro 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 Shiro Project, and to have primary responsibility for management of the projects within the scope of responsibility of The Apache Shiro 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 Shiro Project: * Les Hazlewood (lhazlew...@apache.org) * Kalle Korhonen (kao...@apache.org) * Peter Ledbrook (pledbr...@apache.org) * Jeremy Haile (jha...@apache.org) * Craig L Russell (craig.russ...@oracle.com) NOW, THEREFORE, BE IT FURTHER RESOLVED, that Les Hazlewood be and hereby is appointed to the office of Vice President, Shiro, 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 Shiro Project be and hereby is tasked with the migration and rationalization of the Apache Incubator Shiro podling; and be it further RESOLVED, that all responsibility pertaining to the Apache Incubator Shiro podling encumbered upon the Apache Incubator PMC are hereafter discharged. === - 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: an experiment
On Mon, Aug 16, 2010 at 11:22 AM, Noel J. Bergman n...@devtech.com wrote: What happened? It's all in the archives, but a quick recap. For Subversion, an Incubator PMC member who was never involved in the SVN community jumped in the middle of a committer vote to vote -1. Greg wrote a cranky email telling him to go away. Most of the committers in SVN were taken aback by the behavior. Who is this person? Why do they get to vote -1? For OODT, we voted on a committer - but forgot to do the pre-acknowledgement and Chris got taken out to the woodshed by some members because we sent the ack *after* the vote. Chris didn't go cranky, but I would have. (I was in the middle of moving when that happened - even then I threw away a few cranky emails...) And given that Subversion clearly (should have) had more than 3 PMC members, how did it impact? Even after graduation, in Subversion, Greg has had to constantly reinforce that the Subversion PMC gets to make the decisions in the project and stop looking for others to set policy - as that's the (false) precedent set by the Incubator. The behavior of the Incubator PMC can set a bad tone - and those of us mentoring have often had to take proactive efforts to undo the damage. -- justin - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: an experiment
Hi Noel, Thanks for your reply. Comments below: From my point of view, it would be nice for podlings with active mentors to be able to guide their own decisions, especially if there are 3 active mentors and they approve. For example in our case in OODT, we can achieve consensus and obtain much of the necessary VOTEs and oversight from our mentors like Justin and Ian and myself. Well, that's sufficient, Chris. There should be no nice to have aspect. The only requirement is that the PMC has the ability to oversee. If we can streamline that process, great. Yeah, I guess to me the PPMC* mentors should be fine to oversee without double checking with the IPMC*. The podling mentors represent the IPMC* in my mind and should be its shepherds, not those other IPMC* folks who aren't participating in the day to day of the podling. I'm not sure that teaching the podlings that once they do a committer VOTE with the PPMC that they then have to do an IPMC vote after that is really teaching them the Apache way b/c this isn't the way it'll work when they graduate. I think so long as there are active mentors shepherding the experienced PMC role on the project, then VOTEs at the PPMC level should be all that's required. The problem is that the PPMC has no standing. I keep telling people to stop using the term IPMC. It is the Incubator PMC. The terms IPMC and PPMC make them look somehow equivalent. I guess that's what I take exception to, I think the PPMC* _should_ have standing. I saw your other reply to Joe on this and the fact that you're going to ask for clarification from the Board on seemingly a related subject. Sounds good to me. Now, because you have 3+ PMC members in the project, those votes have standing, and suffice so long as the rest of the PMC is aware of and has the opportunity to exercise oversight. Yeah, like I said, to me, podling mentors = IPMC* oversight, so if 3+ mentors approve, then that should be it IMHO. Cheers, Chris * I'm still using PPMC and IPMC b/c that's what the docs call them [1]. [1] http://incubator.apache.org/guides/ppmc.html ++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: chris.mattm...@jpl.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: [VOTE] Apache Shiro graduation as TLP
On 16 August 2010 19:33, sebb seb...@gmail.com wrote: On 16 August 2010 19:18, Kalle Korhonen kalle.o.korho...@gmail.com wrote: The Apache Shiro community and the mentors of the project think the project is ready to graduate and is asking for IPMC's recommendation to present the project resolution to the board. The community graduation vote was held and resulted in 27 positive votes with no neutral or negatives (see http://mail-archives.apache.org/mod_mbox/incubator-shiro-user/201008.mbox/%3caanlktinqpvrhjxzjhjbyxpyhovzbyl1wqyw=hjln9...@mail.gmail.com%3e). The proposed resolution is attached to the end of this post and is also available at https://cwiki.apache.org/confluence/display/SHIRO/Graduation+Resolution. See the discussion on the project scope and resolution wording at http://mail-archives.apache.org/mod_mbox/incubator-shiro-dev/201008.mbox/browser (linking to the index view, see the [DISCUSS] Graduation Resolution thread). For other supporting information, see all of the completed action items at http://svn.apache.org/repos/asf/incubator/shiro/STATUS and clutch status at http://incubator.apache.org/clutch.html. This is a binding IPMC vote for recommending graduation of Apache Shiro with the proposed resolution. [ ] +1 - Recommend graduation of Apache Shiro as a TLP [ ] -1 - Oppose graduation of Apache Shiro as a TLP (if it's the wording in the resolution, we may refine during the vote) Some of the incubation stages don't seem to have been completed, at least according to the page: http://incubator.apache.org/projects/shiro.html Perhaps these items have been completed, in which case please could the page be updated accordingly? Also, just noticed that the SVN tree does not appear to have a copy of the LICENSE file. Normally this is stored alongside the NOTICE file at the top-level, i.e. in http://svn.apache.org/repos/asf/incubator/shiro/trunk/ Looks like the file was deleted in the following commit: r979180 | kaosko | 2010-07-26 07:45:44 +0100 (Mon, 26 Jul 2010) | 1 line Was this intentional? This vote will remain open for at least 72 hours. === Establish Apache Shiro Project WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software related to application security, for distribution at no charge to the public. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the The Apache Shiro Project, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that The Apache Shiro Project be and hereby is responsible for the creation and maintenance of a software project related to application security; and be it further RESOLVED, that the office of Vice President, Shiro 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 Shiro Project, and to have primary responsibility for management of the projects within the scope of responsibility of The Apache Shiro 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 Shiro Project: * Les Hazlewood (lhazlew...@apache.org) * Kalle Korhonen (kao...@apache.org) * Peter Ledbrook (pledbr...@apache.org) * Jeremy Haile (jha...@apache.org) * Craig L Russell (craig.russ...@oracle.com) NOW, THEREFORE, BE IT FURTHER RESOLVED, that Les Hazlewood be and hereby is appointed to the office of Vice President, Shiro, 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 Shiro Project be and hereby is tasked with the migration and rationalization of the Apache Incubator Shiro podling; and be it further RESOLVED, that all responsibility pertaining to the Apache Incubator Shiro podling encumbered upon the Apache Incubator PMC are hereafter discharged. === - 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: an experiment
i am not confused:-) the entire incubator is a 'walled sandbox'. if projects can grant streamlined karma to sandbox branches to students, why not let podlings add committers? On Aug 16, 2010, at 2:23 PM, Daniel Kulp dk...@apache.org wrote: On Monday 16 August 2010 2:15:32 pm Luciano Resende wrote: On Mon, Aug 16, 2010 at 10:57 AM, Benson Margulies bimargul...@gmail.com wrote: On committers there is a legal / procedural clarification called for. Perhaps I'm just dense, but I got the strong impression from the recent email at members@ that there was much more flexibility possible with committer status than with releases -- that the iPMC could indeed make a one-time, blanket, decision, that PPMC votes were sufficient for committer status. To cite an example to support my position, I'm pretty sure that GSOC students get commit privileges without formal PMC votes. Could you clarify on what do you mean by your statement around GSoC Students. GSoC students are and should be tread as any other contributors to a project and should earn committer karma via regular channels (discuss/vote/etc). I think he's confusing getting commit karma on a project and getting an Apache account that would allow commit to a sandbox or similar. For some projects, we had the students submit a ICLA and we had accounts created that gave them a walled off sandbox to commit their work into rather than have them creating forks or something off at GitHub or similar. They don't have project commit karma to commit to trunk or branches or anything, just a very walled off sandbox. -- Daniel Kulp dk...@apache.org http://dankulp.com/blog - 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
Incubator Board Report - August 2010
Matt Benson, Srinath Perera, and Michael McCandless all joined the Incubator. Several more will be joining this week. Shiro is set to graduate, and it seems that at least a couple of projects are in good shape to graduate in the near future. On to a topic for the Board's attention. There has been some lively discussion this past week, initiated by Joe Schaefer regarding making Incubator projects more self-governing. Although a valid goal, the actual proposals appear troubling in terms of ASF governance structure. A specific proposal, for which Joe would like a formal vote, amounts to whether the ASF Board approves the granting of Committer status without PMC approval, and bypassing the PMC on the matter. Individual current and past Directors have already engaged, but it is requested that the Board consider the issue, and respond. -- = Amber = Amber is a project to develop a Java library which provides an API specification for, and an unconditionally compliant implementation of the OAuth v1.0, v1.0a and v2.0 specifications. OAuth is a mechanism that allows users to authenticate and authorise access by another party to resources they control while avoiding the need to share their username and password credentials. The most important issues that must be addressed before graduation are: * attract new users and developers * making a release The Incubator PMC / ASF Board should be aware that: * Involved people have been very busy due to personal/business issues in the last month. Latest activity: * apply the API definition choices approved by the community. * started implementing the Signing algorithms. Next steps: * finalize the API definition. * implementation of different specification versions (client and server). Community: * The community is in the first stages of formation and solely consists of the developers, though a few users start to appear on the mailing lists. = Bluesky = Did not report, but has reported several months running. The only activity observed is the following e-mail: http://mail-archives.apache.org/mod_mbox/incubator-bluesky-dev/201008.mbox/% 3caanlkti=nafbwoofuu1faxkxyxaiqf2rat5zqdcl1p...@mail.gmail.com%3e = BeanValidation = Apache Bean Validation will deliver an implementation of the JSR303 Bean Validation 1.0 specification. BVAL entered incubation on March 1, 2010. A list of the three most important issues to address in the move towards graduation. * First release of artifacts - Done * Grow the community and committer base - ongoing * Decide on graduation target of TLP or subproject - TBD Any issues that the Incubator PMC or ASF Board might wish/need to be aware of? * None at this time. How has the community developed since the last report? * Committer offer was extended and accepted by Matt Benson. * A couple of new users on the dev list. How has the project developed since the last report? * Currently a 0.2-incubating RC2 release vote is underway. = Chukwa = Chukwa is a distributed log collection and processing system built on top of Hadoop. It is a former Hadoop subproject. CLAs are on file and ASF holds all copyrights. We have been in incubation since July 13, 2010. Since then, we have switched to incubation SVN naming and updated our website to reflect this change. We still need to move mailing lists to incubation. [Pending on Bernd.] We still need to move our website to incubator.apache.org [Pending on permissions]. Should bring onboard more committers; Bill Graham would be the first Chukwa commiter not originally part of the project. = Clerezza = Clerezza (incubating since November 27th, 2009) is an OSGi-based modular application and set of components (bundles) for building RESTFul Semantic Web applications and services. The are currently no issues requiring board attention. Recent activity: * Added support for roaming useres with WebId * Added support for ssl * Started support for editing own foaf-profile with cleint certificate generation * Faster ScalaServer Pages using Scala 2.8.0 * Improved User documentation Next steps: * Streamline architecture around type-handlers and type-renderer * Add ability to easily overwrite the styling in full or partially (skinning) with a bundle Top 2/3 Issues before graduation: * Improve our website with tutorials and getting started content. * Prepare some easy-to-run demos to get people interested in Clerezza. * Prepare for a first release = Deltacloud = Deltacloud is a cross-cloud RESTful abstraction API. The are currently no issues requiring board attention. Recent activity: * Grant of initial code finalized: code relicensed under ASL2.0, iCLA's of all contributor's on file, cCLA from Red Hat for initial submission also on file, code imported to subversion * First draft of an API specification sent to developer's list * Initial content for project website in svn; need to clear up some technical
RE: an experiment
Justin Erenkrantz wrote: a quick recap. an Incubator PMC member who was never involved in [the] community jumped in the middle of a committer vote to vote -1. Greg wrote a cranky email telling him to go away. Most of the committers in SVN were taken aback by the behavior. Who is this person? Why do they get to vote -1? Presumably there was no valid basis for the -1? Sucks, but Joe's proposal doesn't change the fact that any PMC Member can still vote on any project. The ASF does not have subprojects, there is only one PMC. We have gone through this with Jakarta and XML over those issues. For OODT, we voted on a committer - but forgot to do the pre-acknowledgement and Chris got taken out to the woodshed by some members because we sent the ack *after* the vote. Chris didn't go cranky, but I would have. Perhaps we need to remind people that mistakes happen -- ESPECIALLY in the Incubator -- and we need to extend courtesy and assistence, not back-of-the-woodshed beatings. And, as I just noted to Chris, I am all for any streamlining that we can do, so long as it preserves PMC oversight. And given that Subversion clearly (should have) had more than 3 PMC members, how did it impact? after graduation, in Subversion, Greg has had to constantly reinforce that the Subversion PMC gets to make the decisions in the project and stop looking for others to set policy - as that's the (false) precedent set by the Incubator. I see what you are saying, but the issue is that ASF project policy is set by its PMC, and until an Incubator project graduates, that PMC is the Incubator PMC. But we do try to allow the project a lot of leeway to self-govern, which is why the PPMC exists in the first place. And I'm curious as to why Subversion folks got into a habit of looking elsewhere, since the Subversion project pretty much *did* self-govern (having plenty of PMC Members and ASF Members on the project) during its short Incubation. --- Noel - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Incubator Board Report - August 2010
- Original Message From: Noel J. Bergman n...@devtech.com To: bo...@apache.org Cc: general@incubator.apache.org Sent: Mon, August 16, 2010 2:52:18 PM Subject: Incubator Board Report - August 2010 On to a topic for the Board's attention. There has been some lively discussion this past week, initiated by Joe Schaefer regarding making Incubator projects more self-governing. Although a valid goal, the actual proposals appear troubling in terms of ASF governance structure. A specific proposal, for which Joe would like a formal vote, amounts to whether the ASF Board approves the granting of Committer status without PMC approval, and bypassing the PMC on the matter. Individual current and past Directors have already engaged, but it is requested that the Board consider the issue, and respond. All I've asked is that the rule regarding a formal vote from 3 IPMC members be dropped in favor of just honoring the votes of the PPMC. The rest of the umpteen oversight steps regarding inducting a new committer into the Incubator remain intact: describing that as bypassing the PMC isn't really fair to my position. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: an experiment
Chris A Mattmann wrote: Well, that's sufficient, Chris. There should be no nice to have aspect. The only requirement is that the PMC has the ability to oversee. If we can streamline that process, great. Yeah, I guess to me the PPMC mentors should be fine to oversee without double checking with the IPMC. They should be fine, but the PMC still needs to have the opportunity to provide oversight. The podling mentors represent the IPMC in my mind and should be its shepherds, not those other IPMC folks who aren't participating in the day to day of the podling. People not participating should generally stay out of it unless necessary. Necessary might be: - not enough +1 votes, so please help - improper release packaging - something really out of whack Otherwise, get involved or butt out. :-) But until the project graduates, PMC members *can* have a say. Don't like it? Graduate faster! :-D The problem is that the PPMC has no standing. I keep telling people to stop using the term IPMC. It is the Incubator PMC. The terms IPMC and PPMC make them look somehow equivalent. I guess that's what I take exception to, I think the PPMC _should_ have standing. As per http://www.apache.org/foundation/bylaws.html#6.3, the defined governing entity is the Project Management Committee, better known as the PMC. And while the text does say that the PMC Chair shall establish rules and procedures for the day to day management of project(s) for which the committee is responsible, it is the accepted practice of the ASF that the PMC makes all decisions. to me, podling mentors = IPMC* oversight, so if 3+ mentors approve, then that should be it IMHO. I'd say that 3+ Mentors *and* lazy consensus (which basically just means a notice requirement) of the PMC is sufficient. --- Noel - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Apache Shiro graduation as TLP
On Mon, Aug 16, 2010 at 11:33 AM, sebb seb...@gmail.com wrote: On 16 August 2010 19:18, Kalle Korhonen kalle.o.korho...@gmail.com wrote: Some of the incubation stages don't seem to have been completed, at least according to the page: http://incubator.apache.org/projects/shiro.html Perhaps these items have been completed, in which case please could the page be updated accordingly? Uh sorry, we've forgotten the existence of that page - will update. Kalle - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: an experiment
Hi Noel, I guess that's what I take exception to, I think the PPMC _should_ have standing. As per http://www.apache.org/foundation/bylaws.html#6.3, the defined governing entity is the Project Management Committee, better known as the PMC. And while the text does say that the PMC Chair shall establish rules and procedures for the day to day management of project(s) for which the committee is responsible, it is the accepted practice of the ASF that the PMC makes all decisions. Welp, hopefully we get clarification on this and whether or not it can be a PMC (or PMC chair's) call on the *who* gets to make the decisions. One way forward would be if the IPMC consisted of the set of active contributors to a podling (including mentors + podling committers), then we're really saying the same thing. This is one of the things I've heard that's up for discussion and I for one am in favor of it. 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.mattm...@jpl.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: [VOTE] Apache Shiro graduation as TLP
On Mon, Aug 16, 2010 at 11:43 AM, sebb seb...@gmail.com wrote: Also, just noticed that the SVN tree does not appear to have a copy of the LICENSE file. Normally this is stored alongside the NOTICE file at the top-level, i.e. in http://svn.apache.org/repos/asf/incubator/shiro/trunk/ Looks like the file was deleted in the following commit: r979180 | kaosko | 2010-07-26 07:45:44 +0100 (Mon, 26 Jul 2010) | 1 line Was this intentional? Yes, that was intentional, see the commit message: Follow through on the suggestions given when 1.0.0 release was made. Removed LICENSE.txt as that is added to the source distro via Apache parent pom and its remote resource plugin configuration. Renamed NOTICE.txt to NOTICE so it'll replace the default one. Note that http://www.apache.org/legal/src-headers.html#notice indicates that the LICENSE file needs to be present only in the source distro (and not in svn as Sebb claimed) so we are ok. Also note that ant suggested removing the SoftHashMap and Spring related comments completely from NOTICE file but they are regarding copyrights so look fine to me, will confirm on dev list. If you can point out any documentation that says LICENSE will is required in svn, I'll put it in otherwise I'll avoid the redundancy. In any case, thanks for taking a look! More recently, I also integrated apache-rat (the maven plugin) to our build process. Kalle - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: an experiment
On Aug 16, 2010, at 2:52 PM, Noel J. Bergman wrote: Presumably there was no valid basis for the -1? Sucks, but Joe's proposal doesn't change the fact that any PMC Member can still vote on any project. The ASF does not have subprojects, there is only one PMC. We have gone through this with Jakarta and XML over those issues. IIRC, the issue involved the notion of partial committers in subversion -- http://subversion.apache.org/docs/community-guide/roles.html#committers There were objections over the notion of partial committers, not about the individual. I don't view subversion as a particularly good motivating example of why the Incubator is or is not broken. Subversion was unique from the very beginning... In general, I agree with in Noel... Would add that IMO, incubator oversight has helped release processes (and general foundation knowledge) for many projects, not just those who have been through incubation... --kevan - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Bean Validation 0.2-incubating RC2
+1 Signature/checksums, build, source (RAT), and general snooping around with emacs all looked good. Thanks Donald! --kevan On Aug 13, 2010, at 1:38 PM, Donald Woods wrote: A Bean Validation 0.2-incubating release candidate #2 has been created with the following artifacts up for a vote: SVN source tag (r985290): https://svn.apache.org/repos/asf/incubator/bval/tags/0.2-incubating/ Maven staging repo: https://repository.apache.org/content/repositories/orgapachebval-102/ Source release: https://repository.apache.org/content/repositories/orgapachebval-102/org/apache/bval/bval-parent/0.2-incubating/bval-parent-0.2-incubating-source-release.zip Javadoc staging site: http://people.apache.org/~dwoods/bval/0.2-incubating/staging-site/apidocs/ PGP release keys (signed using D018E6B1): https://svn.apache.org/repos/asf/incubator/bval/KEYS Vote will be open for 72 hours. [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) Thanks, Donald - 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: an experiment
Craig L Russell wrote: Here's the current process for getting new committers into an incubating project: 1. Identify candidates 2. Discuss candidates on podling-private 3. Agree that candidate should be a committer All PPMC functions; need no outside involvement. 4. Vote on podling-private 5. Wait for everyone's vote 6. Inform incubator PMC of results of vote 7. Vote in incubator PMC if not all three mentors have voted Translation: vote and talley. How can we streamline this with oversight? - Initiate vote on podling-private concurrently notify PMC - Tally votes (ping PMC if more votes are necessary) - Post vote results to podling-private / cc: private@ I don't see anything to remove, and assuming that the podling has 3+ active Mentors, the PMC is not a time block. But processing of the actual vote *is* where the PMC exerts oversight. 8. Invite committer 9. Send ICLA 10. Wait for ICLA registration 11. Send root request for committer 12. Wait for root to create account 13. Update asf authorization file for new account I don't see anything to remove from here, nor is there any PMC-specific task. --- Noel - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Incubator Board Report - August 2010
Sorry for the lateness, as one of the Amber mentors I would like to sign off on the amber portion of this report. thanks david jencks On Aug 16, 2010, at 11:52 AM, Noel J. Bergman wrote: Matt Benson, Srinath Perera, and Michael McCandless all joined the Incubator. Several more will be joining this week. Shiro is set to graduate, and it seems that at least a couple of projects are in good shape to graduate in the near future. On to a topic for the Board's attention. There has been some lively discussion this past week, initiated by Joe Schaefer regarding making Incubator projects more self-governing. Although a valid goal, the actual proposals appear troubling in terms of ASF governance structure. A specific proposal, for which Joe would like a formal vote, amounts to whether the ASF Board approves the granting of Committer status without PMC approval, and bypassing the PMC on the matter. Individual current and past Directors have already engaged, but it is requested that the Board consider the issue, and respond. -- = Amber = Amber is a project to develop a Java library which provides an API specification for, and an unconditionally compliant implementation of the OAuth v1.0, v1.0a and v2.0 specifications. OAuth is a mechanism that allows users to authenticate and authorise access by another party to resources they control while avoiding the need to share their username and password credentials. The most important issues that must be addressed before graduation are: * attract new users and developers * making a release The Incubator PMC / ASF Board should be aware that: * Involved people have been very busy due to personal/business issues in the last month. Latest activity: * apply the API definition choices approved by the community. * started implementing the Signing algorithms. Next steps: * finalize the API definition. * implementation of different specification versions (client and server). Community: * The community is in the first stages of formation and solely consists of the developers, though a few users start to appear on the mailing lists. = Bluesky = Did not report, but has reported several months running. The only activity observed is the following e-mail: http://mail-archives.apache.org/mod_mbox/incubator-bluesky-dev/201008.mbox/% 3caanlkti=nafbwoofuu1faxkxyxaiqf2rat5zqdcl1p...@mail.gmail.com%3e = BeanValidation = Apache Bean Validation will deliver an implementation of the JSR303 Bean Validation 1.0 specification. BVAL entered incubation on March 1, 2010. A list of the three most important issues to address in the move towards graduation. * First release of artifacts - Done * Grow the community and committer base - ongoing * Decide on graduation target of TLP or subproject - TBD Any issues that the Incubator PMC or ASF Board might wish/need to be aware of? * None at this time. How has the community developed since the last report? * Committer offer was extended and accepted by Matt Benson. * A couple of new users on the dev list. How has the project developed since the last report? * Currently a 0.2-incubating RC2 release vote is underway. = Chukwa = Chukwa is a distributed log collection and processing system built on top of Hadoop. It is a former Hadoop subproject. CLAs are on file and ASF holds all copyrights. We have been in incubation since July 13, 2010. Since then, we have switched to incubation SVN naming and updated our website to reflect this change. We still need to move mailing lists to incubation. [Pending on Bernd.] We still need to move our website to incubator.apache.org [Pending on permissions]. Should bring onboard more committers; Bill Graham would be the first Chukwa commiter not originally part of the project. = Clerezza = Clerezza (incubating since November 27th, 2009) is an OSGi-based modular application and set of components (bundles) for building RESTFul Semantic Web applications and services. The are currently no issues requiring board attention. Recent activity: * Added support for roaming useres with WebId * Added support for ssl * Started support for editing own foaf-profile with cleint certificate generation * Faster ScalaServer Pages using Scala 2.8.0 * Improved User documentation Next steps: * Streamline architecture around type-handlers and type-renderer * Add ability to easily overwrite the styling in full or partially (skinning) with a bundle Top 2/3 Issues before graduation: * Improve our website with tutorials and getting started content. * Prepare some easy-to-run demos to get people interested in Clerezza. * Prepare for a first release = Deltacloud = Deltacloud is a cross-cloud RESTful abstraction API. The are currently no issues requiring board attention. Recent activity: * Grant of initial
RE: an experiment
-Original Message- From: Noel J. Bergman [mailto:n...@devtech.com] Sent: Tuesday, 17 August 2010 4:07 AM To: general@incubator.apache.org Subject: RE: an experiment Noel J. Bergman wrote: Your reading of the corporate structure of this org is needlessly formal. And sometimes the job description of a PMC Chair is Sorry, got distracted by the phone, and didn't finish the thought. Part of the job description of a PMC Chair is to look after the Foundation's interests. I hope that no one would say that I take an obstructionist approach to our projects, but if the PMC Chair doesn't look at these issues, who will? How about a PMC Chair that does more than turn up once a month at , ooh, day before board reports are due and then disappears for a whole month until , ooh, day before report time. And you still expect to run the whole show your way and jump in with 20+ messages in one day about subjects people have been discussing for days if not weeks before. if (P)PMC chairs of other projects acted in this manner others including yourself maybe, would have something to say about it. I'm surprised no-one has mentioned about the Incubator PMC Chair up until now (actually I'm not, and I bet that no one steps up to agree with me here, I expect to be alone in my opinion.) And I can't wait for your excuse to be that the sole role of PMC chair is to file reports. It's a shame because when you do turn up, you do a half decent job. Now to catch up with the other 30+ messages that have steamed in these last few hours. Gav... --- Noel - 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: Name change from Lucene Connectors Framework to Apache Connectors Framework
On Aug 16, 2010, at 9:59 AM, karl.wri...@nokia.com karl.wri...@nokia.com wrote: Hi, The Lucene Connectors Framework committers are voting to rename our project from Lucene Connectors Framework to Apache Connectors Framework, and to cease being a subproject of Lucene. What is the process for doing something like this? Just to clarify, LCF is not a subproject of Lucene at the moment, since it is in the Incubator. The Lucene PMC was sponsoring LCF and is willing to continue to do so. Nothing else project wise would change other than the name at this point. Upon graduation, it likely make sense for LCF/ACF to be a TLP. -Grant - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Name change from Lucene Connectors Framework to Apache Connectors Framework
The relevance of this name might seem clear to project members, but not to me. From my background I would assume this is an implementation of the j2ca connector framework at apache, kind of like (the active part of) codehaus tranql. If I'd been working on tomcat or jetty recently I'd assume it was some kind of generalization of the transport connectors for a web container. Since this now or formerly relates to lucene I kinda doubt either one of these assumptions would be particularly accurate. thanks david jencks On Aug 16, 2010, at 6:59 AM, karl.wri...@nokia.com karl.wri...@nokia.com wrote: Hi, The Lucene Connectors Framework committers are voting to rename our project from Lucene Connectors Framework to Apache Connectors Framework, and to cease being a subproject of Lucene. What is the process for doing something like this? Karl - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: an experiment
Gavin McDonald wrote: How about a PMC Chair that does more than turn up once a month at , ooh, day before board reports are due and then disappears for a whole month until , ooh, day before report time. Actually, I read Incubator e-mail pretty much every day. And you still expect to run the whole show your way and jump in with 20+ messages in one day about subjects people have been discussing for days if not weeks before. I'm voicing an opinion, backing it up, and taking the issue to the Board for their input. If I really expected to run the whole show [my] way, I wouldn't make sure that as much as possible is delegated and distributed to the PMC, and I would be much more vocal. Personally, I believe that the Incubator runs smoothly precisely because of that delegation. In the specific case of Joe's experiment, I would have voice my opinion earlier, but was away. Please note that, as an Incubator PMC Member, you were notified of my schedule. And I can't wait for your excuse to be that the sole role of PMC chair is to file reports. No, it isn't. The role of the PMC Chair is to make sure that the project runs smoothly. I was very vocal during the formative days of the Incubator, and speak up when I've something to say. Otherwise, I am quite happy to see others stepping up and staking a role in the Incubator. --- Noel - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: Name change from Lucene Connectors Framework to Apache Connectors Framework
Grant Ingersoll wrote: The Lucene Connectors Framework committers are voting to rename our project from Lucene Connectors Framework to Apache Connectors Framework, and to cease being a subproject of Lucene. What is the process for doing something like this? LCF is not a subproject of Lucene at the moment, since it is in the Incubator. Nothing else project wise would change other than the name at this point. Unless there is an objection, I don't see a problem. Nothing in Apache Connectors Framework smacks of a possible trademark issue. --- Noel - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Radical revamp (was: an experiment)
On Mon, Aug 16, 2010 at 12:45, Justin Erenkrantz jus...@erenkrantz.com wrote: On Mon, Aug 16, 2010 at 9:36 AM, Noel J. Bergman n...@devtech.com wrote: And if the Mentors aren't being active, voting, etc., then *that* is what needs to be addressed. As I've repeatedly stated before (here and elsewhere), in the podlings I've been recently involved with, having three mentors isn't the issue. It's the PMC members who aren't involved sticking their nose in and trying to poison the community. We have one of the largest PMCs in the ASF. If we I view this as potentially the crux of the problem - people who aren't stakeholders in the community shouldn't have a say. Right now, they feel they do. So, if we want to mandate at least 3 mentors - fine, but that must come at the cost of telling the rest of the IPMC to go away - unless they actively contribute to the community and earn merit...of course. -- justin I threw out a radical idea on IRC and a few of us walked through it. At its core, it solves the peanut gallery problem that you're talking about. Consider this: Make the podling a TLP comprised of *only* ASF Members, with at least *three* minimum (preferably more, to deal with idle times). The podling committers are invited onto the priv...@$podling.apache.org mailing list, but have non-binding votes. They are there for private discussion, to offer non-binding votes on committers, and to see how a private mailing is used and how it is NOT used. Since you have (at least) three people on the PMC, you can accomplish all necessary business: releases, adding accounts, and deciding to ask the Board for your graduation. The mailing lists can be in the right place, but can have footers attached noting the incubation status. The $podling.apache.org website should redirect to (say) incubator.apache.org/projects/$podling and have all the standard disclaimers. At graduation, they get the apache.org site and a few redirects are put in place. Releases should also have all the same caveats, warnings, and disclaimers. Graduation could simply be a TLP deciding to add the rest of the committers to its PMC and asking infrastructure to create the website, etc. Or it could require a Board resolution which also mass-adds PMC members. It's kind of unclear how much oversight the Board should have on the graduation (note that the (pseudo) TLP will be filing reports just like any other TLP, so the Board sees its progress). This pattern can be documented by the Incubator or the Community Development project. Doesn't matter, but it would certainly be standardized much like we're standardizing within the Incubator itself. Restrictions like those on websites or releases could be relaxed. It was a fair question to ask, why keep those in place? what are we trying to protect? Using this model decentralizes the process, removes vocal minorities, allows for better tuning of a PMC process to its community, and breaks down the Incubator umbrella project. Finding 3+ Members to be on these mini/pseudo TLPs would be quite difficult. I don't think this kind of process would be available or workable to *all* podlings. But for projects with active Member support, this could be a valid approach (tho what does it say about projects without this kind of active support?). Obviously, we'd also need Board buy-in for the construction of these TLPs (tho, it *is* only comprised of Members). Thoughts? Cheers, -g - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: an experiment
On Mon, Aug 16, 2010 at 13:57, Benson Margulies bimargul...@gmail.com wrote: ... On committers there is a legal / procedural clarification called for. Perhaps I'm just dense, but I got the strong impression from the recent email at members@ that there was much more flexibility possible with committer status than with releases -- that the iPMC could indeed make a one-time, blanket, decision, that PPMC votes were sufficient for committer status. To cite an example to support my position, I'm pretty sure that GSOC students get commit privileges without formal PMC votes. However, if I am dense, and if the foundation requirements do require a real PMC vote for committer access, then the idea of my first paragraph would apply. For reference, any Subversion PMC member can grant (limited) commit status to another individual. We believe that if somebody with long-term involvement in the project (on the PMC) feels that another can do some good work, then they are entitled to make that happen. The new committer can *only* commit into a specific area (like a branch, or a specific directory), so we aren't scared for the project. We can always revert the commits and/or remove commit rights. The commits get reviewed, so we don't feel there are issues around submarine code either. Getting onto the PMC itself is a full vote, however. And those account requests *do* have to come from me, as the VP of Subversion (a rule from root@, tho Joe has said he is relaxing that a bit as long as the private@ list is cc'd). But your point is true: committership is a local, PMC decision. They can apply easy or strict rules. The IPMC could certainly delegate these decisions to the PPMCs. Cheers, -g - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: an experiment
On Mon, Aug 16, 2010 at 16:47, Noel J. Bergman n...@devtech.com wrote: Kevan Miller wrote: IIRC, the issue involved the notion of partial committers in subversion There were objections over the notion of partial committers, not about the individual. shrug There are other instances of such things, such as httpd-docs (IIUC), and I don't see a problem with it where a project feels it makes sense. Our project thought it did make sense, but the busy-bodies and rules pedants got all in our face. Every message that I've seen from you today, Noel, is gee. everything is operating just fine. just like it should. oversight is everything, and we need to do that, so I'm not going to listen to any suggestion of fixing anything or restructuring anything. Every. Message. Your head is in the sand. The Incubator is a broken process. Everybody hates it. Everybody wants to get out of it. Subversion was fortunate in that we had enough support to bully our way through, to route around damage, and to check everything off the list rapidly. Whoever said it before: if we *didn't* have that fortunate fact behind us, then our approach to the ASF would have been very very different. -g - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: an experiment
-Original Message- From: Noel J. Bergman [mailto:n...@devtech.com] Sent: Tuesday, 17 August 2010 9:13 AM To: general@incubator.apache.org Subject: RE: an experiment Gavin McDonald wrote: How about a PMC Chair that does more than turn up once a month at , ooh, day before board reports are due and then disappears for a whole month until , ooh, day before report time. Actually, I read Incubator e-mail pretty much every day. Then why do you store up all your replies until report time? It makes no sense. And you still expect to run the whole show your way and jump in with 20+ messages in one day about subjects people have been discussing for days if not weeks before. I'm voicing an opinion, backing it up, and taking the issue to the Board for their input. If I really expected to run the whole show [my] way, I wouldn't make sure that as much as possible is delegated and distributed to the PMC, and I would be much more vocal. Personally, I believe that the Incubator runs smoothly precisely because of that delegation. In the specific case of Joe's experiment, I would have voice my opinion earlier, but was away. Please note that, as an Incubator PMC Member, you were notified of my schedule. Yes, and if it were just this month then fine, but it's not. Why on earth I notice these things I don't know, maybe it's not important in the grand scheme of things, but I can't help feeling irritated that you turn up once a month with your slew of emails and then think all is great again until the following months reporting period. Oh right, I need to back that up. Let's just only go as far back as January this year. January board meeting was: 20th: you posted on 18th,19th. February board meeting was: 17th: you posted on 15th,16th,24th. March board meeting was: 17th: you posted on 16th. April board meeting was: 21st: you posted on 20th,21st. May board meeting was: 19th: you posted on 18th. June board meeting was: 16th: you posted on 15th,18th. July board meeting was: 21st: you posted on 19th,22nd. Note that these dates are as I received them my TZ (GMT+9) but you get the idea. I see a pattern. And I can't wait for your excuse to be that the sole role of PMC chair is to file reports. No, it isn't. The role of the PMC Chair is to make sure that the project runs smoothly. I was very vocal during the formative days of the Incubator, and speak up when I've something to say. Otherwise, I am quite happy to see others stepping up and staking a role in the Incubator. Ok, if you see all is well then fine, but can you not just at least look like you are a bit more interested other than just at reporting time? another example, you just posted a whole months worth at members requesting to join the Incubator PMC and Greg just acked the lot -- is this something that only you as Incubator PMC chair can do or can any member send off this ack request to the board? If it makes things easier I'd be glad to help. Gav... --- Noel - 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: an experiment
On 17/08/2010 02:05, Greg Stein wrote: On Mon, Aug 16, 2010 at 16:47, Noel J. Bergmann...@devtech.com wrote: ... Your head is in the sand. The Incubator is a broken process. Everybody hates it. Everybody wants to get out of it. Subversion was fortunate in that we had enough support to bully our way through, to route around damage, and to check everything off the list rapidly. Whoever said it before: if we *didn't* have that fortunate fact behind us, then our approach to the ASF would have been very very different. I have to agree. I am currently working with a very large project that is interested in coming into the incubator. There are two major issues for me to address: One is getting the lawyers from the originating company to agree to the legal sign-off - nothing new there. The other is getting the project through the incubator in a reasonable time so that its large number of users don't get the jitters and switch to an alternative platform. The project genuinely tries to operate in an ASF like manner but has some inherent problems that are rooted in the fact that 75%+ of committers all being part of a single company and all lacking experience of ASF style development models. Consequently, some working practices will need to be changed, but the committers are aware of the changes required and willing to do the work. Unlike Subversion there are no pre-existing members on the commit list and thus noone to shelter the project team from the peanut gallery here in gene...@. I've already decided that I'm going to have to recruit a number of key mentors to help me protect the project during incubation. For some reason that never occurred to me as being kind of anti-apache. Aren't we a flat organisation? It really shouldn't matter who the mentors are as long as they are members, yet I had subconsciously decided that it did matter. For this reason I have to agree that the Incubator process is not coping well with the large numbers of interested bystanders we have on the IPMC. Oversight is good, but we don't need the oversight of the peanut gallery. Kudos to those trying to solve this problem without completely breaking up an otherwise healthy incubation process. Ross - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: an experiment
Greg Stein wrote: Noel J. Bergman n...@devtech.com wrote: shrug There are other instances of such things, such as httpd-docs (IIUC), and I don't see a problem with it where a project feels it makes sense. Our project thought it did make sense Fine, and I'd agree with you. but the busy-bodies and rules pedants got all in our face. I read that thread, and as I commented on private@, I thought that it could have been handled better. Every message that I've seen from you today, Noel, is gee. everything is operating just fine. just like it should. oversight is everything, and we need to do that, so I'm not going to listen to any suggestion of fixing anything or restructuring anything. Then you need to re-read them. Did you miss the several points where I said that if someone isn't participating in a given project then unless they have one of a few issues of substance they should either actively become part of the community or butt out? And did you miss my request to the Board for their input on the issue of whether or not the PMC has to vote on new Committers? Claiming that I'm not listening or open is, frankly, insulting. The Incubator is a broken process. Everybody hates it. Everybody wants to get out of it. That is not the message that we get from most participants, but if that is the case, then let's fix it. Subversion was fortunate in that we had enough support to bully our way through, to route around damage Such as? Let's be concrete and constructive, identify the specific problems and address them. --- Noel - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: an experiment
On Mon, Aug 16, 2010 at 21:30, Noel J. Bergman n...@devtech.com wrote: Greg Stein wrote: ... but the busy-bodies and rules pedants got all in our face. I read that thread, and as I commented on private@, I thought that it could have been handled better. I certainly could have handled it better. But that thread is *indicative* of the problem. We've pointed out a several now: two with Subversion, one with OODT. If that isn't enough for you, then you need to wake up to the pattern. Every message that I've seen from you today, Noel, is gee. everything is operating just fine. just like it should. oversight is everything, and we need to do that, so I'm not going to listen to any suggestion of fixing anything or restructuring anything. Then you need to re-read them. Did you miss the several points where I said that if someone isn't participating in a given project then unless they have one of a few issues of substance they should either actively become part of the community or butt out? Say it all you want, but that isn't how people operate here. Simple fact. If you want to fix it, then *DO* something rather than speak about it. And did you miss my request to the Board for their input on the issue of whether or not the PMC has to vote on new Committers? Claiming that I'm not listening or open is, frankly, insulting. I saw that, and I saw Joe's request that you mischaracterized him, and then you brushed him off. Oh yes, I *am* tracking all this. Very closely. The Incubator is a broken process. Everybody hates it. Everybody wants to get out of it. That is not the message that we get from most participants, but if that is the case, then let's fix it. Who is we?? I'm part of the IPMC, so I'm part of that we. Most of the feedback that I ever hear is not supportive. Might be interesting to run a poll. Get some real numbers. Have you been through Incubation? Was it a positive experience? Subversion was fortunate in that we had enough support to bully our way through, to route around damage Such as? Let's be concrete and constructive, identify the specific problems and address them. I've already told you. Disinterested third parties touting rules and patterns that were NOT part of the Apache Way, but were most definitely anti-Subversion-community. Certainly they had some *commonality* around Apache projects, but were in no way a required part of a collaborative, community-driven development process. They were just different, so these third parties got in our face. Because they *could*. The Incubator supports the concept of random drive-bys from disinterested third parties. -g - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: an experiment
On 08/16/2010 07:30 PM, Noel J. Bergman wrote: That is not the message that we get from most participants, but if that is the case, then let's fix it. As I mentioned in a previous post, the main problem we (ATS) had was to get enough binding votes. Even from the IPMC we failed one release vote due to lack of votes (there were no -1's, just not enough +1's), and several times did I have to beg to get votes for a committer addition (all our committer votes had to be voted on in the IPMC, to get binding votes). We were however extremely fortunate to have the active support of several Apache old-timers, who stepped up and helped us push through the process, and they were a huge reason why we could graduate as quickly as we did. That other thing that surprised me was that there was no exit review process out of incubation. Meaning, I would have expected each graduating project to provide some sort of feedback or evaluation to the IPMC, to help improve the incubation process incrementally. Yes, I know we can all just post to general@ (or private@), but it seems that having a more official exist review of the project and its incubation experience would be helpful. This would give feedback to the IPMC (Sponsor), as well as Mentors and Champion, about what worked, and what didn't. -- Leif - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: Radical revamp (was: an experiment)
Greg Stein wrote: Justin Erenkrantz wrote: I view this as potentially the crux of the problem - people who aren't stakeholders in the community shouldn't have a say. Right now, they feel they do. So, if we want to mandate at least 3 mentors - fine, but that must come at the cost of telling the rest of the IPMC to go away - unless they actively contribute to the community and earn merit...of course. Consider this: Make the podling a TLP comprised of *only* ASF Members, with at least *three* minimum (preferably more, to deal with idle times). The podling committers are invited onto the priv...@$podling.apache.org mailing list, but have non-binding votes. They are there for private discussion, to offer non-binding votes on committers, and to see how a private mailing is used and how it is NOT used. How does that differ from the current system (given the assumption of 3+ PMC Members), except that it precludes potential oversight from others -- the flipside of solves the peanut gallery problem that apparently plagued Subversion? Since you have (at least) three people on the PMC, you can accomplish all necessary business: releases, adding accounts, and deciding to ask the Board for your graduation. Yes. You can do that today, too, with 3+ PMC Members. The mailing lists can be in the right place, but can have footers attached noting the incubation status. The $podling.apache.org website should redirect to (say) incubator.apache.org/projects/$podling and have all the standard disclaimers. At graduation, they get the apache.org site and a few redirects are put in place. Releases should also have all the same caveats, warnings, and disclaimers. We could do that now, except that people have previously disliked the idea of $podling.apache.org being provided prior to graduation, for either e-mail or web site addresses. If the consensus is to change that, fine. Graduation could simply be a TLP deciding to add the rest of the committers to its PMC and asking infrastructure to create the website, etc. Or it could require a Board resolution which also mass-adds PMC members. It's kind of unclear how much oversight the Board should have on the graduation (note that the (pseudo) TLP will be filing reports just like any other TLP, so the Board sees its progress). Please clarify. Wouldn't the Board have to establish this TLP pre-Incubation, what *are* the graduation metrics, and who votes on graduation? Restrictions like those on websites or releases could be relaxed. It was a fair question to ask, why keep those in place? what are we trying to protect? Why relax them uniquely for such projects? And presumably we are protecting the ASF brand, as well as downstream consumers who rely on our output, including clean licensing, etc. But getting back to the first point, is there some rationale to relax them for these podlings and not for others? If we can justify them for some, should we re-examine them in general? Using this model decentralizes the process So does having 3+ PMC Members today. removes vocal minorities True. The flipside is that it also removes additional oversight. Remember that the Board created the Incubator because of problems with existing projects trying incubation on their own. But we have learned a lot since then. allows for better tuning of a PMC process to its community, and breaks down the Incubator umbrella project. Possibly so, which would be good things. Finding 3+ Members to be on these mini/pseudo TLPs would be quite difficult. I don't think this kind of process would be available or workable to *all* podlings. But for projects with active Member support, this could be a valid approach Thoughts? I think that it is a very interesting proposal, that could work very well in specific circumstances, and I'd be willing to see it tried as an experiment, if the Board buys into it. Do we have any such projects pending or already in the Incubator? --- Noel - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Radical revamp
On 17/08/2010 03:00, Noel J. Bergman wrote: I think that it is a very interesting proposal, that could work very well in specific circumstances, and I'd be willing to see it tried as an experiment, if the Board buys into it. Do we have any such projects pending or already in the Incubator? I'd be up for trying this, or whatever the board and IPMC approve, with the project I mentioned in the other thread. Problem there is that we don't know how long the legal stuff will be in progress or that the proposal will even be accepted. Anything from a couple of weeks to a few months would be my guess at this point. Ross - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Radical revamp (was: an experiment)
On Mon, Aug 16, 2010 at 22:00, Noel J. Bergman n...@devtech.com wrote: Greg Stein wrote: ... Make the podling a TLP comprised of *only* ASF Members, with at least *three* minimum (preferably more, to deal with idle times). The podling committers are invited onto the priv...@$podling.apache.org mailing list, but have non-binding votes. They are there for private discussion, to offer non-binding votes on committers, and to see how a private mailing is used and how it is NOT used. How does that differ from the current system (given the assumption of 3+ PMC Members), except that it precludes potential oversight from others -- the flipside of solves the peanut gallery problem that apparently plagued Subversion? Presumably 3+ ASF Members is sufficient oversight. Given these Members are the ONLY PMC members, then they must also remain pretty active in their podling which implies oversight. oversight from others is NOT a goal, when you have 3+ PMC members already. My proposal ups that from 3+ PMC members to 3+ ASF Members, which (IMO) is a stronger guarantee. (tho, for the most part, IPMC members *are* ASF Members, but Joe's recent suggestions (which are good!) would alter that balance) And do not minimize the peanut gallery problem. That is a very real issue, and the flipside as you suggest is not a necessary part of the process. Since you have (at least) three people on the PMC, you can accomplish all necessary business: releases, adding accounts, and deciding to ask the Board for your graduation. Yes. You can do that today, too, with 3+ PMC Members. Empirically speaking... no, you cannot. The peanut gallery gets in the way. The mailing lists can be in the right place, but can have footers attached noting the incubation status. The $podling.apache.org website should redirect to (say) incubator.apache.org/projects/$podling and have all the standard disclaimers. At graduation, they get the apache.org site and a few redirects are put in place. Releases should also have all the same caveats, warnings, and disclaimers. We could do that now, except that people have previously disliked the idea of $podling.apache.org being provided prior to graduation, for either e-mail or web site addresses. If the consensus is to change that, fine. I'm not asking for consensus. I'm proposing a whole new approach. And this particular approach minimizes the external effects of graduation: no mailing list renames, no subversion moves, no reporting moves, etc. Graduation could simply be a TLP deciding to add the rest of the committers to its PMC and asking infrastructure to create the website, etc. Or it could require a Board resolution which also mass-adds PMC members. It's kind of unclear how much oversight the Board should have on the graduation (note that the (pseudo) TLP will be filing reports just like any other TLP, so the Board sees its progress). Please clarify. Wouldn't the Board have to establish this TLP pre-Incubation, Yes. Thus, my point that the Board is going to have to weigh in on this topic at some point. But it needs some rounds of support and beat-downs here on general@ before it is in a reasonable proposal state for the Board. We also need some podlings who would like to volunteer for this new approach, for the Board to consider. what *are* the graduation metrics, and who votes on graduation? Dunno. I raised that in my original email. I suspect that the metrics would be defined by the Incubator: basically the checklist of considerations already present. Regarding the vote: as I mentioned: the PMC comprised of the ASF Members. It is possible that the PMC might add some non-Members over time (like a regular PMC can and does), but I'm not very supportive of this for projects in a *podling* state. I'd rather all those people are added to the PMC at graduation time. There could be two ways to graduate: 1) the PMC self-graduates 2) the PMC proposes graduation to the Board I prefer the latter, as a final checkup/signoff to the process. The PMC would need to arrive with $materials demonstrating satisfactory completion of all incubation requirements. Note: if *all* podlings move to this process, then the Incubator would reduce to docs rather than oversight; which could imply a merge into ComDev. But as I mentioned: I'm not sure the Members requirement is a bar that most podlings can reach, so the Incubator is not going anywhere, any time soon. Restrictions like those on websites or releases could be relaxed. It was a fair question to ask, why keep those in place? what are we trying to protect? Why relax them uniquely for such projects? And presumably we are protecting Dunno. The question was raised, and it is a good question for discussion. What *are* we attempting to protect by limiting releases from podlings? Does that hold in this scenario? Are there other modifications to the restrictions that can occur for these TLP-podlings? etc. A discussion points,
RE: an experiment
Greg Stein wrote: I read that thread, and as I commented on private@, I thought that it could have been handled better. I certainly could have handled it better. I didn't mean by YOU. See my reply on private@ before jumping to that conclusion. But that thread is *indicative* of the problem. We've pointed out a several now: two with Subversion, one with OODT. OK. So let's address it. Did you miss the several points where I said that if someone isn't participating in a given project then unless they have one of a few issues of substance they should either actively become part of the community or butt out? Say it all you want, but that isn't how people operate here. Simple fact. If you want to fix it, then *DO* something rather than speak about it. Fine. What would you suggest? And that includes your proposal, which I do consider interesting. But consider, too, Leif's issue that their biggest problem was the opposite: *getting* the 3 necessary votes. So lets resolve this in a more general fashion than TLP level partitioning. And did you miss my request to the Board for their input on the issue of whether or not the PMC has to vote on new Committers? Claiming that I'm not listening or open is, frankly, insulting. I saw that, and I saw Joe's request that you mischaracterized him, and then you brushed him off. I didn't brush Joe off. I went back at the same time and replied on this list in the related thread, which is where the actual details had been posted, rather than in the abstract on bo...@. See my reply to CLR for details. The Incubator is a broken process. Everybody hates it. Everybody wants to get out of it. That is not the message that we get from most participants, but if that is the case, then let's fix it. Who is we?? I'm part of the IPMC, so I'm part of that we. Most of the feedback that I ever hear is not supportive. We is the PMC as a whole, general@, priv...@. But, sure, let's follow through on your suggestion and run a poll. Lets find out if things are going well, what the problems are, how widespread or isolated they are, and make the effort to resolve them. As I said ... Let's be concrete and constructive, identify the specific problems and address them. I've already told you. Disinterested third parties touting rules and patterns that were NOT part of the Apache Way, but were most definitely anti-Subversion-community. Certainly they had some *commonality* around Apache projects, but were in no way a required part of a collaborative, community-driven development process. They were just different The Incubator supports the concept of random drive-bys from disinterested third parties. A bit harsh to call them disinterested. :-) OK, to be clear, what I'm reading from you, Justin and others, is that this is *the* problem you want to resolve. --- Noel - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: Radical revamp
Ross Gardler wrote: Noel J. Bergman wrote: I think that it is a very interesting proposal, that could work very well in specific circumstances, and I'd be willing to see it tried as an experiment, if the Board buys into it. Do we have any such projects pending or already in the Incubator? I'd be up for trying this, or whatever the board and IPMC approve, with the project I mentioned in the other thread. You also wrote: Unlike Subversion there are no pre-existing members on the commit list and thus noone to shelter the project team from the peanut gallery here in gene...@. We need to deal with the negative aspects of the peanut gallery issue, but we also need to provide oversight and positive, beneficial, guidance. As you say, unlike Subversion, this project doesn't have any existing ASF folks, which means that it likely needs more community work. In addition to Greg's structural partitioning, perhaps we need to work on Incubation Etiquette, and get people to voluntarily stop doing drive-bys? --- Noel - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Radical revamp (was: an experiment)
- Original Message From: Noel J. Bergman n...@devtech.com To: general@incubator.apache.org Sent: Mon, August 16, 2010 10:00:40 PM Subject: RE: Radical revamp (was: an experiment) Greg Stein wrote: Using this model decentralizes the process So does having 3+ PMC Members today. To me this is a common flaw in both how the IPMC operates today and how Greg's proposal relies on 3 Members to get anything accomplished. If you've been paying attention to what actually happens in this PMC over time, you can't possibly have missed all the begging for votes that goes on. Reliance on 3 overworked people who are typically not podling committers to always be there when the project needs them is both unrealistic and doesn't scale. We've been doing it for years, inflicting massive pain on the podlings whenever they release or want new committers, and it sucks. That's what my experiment aims to fix. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Radical revamp
On Mon, Aug 16, 2010 at 22:07, Ross Gardler rgard...@apache.org wrote: On 17/08/2010 03:00, Noel J. Bergman wrote: I think that it is a very interesting proposal, that could work very well in specific circumstances, and I'd be willing to see it tried as an experiment, if the Board buys into it. Do we have any such projects pending or already in the Incubator? I'd be up for trying this, or whatever the board and IPMC approve, with the project I mentioned in the other thread. Problem there is that we don't know how long the legal stuff will be in progress or that the proposal will even be accepted. Anything from a couple of weeks to a few months would be my guess at this point. This raises some interesting points to refine my blue-sky proposal. First, the IPMC wouldn't be approving the project's incubation. It would be the Board setting up the TLP to hold the podling. I'm not sure how many proposals a month we get at the Incubator... 2 per month? I think the Board could handle that, but ... with all that said, it may still want to delegate an initial discussion/evaluation to the Incubator PMC first to weed out noise and refine the proposal. Then again, given the 3+ Member bar that must be reached... there won't be many arriving at the ASF with that kind of built-in backing. This alternate approach will only be available to a subset, I believe. If the stuff sits in legal review for a while, then no big deal. The Board can still construct an (empty) TLP that will manage the receipt and review of the software grant. If the originators bail out, then the TLP just gets shut down. I certainly don't see a big issue here. Cheers, -g - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: an experiment
On Mon, Aug 16, 2010 at 22:29, Noel J. Bergman n...@devtech.com wrote: Greg Stein wrote: I read that thread, and as I commented on private@, I thought that it could have been handled better. I certainly could have handled it better. I didn't mean by YOU. See my reply on private@ before jumping to that conclusion. Well aware of that, but it doesn't make my statement any less true :-P Cheers, -g - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Radical revamp (was: an experiment)
Hey Guys, I suspect the OODT guys might want to try this (it has four ASF Members as Mentors who could comprise the PMC). Subversion would have done this, based on my own thoughts/experiences and knowledge of what the ASF needs/wants. +1 from me with my OODT hat on. Also, I like Greg's proposal b/c it puts the onus on those (proposed) $podling.apache.org PMC members who are active, without external peanut gallery oversight. 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.mattm...@jpl.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: Radical revamp (was: an experiment)
On Mon, Aug 16, 2010 at 22:31, Joe Schaefer joe_schae...@yahoo.com wrote: - Original Message From: Noel J. Bergman n...@devtech.com To: general@incubator.apache.org Sent: Mon, August 16, 2010 10:00:40 PM Subject: RE: Radical revamp (was: an experiment) Greg Stein wrote: Using this model decentralizes the process So does having 3+ PMC Members today. To me this is a common flaw in both how the IPMC operates today and how Greg's proposal relies on 3 Members to get anything accomplished. If you've been paying attention to what actually happens in this PMC over time, you can't possibly have missed all the begging for votes that goes on. Reliance on 3 overworked people who are typically not podling committers to always be there when the project needs them is both unrealistic and doesn't scale. We've been doing it for years, inflicting massive pain on the podlings whenever they release or want new committers, and it sucks. That's what my experiment aims to fix. I hear you, and I think that *if* you have 3+ *active* ASF Members, then my approach will dramatically improve the process. Also, those Members in the hot seat are going to be more active because they *know* they're on the hook. There is nobody to pass the buck to. They are part of the reports to the Board (One of our PMC Members, John Doe, has been absent.). If a project has the support, then this gets the second-guessing of the IPMC and the second-level of unnecessary oversight out of the way. It directly introduces the project to its future place within the organization. Cheers, -g - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: an experiment
On Mon, Aug 16, 2010 at 6:05 PM, Greg Stein gst...@gmail.com wrote: Your head is in the sand. The Incubator is a broken process. Everybody hates it. Everybody wants to get out of it. Subversion was fortunate in that we had enough support to bully our way through, to route around damage, and to check everything off the list rapidly. Whoever said it before: if we *didn't* have that fortunate fact behind us, then our approach to the ASF would have been very very different. Perhaps it's useful to have some other experiences heard from those who are currently going through the incubation process. Apache Shiro is on the verge of graduation (voting going on right now), I'm a new member of Apache (i.e. not one of the people in the original project proposal) and I don't see much wrong in the current process. We have a small PPMC and there have been a few cases where we've needed to prod the interest of the mentors to gain enough votes but I don't think there's anything broken in that. For the more important votes, we've gotten some -1s from some Apache members we've never heard of before, but negatives need to be and are justified and are typically given for reasons we as new members had missed or hadn't considered at all. I recognize there's a lot of history before our project so I for would give a benefit of doubt for any random drive-bys from disinterested third parties :) I mean, after all, the incubator process is about teaching the Apache way and whatever it is, it's probably not about changing the process to your liking. If I have to beg for a few +1s or reason my way out of -1s, I'll be happy to do that, and hopefully demonstrate our willingness and ability to self govern along way. Kalle - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Radical revamp (was: an experiment)
It's optimized for success while making mentors potentially responsible for failure (iow a project with crappy mentors will fail no matter how much they grok apache). Still have doubts about escalating the graduation decision to the board. Sent from my iPhone On Aug 16, 2010, at 10:46 PM, Greg Stein gst...@gmail.com wrote: On Mon, Aug 16, 2010 at 22:31, Joe Schaefer joe_schae...@yahoo.com wrote: - Original Message From: Noel J. Bergman n...@devtech.com To: general@incubator.apache.org Sent: Mon, August 16, 2010 10:00:40 PM Subject: RE: Radical revamp (was: an experiment) Greg Stein wrote: Using this model decentralizes the process So does having 3+ PMC Members today. To me this is a common flaw in both how the IPMC operates today and how Greg's proposal relies on 3 Members to get anything accomplished. If you've been paying attention to what actually happens in this PMC over time, you can't possibly have missed all the begging for votes that goes on. Reliance on 3 overworked people who are typically not podling committers to always be there when the project needs them is both unrealistic and doesn't scale. We've been doing it for years, inflicting massive pain on the podlings whenever they release or want new committers, and it sucks. That's what my experiment aims to fix. I hear you, and I think that *if* you have 3+ *active* ASF Members, then my approach will dramatically improve the process. Also, those Members in the hot seat are going to be more active because they *know* they're on the hook. There is nobody to pass the buck to. They are part of the reports to the Board (One of our PMC Members, John Doe, has been absent.). If a project has the support, then this gets the second-guessing of the IPMC and the second-level of unnecessary oversight out of the way. It directly introduces the project to its future place within the organization. Cheers, -g - 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: Radical revamp (was: an experiment)
Greg Stein wrote: Noel J. Bergman wrote: Greg Stein wrote: Make the podling a TLP comprised of *only* ASF Members, with at least *three* minimum (preferably more, to deal with idle times). How does that differ from the current system (given the assumption of 3+ PMC Members), except that it precludes potential oversight from others -- the flipside of solves the peanut gallery problem that apparently plagued Subversion? Presumably 3+ ASF Members is sufficient oversight. Given these Members are the ONLY PMC members, then they must also remain pretty active in their podling which implies oversight. Well, that has been an issue with many podlings so far. Subversion is an exception, not the rule, although I don't know that we've got a handle on the ratio of projects for which getting 3 binding votes isn't an issue. My proposal ups that from 3+ PMC members to 3+ ASF Members, which (IMO) is a stronger guarantee. Greg, *the* most common problem has been IP and release related. RAT has fixed a lot of it, but ASF Members were not even remotely immune to the problem. Without RAT, I suspect we'd still be mired in the muck, and needing as many eyes as we've had. And do not minimize the peanut gallery problem. That is a very real issue I'd really like to know how widespread it is, other than that it bit a burr under the saddle of some ASF Members on a few projects. And I'm still not minimizing its impact on even a single project, just wondering about prevalence. Empirically speaking... no, you cannot. The peanut gallery gets in the way. Let's agree to resolve the peanut gallery issue, and move on to see if there are any other issues. We could do that now, except that people have previously disliked the idea of $podling.apache.org being provided prior to graduation, for either e-mail or web site addresses. If the consensus is to change that, fine. I'm not asking for consensus. I'm proposing a whole new approach. Yes, but we still need to find out of the Board will agree to providing $X.apache.org resources, and branding, for provisional projects. Yes. Thus, my point that the Board is going to have to weigh in on this topic at some point. But it needs some rounds of support and beat-downs here on general@ before it is in a reasonable proposal state for the Board. We also need some podlings who would like to volunteer for this new approach, for the Board to consider. Well, if it isn't clear, I'm not trying to tear this down on you, and if OODT wants to give it a go, I'd support the experiment. But don't we first need to address ... what *are* the graduation metrics, and who votes on graduation? I suspect that the metrics would be defined by the Incubator: basically the checklist of considerations already present. There could be two ways to graduate: 1) the PMC self-graduates 2) the PMC proposes graduation to the Board I prefer the latter, as a final checkup/signoff to the process. The PMC would need to arrive with $materials demonstrating satisfactory completion of all incubation requirements. Is there any role for the Incubator, or is it strictly between the podling and the Board for this class of podling? Restrictions like those on websites or releases could be relaxed. It was a fair question to ask, why keep those in place? what are we trying to protect? Why relax them uniquely for such projects? And presumably we are protecting the ASF brand, as well as downstream consumers who rely on our output, including clean licensing, etc. But getting back to the first point, is there some rationale to relax them for these podlings and not for others? If we can justify them for some, should we re-examine them in general? Yup, good questions all. It was a fair point raised on IRC that I'm bringing here. Fair enough. :-) Using this model decentralizes the process So does having 3+ PMC Members today. The IPMC is anything but decentralized. And empirical evidence shows it to peanut-gallery-ism. Empirical evidence also shows that we rarely hear from most projects except when they need binding votes or put in a report. Again, I agree with your idea of polling the community. Remember that the Board created the Incubator because of problems with existing projects trying incubation on their own. But we have learned a lot since then. Yups. The Incubator has provided a lot of focus on what we need, what kinds of problems arise, and what we don't need. I maintain that additional oversight is not required given the composition of these TLPs membership (all ASF Members). I may agree with you now, given RAT. As I've noted before, ASF Members have not been immune to release issues. And hopefully we won't come back to realize that not all ASF Members aren't good at project building. Not every ASF Member is you, Justin, Roy, Bertrand, Jukka, etc. I'm not even sure that most are. Reference Justin's point about the Subversion PMC not recognizing
Re: Radical revamp (was: an experiment)
On Mon, Aug 16, 2010 at 22:53, Joe Schaefer joe_schae...@yahoo.com wrote: It's optimized for success while making mentors potentially responsible for failure (iow a project with crappy mentors will fail no matter how much they grok apache). Fair assessment, but those *are* the projects that I'm looking at. Those which have large enough Member support, can be fully self-supported. But you raise a larger question: if a project has crappy mentors, then how do we solve *that* problem? (new thread, please!) Still have doubts about escalating the graduation decision to the board. Me too. I certainly believe that we can figure that out as we go. We don't have to hold up a new TLP-based podling based on solving the graduation answer today. Presumably, there would be a few months to explore. And certainly when the project *feels* it is ready, then the discussion will begin in earnest. Cheers, -g - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Radical revamp (was: an experiment)
On Mon, Aug 16, 2010 at 7:41 PM, Mattmann, Chris A (388J) chris.a.mattm...@jpl.nasa.gov wrote: Hey Guys, I suspect the OODT guys might want to try this (it has four ASF Members as Mentors who could comprise the PMC). Subversion would have done this, based on my own thoughts/experiences and knowledge of what the ASF needs/wants. +1 from me with my OODT hat on. Also, I like Greg's proposal b/c it puts the onus on those (proposed) $podling.apache.org PMC members who are active, without external peanut gallery oversight. Generally speaking, I'm supportive of trying different things to break through the logjam that we currently have within the Incubator. However, I think we should probably have a discussion on the OODT list as we should think through what this means and how it'd affect the nascent community. With Subversion, it already had a very vibrant, diverse, and self-governing community - OODT isn't quite there so there's a bit of a risk there. Perhaps this will act as a prod to promote the self-governance - which is ideally what we want anyway. At the moment, I probably don't have the time necessary to sit down and lead the conversation within OODT. That alone does give me a bit of a reservation about what exactly we're signing up for. =) -- justin - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: an experiment
On Mon, Aug 16, 2010 at 6:26 PM, Ross Gardler rgard...@apache.org wrote: I've already decided that I'm going to have to recruit a number of key mentors to help me protect the project during incubation. Historically, I think there are two classes of podlings: - one which has a self-governing community and just needs to get indoctrinated in the Apache Way (SpamAssassin, Subversion, etc.) - one which doesn't have a self-governing community (thrift, traffic server, etc.) Perhaps Greg is on to something with having us split up the process. It's always bugged me that there were two different classes that we tried to shoehorn into one process. Accordingly, in these two models, the role of the mentor is very different: - self-governing community: making sure they get introduced to the right people and understand the minimum requirements; but, really, they shouldn't interfere with the actual day-to-day governance. - no self-governing community: helping the developers understand what it means to self-govern. For an existing self-governing case, I would ideally like it so that the mentors were purely advisory - the ultimate responsibility lies with the community - as it must, or we're teaching them the wrong things. I don't know (or really care) how that reconciles with any corporate structures - but I'm sure we can certainly get creative in solving this. In Subversion, the mentors we had were already full committers and had earned their merit within the community. So, when Greg, Dan, Sander, or I said something, the rest of the community knew we weren't crackpots. Based on Ross's description of the community, it doesn't sound like there's enough coverage to get a 3 member minimum - but, the very fact that a community can decide to come to Apache is itself a form of self-governance. So...it's a touch circular, but I go back to thinking that a purely advisory role is right for any mentors coming in when there's self-governance already existing. Considering Thrift's situation in trying to bootstrap their self-governance, I can totally see why Joe likes that particular tweak and why that might be sufficient for their case. I don't have any clear answers, but, I'd really like to continue exploring where this thought takes us as I think there's a solution here that can ease the pain somewhat. -- justin - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] OODT Podling Incubator Experiment (was Re: Radical revamp (was: an experiment))
[ CCing gene...@incubator as I think I can now place my finger a bit as to why I'm discomforted with Greg's proposal in the OODT context ; and more importantly, another potential experiment at the end; leaving context in for those on gene...@incubator ] On Mon, Aug 16, 2010 at 9:21 PM, Mattmann, Chris A (388J) chris.a.mattm...@jpl.nasa.gov wrote: (moving to oodt-...@incubator.a.o, context coming in separate email FWD) Hey Justin, +1 from me with my OODT hat on. Also, I like Greg's proposal b/c it puts the onus on those (proposed) $podling.apache.org PMC members who are active, without external peanut gallery oversight. However, I think we should probably have a discussion on the OODT list as we should think through what this means and how it'd affect the nascent community. With Subversion, it already had a very vibrant, diverse, and self-governing community - OODT isn't quite there so there's a bit of a risk there. Perhaps this will act as a prod to promote the self-governance - which is ideally what we want anyway. +1 At the moment, I probably don't have the time necessary to sit down and lead the conversation within OODT. That alone does give me a bit of a reservation about what exactly we're signing up for. =) -- To me, all we are signing up for with Greg's proposal is basically to have something like: 1. oodt.apache.org exists today 2. Ian, Chris, Justin and Jean Frederic are OODT PMC members + committers 3. OODT committers continue as-is 5. There is no more IPMC oversight 5. VOTEs on releases are approved by 3 +1s of OODT PMC members - OODT committers weigh in on releases and their weigh in is taken into consideration by OODT PMC members (as is done today even with PPMC and IPMC) 6. VOTEs on new committers are approved by 3 +1s of OODT PMC members - OODT committers weigh in on new committers and their weigh in is taken into consideration by OODT PMC members (as is done today even with PPMC and IPMC) 7. When we're ready (we can even keep the same Incubator checklist), we put up a board resolution to graduate into *true* oodt.apache.org TLP. To me, ready = - we've made at least 1 release (we're close!) - we've VOTE'd in a couple new committers (keep those patches coming people!) hopefully with some diversity in mind, but if we don't get there, and the committers are still vibrant and healthy, then we move forward. OODT already has a pretty vast user community and healthy community that I'm slowing working to get signed up over here in the Incubator. We've had contributions from folks from Children's Hospital (thanks guys!), interest from other NASA centers (welcome Mark and others!), and some new folks from JPL stepping up and earning merit (welcome Cameron, and thanks for popping up Rishi!). Is that your take too? Yes, I think that roughly outlines what Greg proposed. See, here's where I get a bit discomforted by this entire process: I honestly don't feel that I deserve a vote on OODT releases. I've known you and Dave for long enough that I have no concerns advising the OODT community and trying to help out - but...giving me a binding vote? I want to encourage a process where the people doing the work get to have the power. At the core, that is what Apache is about - and having doofus's like me casting a vote for a release seems like straying from that. I'm *totally* fine turning on cranky mode and keeping the peanut gallery away so ya'll on oodt-dev@ get real work done. For Subversion, I was already a full committer and earned my merit. So, I had zero qualms about giving my $.02 there whether they wanted it or not. =) Given your (Chris) experience with other ASF projects (and, heck, being a PMC Chair), I can see exactly how the Subversion analogy (in my head) applies to you. You're a member, you know how things work, you have merit within OODT - so, yah, perfect sense. Smucks like me who get confuzzled reading Maven build scripts? Nah, not right that I should have a binding vote. Now, could we say that I would act as a certifier/observer that all of the major processes were followed? Heck yah. No qualms there. Here's an analogy I'm coming around to: in a lot of new democracies, there are observers who are sent in to monitor elections. They witness the elections, poke around, and make sure nothing unseemly is going on. They don't vote, but they do observe. They then issue a certification or report to be filed with the vote. (I'm catching up on my backlog of issues of The Economist; just read their article about nascent democracies in Africa on the plane...) Hmm, maybe there's something to this observer model as this reconciles my qualms and could provide the basis for an oversight model. Does this analogy move the needle for anyone else? Could a combination of mentor and observer be sufficient? I think so... -- justin - To unsubscribe, e-mail:
Re: [DISCUSS] OODT Podling Incubator Experiment (was Re: Radical revamp (was: an experiment))
Hey Justin, Thanks so much for your thoughtful reply. My comments below: See, here's where I get a bit discomforted by this entire process: I honestly don't feel that I deserve a vote on OODT releases. I've known you and Dave for long enough that I have no concerns advising the OODT community and trying to help out - but...giving me a binding vote? I want to encourage a process where the people doing the work get to have the power. At the core, that is what Apache is about - and having doofus's like me casting a vote for a release seems like straying from that. I'm *totally* fine turning on cranky mode and keeping the peanut gallery away so ya'll on oodt-dev@ get real work done. So basically you are moving more towards Joe's proposal, that the PPMC would have the binding VOTEs in e.g., new committers/PMC members, and on releases? Of course, with the caveats below, as you mention, i.e., the observers can observe and step in where necessary, but ultimately, they're there to ensure things are going great, and not to get in the way, unless they aren't? +1 to that. Given your (Chris) experience with other ASF projects (and, heck, being a PMC Chair), I can see exactly how the Subversion analogy (in my head) applies to you. You're a member, you know how things work, you have merit within OODT - so, yah, perfect sense. Smucks like me who get confuzzled reading Maven build scripts? Nah, not right that I should have a binding vote. No way you'd ever be a smuck in my book. And don't worry I'll get you on the Maven bandwagon! ^_^ Now, could we say that I would act as a certifier/observer that all of the major processes were followed? Heck yah. No qualms there. Here's an analogy I'm coming around to: in a lot of new democracies, there are observers who are sent in to monitor elections. They witness the elections, poke around, and make sure nothing unseemly is going on. They don't vote, but they do observe. They then issue a certification or report to be filed with the vote. (I'm catching up on my backlog of issues of The Economist; just read their article about nascent democracies in Africa on the plane...) +1. So our OODT observers would be: You, Jean Frederic, Ross, Ian, and me? PPMC stays the same, but they are given: * binding release/committer VOTEs In this case, observers are just really the mentors, and we move towards the mentors ensuring all is going well (which they should do now anyways), but IPMC ratification isn't required, and PPMC gets to self-govern. +1 from me on that, I think that's the right thing to teach, and with mentors that pay attention, I think we'll be great. I've heard a lot of talk in not just this thread, but over the past day about podlings with mentors that aren't active. Well, if the mentors aren't active, then they shouldn't be a mentor and we should make room for those that have the cycles and that are ready to observe. Hmm, maybe there's something to this observer model as this reconciles my qualms and could provide the basis for an oversight model. Does this analogy move the needle for anyone else? Could a combination of mentor and observer be sufficient? I think so... If my interpretation above is correct, big +1 from me. 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.mattm...@jpl.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: [DISCUSS] OODT Podling Incubator Experiment (was Re: Radical revamp (was: an experiment))
On Tue, Aug 17, 2010 at 01:08, Mattmann, Chris A (388J) chris.a.mattm...@jpl.nasa.gov wrote: Hey Justin, Thanks so much for your thoughtful reply. My comments below: See, here's where I get a bit discomforted by this entire process: I honestly don't feel that I deserve a vote on OODT releases. I've known you and Dave for long enough that I have no concerns advising the OODT community and trying to help out - but...giving me a binding vote? You know when to vote and *how* to vote. I see no reason to deny your vote. The (only) problem to arise would be if OODT was at the minimum of (3) ASF Members, and your vote was required. With Chris becoming a Member, OODT is at 5 Members that could comprise the mini/pseudo TLP that I propose. (maybe there are others interested, but I have zero insight into this community) ... Now, could we say that I would act as a certifier/observer that all of the major processes were followed? Heck yah. No qualms there. Here's an analogy I'm coming around to: in a lot of new democracies, there are observers who are sent in to monitor elections. They witness the elections, poke around, and make sure nothing unseemly is going on. They don't vote, but they do observe. They then issue a certification or report to be filed with the vote. (I'm catching up on my backlog of issues of The Economist; just read their article about nascent democracies in Africa on the plane...) +1. So our OODT observers would be: You, Jean Frederic, Ross, Ian, and me? PPMC stays the same, but they are given: * binding release/committer VOTEs In this case, observers are just really the mentors, and we move towards the mentors ensuring all is going well (which they should do now anyways), but IPMC ratification isn't required, and PPMC gets to self-govern. +1 from me on that, I think that's the right thing to teach, and with mentors that pay attention, I think we'll be great. I'm not sure that I'm reading the above properly, but... whatevs. Under my proposed TLP-based approach, the PMC would be comprised of: justin, jean, ross, ian, chris. The current committers (who are also on the PPMC, presumably) would be invited to the private@ list, but would not be on the PMC. Thus, they would have non-binding votes across all project decisions. But that should not be a problem as those PMC members also understand how to build and listen to consensus. If there are issues in the community, then the difference between binding and non-binding votes makes *zero* difference. The (podling) project/PMC would report directly to the Board. No more peanut gallery, or a second-guessing group. I do agree there is a lot of hand-waving around how to graduate, but I presume that the community can figure that out and provide information for future projects and communities. ... Cheers, -g - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] OODT Podling Incubator Experiment (was Re: Radical revamp (was: an experiment))
On Mon, Aug 16, 2010 at 10:08 PM, Mattmann, Chris A (388J) chris.a.mattm...@jpl.nasa.gov wrote: So basically you are moving more towards Joe's proposal, that the PPMC would have the binding VOTEs in e.g., new committers/PMC members, and on releases? Of course, with the caveats below, as you mention, i.e., the observers can observe and step in where necessary, but ultimately, they're there to ensure things are going great, and not to get in the way, unless they aren't? +1 to that. Yes, I know Joe was looking to only try something small and incremental. Given its history, a small incremental change in process is probably right for Thrift, but perhaps we can use OODT as an experiment for something even more bonkers. I don't see how we have much to lose - we've already been taken out to the woodshed once by the Incubator PMC. =) +1. So our OODT observers would be: You, Jean Frederic, Ross, Ian, and me? PPMC stays the same, but they are given: * binding release/committer VOTEs Yes, I think so. Perhaps to satisfy the governance rules, the observers (in the eyes of the Board, the PMC for the TLP) certify the votes from the PPMC (in the eyes of the PMC, the real ones). So, maybe it's not directly a binding vote, but the expectation is that the observers are meant to only certify and *not* provide technical oversight - unless they are *also* part of that PPMC. In this case, observers are just really the mentors, and we move towards the mentors ensuring all is going well (which they should do now anyways), but IPMC ratification isn't required, and PPMC gets to self-govern. +1 from me on that, I think that's the right thing to teach, and with mentors that pay attention, I think we'll be great. Yes. Hmm, maybe there's something to this observer model as this reconciles my qualms and could provide the basis for an oversight model. Does this analogy move the needle for anyone else? Could a combination of mentor and observer be sufficient? I think so... If my interpretation above is correct, big +1 from me. I think we could perhaps make something workable from this. Dunno. Need to see who else chimes in...hey, a message from Greg. =) -- justin - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] OODT Podling Incubator Experiment (was Re: Radical revamp (was: an experiment))
On Mon, Aug 16, 2010 at 10:20 PM, Greg Stein gst...@gmail.com wrote: You know when to vote and *how* to vote. I see no reason to deny your vote. Of course. It's always seemed awkward if you can't contribute technically to suddenly have a binding vote. I'm sure if I *wanted* to learn how to build something with Maven, I could. But, why? =) So, it makes me leery on being forced to cast a vote on a release - on par with those who have actually tested it and know something about the codebase. The standard that I force myself to adhere to on Subversion and httpd for example would be something that I'd fall short with in OODT. The (only) problem to arise would be if OODT was at the minimum of (3) ASF Members, and your vote was required. With Chris becoming a Member, OODT is at 5 Members that could comprise the mini/pseudo TLP that I propose. (maybe there are others interested, but I have zero insight into this community) Sure. It's just that Chris and I have discussed the pain points in the Incubation process, so we're on the lookout for making it easier on us. =) Plus, the experience with Subversion also showed me where things break down too. I'm not sure that I'm reading the above properly, but... whatevs. Under my proposed TLP-based approach, the PMC would be comprised of: justin, jean, ross, ian, chris. The current committers (who are also on the PPMC, presumably) would be invited to the private@ list, but would not be on the PMC. Thus, they would have non-binding votes across all project decisions. But that should not be a problem as those PMC members also understand how to build and listen to consensus. If there are issues in the community, then the difference between binding and non-binding votes makes *zero* difference. If we ran it with the intention that the PMC is there to solely provide non-technical oversight and that the PPMC does the actual work, I think that's something I could live with and address my concerns in the overall process. I don't think this is at odds with what you are saying nor would it run afoul of any corporate structures. It could just be the informal agreement between the PMC members that the PPMC should be the ones making the technical decisions. (If some other set of mentors wanted to run it differently, they could. But, this separation is one I could live with myself.) The (podling) project/PMC would report directly to the Board. No more peanut gallery, or a second-guessing group. Right. The listed members of the PMC are on the line dealing with the Board. (Hmm...would the PMC require a VP? I guess so.) If the Board has an issue with how they are running things, the Board can chime in. I do agree there is a lot of hand-waving around how to graduate, but I presume that the community can figure that out and provide information for future projects and communities. I very much like the Incubator providing what the general checklist form would look like. The Board could receive the checklist, review it, and then vote on the Graduation resolution. It'd also raise the oversight of the podlings (in this structure) back to the Board...which is likely a good thing so as things don't get hidden. -- justin - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
