Having searched the archives of private@, I see that the last change to the PMC was in May of 2012, when Dan rejoined.
Greg. On Tue, 2013-05-07 at 05:33, Greg Trasuk wrote: > It's that time again... Any issues or additions to the following? I > need to submit it before tomorrow. > > Question to all - For the life of me I can't find an email with a record > of our last new committer. I think it was Dennis, but I can't remember > the date - anyone? > > Cheers, > > Greg. > > > Apache River is a Java-based Service Oriented Architecture, implementing > the Jini Specification and Jini Technology Starter Kit originally > donated by Sun Microsystems. > > ISSUES FOR THE BOARD > > There are no board-level issues at this time > > RELEASES > > Apache River 2.2.1 was released on May 2, 2013. At time of writing the > release has been approved by the PMC but not announced yet (just waiting > for the distribution mirrors). We also expect to release artifacts for > version 2.2.1 to the Maven repository in the near future (these will be > subject to another release vote as we understand it). The last previous > release was 2.2.0 in July 0f 2011. > > COMMUNITY > > No new committers have been added since Feb 2012, although a couple of > emeritus committers have showed up on the mailing list in recent months. > > ACTIVITY > > There has been significant activity around the release. The 2.2.1 > release was a maintenance release of the 2.2 branch. In the time since > the 2.2 branch there have been a large number of changes to the trunk > code and the QA test code, particularly in regards to concurrency > issues, leading to some debate around the confidence level in the trunk > code. Basically, we feel that we waited far too long between releases. > With the 2.2.1 maintenance release out of the way, the community is > discussing how to proceed with release of the trunk code (which will > likely become the 2.3 stream). Also, we are discussing a switch to > Review-then-Commit procedure on the trunk code (previously we had > specified RTC only on API changes, but Commit-then-Review on the > implementation code). The discussions have been at times spirited, but > generally cordial. > > There have been some suggestions that we should consider switching to > Git for version control. We're watching other project's experiences > with interest. > >
