geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <ge...@apache.org>
Subject Re: svn commit: r225141 - in /geronimo/site: docs/guidelines.html xdocs/guidelines.xml
Date Mon, 25 Jul 2005 18:29:35 GMT

On Jul 25, 2005, at 1:37 PM, Dain Sundstrom wrote:

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

It's not clear that Incubator's rules are relevant, as they are for a  
really different kind of project. (I'm guessing, as I didn't go look...)

As for the others, they are probably derived from httpd in some way.

What aspects do you feel are unworkable for us?  Lets just fix those  
bugs that you see.

geir

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

-- 
Geir Magnusson Jr                                  +1-203-665-6437
geirm@apache.org



Mime
View raw message