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="[email protected]">
+
+
+
+
+
+
+
+ <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 >> patchfile.txt</pre>
+ <p>or</p>
+ <pre> cvs diff -
u http_main.c >> 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
< 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 © 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="[email protected]">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 >>
patchfile.txt</pre>
+<p>or</p>
+<pre> cvs diff -u http_main.c >> 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 < 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>
+
