In short : according to me they are.. Any feedback and additions appreciated.. On note : I like to see that at least the plugins get a release before we start a vote on dev (and I expressed below that you are targetting to have a release of core before leaving the incubator, although that could be a misunderstanding)
If everyone agrees on dev, we start a vote on the incubator general list and after that on the MyFaces private list. Exit strategy probably needs to be discussed with the MyFaces crowd (like mailinglists) and they probably need to have votes on people on the trinidad ppmc list that are not yet on the MyFaces PMC (but that's up to the MyFaces PMC). I'll subscribe to the private myfaces list (in case you didn't know : I can as a member, which doesn't actually mean that I am on that PMC or have a binding vote there). The very long version : To determine if Trinidad is ready to leave the incubator I took http://incubator.apache.org/incubation/Incubation_Policy.html#Exiting+the+Incubator and tried to answer all the questions. The first 3 on that page are actually the last ones, since I am treating them more as general conclusions. Legal * All code ASL'ed Looking at https://issues.apache.org/jira/browse/ADFFACES-355 it is solved. Most important is that before the release everything is ok, so that check needs to be done before a release (eg by using RAT, mojo.codehaus.org is working on a maven2 plugin atm). * No non ASL or ASL compatbile dependencies in the code base Don't see any problems here (just checked the deps in the poms). * License grant complete Yep * CLAs on file. Yep. Even people who submitted patches were asked to file a CLA. * Check of project name for trademark issues Was tried, but since no one as access to the trademark database, it has hard to determine. Meritocracy / Community * Demonstrate an active and diverse development community The community is very active, people send in patches that get applied, user community is a bit behind, but that should grow ones Trinidad is released. * The project is not highly dependent on any single contributor (there's at least 3 legally independent committers and there is no single company or entity that is vital to the success of the project) The main contributors are all employed by Oracle (based on the *commits* since end of December). These are matzew, jwaldman and awiner. gcrawford - Oracle jfallows - Not oracle anymore mmarinschek - Irian (?) slessard - DMR Consulting Inc (?) baranda - ? Mentors / champions craigmcc - Sun mvdb - Ordina (I don't count myself as a committer though) mgeiler - ? (not oracle afaik) Looking at the above list, it could mean a worry, which will be a lot less worry looking at the rest of the exit list. * The above implies that new committers are admitted according to ASF practices Absolutely. There were 3 committers added during incubation, one not Oracle and 2 Oracle people. >From my perspective all 3 deserved to be committer (with that amount of >activity, people should be voted in as a committer to be honest), so no favours were made just because someone is from Oracle. Currently some other people are on the radar to become committer (non Oracle). * ASF style voting has been adopted and is standard practice In every way. * Demonstrate ability to tolerate and resolve conflict within the community. Haven't noted much conflicts to be honest, but I am happy with the oversight that is done and how commits that get feedback get resolved quickly. I use the word feedback, since I haven't noticed any strong -1 on a commit, since there is respect for each others knowledge, ego's don't tend to play up, which is a good thing. * Release plans are developed and excuted in public by the community. This is done and currently the project is making it easier to do release (cut down the manual work of the release). The project has some problems getting a release out the door, which is partially solved by adding another mentor, so the project actually can get 3 binding votes on a release. The goal is to release the plugins and the core before leaving incubation. Currently there is http://wiki.apache.org/myfaces/TrinidadReleaseProcedure on the wiki, which after the releases are done can be formalised as a permanent part of the website. * Engagement by the incubated community with the other ASF communities, particularly infrastructure@ (this reflects my personal bias that projects should pay an nfrastructure "tax"). This is the case, since there is my synergy with the MyFaces community and most people from Trinidad are also actively involved there. So infrastructure is less of a problem, since that is handled (in the future) by the MyFaces PMC. * Incubator PMC has voted for graduation * Destination PMC, or ASF Board for a TLP, has voted for final acceptance The goal of this mail to get those votes :) Alignment / Synergy * Use of other ASF subprojects Not specifically, since the goals is to be JSR compliant. * Develop synergistic relationship with other ASF subprojects MyFaces is the sponsoring PMC. Infrastructure * SVN module has been created Yep, but it will move to MyFaces. * Mailing list(s) have been created * Mailing lists are being archived Do we keep the trinidad lists ? * Issue tracker has been created * Project website has been created Yep. * Project ready to comply with ASF mirroring guidlines The maven plugins don't need a seperate download and are therefor mirrored to the maven repositories. The Trinidad core still needs a release and will setup a download page according to the mirroring guidelines. * Project is integrated with GUMP if appropriate It is appropiate, but no gump integration afaik (since I am on the Gump PMC, I like to see this happening). * Releases are PGP signed by a member of the community Yep. Key signing is part of the standard release process. * Developers tied into ASF PGP web of trust Don't have a clue. Everyone coming to Apachecon however can join the Key Signing session to be trusted even more :). Conclusions : * it is a worthy and healthy project It is definitely a worthy and healthy project. Even though there can be concerns about the number of Oracle people involved, I think they have proven that they treat this project as an Apache project and not as an Oracle project. I think a complement is even in order, since it could be very tempting to do it the wrong way. * it truly fits within the ASF framework +1 * it "gets" the Apache Way. It definitely gets the Apache Way. They are open for feedback, act promptly when something slipped through the cracks and they really *want* to do the right thing. I even never heard a complaint on having to do things the Apache way. Mvgr, Martin
