husted 01/03/24 06:15:20
Added: xdocs/site/pmc index.xml 01-01-17-meeting-minutes.xml
Log:
Add index to PMC folder, and minutes from January meeting.
Revision Changes Path
1.1 jakarta-site2/xdocs/site/pmc/index.xml
Index: index.xml
===================================================================
<?xml version="1.0"?>
<document>
<properties>
<author email="[EMAIL PROTECTED]">Ted Husted</author>
<title>PMC Meeting Archive</title>
</properties>
<body>
<section name="PMC Meeting Archive">
<p>2001 March 19</p>
<ul>
<li><a href="./01-03-19-meeting-agenda.html">Meeting Agenda</a></li>
<li><a href="./01-03-19-meeting-irclog.html">Meeting Minutes (IRC Log)</a></li>
<li><a href="./01-03-19-meeting-summary.html">Meeting Summary</a></li>
</ul>
<p>2001 January 17</p>
<ul>
<li><a href="./01-01-17-meeting-minutes.html">Meeting Minutes</a></li>
</ul>
</section>
</body>
</document>
1.1 jakarta-site2/xdocs/site/pmc/01-01-17-meeting-minutes.xml
Index: 01-01-17-meeting-minutes.xml
===================================================================
<?xml version="1.0"?>
<document>
<properties>
<author email="[EMAIL PROTECTED]">Ram Ruby</author>
<title>2001 January 17 - Jakarta PMC Meeting Minutes</title>
</properties>
<body>
<section name="2001 January 17 - Jakarta PMC Meeting Minutes">
<p>Below is the text of an email message posted to the Jakarta General list on 20
Jan 2001.</p>
<source><![CDATA[
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 [EMAIL PROTECTED] 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
[EMAIL PROTECTED]
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 <[EMAIL PROTECTED]> (partial time)
Geir Magnusson Jr. <[EMAIL PROTECTED]> (partial time)
- Sam Ruby
]]></source>
</section>
</body>
</document>
