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@apache.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