geronimo-scm mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ge...@apache.org
Subject svn commit: r225141 - in /geronimo/site: docs/guidelines.html xdocs/guidelines.xml
Date Mon, 25 Jul 2005 15:47:19 GMT
Author: geirm
Date: Mon Jul 25 08:47:16 2005
New Revision: 225141

URL: http://svn.apache.org/viewcvs?rev=225141&view=rev
Log:
these also : 

these are the guidelines from HTTPD that I'm putting up as a 
starting point of discussion.  I believe they are clearly marked 
as proposed.

Please veto of this is unacceptable to someone


Added:
    geronimo/site/docs/guidelines.html
    geronimo/site/xdocs/guidelines.xml

Added: geronimo/site/docs/guidelines.html
URL: http://svn.apache.org/viewcvs/geronimo/site/docs/guidelines.html?rev=225141&view=auto
==============================================================================
--- geronimo/site/docs/guidelines.html (added)
+++ geronimo/site/docs/guidelines.html Mon Jul 25 08:47:16 2005
@@ -0,0 +1,535 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
+
+<!--
+Copyright 1999-2004 The Apache Software Foundation
+Licensed under the Apache License, Version 2.0 (the "License");
+you may not use this file except in compliance with the License.
+You may obtain a copy of the License at
+
+http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing, software
+distributed under the License is distributed on an "AS IS" BASIS,
+WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+See the License for the specific language governing permissions and
+limitations under the License.
+-->
+
+
+<!-- Content Stylesheet for Site -->
+
+        
+<!-- start the processing -->
+    <!-- ====================================================================== -->
+    <!-- GENERATED FILE, DO NOT EDIT, EDIT THE XML FILE IN xdocs INSTEAD! -->
+    <!-- Main Page Section -->
+    <!-- ====================================================================== -->
+    <html>
+        <head>
+            <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"/>
+
+                                                    <meta name="author" value="Geronimo
Documentation Team">
+            <meta name="email" value="dev@geronimo.apache.org">
+            
+           
+            
+            
+            
+            
+            
+            <title>Apache Geronimo - Apache Geronimo - Project Guidelines</title>
+        </head>
+
+        <body bgcolor="#ffffff" text="#000000" link="#525D76">        
+            <table border="0" width="100%" cellspacing="0">
+                <!-- TOP IMAGE -->
+                <tr>
+                    <td align='LEFT'>
+                    <td align="left">
+<a href="http://geronimo.apache.org/"><img src="./images/geronimo-logo.png" alt="Apache
Geronimo" border="0"/></a>
+</td>
+                    </td>
+                </tr>
+            </table>
+            <table border="0" width="100%" cellspacing="4">
+                <tr><td colspan="2">
+                    <hr noshade="" size="1"/>
+                </td></tr>
+
+                <tr>
+                    <!-- LEFT SIDE NAVIGATION -->
+                    <td width="20%" valign="top" nowrap="true">
+
+                <!-- special ACon Logo - leave here for next time 
+
+                   <a href="http://apachecon.com"><img src="http://apache.org/images/ac2005eu_135x50.gif"
+                        alt="ApacheCon Logo" border="0"/></a>
+                 -->
+                   <!-- regular menu -->
+
+                    
+    <!-- ============================================================ -->
+
+                <p><strong>General</strong></p>
+        <ul>
+                    <li>    <a href="./index.html">Home</a>
+</li>
+                    <li>    <a href="./license.html">License</a>
+</li>
+                    <li>    <a href="http://www.apache.org/">ASF</a>
+</li>
+                    <li>    <a href="./downloads.html">Downloads</a>
+</li>
+                </ul>
+            <p><strong>Community</strong></p>
+        <ul>
+                    <li>    <a href="./get-involved.html">Get Involved</a>
+</li>
+                    <li>    <a href="./contributors.html">Committers</a>
+</li>
+                    <li>    <a href="./mailing.html">Mailing Lists</a>
+</li>
+                    <li>    <a href="./documentation.html">Documentation</a>
+</li>
+                    <li>    <a href="./faq.html">FAQ</a>
+</li>
+                    <li>    <a href="http://wiki.apache.org/geronimo">Wiki</a>
+</li>
+                </ul>
+            <p><strong>Development</strong></p>
+        <ul>
+                    <li>    <a href="./roadmap.html">Road Map / TODO</a>
+</li>
+                    <li>    <a href="./api/index.html">Javadoc</a>
+</li>
+                    <li>    <a href="./svn.html">Source Code</a>
+</li>
+                    <li>    <a href="http://wiki.apache.org/geronimo/CodingStandards">Coding
Standards</a>
+</li>
+                    <li>    <a href="http://nagoya.apache.org/jira/secure/BrowseProject.jspa?id=10220">JIRA</a>
+</li>
+                    <li>    <a href="./dependencies.html">Related Projects</a>
+</li>
+                </ul>
+            <p><strong>Proposed</strong></p>
+        <ul>
+                    <li>    <a href="./guidelines.html">Project Guidelines</a>
+</li>
+                </ul>
+                        </td>
+                    <td width="80%" align="left" valign="top">
+                                                                    <table border="0"
cellspacing="0" cellpadding="2" width="100%">
+      <tr><td bgcolor="#525D76">
+        <font color="#ffffff" face="arial,helvetica,sanserif">
+          <a name="Project Guidelines"><strong>Project Guidelines</strong></a>
+        </font>
+      </td></tr>
+      <tr><td>
+        <blockquote>
+                                    <p>
+<b>NOTE : </b>  The following guidelines are
+ <b><i>PROPOSED</i></b> for discussion only.  They will need to be
discussed
+ by the Geronimo community and a final version approved by
+ a vote by the Apache Geronimo PMC.  These guidelines were adopted from the
+ <a href="http://httpd.apache.org/">Apache HTTPD</a> project.
+</p>
+                                                <p>This document defines the guidelines
for the
+<a href="http://geronimo.apache.org/">Apache Geronimo Project</a>.
+It includes definitions of how conflict is resolved by voting,
+who is able to vote, and the procedures to follow for proposing and 
+making changes to the Apache products.</p>
+                                                <p>The objective here is to avoid unnecessary
conflict over changes and
+continue to produce a quality system in a timely manner.  Not all conflict
+can be avoided, but at least we can agree on the procedures for conflict
+to be resolved.</p>
+                            </blockquote>
+        </p>
+      </td></tr>
+      <tr><td><br/></td></tr>
+    </table>
+                                                <table border="0" cellspacing="0" cellpadding="2"
width="100%">
+      <tr><td bgcolor="#525D76">
+        <font color="#ffffff" face="arial,helvetica,sanserif">
+          <a name="People, Places, and Things"><strong>People, Places, and Things</strong></a>
+        </font>
+      </td></tr>
+      <tr><td>
+        <blockquote>
+                                    <dl>
+  <dt><strong>Apache Geronimo Project Management Committee</strong></dt>
+  <dd>The group of volunteers who are responsible for managing the Apache
+      Geronimo Project.  This includes deciding what is distributed
+      as products of the Project, maintaining the 
+      Project's shared resources, speaking on behalf of the Project, 
+      resolving license disputes regarding Apache products, nominating
+      new PMC members or committers, and establishing these guidelines.
+
+      <p>Membership in the Apache PMC is by invitation only and must
+      be approved by consensus of the active Apache PMC members.
+      A PMC member is considered inactive by their own declaration or by 
+      not contributing in any form to the project for over six months.  
+      An inactive member can become active again by reversing whichever
+      condition made them inactive (<em>i.e.</em>, by reversing their 
+      earlier declaration or by once again contributing toward the 
+      project's work).  Membership can be revoked by a unanimous vote of 
+      all the active PMC members other than the member in question.</p>
+
+      <p>
+      Our goal is that every committer willing and interested in the day-to-day
+      oversight and management of the project will be invited at the right time
+      to join the PMC.  Our goal is 100% of the committers on the PMC.
+      </p>
+
+  </dd>
+
+  <dt><strong>Apache Geronimo Committers</strong></dt>
+  <dd>The group of volunteers who are responsible for the technical
+      aspects of the Apache Geronimo Project.  This group has
+      write access to the appropriate source repositories and these
+      volunteers may cast binding votes on any technical discussion.
+
+      <p>Membership as a Committer is by invitation only and must
+      be approved by consensus of the active Apache PMC members.
+      A Committer is considered inactive by their own declaration or by 
+      not contributing in any form to the project for over six months.  
+      An inactive member can become active again by reversing whichever
+      condition made them inactive (<em>i.e.</em>, by reversing their 
+      earlier declaration or by once again contributing toward the 
+      project's work).  Membership can be revoked by a unanimous vote of 
+      all the active PMC members (except the member in question if they
+      are a PMC member).</p>
+  </dd>
+
+  <dt><strong>Apache Geronimo Developers</strong></dt>
+  <dd>All of the volunteers who are contributing time, code, documentation,
+      or resources to the Apache Geronimo Project.  A developer that makes sustained,
+      welcome contributions to the project for over six months is usually
+      invited to become a Committer, though the exact timing of such
+      invitations depends on many factors.</dd>
+
+  <dt><strong>Mail lists</strong></dt>
+  <dd>
+      Communication within the project is primarily throught he various
+      <a href="mailing.html">mail lists</a> for the project.
+  </dd>
+
+</dl>
+                            </blockquote>
+        </p>
+      </td></tr>
+      <tr><td><br/></td></tr>
+    </table>
+                                                <table border="0" cellspacing="0" cellpadding="2"
width="100%">
+      <tr><td bgcolor="#525D76">
+        <font color="#ffffff" face="arial,helvetica,sanserif">
+          <a name="STATUS"><strong>STATUS</strong></a>
+        </font>
+      </td></tr>
+      <tr><td>
+        <blockquote>
+                                    <p>Each of the Apache Geronimo's active source
code repositories contain a
+file called "STATUS" which is used to keep track of the agenda and plans 
+for work within that repository.  The STATUS file includes information 
+about release plans, a summary of code changes committed since the last 
+release, a list of proposed changes that are under discussion, brief 
+notes about items that individual developers are working on or want 
+discussion about, and anything else that might be useful to help the 
+group track progress.  The active STATUS files are automatically posted 
+to the mailing list each week.</p>
+                                                <p>Many issues will be encountered
by the project, each resulting in 
+zero or more proposed action items.  Issues should be raised on the
+mailing list as soon as they are identified.  Action items 
+<strong>must</strong> be raised on the mailing list and added to the 
+relevant STATUS file.  All action items may be voted on, but not all 
+of them will require a formal vote.</p>
+                            </blockquote>
+        </p>
+      </td></tr>
+      <tr><td><br/></td></tr>
+    </table>
+                                                <table border="0" cellspacing="0" cellpadding="2"
width="100%">
+      <tr><td bgcolor="#525D76">
+        <font color="#ffffff" face="arial,helvetica,sanserif">
+          <a name="Voting"><strong>Voting</strong></a>
+        </font>
+      </td></tr>
+      <tr><td>
+        <blockquote>
+                                    <p>Any of the Apache Developers may vote on any
issue or action item.
+However, the only binding votes are those cast by active members of the
+Apache Geronimo PMC; if the vote is about a change to source code or
+documentation, the primary author of what is being changed may also 
+cast a binding vote on that issue.  All other votes are non-binding.
+All developers are encouraged to participate in decisions, but the 
+decision itself is made by those who have been long-time contributors 
+to the project.  In other words, the Apache Geronimo Project is a
+minimum-threshold meritocracy.</p>
+                                                <p>The act of voting carries certain
obligations -- voting members are 
+not only stating their opinion, they are agreeing to help do the work of 
+the Apache Geronimo Project.  Since we are all volunteers, members often become
+inactive for periods of time in order to take care of their "real jobs" 
+or devote more time to other projects. It is therefore unlikely that the 
+entire group membership will vote on every issue.  To account for this, 
+all voting decisions are based on a minimum quorum.</p>
+                                                <p>Each vote can be made in one of
three flavors:</p>
+                                                <dl compact="compact">
+  <dt><strong>+1</strong></dt>
+  <dd>Yes, agree, or the action should be performed.  On some issues, this
+      vote is only binding if the voter has tested the action on
+      their own system(s).
+  </dd>
+  <dt><strong>0</strong></dt>
+  <dd>Abstain, no opinion, or I am happy to let the other group members
+      decide this issue.  An abstention may have detrimental effects if
+      too many people abstain.
+  </dd>
+  <dt><strong>-1</strong></dt>
+  <dd>No. On issues where consensus is required, this vote counts as a
+      <strong>veto</strong>.  All vetos must include an explanation of
+      why the veto is appropriate.  A veto with no explanation is void.
+      No veto can be overruled. If you disagree with the veto, you
+      should lobby the person who cast the veto. Voters intending to veto
+      an action item should make their opinions known to the group immediately,
+      so that the problem can be remedied as early as possible.
+  </dd>
+</dl>
+                                                <p>An action item requiring <em>consensus
approval</em> must receive
+at least <strong>3 binding +1</strong> votes and <strong>no vetos</strong>.
+An action item requiring <em>majority approval</em> must receive
+at least <strong>3 binding +1</strong> votes and more <strong>+1</strong>
+votes than <strong>-1</strong> votes (<em>i.e.</em>, a majority with
a minimum
+quorum of three positive votes).  All other action items are considered
+to have <em>lazy approval</em> until someone votes <strong>-1</strong>,
+after which point they are decided by either consensus or a majority vote,
+depending upon the type of action item.</p>
+                                                <p>Votes are tallied within the STATUS
file, adjacent to the action
+item under vote. All votes must be sent to the mailing list.</p>
+                            </blockquote>
+        </p>
+      </td></tr>
+      <tr><td><br/></td></tr>
+    </table>
+                                                <table border="0" cellspacing="0" cellpadding="2"
width="100%">
+      <tr><td bgcolor="#525D76">
+        <font color="#ffffff" face="arial,helvetica,sanserif">
+          <a name="Types of Action Items"><strong>Types of Action Items</strong></a>
+        </font>
+      </td></tr>
+      <tr><td>
+        <blockquote>
+                                    <dl>
+  <dt><strong>Long Term Plans</strong></dt>
+  <dd>Long term plans are simply announcements that group members
+      are working on particular issues related to the Apache software.
+      These are not voted on,
+      but group members who do not agree with a particular plan,
+      or think an alternate plan would be better, are obligated to
+      inform the group of their feelings.  In general, it is always
+      better to hear about alternate plans <strong>prior</strong> to
+      spending time on less adequate solutions.
+  </dd>
+
+  <dt><strong>Short Term Plans</strong></dt>
+  <dd>Short term plans are announcements that a developer is working on
+      a particular set of documentation or code files, with the implication
+      that other developers should avoid them or try to coordinate their
+      changes.  This is a good way to proactively avoid conflict and 
+      possible duplication of work.
+  </dd>
+
+  <dt><strong>Release Plan</strong></dt>
+  <dd>A release plan is used to keep all the developers aware of when a
+      release is desired, who will be the release manager, when the
+      repository will be frozen in order to create the release, and 
+      assorted other trivia to keep us from tripping over ourselves
+      during the final moments.  Lazy majority decides each issue in
+      the release plan.
+  </dd>
+
+  <dt><strong>Release Testing</strong></dt>
+  <dd>After a new release is built, colloquially termed a tarball, it
+      must be tested before being released to the public.  Majority
+      approval is required before the tarball can be publically released.
+  </dd>
+
+  <dt><strong>Showstoppers</strong></dt>
+  <dd>Showstoppers are issues that require a fix be in place
+      before the next public release.  They are listed in the STATUS file
+      in order to focus special attention on the problem.  An issue becomes
+      a showstopper when it is listed as such in STATUS and remains
+      so by lazy consensus.
+  </dd>
+
+  <dt><strong>Product Changes</strong></dt>
+  <dd>Changes to the Apache products, including code and documentation,
+      will appear as action items under several categories corresponding
+      to the change status:
+      <dl>
+      <dt><strong>concept/plan</strong></dt>
+      <dd>An idea or plan for a change.  These are usually only listed in
+          STATUS when the change is substantial, significantly impacts the
+          API, or is likely to be controversial.  Votes are being requested
+          early so as to uncover conflicts before too much work is done.
+      </dd>
+      <dt><strong>proposed patch</strong></dt>
+      <dd>A specific set of changes to the current product in the form
+          of <a href="#patch">input to the patch command</a> (a diff output).
+      </dd>
+      <dt><strong>committed change</strong></dt>
+      <dd>A one-line summary of a change that has been committed to the
+          repository since the last public release.
+      </dd>
+      </dl>
+      <p>All product changes to the currently active repository are subject
+      to lazy consensus.  All product changes to a prior-branch (old version)
+      repository require consensus before the change is committed.</p>
+  </dd>
+</dl>
+                            </blockquote>
+        </p>
+      </td></tr>
+      <tr><td><br/></td></tr>
+    </table>
+                                                <table border="0" cellspacing="0" cellpadding="2"
width="100%">
+      <tr><td bgcolor="#525D76">
+        <font color="#ffffff" face="arial,helvetica,sanserif">
+          <a name="When to Commit a Change"><strong>When to Commit a Change</strong></a>
+        </font>
+      </td></tr>
+      <tr><td>
+        <blockquote>
+                                    <p>Ideas must be review-then-commit; patches can
be commit-then-review.
+With a commit-then-review process, we trust that the developer doing the
+commit has a high degree of confidence in the change.  Doubtful changes,
+new features, and large-scale overhauls need to be discussed before
+being committed to a repository. Any major change 
+must receive consensus approval on the mailing list before being committed.
+</p>
+                                                <p>Each developer is responsible for
notifying the mailing list and 
+adding an action item to STATUS when they have an idea for a new feature 
+or major change to propose for the product.  The distributed nature of the
+Apache project requires an advance notice of 48 hours in order to properly
+review a major change -- consensus approval of either the concept or a
+specific patch is required before the change can be committed.  Note that
+a committer might veto the concept (with an adequate explanation), but later
+rescind that veto if a specific patch satisfies their objections.
+No advance notice is required to commit singular bug fixes.</p>
+                                                <p>Related changes should be committed
as a group, or very closely 
+together.  Half-completed projects should not be committed unless 
+doing so is necessary to pass the baton to another developer who has 
+agreed to complete the project in short order.  All code changes must 
+be successfully compiled on the developer's platform before being 
+committed.</p>
+                                                <p>The current source code tree should
be capable of complete compilation
+at all times.  However, it is sometimes impossible for a developer on
+one platform to avoid breaking some other platform when a change is
+committed, particularly when completing the change requires access to
+a special development tool on that other platform.  If it is anticipated
+that a given change will break some other platform, the committer must
+indicate that in the commit log.</p>
+                                                <p>The committer is responsible to
follow the Apache Geronimo procedure
+for any third-party code
+or documentation they commit to the repository.  All software committed
+to the repository must be covered by the Apache LICENSE or contain a
+copyright and license that allows redistribution under the same conditions
+as the Apache LICENSE.</p>
+                                                <p>A committed change must be reversed
if it is vetoed by one of the 
+voting committers and the veto conditions cannot be immediately satisfied by 
+the equivalent of a "bug fix" commit.  The veto must be rescinded before 
+the change can be included in any public release.</p>
+                            </blockquote>
+        </p>
+      </td></tr>
+      <tr><td><br/></td></tr>
+    </table>
+                                                <table border="0" cellspacing="0" cellpadding="2"
width="100%">
+      <tr><td bgcolor="#525D76">
+        <font color="#ffffff" face="arial,helvetica,sanserif">
+          <a name="Patch Format"><strong>Patch Format</strong></a>
+        </font>
+      </td></tr>
+      <tr><td>
+        <blockquote>
+                                    <p>When a specific change to the software is proposed
for discussion or
+voting on the mailing list, it should be presented in the form of input 
+to the patch command.  When sent to the mailing list, the message 
+should contain a Subject beginning with <code>[PATCH]</code> and a 
+distinctive one-line summary corresponding to the action item for that 
+patch.  Afterwords, the patch summary in the STATUS file should be 
+updated to point to the Message-ID of that message.</p>
+                                                <p>The patch should be created by using
the <CODE>diff -u</CODE> 
+command from the original software file(s) to the modified software 
+file(s).  E.g.,</p>
+                                                <pre>    diff -u http_main.c.orig http_main.c
&gt;&gt; patchfile.txt</pre>
+                                                <p>or</p>
+                                                <pre>    cvs diff -u http_main.c &gt;&gt;
patchfile.txt</pre>
+                                                <p>All patches necessary to address
an action item should be concatenated
+within a single patch message.  If later modification of the patch
+proves necessary, the entire new patch should be posted and not just
+the difference between two patches.  The STATUS file entry should then
+be updated to point to the new patch message.</p>
+                                                <p>The completed patchfile should produce
no errors or prompts when the
+command,</p>
+                                                <pre>    patch -s &lt; patchfile</pre>
+                                                <p>is issued in the target repository.</p>
+                            </blockquote>
+        </p>
+      </td></tr>
+      <tr><td><br/></td></tr>
+    </table>
+                                                <table border="0" cellspacing="0" cellpadding="2"
width="100%">
+      <tr><td bgcolor="#525D76">
+        <font color="#ffffff" face="arial,helvetica,sanserif">
+          <a name="Addendum"><strong>Addendum</strong></a>
+        </font>
+      </td></tr>
+      <tr><td>
+        <blockquote>
+                                    <p>Outstanding issues with this document</p>
+                                                <ul>
+    <li>We may need a better definition for "lazy consensus".</li>
+    <li>We should clarify under what conditions a veto can be rescinded 
+        or overridden.</li>
+    <li>Should we set a time limit on vetos of patches?  Two weeks?</li>
+</ul>
+                            </blockquote>
+        </p>
+      </td></tr>
+      <tr><td><br/></td></tr>
+    </table>
+                                        </td>
+                </tr>
+
+                <!-- FOOTER -->
+                <tr><td colspan="2">
+                    <hr noshade="" size="1"/>
+                </td></tr>
+                <tr><td colspan="2">
+                    <div align="center"><font color="#525D76" size="-1"><em>
+                    Copyright &#169; 2003-2005, The Apache Software Foundation
+                    </em></font></div>
+                </td></tr>
+            </table>
+        </body>
+    </html>
+<!-- end the processing -->
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+

Added: geronimo/site/xdocs/guidelines.xml
URL: http://svn.apache.org/viewcvs/geronimo/site/xdocs/guidelines.xml?rev=225141&view=auto
==============================================================================
--- geronimo/site/xdocs/guidelines.xml (added)
+++ geronimo/site/xdocs/guidelines.xml Mon Jul 25 08:47:16 2005
@@ -0,0 +1,355 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!--
+
+    Copyright 2003-2004 The Apache Software Foundation
+
+    Licensed under the Apache License, Version 2.0 (the "License");
+    you may not use this file except in compliance with the License.
+    You may obtain a copy of the License at
+  
+       http://www.apache.org/licenses/LICENSE-2.0
+  
+    Unless required by applicable law or agreed to in writing, software
+    distributed under the License is distributed on an "AS IS" BASIS,
+    WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+    See the License for the specific language governing permissions and
+    limitations under the License.
+-->
+  
+<document>
+
+ <properties>
+  <title>Apache Geronimo - Project Guidelines</title>
+  <author email="dev@geronimo.apache.org">Geronimo Documentation Team</author>
+ </properties>
+
+ <body>
+  <section name="Project Guidelines">
+
+<p>
+<b>NOTE : </b>  The following guidelines are
+ <b><i>PROPOSED</i></b> for discussion only.  They will need to be
discussed
+ by the Geronimo community and a final version approved by
+ a vote by the Apache Geronimo PMC.  These guidelines were adopted from the
+ <a href="http://httpd.apache.org/">Apache HTTPD</a> project.
+</p>
+
+<p>This document defines the guidelines for the
+<a href="http://geronimo.apache.org/">Apache Geronimo Project</a>.
+It includes definitions of how conflict is resolved by voting,
+who is able to vote, and the procedures to follow for proposing and 
+making changes to the Apache products.</p>
+
+<p>The objective here is to avoid unnecessary conflict over changes and
+continue to produce a quality system in a timely manner.  Not all conflict
+can be avoided, but at least we can agree on the procedures for conflict
+to be resolved.</p>
+</section>
+
+<section name="People, Places, and Things">
+
+<dl>
+  <dt><strong>Apache Geronimo Project Management Committee</strong></dt>
+  <dd>The group of volunteers who are responsible for managing the Apache
+      Geronimo Project.  This includes deciding what is distributed
+      as products of the Project, maintaining the 
+      Project's shared resources, speaking on behalf of the Project, 
+      resolving license disputes regarding Apache products, nominating
+      new PMC members or committers, and establishing these guidelines.
+
+      <p>Membership in the Apache PMC is by invitation only and must
+      be approved by consensus of the active Apache PMC members.
+      A PMC member is considered inactive by their own declaration or by 
+      not contributing in any form to the project for over six months.  
+      An inactive member can become active again by reversing whichever
+      condition made them inactive (<em>i.e.</em>, by reversing their 
+      earlier declaration or by once again contributing toward the 
+      project's work).  Membership can be revoked by a unanimous vote of 
+      all the active PMC members other than the member in question.</p>
+
+      <p>
+      Our goal is that every committer willing and interested in the day-to-day
+      oversight and management of the project will be invited at the right time
+      to join the PMC.  Our goal is 100% of the committers on the PMC.
+      </p>
+
+  </dd>
+
+  <dt><strong>Apache Geronimo Committers</strong></dt>
+  <dd>The group of volunteers who are responsible for the technical
+      aspects of the Apache Geronimo Project.  This group has
+      write access to the appropriate source repositories and these
+      volunteers may cast binding votes on any technical discussion.
+
+      <p>Membership as a Committer is by invitation only and must
+      be approved by consensus of the active Apache PMC members.
+      A Committer is considered inactive by their own declaration or by 
+      not contributing in any form to the project for over six months.  
+      An inactive member can become active again by reversing whichever
+      condition made them inactive (<em>i.e.</em>, by reversing their 
+      earlier declaration or by once again contributing toward the 
+      project's work).  Membership can be revoked by a unanimous vote of 
+      all the active PMC members (except the member in question if they
+      are a PMC member).</p>
+  </dd>
+
+  <dt><strong>Apache Geronimo Developers</strong></dt>
+  <dd>All of the volunteers who are contributing time, code, documentation,
+      or resources to the Apache Geronimo Project.  A developer that makes sustained,
+      welcome contributions to the project for over six months is usually
+      invited to become a Committer, though the exact timing of such
+      invitations depends on many factors.</dd>
+
+  <dt><strong>Mail lists</strong></dt>
+  <dd>
+      Communication within the project is primarily throught he various
+      <a href="mailing.html">mail lists</a> for the project.
+  </dd>
+
+</dl>
+</section>
+
+<section name="STATUS">
+
+<p>Each of the Apache Geronimo's active source code repositories contain a
+file called "STATUS" which is used to keep track of the agenda and plans 
+for work within that repository.  The STATUS file includes information 
+about release plans, a summary of code changes committed since the last 
+release, a list of proposed changes that are under discussion, brief 
+notes about items that individual developers are working on or want 
+discussion about, and anything else that might be useful to help the 
+group track progress.  The active STATUS files are automatically posted 
+to the mailing list each week.</p>
+
+<p>Many issues will be encountered by the project, each resulting in 
+zero or more proposed action items.  Issues should be raised on the
+mailing list as soon as they are identified.  Action items 
+<strong>must</strong> be raised on the mailing list and added to the 
+relevant STATUS file.  All action items may be voted on, but not all 
+of them will require a formal vote.</p>
+</section>
+
+<section name="Voting">
+
+<p>Any of the Apache Developers may vote on any issue or action item.
+However, the only binding votes are those cast by active members of the
+Apache Geronimo PMC; if the vote is about a change to source code or
+documentation, the primary author of what is being changed may also 
+cast a binding vote on that issue.  All other votes are non-binding.
+All developers are encouraged to participate in decisions, but the 
+decision itself is made by those who have been long-time contributors 
+to the project.  In other words, the Apache Geronimo Project is a
+minimum-threshold meritocracy.</p>
+
+<p>The act of voting carries certain obligations -- voting members are 
+not only stating their opinion, they are agreeing to help do the work of 
+the Apache Geronimo Project.  Since we are all volunteers, members often become
+inactive for periods of time in order to take care of their "real jobs" 
+or devote more time to other projects. It is therefore unlikely that the 
+entire group membership will vote on every issue.  To account for this, 
+all voting decisions are based on a minimum quorum.</p>
+
+<p>Each vote can be made in one of three flavors:</p>
+
+<dl compact="compact">
+  <dt><strong>+1</strong></dt>
+  <dd>Yes, agree, or the action should be performed.  On some issues, this
+      vote is only binding if the voter has tested the action on
+      their own system(s).
+  </dd>
+  <dt><strong>0</strong></dt>
+  <dd>Abstain, no opinion, or I am happy to let the other group members
+      decide this issue.  An abstention may have detrimental effects if
+      too many people abstain.
+  </dd>
+  <dt><strong>-1</strong></dt>
+  <dd>No. On issues where consensus is required, this vote counts as a
+      <strong>veto</strong>.  All vetos must include an explanation of
+      why the veto is appropriate.  A veto with no explanation is void.
+      No veto can be overruled. If you disagree with the veto, you
+      should lobby the person who cast the veto. Voters intending to veto
+      an action item should make their opinions known to the group immediately,
+      so that the problem can be remedied as early as possible.
+  </dd>
+</dl>
+
+<p>An action item requiring <em>consensus approval</em> must receive
+at least <strong>3 binding +1</strong> votes and <strong>no vetos</strong>.
+An action item requiring <em>majority approval</em> must receive
+at least <strong>3 binding +1</strong> votes and more <strong>+1</strong>
+votes than <strong>-1</strong> votes (<em>i.e.</em>, a majority with
a minimum
+quorum of three positive votes).  All other action items are considered
+to have <em>lazy approval</em> until someone votes <strong>-1</strong>,
+after which point they are decided by either consensus or a majority vote,
+depending upon the type of action item.</p>
+
+<p>Votes are tallied within the STATUS file, adjacent to the action
+item under vote. All votes must be sent to the mailing list.</p>
+
+</section>
+
+<section name="Types of Action Items">
+<dl>
+  <dt><strong>Long Term Plans</strong></dt>
+  <dd>Long term plans are simply announcements that group members
+      are working on particular issues related to the Apache software.
+      These are not voted on,
+      but group members who do not agree with a particular plan,
+      or think an alternate plan would be better, are obligated to
+      inform the group of their feelings.  In general, it is always
+      better to hear about alternate plans <strong>prior</strong> to
+      spending time on less adequate solutions.
+  </dd>
+
+  <dt><strong>Short Term Plans</strong></dt>
+  <dd>Short term plans are announcements that a developer is working on
+      a particular set of documentation or code files, with the implication
+      that other developers should avoid them or try to coordinate their
+      changes.  This is a good way to proactively avoid conflict and 
+      possible duplication of work.
+  </dd>
+
+  <dt><strong>Release Plan</strong></dt>
+  <dd>A release plan is used to keep all the developers aware of when a
+      release is desired, who will be the release manager, when the
+      repository will be frozen in order to create the release, and 
+      assorted other trivia to keep us from tripping over ourselves
+      during the final moments.  Lazy majority decides each issue in
+      the release plan.
+  </dd>
+
+  <dt><strong>Release Testing</strong></dt>
+  <dd>After a new release is built, colloquially termed a tarball, it
+      must be tested before being released to the public.  Majority
+      approval is required before the tarball can be publically released.
+  </dd>
+
+  <dt><strong>Showstoppers</strong></dt>
+  <dd>Showstoppers are issues that require a fix be in place
+      before the next public release.  They are listed in the STATUS file
+      in order to focus special attention on the problem.  An issue becomes
+      a showstopper when it is listed as such in STATUS and remains
+      so by lazy consensus.
+  </dd>
+
+  <dt><strong>Product Changes</strong></dt>
+  <dd>Changes to the Apache products, including code and documentation,
+      will appear as action items under several categories corresponding
+      to the change status:
+      <dl>
+      <dt><strong>concept/plan</strong></dt>
+      <dd>An idea or plan for a change.  These are usually only listed in
+          STATUS when the change is substantial, significantly impacts the
+          API, or is likely to be controversial.  Votes are being requested
+          early so as to uncover conflicts before too much work is done.
+      </dd>
+      <dt><strong>proposed patch</strong></dt>
+      <dd>A specific set of changes to the current product in the form
+          of <a href="#patch">input to the patch command</a> (a diff output).
+      </dd>
+      <dt><strong>committed change</strong></dt>
+      <dd>A one-line summary of a change that has been committed to the
+          repository since the last public release.
+      </dd>
+      </dl>
+      <p>All product changes to the currently active repository are subject
+      to lazy consensus.  All product changes to a prior-branch (old version)
+      repository require consensus before the change is committed.</p>
+  </dd>
+</dl>
+</section>
+
+<section name="When to Commit a Change">
+
+<p>Ideas must be review-then-commit; patches can be commit-then-review.
+With a commit-then-review process, we trust that the developer doing the
+commit has a high degree of confidence in the change.  Doubtful changes,
+new features, and large-scale overhauls need to be discussed before
+being committed to a repository. Any major change 
+must receive consensus approval on the mailing list before being committed.
+</p>
+
+<p>Each developer is responsible for notifying the mailing list and 
+adding an action item to STATUS when they have an idea for a new feature 
+or major change to propose for the product.  The distributed nature of the
+Apache project requires an advance notice of 48 hours in order to properly
+review a major change -- consensus approval of either the concept or a
+specific patch is required before the change can be committed.  Note that
+a committer might veto the concept (with an adequate explanation), but later
+rescind that veto if a specific patch satisfies their objections.
+No advance notice is required to commit singular bug fixes.</p>
+
+<p>Related changes should be committed as a group, or very closely 
+together.  Half-completed projects should not be committed unless 
+doing so is necessary to pass the baton to another developer who has 
+agreed to complete the project in short order.  All code changes must 
+be successfully compiled on the developer's platform before being 
+committed.</p>
+
+<p>The current source code tree should be capable of complete compilation
+at all times.  However, it is sometimes impossible for a developer on
+one platform to avoid breaking some other platform when a change is
+committed, particularly when completing the change requires access to
+a special development tool on that other platform.  If it is anticipated
+that a given change will break some other platform, the committer must
+indicate that in the commit log.</p>
+
+<p>The committer is responsible to follow the Apache Geronimo procedure
+for any third-party code
+or documentation they commit to the repository.  All software committed
+to the repository must be covered by the Apache LICENSE or contain a
+copyright and license that allows redistribution under the same conditions
+as the Apache LICENSE.</p>
+
+<p>A committed change must be reversed if it is vetoed by one of the 
+voting committers and the veto conditions cannot be immediately satisfied by 
+the equivalent of a "bug fix" commit.  The veto must be rescinded before 
+the change can be included in any public release.</p>
+
+</section>
+
+<section id="patch" name="Patch Format">
+<p>When a specific change to the software is proposed for discussion or
+voting on the mailing list, it should be presented in the form of input 
+to the patch command.  When sent to the mailing list, the message 
+should contain a Subject beginning with <code>[PATCH]</code> and a 
+distinctive one-line summary corresponding to the action item for that 
+patch.  Afterwords, the patch summary in the STATUS file should be 
+updated to point to the Message-ID of that message.</p>
+
+<p>The patch should be created by using the <CODE>diff -u</CODE> 
+command from the original software file(s) to the modified software 
+file(s).  E.g.,</p>
+
+<pre>    diff -u http_main.c.orig http_main.c &gt;&gt; patchfile.txt</pre>
+<p>or</p>
+<pre>    cvs diff -u http_main.c &gt;&gt; patchfile.txt</pre>
+
+<p>All patches necessary to address an action item should be concatenated
+within a single patch message.  If later modification of the patch
+proves necessary, the entire new patch should be posted and not just
+the difference between two patches.  The STATUS file entry should then
+be updated to point to the new patch message.</p>
+
+<p>The completed patchfile should produce no errors or prompts when the
+command,</p>
+<pre>    patch -s &lt; patchfile</pre>
+<p>is issued in the target repository.</p>
+</section>
+
+<section name="Addendum">
+
+<p>Outstanding issues with this document</p>
+
+<ul>
+    <li>We may need a better definition for "lazy consensus".</li>
+    <li>We should clarify under what conditions a veto can be rescinded 
+        or overridden.</li>
+    <li>Should we set a time limit on vetos of patches?  Two weeks?</li>
+</ul>
+
+</section>
+
+</body>
+</document>
+   



Mime
View raw message