harmony-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From nadi...@apache.org
Subject svn commit: r550894 - in /harmony/standard/site: docs/guidelines.html xdocs/guidelines.xml
Date Tue, 26 Jun 2007 18:20:23 GMT
Author: nadinem
Date: Tue Jun 26 11:20:22 2007
New Revision: 550894

URL: http://svn.apache.org/viewvc?view=rev&rev=550894
Log:
removed inadequate STATUS, Addendum from Guidelines, changed heading hierarchy

Modified:
    harmony/standard/site/docs/guidelines.html
    harmony/standard/site/xdocs/guidelines.xml

Modified: harmony/standard/site/docs/guidelines.html
URL: http://svn.apache.org/viewvc/harmony/standard/site/docs/guidelines.html?view=diff&rev=550894&r1=550893&r2=550894
==============================================================================
--- harmony/standard/site/docs/guidelines.html (original)
+++ harmony/standard/site/docs/guidelines.html Tue Jun 26 11:20:22 2007
@@ -176,246 +176,288 @@
       <a name="Project Guidelines">Project Guidelines</a>
     </h1>
                         <p>
-This document defines the guidelines for the
-<a href="http://harmony.apache.org/">Apache Harmony 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>
-                <p class="backtotop"><a href="#top">Back to top</a></p>
-                                        <h1>
-      <a name="STATUS">STATUS</a>
-    </h1>
-                        <p>Each of the Apache Harmony'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>
-                <p class="backtotop"><a href="#top">Back to top</a></p>
-                                        <h1>
-      <a name="Voting">Voting</a>
-    </h1>
-                        <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 Harmony 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 Harmony 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 Harmony 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>
+        This document defines the guidelines for the
+        <a href="http://harmony.apache.org/">Apache Harmony 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>
+                                    
+    <h2>
+        <a name="Voting">Voting</a>
+    </h2>
+      
+                        <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 Harmony 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 Harmony 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 Harmony 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>
-  <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>
-                <p class="backtotop"><a href="#top">Back to top</a></p>
-                                        <h1>
-      <a name="Types of Action Items">Types of Action Items</a>
-    </h1>
+        <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>
+                   
+                                    
+    <h2>
+        <a name="Types of Action Items">Types of Action Items</a>
+    </h2>
+      
                         <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>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>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 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>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>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 Format">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>
+        <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 Format">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>
-      <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>
-                <p class="backtotop"><a href="#top">Back to top</a></p>
-                                        <h1>
-      <a name="When to Commit a Change">When to Commit a Change</a>
-    </h1>
+                   
+                                    
+    <h2>
+        <a name="When to Commit a Change">When to Commit a Change</a>
+    </h2>
+      
                         <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.
-  For detailed instructions on reporting, resolving and closing issues, refer to
-  <a href="issue_resolution_guideline.html">Good Issue Resolution Guideline</a>. 
-</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 Harmony 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>
-                <p class="backtotop"><a href="#top">Back to top</a></p>
-                                        <h1>
-      <a name="Patch Format">Patch Format</a>
-    </h1>
-                        <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. Afterwards, 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).</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.
+        For detailed instructions on reporting, resolving and closing issues, refer to
+        <a href="issue_resolution_guideline.html">Good Issue Resolution Guideline</a>.
+      </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 Harmony 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>
+                   
+                                    
+    <h2>
+        <a name="Patch Format">Patch Format</a>
+    </h2>
+      
+                        <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. Afterwards, 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).
+      </p>
                                 <p class="example">Example</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>
+                                <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>
-                <p class="backtotop"><a href="#top">Back to top</a></p>
-                                        <h1>
-      <a name="Addendum">Addendum</a>
-    </h1>
-                        <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>
+                   
                 <p class="backtotop"><a href="#top">Back to top</a></p>
                 
                                             </div> <!-- top aka Main Content -->

Modified: harmony/standard/site/xdocs/guidelines.xml
URL: http://svn.apache.org/viewvc/harmony/standard/site/xdocs/guidelines.xml?view=diff&rev=550894&r1=550893&r2=550894
==============================================================================
--- harmony/standard/site/xdocs/guidelines.xml (original)
+++ harmony/standard/site/xdocs/guidelines.xml Tue Jun 26 11:20:22 2007
@@ -24,271 +24,302 @@
   <author email="dev@harmony.apache.org">Harmony Documentation Team</author>
  </properties>
 
- <body>
-  <section name="Project Guidelines">
+  <body>
+    <section name="Project Guidelines">
 
-<p>
-This document defines the guidelines for the
-<a href="http://harmony.apache.org/">Apache Harmony 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="STATUS">
-
-<p>Each of the Apache Harmony'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 Harmony 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 Harmony 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 Harmony 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>
-  <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:
+      <p>
+        This document defines the guidelines for the
+        <a href="http://harmony.apache.org/">Apache Harmony 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>
+
+
+
+
+    <subsection 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 Harmony 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 Harmony 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 Harmony 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>
+        <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>
+
+    </subsection>
+
+    <subsection name="Types of Action Items">
       <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 Format">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>
+        <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 Format">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>
-      <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.
-  For detailed instructions on reporting, resolving and closing issues, refer to
-  <a href="issue_resolution_guideline.html">Good Issue Resolution Guideline</a>. 
-</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 Harmony 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 Format" 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. Afterwards, 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).</p>
-    <p class="example">Example</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>
+    </subsection>
 
-</section>
+    <subsection name="When to Commit a Change">
 
-</body>
+      <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.
+        For detailed instructions on reporting, resolving and closing issues, refer to
+        <a href="issue_resolution_guideline.html">Good Issue Resolution Guideline</a>.
+      </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 Harmony 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>
+
+    </subsection>
+
+    <subsection id="Patch Format" 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. Afterwards, 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).
+      </p>
+      <p class="example">Example</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>
+    </subsection>
+    </section>
+  </body>
 </document>
    



Mime
View raw message