You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@harmony.apache.org by na...@apache.org on 2007/06/26 20:20:23 UTC
svn commit: r550894 - in /harmony/standard/site: docs/guidelines.html
xdocs/guidelines.xml
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 >> patchfile.txt</pre>
<p>or</p>
<pre>cvs diff -u http_main.c >> patchfile.txt</pre>
- <p>All patches necessary to address an action item should be concatenated
-within a single patch message. If later modification of the patch
-proves necessary, the entire new patch should be posted and not just
-the difference between two patches. The STATUS file entry should then
-be updated to point to the new patch message.</p>
- <p>The completed patchfile should produce no errors or prompts when the
-command,</p>
+ <p>
+ All patches necessary to address an action item should be concatenated
+ within a single patch message. If later modification of the patch
+ proves necessary, the entire new patch should be posted and not just
+ the difference between two patches. The STATUS file entry should then
+ be updated to point to the new patch message.
+ </p>
+ <p>
+ The completed patchfile should produce no errors or prompts when the
+ command,
+ </p>
<pre>patch -s < patchfile</pre>
<p>is issued in the target repository.</p>
- <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 >> patchfile.txt</pre>
-<p>or</p>
-<pre>cvs diff -u http_main.c >> patchfile.txt</pre>
-
-<p>All patches necessary to address an action item should be concatenated
-within a single patch message. If later modification of the patch
-proves necessary, the entire new patch should be posted and not just
-the difference between two patches. The STATUS file entry should then
-be updated to point to the new patch message.</p>
-
-<p>The completed patchfile should produce no errors or prompts when the
-command,</p>
-<pre>patch -s < patchfile</pre>
-<p>is issued in the target repository.</p>
-</section>
-
-<section name="Addendum">
-
-<p>Outstanding issues with this document</p>
-
-<ul>
- <li>We may need a better definition for "lazy consensus".</li>
- <li>We should clarify under what conditions a veto can be rescinded
- or overridden.</li>
- <li>Should we set a time limit on vetos of patches? Two weeks?</li>
-</ul>
+ </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 >> patchfile.txt</pre>
+ <p>or</p>
+ <pre>cvs diff -u http_main.c >> patchfile.txt</pre>
+
+ <p>
+ All patches necessary to address an action item should be concatenated
+ within a single patch message. If later modification of the patch
+ proves necessary, the entire new patch should be posted and not just
+ the difference between two patches. The STATUS file entry should then
+ be updated to point to the new patch message.
+ </p>
+
+ <p>
+ The completed patchfile should produce no errors or prompts when the
+ command,
+ </p>
+ <pre>patch -s < patchfile</pre>
+ <p>is issued in the target repository.</p>
+ </subsection>
+ </section>
+ </body>
</document>