geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <d...@iq80.com>
Subject Re: svn commit: r225141 - in /geronimo/site: docs/guidelines.html xdocs/guidelines.xml
Date Mon, 25 Jul 2005 17:37:13 GMT
I think we should start with guidelines that are from a project that  
is in a much earlier stage of development.  These guidelines work  
well for httpd since it is such a stable code base, but I believe  
unworkable for us.  Are there other project guidelines we can start  
with? Perhaps incubator, jakarta, or web-services?

-dain

On Jul 25, 2005, at 8:47 AM, geirm@apache.org wrote:

> 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