Jakarta PMC meeting minutes.

[Sam Ruby <ru...@us.ibm.com>]

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 <An...@eng.sun.com>  (partial time)
   Geir Magnusson Jr. <ge...@optonline.net>     (partial time)

- Sam Ruby

Re: Jakarta PMC meeting minutes.

[Peter Donald <do...@apache.org>]

At 07:55  20/1/01 -0500, Ted Husted wrote:
>My reading of this affirms the offhand suggestion I made before. The
>PMC could consist of a Commiter elected by each subproject. Each PMC
>member could serve a two-year term, and the terms could be staggered so
>everyone is not elected at once. The chair could be elected annually,
>as he or she is now. 

I am not sure a 2 year term is appropriate - mainly because of the speed at
which these projects tend to move. Think back 2 years to where apache was
with respect to java and have a guess where it will be in another 2 years.
Massive changes will take place. Perhaps a term of 6, 9 or 12 months is
more approriate ?

Cheers,

Pete

*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof."                   |
|              - John Kenneth Galbraith               |
*-----------------------------------------------------*

Re: Jakarta PMC meeting minutes.

[Ted Husted <ne...@husted.com>]

Thanks for posting these, Sam. 

My reading of this affirms the offhand suggestion I made before. The
PMC could consist of a Commiter elected by each subproject. Each PMC
member could serve a two-year term, and the terms could be staggered so
everyone is not elected at once. The chair could be elected annually,
as he or she is now. 

I would also suggest that each subproject's charter be reviewed on an
annual basis, and if appropriate, tagged inactive by a 3/4 vote of the
PMC. 

This would help ensure that the committee remained in-step with the
subprojects, and automatically scale the PMC to the number of active
subprojects.

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

Can we also copy that here? 

Is there a draft of the "Rules for Revolutionaries" available anywhere?
I was distracted when a lot of this first circulated. 

-Ted.

-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel 716 425-0252; Fax 716 223-2506.
-- http://www.husted.com/about/struts/