2011/12/21 - Jakarta has been retired.

Appointment of recording secretary: Sam Ruby volunteered. James gave some introductory remarks on the role of the PMC. How it currently is opaque, primarily because it is growing. It is responsible to the ASF. The ASF owns the entire body of the Apache Public Licensed code, but it delegates the daily maintenance of these code bases to the individual PMCs. Roy added some legal perspective to the rationale behind the rules, dealing with such topics as liability. The intent is to run the ASF as a meritocracy, with decision making pushed down whenever possible. James observed that much of these rules are being made up as we go along, so there is no reason to pay too much attention to precedence, we need to decide what is the right thing to do any given point in time. Topic 1: The issue before the table is that the Jakarta PMC (as well as perhaps several others) are significantly out of scope. Roy gave background on the current bylaws - there needs to be someone responsible to ensure that each project stays within the bounds of the law. In Roy's opinion there is no way for a single PMC to oversee all of the scope of the current Jakarta project, Roy proposed that it needs to be split up. Brian gave the observation that many feel the PMC creates an insulation layer, and wondered what an appropriate metric would be to determine the right size of a given project. James read down the list of current Jakarta projects. It is a lengthy list. He gave a brief historical perspective on how we evolved to this state. Jon gave a list of other Java Apache projects that he intends to bring over. Hans indicated that he felt that there was too much - his primary focus has been solely on the Tomcat project. Jon asked where should cocoon go? His point is that the lines are fuzzy. Brian suggested that perhaps all template engines should go into one project. Sam observed that they all hate one another ;-) Brian pointed out that putting all the "warring factions" into the same room is sometimes a way to address the duplication issue. Craig added that perhaps some projects are big enough to stand alone, and perhaps it would be less than productive to spend time grouping these projects when ultimately we will be breaking them out. Pier saw the PMC as perhaps one "view" or projection on how we organize things, and there should perhaps be multiple overlapping views. Brian restated that he would like the divisions to be driven by technical boundaries. Sam argued that given that we want to keep PMCs small, and push down decisions as much as humanly possible, and the fact that the current PMC has not be running as efficiently as we could (regular meetings, published minutes), it is quite possible that the current organization is actually the correct one. Straw poll: Sam suggested that we try to make this organization work Craig felt there was a maximum upper limit to the scope, and that the current Jakarta scope exceeds that Hans agreed that there was a maximum limit, but recognized that splitting would reduce the impetus for cooperation Pier observed that the current PMCs are virtually nonexistent, his vote would be to try to make the current structure work, but that we should ensure that there is adequate representation for each project. If that doesn't work, we should revisit this periodically, perhaps in six months. Jon suggested that people who are on the PMC should take their job seriously and devote a specific portion of their time to the task. Anil stated that we need to figure out the charter first before we decide the appropriate size of a PMC. James argued that the more layers we have, the more the efforts of the "thought leaders" are diluted. Consensus: we need to focus on scope of the PMC first. Observation: there is a strong desire to keep the role of the PMC as minimal as possible. Observation: the people in the PMC need to be thought leaders and active participants. Question: is the PMC a crossroads, where cross-project communication occurs? Answer: No! Observation: one of the roles of the PMC is to establish the Apache culture within the community Question: should the PMC be the "cop"? Asnwer: Veto of last resort. Question: should the PMCs be elected directly by the committers? Jason summed it up well: the charter of the PMC is to resolve interpersonal disputes, security concerns, legal issues, veto of last resort, approval of new subprojects within the scope of the project, responsible to the ASF corporation as chartered. (example: Tomcat compliance with the servlet spec). Topic 2: Formalization of the subproject hierarchy Brian penned: Servlet API Tomcat/Catalina (Jserv*, mod_java*) Watchdog Template Engines Jasper (from Tomcat) / Taglibs Velocity / ECS, JSSI*, SPFC* Dev Tools / Utilities Ant, Oro/Regexp, Jmeter*, Log4j, Alexandria*, Jyve* Frameworks Struts / Turbine* / JetSpeed* Slide Avalon / James* / PicoServer* Cocoon Sam inquired whether or not there already were existing people who covered the most of this, and with some minor tweaks could attain full coverage. Second straw poll (how many PMCs): Sam: 1 Craig: 1 Hans: multiple Pier: 1, on a trial basis Jon: abstain until some way to enforce responsibility is established Anil: no longer present James: multiple [Jason: multiple, tiered] [Manoj: 1, with a severely limited scope of decision making] Provisional decision: recharter under a larger charter, and establish some sort of hierarchy. James noted that he was a dissenter and therefore would like to ask for some other PMC member to draft the proposal. Roy identified two potential showstoppers and (1) if there was overlap with other PMCs (example: Cocoon), and (2) if the new proposed PMC could not demonstrate that there is adequate coverage. James noted that the existing charter of the PMC should stay until the new PMC structure is formed. Roy stated a deadline of a the board meeting after the one tomorrow (approximately one month). Topic 3: Status of the rules for revolutionaries document. Roy asked if this should be done at the foundation level? James commented that the rules are incomplete. Straw poll: Sam: it is a good thing to baseline. We can always tweak Craig: he is uncomfortable given the holes (particularly the name) Hans: it is a good thing to baseline. Pier: good base, the holes are largely outside the scope of the PMC Jon: good base, urgent need to address the times when committers disagree and forks in general Anil: still not present James: adopted as a reference document, informational (non-normative) Brian suggested that prior to proposal to the members, adopting by the PMC level first would be a good idea. Craig asked whether or not this is within the scope of the PMC. Decision: the PMC endorses the document and subject to general consensus of the general@jakarta.apache.org community it would be established as a part of the bylaws. A second follow on action would be that this should be brought forward to the ASF. Vote: Punt. There was some discussion of deferring the adoption until the major issues are resolved. Some may be addressed by subsequent agenda items establishing precedent. The remainder needs to be addressed as an agenda item in a subsequent PMC meeting. Costin noted that this document may have inadvertently lead to the current issues, and noted that this was adopted by vote by committers of a project and expressed concern over this being discussed by the PMC as an instance of the PMC potentially overriding the will of a project. Topic 4: Clarify the voting rules (specifically vetos). Veto without reasons are invalid Vetos with reasons can be challenged, and it requires another person with voting rights to state that the reason was valid (not necessarily that they agree, but merely that the reason was valid). Roy states that you can't veto a release - that's a majority decision. Federico suggested that if, after a significant period of time elapsed and the veto stops the health of the project, no resolution occurs within the scope of a project, the PMC can override the veto. Roy was very uneasy with this. Action item [James]: giving some examples and updating the document on the web site and proposing to general. Topic 5: Tomcat 3.x vs Tomcat 4 Straw Poll {with other discussion mixed in}: Hans: 3.x is the code base for 2.2/1.1, and 4.0 is the code base for 2.3/1.2. Pier: does not wish to see new features added to 3.x. Concern with the pattern of lack of support to 3.2 tree affecting Tomcat's image Craig: 37000 downloads of 3.2 the day it was released. His concern is support. Second concern is the confusion over the name. He stated that his original motion for 4.0 did not clearly put a sunset to 3.x. Craig indicated that he may be willing to "neg 0" a 3.3 proposal, but he does not intent to support it. { Pier commented on the issues of slander to his current employer } { James commented on a revolution being what caused the current state } Sam: the rules for revolution explicitly allows for multiple competing code bases - even if it causes confusion. The only thing it clearly disallows is the assigning a release number to code base without a vote on the issue. {Jon clarified that this status of being without a label should be clearly identified, as it was with Catalina.} { Roy stated that the people who vote for a release are accountable for its maintenance. Roy also stated the name goes with the majority. James asked who should be given the right to vote. Brian answered committers. } Jon: releasing 3.3 would be good for the community, but is deeply concerned that it will not be maintained. But, he does not want 3.3 hold up 4.0. He believes that the entire Tomcat line has delayed what was to be JServ 2.0 too long. He would like to see 3.x killed - at some point we need to say enough is enough and move on. { Brian gave an overview of the FreeBSD release strategies. Stable releases do get functional changes, but there needs to be a significant QA on stable releases. In his opinion, once a release is named current, the right thing for competition to the current base is to position itself as a successor to current. Brian stated that this has been quite useful as a forum for airing ideas, but he believe that any votes should be held by the committers of the codebase. } James: we really need to see a release plan for any work based on 3.x. { Costin explained that his efforts were focused on refactoring 3.1 into what has been referred to 3.3. What was 3.2 was a snapshot taken "in flight", and was done by another set of release managers. Therefore criticism that he didn't support 3.2 as an indication that he would not support 3.3 are not valid. } { Roy: no person or set of committers can reserve a name or label, until there has been a vote } {Hans: it would be a mistake for the PMC to make this decision. He calls for the "3.x developers" to pull together a release plan and a proposal for 3.3; alternately these same developers should pull together a release plan for a 5.x candidate. } {Jon suggests that any proposal for a 3.3 release specifically lists who intents to provide support for the release} Resolution: Costin agrees to put together a release plan in short order for a vote by the tomcat dev community. {Brian suggests that if Costin were to focus on clearing the backlog of defects reported on the 3.2 base (possibly in the 3.3 base) it would add to the a good faith of the proposal and therefore would remove much of the emotion } Action: James is to put out a clear and separate e-mail to the tomcat mailing lists indicating what the criteria is for a release plan. Topic 6: PMC mailing list: public or private? PMC members should do general discussions on general, and restrict PMC discussions to matters which require privacy. Resolution: the PMC will post minutes (or possibly sanitized versions when necessary) of meetings publicly. Concerns about the civility of e-mail should be directed to board.AT.apache.DOT.org. Topic 7: Proposal for cvs layout [deferred] Topic 8: Election of chair Poll on whether the current bylaws imply a one term limit Sam: neutral Craig: no term limit Pier: neutral Jon: no term limit Resolved: the bylaws will be updated to reflect that chairmens can be reelected. We will defer the actual election to the PMC mailing list. Jon nominated Sam. James nominated Craig. Topic 9: Review the bylaws of the PMC - amend or follow? It was noted by James that to date, we have not been good with following the rules, in particular for the monthly meetings. Action: [James] review the bylaws. Topic 10: Schedule for the next meeting. James proposed February 15th. Tentatively adopted. Likely late morning PST / early afternoon EST. Topic 11: Dinner (occurred during the course of topic 5). James moves to adjourn. Adopted. Attendees: Roy Fielding eBuild, Inc Keri Carpenter CollabNet Sam Ruby IBM Brian Behlendorf CollabNet Craig McClanahan Sun Daniel Schulze Olliance Jason Brittain Olliance Costin Manolache Sun Hans Bergsten Gefion Software Aaron Mulder Olliance Adam Gould CollabNet Remy Maucherat Sun Ian Kuller self Scott Sanders TotalSync Manoj Kasichinula CollabNet Jason Hunter CollabNet Pier Fumagalli Sun Jon "Pain the the ass" Stevens CollabNet James Davidson Sun Jim Driscoll Sun Pierre Delisle Sun Michael Percy Purtema Danny Coward Sun Amy Roh Sun Federico Barbieri Olliance On the phone was: Anil Vijendran <Anil.Vijendran@eng.sun.com> (partial time) Geir Magnusson Jr. <geirm@optonline.net> (partial time) - Sam Ruby