Sorry if I missed your reply, but I don't see it on general - if it went to pmc, I didn't get it because I'm not a PMC member. Since I first came to the project I had always been under the impression that we needed PMC approval for decisions involving SVN access and releases, but if our team vote is good enough for the former, that's great news.
Thanks, Dan "Tom Jordahl" <[EMAIL PROTECTED]> wrote on 05/07/2008 11:17:35 AM: > As I already pointed out, you don’t *need* any PMC members to vote > on committers in your project. > If all the current committers have voted +1, then that is all that is needed. > -- > Tom Jordahl > WS PMC member > > From: Daniel Jemiolo [mailto:[EMAIL PROTECTED] > Sent: Wednesday, May 07, 2008 10:54 AM > To: [email protected] > Subject: Fw: [VOTE] new committers > > moving from pmc to general to try and reach more PMC members... > > > ----- Forwarded by Daniel Jemiolo/Durham/IBM on 05/07/2008 10:50 AM ----- > > Daniel Jemiolo/Durham/IBM wrote on 04/30/2008 01:23:01 PM: > > > Hello PMC members, > > > > I started a vote to add some new committers to the Muse project last > > Monday (see general and muse-dev), but we haven't received any PMC > > votes yet. All of the active committers have given a +1, but these > > are not binding votes. Please take the time to review the vote email > > (below) and send in your vote; the nominees are willing and the > > content is there, but we need some new leaders if the project is > > going to move forward. > > > > Thanks, > > Dan > > > > > ----- Forwarded by Daniel Jemiolo/Durham/IBM on 04/30/2008 01:16 PM ----- > > > > Daniel Jemiolo/Durham/[EMAIL PROTECTED] wrote on 04/21/2008 03:28:50 PM: > > > > > Lately there has been a lot of talk on the Muse mailing list about > > > pulling all of contributions from the last year together and > > > creating a 2.3 release. Of course, it won't be as simple as that: > > > there are lots of new features and plenty of important bug fixes > > > based on real world experience with the code, but unfortunately, the > > > current committers have been pulled away to other projects. I think > > > that it's time to nominate some new committers, people who have > > > shown that they can maintain and grow the Muse code base through > > > their code contributions and time volunteered helping others on the > > > mailing list. > > > > > > Below is the list of people that I am nominating to take on the > > > responsibility of shaping, testing, and delivering Muse 2.3.0; they > > > will be joined by existing committers Vinh Nguyen (Cisco) and Joel > > > Hawkins (Compuware). > > > > > > > > > Saurabh Dravid - Saurabh initially worked on the Eclipse TPTP > > > project, building Eclipse tooling for Muse users. Much of his bug > > > reporting (and solving) is split between Apache and Eclipse bug > > > trackers, but together these two sources show that he is very > > > comfortable getting knee deep in the code and solving problems. With > > > that knowledge under his belt, Saurabh is now contributing new > > > features around security and resource discovery, things that are > > > crucial to deployers and could not be completed without lots of > > > intense study and determination. > > > > > > Balan Subramanian - Everything I said about Saurabh can be applied > > > equally to Balan. Balan has also spent years handling the legal and > > > administrative issues surrounding open source development with > > > Apache and Eclipse (from a corporate perspective), and is well- > > > suited to review new contributions and ensure that due diligence is > > > in place for all of them; the 2.3 contributions come from sources > > > that are more disparate than ever, so this skill and patience isimportant. > > > > > > Chris Twiner - Chris Twiner is a 'real world' user of Muse who has > > > found and cracked many tough problems in the code base. In my > > > personal opinion, his contributions on MUSE-270[1] alone are enough > > > to warrant nomination, but his involvement is not limited to this. > > > In addition to being a significant code contributor, Chris is an > > > active mailing list problem solver who often has insight that the > > > original developers could not have had when they first wrote the > > > code; he has also shown the tact and resourcefulness that I think is > > > required to balance the needs of new users with the desire of > > > developers to move forward. > > > > > > Kam Yee - Kam has made strong contributions in an area that is > > > extremely important but often overlooked because of its difficulty: > > > he has created a test harness for Muse FVT and SVT, including WS-* > > > spec compliance. This is something that we've wanted for a very long > > > time, but the complexity of WS-* deployment and testing has pushed > > > it to the bottom of the list. I think Kam's work will be key to > > > ensuring that we don't have regressions in spec compliance or in the > > > tedious-but-important WSDL/SOAP/codegen issues that we face all the time. > > > > > > > > > Committers and PMC members: please reply to muse-dev and general > > > with your votes. You can either send one vote for all or vote for > > > each individual separately. > > > > > > Here is my +1 for all four nominees. > > > > > > Thanks, > > > Dan > > > > > > > > > [1] http://issues.apache.org/jira/browse/MUSE-270
