You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@httpd.apache.org by jo...@apache.org on 2012/05/07 00:53:20 UTC
svn commit: r1334814 [2/3] - /httpd/site/trunk/content/dev/
Copied: httpd/site/trunk/content/dev/guidelines.mdtext (from r1334802, httpd/site/trunk/content/dev/guidelines.xml)
URL: http://svn.apache.org/viewvc/httpd/site/trunk/content/dev/guidelines.mdtext?p2=httpd/site/trunk/content/dev/guidelines.mdtext&p1=httpd/site/trunk/content/dev/guidelines.xml&r1=1334802&r2=1334814&rev=1334814&view=diff
==============================================================================
--- httpd/site/trunk/content/dev/guidelines.xml (original)
+++ httpd/site/trunk/content/dev/guidelines.mdtext Sun May 6 22:53:19 2012
@@ -1,458 +1,413 @@
-<?xml version="1.0"?>
-<document>
- <properties>
- <author email="docs@httpd.apache.org">Documentation Group</author>
- <title>Apache HTTP Server Project Guidelines and Voting Rules</title>
- </properties>
-<body>
-
-<section><title>Apache Project Guidelines</title>
-
-<p>This document defines the guidelines for the
-<a href="http://httpd.apache.org/">Apache HTTP Server 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><title>People, Places, and Things</title>
-
-<dl>
- <dt><strong>Apache HTTP Server Project Management Committee</strong></dt>
- <dd>The group of volunteers who are responsible for managing the Apache
- HTTP Server Project. This includes deciding what is distributed
- as products of the Apache HTTP Server Project, maintaining the
- Project's shared resources, speaking on behalf of the Project,
- resolving license disputes regarding Apache products, nominating
- new PMC members or committers, and establishing these guidelines.
-
- <p>Membership in the Apache PMC is by invitation only and must
- be approved by consensus of the active Apache PMC members.
- A PMC member is considered inactive by their own declaration or by
- not contributing in any form to the project for over six months.
- An inactive member can become active again by reversing whichever
- condition made them inactive (<em>i.e.</em>, by reversing their
- earlier declaration or by once again contributing toward the
- project's work). Membership can be revoked by a unanimous vote of
- all the active PMC members other than the member in question.</p>
- </dd>
-
- <dt><strong>Apache HTTP Server Committers</strong></dt>
- <dd>The group of volunteers who are responsible for the technical
- aspects of the Apache HTTP Server Project. This group has
- write access to the appropriate source repositories and these
- volunteers may cast binding votes on any technical discussion.
-
- <p>Membership as a Committer is by invitation only and must
- be approved by consensus of the active Apache PMC members.
- A Committer is considered inactive by their own declaration or by
- not contributing in any form to the project for over six months.
- An inactive member can become active again by reversing whichever
- condition made them inactive (<em>i.e.</em>, by reversing their
- earlier declaration or by once again contributing toward the
- project's work). Membership can be revoked by a unanimous vote of
- all the active PMC members (except the member in question if they
- are a PMC member).</p>
- </dd>
-
- <dt><strong>Apache Developers</strong></dt>
- <dd>All of the volunteers who are contributing time, code, documentation,
- or resources to the Apache Project. A developer that makes sustained,
- welcome contributions to the project for over six months is usually
- invited to become a Committer, though the exact timing of such
- invitations depends on many factors.</dd>
-
- <dt><strong>mailing list</strong></dt>
- <dd>The Apache developers' primary mailing list for discussion of issues
- and changes related to the project (<em>dev@httpd.apache.org</em>).
- Subscription to the list is open, but only subscribers
- can post directly to the list.
- </dd>
-
- <dt><strong>private list</strong></dt>
- <dd>The Apache PMC's private mailing list for discussion of issues
- that are inappropriate for public discussion, such as legal, personal,
- or security issues prior to a published fix. Subscription to the list
- is only open (actually: mandatory) to Apache httpd's Project Management
- Comittee.
- </dd>
-
- <dt><strong>Subversion</strong></dt>
- <dd>All of the Apache products are maintained in shared information
- repositories using <a href="devnotes.html">Subversion on
- <em>svn.apache.org</em></a>. Only some of the Apache developers have
- write access to these repositories; everyone has
- <a href="http://svn.apache.org/repos/asf/httpd/httpd">read access</a>.
- </dd>
-</dl>
-</section>
-
-<section><title>STATUS</title>
-
-<p>Each of the Apache Project'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><title>Voting</title>
-
-<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 HTTP Server; 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 httpd 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 Project. Since we are all volunteers, members often become
-inactive for periods of time in order to take care of their "real jobs"
-or devote more time to other projects. It is therefore unlikely that the
-entire group membership will vote on every issue. To account for this,
-all voting decisions are based on a minimum quorum.</p>
-
-<p>Each vote can be made in one of three flavors:</p>
-
-<dl compact="compact">
- <dt><strong>+1</strong></dt>
- <dd>Yes, agree, or the action should be performed. On some issues, this
- vote is only binding if the voter has tested the action on
- their own system(s).
- </dd>
- <dt><strong>±0</strong></dt>
- <dd>Abstain, no opinion, or I am happy to let the other group members
- decide this issue. An abstention may have detrimental effects if
- too many people abstain.
- </dd>
- <dt><strong>-1</strong></dt>
- <dd>No. On issues where consensus is required, this vote counts as a
- <strong>veto</strong>. All vetos must include an explanation of
- why the veto is appropriate. A veto with no explanation is void.
- No veto can be overruled. If you disagree with the veto, you
- should lobby the person who cast the veto. Voters intending to veto
- an action item should make their opinions known to the group immediately,
- so that the problem can be remedied as early as possible.
- </dd>
-</dl>
-
-<p>An action item requiring <em>consensus approval</em> must receive
-at least <strong>3 binding +1</strong> votes and <strong>no vetos</strong>.
-An action item requiring <em>majority approval</em> must receive
-at least <strong>3 binding +1</strong> votes and more <strong>+1</strong>
-votes than <strong>-1</strong> votes (<em>i.e.</em>, a majority with a minimum
-quorum of three positive votes). All other action items are considered
-to have <em>lazy approval</em> until someone votes <strong>-1</strong>,
-after which point they are decided by either consensus or a majority vote,
-depending upon the type of action item.</p>
-
-<p>Votes are tallied within the STATUS file, adjacent to the action
-item under vote. All votes must be either sent to the mailing list
-or added directly to the STATUS file entry for that action item.</p>
-
-</section>
-
-<section><title>Types of Action Items</title>
-<dl>
- <dt><strong>Long Term Plans</strong></dt>
- <dd>Long term plans are simply announcements that group members
- are working on particular issues related to the Apache software.
- These are not voted on,
- but group members who do not agree with a particular plan,
- or think an alternate plan would be better, are obligated to
- inform the group of their feelings. In general, it is always
- better to hear about alternate plans <strong>prior</strong> to
- spending time on less adequate solutions.
- </dd>
-
- <dt><strong>Short Term Plans</strong></dt>
- <dd>Short term plans are announcements that a developer is working on
- a particular set of documentation or code files, with the implication
- that other developers should avoid them or try to coordinate their
- changes. This is a good way to proactively avoid conflict and
- possible duplication of work.
- </dd>
-
- <dt><strong>Release Plan</strong></dt>
- <dd>A release plan is used to keep all the developers aware of when a
- release is desired, who will be the release manager, when the
- repository will be frozen in order to create the release, and
- assorted other trivia to keep us from tripping over ourselves
- during the final moments. Lazy majority decides each issue in
- the release plan.
- </dd>
-
- <dt><strong>Release Testing</strong></dt>
- <dd>After a new release is built, colloquially termed a tarball, it
- must be tested before being released to the public. Majority
- approval is required before the tarball can be publically released.
- </dd>
-
- <dt><strong>Showstoppers</strong></dt>
- <dd>Showstoppers are issues that require a fix be in place
- before the next public release. They are listed in the STATUS file
- in order to focus special attention on the problem. An issue becomes
- a showstopper when it is listed as such in STATUS and remains
- so by lazy consensus.
- </dd>
-
- <dt><strong>Product Changes</strong></dt>
- <dd>Changes to the Apache products, including code and documentation,
- will appear as action items under several categories corresponding
- to the change status:
- <dl>
- <dt><strong>concept/plan</strong></dt>
- <dd>An idea or plan for a change. These are usually only listed in
- STATUS when the change is substantial, significantly impacts the
- API, or is likely to be controversial. Votes are being requested
- early so as to uncover conflicts before too much work is done.
- </dd>
- <dt><strong>proposed patch</strong></dt>
- <dd>A specific set of changes to the current product in the form
- of <a href="#patch">input to the patch command</a> (a diff output).
- </dd>
- <dt><strong>committed change</strong></dt>
- <dd>A one-line summary of a change that has been committed to the
- repository since the last public release.
- </dd>
- </dl>
- <p>All product changes to the currently active repository are subject
- to lazy consensus. All product changes to a prior-branch (old version)
- repository require consensus before the change is committed.</p>
- </dd>
-
- <dt><strong>Backport</strong></dt>
- <dd>A backport is the application of a change on the Subversion
- repository trunk to the a maintenance branch of the project. This is
- necessary in cases where an issue exists in multiple versions of the
- Apache HTTP Server. A fix for such an issue will typically be developed
- for the trunk, which is under active development.
- </dd>
-</dl>
-</section>
-
-<section><title>When to Commit a Change</title>
-
-<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 change that affects the semantics
-of arguments to configurable directives, significantly adds to the runtime
+Title: Apache HTTP Server Project Guidelines and Voting Rules
+Notice: Licensed to the Apache Software Foundation (ASF) under one
+ or more contributor license agreements. See the NOTICE file
+ distributed with this work for additional information
+ regarding copyright ownership. The ASF licenses this file
+ to you under the Apache License, Version 2.0 (the
+ "License"); you may not use this file except in compliance
+ with the License. You may obtain a copy of the License at
+ .
+ http://www.apache.org/licenses/LICENSE-2.0
+ .
+ Unless required by applicable law or agreed to in writing,
+ software distributed under the License is distributed on an
+ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ KIND, either express or implied. See the License for the
+ specific language governing permissions and limitations
+ under the License.
+
+This document defines the guidelines for the [Apache HTTP Server
+Project](http://httpd.apache.org/). 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.
+
+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.
+
+# People, Places, and Things #
+
+**Apache HTTP Server Project Management Committee**
+: The group of volunteers who are responsible for managing the Apache
+ HTTP Server Project. This includes deciding what is distributed as
+ products of the Apache HTTP Server Project, maintaining the Project's
+ shared resources, speaking on behalf of the Project, resolving license
+ disputes regarding Apache products, nominating new PMC members or
+ committers, and establishing these guidelines.
+Membership in the Apache PMC is by invitation only and must be approved by
+consensus of the active Apache PMC members. A PMC member is considered
+inactive by their own declaration or by not contributing in any form to the
+project for over six months. An inactive member can become active again by
+reversing whichever condition made them inactive ( *i.e.* , by reversing
+their earlier declaration or by once again contributing toward the
+project's work). Membership can be revoked by a unanimous vote of all the
+active PMC members other than the member in question.
+
+**Apache HTTP Server Committers**
+: The group of volunteers who are responsible for the technical aspects
+ of the Apache HTTP Server Project. This group has write access to the
+ appropriate source repositories and these volunteers may cast binding
+ votes on any technical discussion.
+Membership as a Committer is by invitation only and must be approved by
+consensus of the active Apache PMC members. A Committer is considered
+inactive by their own declaration or by not contributing in any form to the
+project for over six months. An inactive member can become active again by
+reversing whichever condition made them inactive ( *i.e.* , by reversing
+their earlier declaration or by once again contributing toward the
+project's work). Membership can be revoked by a unanimous vote of all the
+active PMC members (except the member in question if they are a PMC
+member).
+
+**Apache Developers**
+: All of the volunteers who are contributing time, code, documentation,
+ or resources to the Apache Project. A developer that makes sustained,
+ welcome contributions to the project for over six months is usually
+ invited to become a Committer, though the exact timing of such
+ invitations depends on many factors.
+
+**mailing list**
+: The Apache developers' primary mailing list for discussion of issues
+ and changes related to the project ( *dev@httpd.apache.org* ).
+ Subscription to the list is open, but only subscribers can post
+ directly to the list.
+
+**private list**
+: The Apache PMC's private mailing list for discussion of issues that
+ are inappropriate for public discussion, such as legal, personal, or
+ security issues prior to a published fix. Subscription to the list is
+ only open (actually: mandatory) to Apache httpd's Project Management
+ Comittee.
+
+**Subversion**
+: All of the Apache products are maintained in shared information
+ repositories using [Subversion on](devnotes.html). Only some of the
+ Apache developers have write access to these repositories; everyone
+ has [read access](http://svn.apache.org/repos/asf/httpd/httpd).
+
+# STATUS #
+
+Each of the Apache Project'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.
+
+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 **must** 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.
+
+# Voting #
+
+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 HTTP
+Server; 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
+httpd Project is a minimum-threshold meritocracy.
+
+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 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.
+
+Each vote can be made in one of three flavors:
+
+**+1**
+: 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).
+
+**±0**
+: 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.
+
+**-1**
+: No. On issues where consensus is required, this vote counts as a
+ **veto**. 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.
+An action item requiring *consensus approval* must receive at least **3
+binding +1** votes and **no vetos**. An action item requiring *majority
+approval* must receive at least **3 binding +1** votes and more **+1**
+votes than **-1** votes ( *i.e.* , a majority with a minimum quorum of
+three positive votes). All other action items are considered to have *lazy
+approval* until someone votes **-1** , after which point they are decided
+by either consensus or a majority vote, depending upon the type of action
+item.
+
+Votes are tallied within the STATUS file, adjacent to the action item under
+vote. All votes must be either sent to the mailing list or added directly
+to the STATUS file entry for that action item.
+
+# Types of Action Items #
+
+**Long Term Plans**
+: 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 **prior** to spending time on less adequate
+ solutions.
+
+**Short Term Plans**
+: 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.
+
+**Release Plan**
+: 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.
+
+**Release Testing**
+: 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.
+
+**Showstoppers**
+: 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.
+
+**Product Changes**
+: Changes to the Apache products, including code and documentation, will
+ appear as action items under several categories corresponding to the
+ change status:
+
+**concept/plan**
+: 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.
+
+**proposed patch**
+: A specific set of changes to the current product in the form of [input
+ to the patch command](#patch) (a diff output).
+
+**committed change**
+: A one-line summary of a change that has been committed to the
+ repository since the last public release.
+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.
+
+**Backport**
+: A backport is the application of a change on the Subversion repository
+ trunk to the a maintenance branch of the project. This is necessary in
+ cases where an issue exists in multiple versions of the Apache HTTP
+ Server. A fix for such an issue will typically be developed for the
+ trunk, which is under active development.
+
+# When to Commit a Change #
+
+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 change that affects the semantics of
+arguments to configurable directives, significantly adds to the runtime
size of the program, or changes the semantics of an existing API function
must receive consensus approval on the mailing list before being committed.
-</p>
-<p>Each developer is responsible for notifying the mailing list and
-adding an action item to STATUS when they have an idea for a new feature
-or major change to propose for the product. The distributed nature of the
-Apache project requires an advance notice of 48 hours in order to properly
-review a major change -- consensus approval of either the concept or a
-specific patch is required before the change can be committed. Note that
-a member 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 for the quality of 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 members 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="changelogs"><title>CHANGES file and Subversion logs</title>
-<p>Many code changes should be noted in the CHANGES file, and
-all should be documented in Subversion commit messages.
-Often the text of the Subversion log and the CHANGES entry are the same, but
-the distinct requirements sometimes result in different information.</p>
-
-<section><title>Subversion log</title>
-<p>The Subversion commit log message contains any information needed by
-<ul>
-<li>fellow developers or other people researching source code changes/fixes</li>
-<li>end users (at least point out what the implications are for end
-users; it doesn't have to be in the most user friendly wording)</li>
-</ul>
-</p>
-
-<p>If the code change was provided by a non-committer, attribute it
-using Submitted-by. If the change was committed verbatim, identify
-the committer(s) who reviewed it with Reviewed-by. If the change was
-committed with modifications, use the appropriate wording to document
-that, perhaps "committed with changes" if the person making the commit
-made the changes, or "committed with contributions from xxxx" if
-others made contributions to the code committed.</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 member
+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.
+
+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.
+
+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.
+
+The committer is responsible for the quality of 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.
+
+A committed change must be reversed if it is vetoed by one of the voting
+members 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.
+
+# CHANGES file and Subversion logs # {#changelogs}
+
+Many code changes should be noted in the CHANGES file, and all should be
+documented in Subversion commit messages. Often the text of the Subversion
+log and the CHANGES entry are the same, but the distinct requirements
+sometimes result in different information.
+
+## Subversion log ##
+
+The Subversion commit log message contains any information needed by
+
+- fellow developers or other people researching source code changes/fixes
+
+- end users (at least point out what the implications are for end users; it
+doesn't have to be in the most user friendly wording)
+
+If the code change was provided by a non-committer, attribute it using
+Submitted-by. If the change was committed verbatim, identify the
+committer(s) who reviewed it with Reviewed-by. If the change was committed
+with modifications, use the appropriate wording to document that, perhaps
+"committed with changes" if the person making the commit made the changes,
+or "committed with contributions from xxxx" if others made contributions to
+the code committed.
-<p>Example log message:
-
-<pre>
+Example log message: `
Check the return code from parsing the content length, to avoid a
crash if requests contain an invalid content length.
PR: 99999
Submitted by: Jane Doe <janedoe example.com>
Reviewed by: susiecommitter
-</pre>
-</p>
+`
+
+Commit messages can be minimal when making routine updates to STATUS, for
+example to propose a backport or vote.
+
+## CHANGES ##
+
+CHANGES is the subset of the information that end users need to see when
+they upgrade from one release to the next:
+
+- what can I now do that I couldn't do before
+
+- what problems that we anticipate a user could have suffered from are now
+fixed
+
+- all security fixes included, with CVE number. (If not available at the
+time of the commit, add later.)
+
+The usability of CHANGES for end users decreases as information of use to
+few individuals, or which doesn't pertain to evaluating the new release, is
+added. Specifically:
-<p>Commit messages can be minimal when making routine updates to STATUS,
-for example to propose a backport or vote.</p>
+- Fixes for bugs introduced after the last release don't belong in CHANGES.
-</section>
+- Fixes for bugs that we don't expect anybody noticed don't belong in
+CHANGES. (Bend the rule a little for outside contributions, as the
+submitter may need to see their name in lights as reward for their efforts,
+which typically were undertaken with no guarantee that any committer would
+take interest.)
-<section><title>CHANGES</title>
-<p>CHANGES is the subset of the information that end users need to see
-when they upgrade from one release to the next:<ul>
-<li>what can I now do that I couldn't do before</li>
-<li>what problems that we anticipate a user could have suffered from are now fixed</li>
-<li>all security fixes included, with CVE number. (If not available at
-the time of the commit, add later.)</li>
-</ul></p>
-
-<p>The usability of CHANGES for end users decreases as information of use
-to few individuals, or which doesn't pertain to evaluating the new
-release, is added. Specifically:<ul>
-<li>Fixes for bugs introduced after the last release don't belong in CHANGES.</li>
-<li>Fixes for bugs that we don't expect anybody noticed don't belong in
-CHANGES. (Bend the rule a little for outside contributions, as the
-submitter may need to see their name in lights as reward for their
-efforts, which typically were undertaken with no guarantee that any
-committer would take interest.)</li>
-<li>Documentation fixes, whether for end users or developers, don't
-belong in CHANGES.</li></ul></p>
-
-<p>CHANGES applies to changes even between alpha releases, so backporting
-a change from trunk to a stable release does not generally require removing
-the change from the CHANGES file in trunk.</p>
-
-<p>The attribution for the change is anyone responsible for the code changes.</p>
-</section>
-
-<section><title>Formatting</title>
-<p>Identify non-committers by name, and their email in obfuscated
-form if available. The obfuscation is done by replacing "@" with a
-space and adding "<" and ">" around the address. For example,
-change <tt>user@example.com</tt> to <tt><user example.com></tt>.
-</p>
+- Documentation fixes, whether for end users or developers, don't belong in
+CHANGES.
-<p>Identify committers with their Apache userid, e.g. <tt>xyz</tt>
-(no domain name needed). </p>
+CHANGES applies to changes even between alpha releases, so backporting a
+change from trunk to a stable release does not generally require removing
+the change from the CHANGES file in trunk.
-<p>If the change is related to a bugzilla issue, include the PR number
-in the log in the format:<pre>
+The attribution for the change is anyone responsible for the code changes.
+
+## Formatting ##
+
+Identify non-committers by name, and their email in obfuscated form if
+available. The obfuscation is done by replacing "@" with a space and adding
+"<" and ">" around the address. For example, change
+`user@example.com` to `<user example.com>`.
+
+Identify committers with their Apache userid, e.g. `xyz` (no domain name
+needed).
+
+If the change is related to a bugzilla issue, include the PR number in the
+log in the format: `
PR nnnnn
-</pre></p>
+`
-<p>Security-related changes should start like this:<pre>
+Security-related changes should start like this: `
*) SECURITY: CVE-YYYY-NNNN (cve.mitre.org)
xxxxxxxxxx
-</pre></p>
+`
-<p>Most changes are inserted at the top of the CHANGES file. However,
+Most changes are inserted at the top of the CHANGES file. However,
security-related changes should always be at the top of the list of changes
-for the relevant release, so if there are unreleased security changes
-at the top of the file, insert other changes below them.</p>
+for the relevant release, so if there are unreleased security changes at
+the top of the file, insert other changes below them.
-<p>Example CHANGES entries:
-
-<pre>
+Example CHANGES entries: `
*) SECURITY: CVE-2009-3095 (cve.mitre.org)
mod_proxy_ftp: sanity check authn credentials.
- [Stefan Fritsch <sf fritsch.de>, Joe Orton]
+ [Stefan Fritsch <sf fritsch.de>, Joe Orton]
- *) Replace AcceptMutex, LockFile, RewriteLock, SSLMutex, SSLStaplingMutex,
+ *) Replace AcceptMutex, LockFile, RewriteLock, SSLMutex,
+ SSLStaplingMutex,
and WatchdogMutexPath with a single Mutex directive. Add APIs to
simplify setup and user customization of APR proc and global mutexes.
(See util_mutex.h.) Build-time setting DEFAULT_LOCKFILE is no longer
respected; set DEFAULT_REL_RUNTIMEDIR instead. [Jeff Trawick]
-</pre>
-</p>
+`
+
+# Patch Format # {#patch}
+
+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 `[PATCH]` and a distinctive one-line summary
+corresponding to the action item for that patch. Afterwords, the patch
+summary in the STATUS file should be updated to point to the Message-ID of
+that message.
+
+The patch should be created by using the<CODE>diff -u</CODE>command from
+the original software file(s) to the modified software file(s). E.g.,
+` diff -u http_main.c.orig http_main.c >> patchfile.txt`
+or
+` svn diff http_main.c >> patchfile.txt`
+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.
+
+The completed patchfile should produce no errors or prompts when the
+command,
+` patch -s < patchfile`
+is issued in the target repository.
+
+# Addendum #
+
+Outstanding issues with this document
-</section>
+- We may need a better definition for "lazy consensus".
-</section>
+- We should clarify under what conditions a veto can be rescinded or
+overridden.
-<section id="patch"><title>Patch Format</title>
-<p>When a specific change to the software is proposed for discussion or
-voting on the mailing list, it should be presented in the form of input
-to the patch command. When sent to the mailing list, the message
-should contain a Subject beginning with <code>[PATCH]</code> and a
-distinctive one-line summary corresponding to the action item for that
-patch. Afterwords, the patch summary in the STATUS file should be
-updated to point to the Message-ID of that message.</p>
-
-<p>The patch should be created by using the <CODE>diff -u</CODE>
-command from the original software file(s) to the modified software
-file(s). E.g.,</p>
-
-<pre> diff -u http_main.c.orig http_main.c >> patchfile.txt</pre>
-<p>or</p>
-<pre> svn diff 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><title>Addendum</title>
-
-<p>Outstanding issues with this document</p>
-
-<ul>
- <li>We may need a better definition for "lazy consensus".</li>
- <li>We should clarify under what conditions a veto can be rescinded
- or overridden.</li>
- <li>Should we set a time limit on vetos of patches? Two weeks?</li>
-</ul>
-</section>
+- Should we set a time limit on vetos of patches? Two weeks?
-</body>
-</document>
Copied: httpd/site/trunk/content/dev/how-to-release.mdtext (from r1334802, httpd/site/trunk/content/dev/how-to-release.xml)
URL: http://svn.apache.org/viewvc/httpd/site/trunk/content/dev/how-to-release.mdtext?p2=httpd/site/trunk/content/dev/how-to-release.mdtext&p1=httpd/site/trunk/content/dev/how-to-release.xml&r1=1334802&r2=1334814&rev=1334814&view=diff
==============================================================================
--- httpd/site/trunk/content/dev/how-to-release.xml (original)
+++ httpd/site/trunk/content/dev/how-to-release.mdtext Sun May 6 22:53:19 2012
@@ -1,380 +1,317 @@
-<?xml version="1.0"?>
-<document>
- <properties>
- <author email="docs@httpd.apache.org">Documentation Group</author>
- <title>How to build a release of Apache</title>
- </properties>
-<body>
-
-<section><title>How to build a release of Apache</title>
-<p>
-Alexei Kosut <akosut@apache.org><br />
-Ralf S. Engelschall <rse@apache.org><br />
-Jim Jagielski <jim@apache.org><br />
-Ken Coar <coar@apache.org><br />
-Martin Kraemer <martin@apache.org><br />
-</p>
-
-<p><b><font color="red">This document has been obsoleted in httpd-2.0 by the
-httpd/site/trunk/tools/release.sh script.</font></b> It does everything for
-you. At some point, we may come back and update this document. So, in the
-meantime, ignore this and use that script for Apache 2.0 rolls.</p>
-
-<p>This document describes the typical release cycle the release manager has
-to step through when creating a new Apache release. It is written down as a
-step-by-step instruction list and should be followed exactly as specified to
-avoid problems or inconsistencies both in the created tarballs and the source
-repository.</p>
-
-</section>
-
-<section id="unix"><title>How to build an Apache Unix release</title>
-
-<p><font color="red">Note:</font> The below assumes that you are
-using <code>ssh</code> to login to your <code>httpd.apache.org</code>
-account. If you are "rolling the tarball" remotely, the differences
-will be noted.</p>
-
-<p><font color="red">Important:</font> Once tagged and the tarball
-is rolled, there is <b>no going back</b>. If there are
-problems with the tarball, the version number (either the rev-level
-or beta-level) <em>must</em> be bumped resulting in a new tag,
-tarball and release.</p>
-
-<hr />
-<ol>
- <li>Checkout the Apache source if needed into a scratch directory:<br />
- <p>For Apache 2.<em>X</em>:<br />
- <code><b>$ cvs checkout -r APACHE_2_<em>X</em>_BRANCH -Pd httpd-2.<em>X</em></b> httpd-2.0</code><br />
- <code><b>$ cd httpd-2.<i>X</i>/srclib</b></code><br />
- <code><b>$ cvs checkout apr apr-util</b></code><br />
- Omit the -r APACHE_2_<em>X</em>_BRANCH flag for the current development
- branch (e.g. 2.1-dev.) The current development branch always sits at
- cvs HEAD.
- </p>
- </li>
- <li>cd into the <code>apache</code> CVS tree.<br />
- <code><b>$ cd apache-1.<em>X</em></b></code><br />
- or<br />
- <code><b>$ cd httpd-2.<em>X</em></b></code>
- </li>
- <li>Adjust Announcement to taste.<br />
- <p>A prototype <code>Announcement</code> is included in
- the main CVS source tree. This file should be updated
- to reflect the current state of affairs concerning the
- release. For example, the Release Version should reflect
- what is actually being announced. Also, the key enhancements
- of the Release should be noted.<br />
- <code><b>$ vi Announcement</b></code><br />
- <code><b>$ cvs commit Announcement</b></code><br />
- <p><b>Note:</b> This document is also present in the
- <code>httpd-dist</code> cvs module, both in HTML and plain
- text form. You may want to create one version out of the other.</p>
- </p>
- </li>
- <li>Change the version number to indicate a release.<br />
- <p>For Apache 2.0:<br />
- Change <code>SERVER_BASEREVISION</code> in <TT>include/httpd.h</TT>
- from ``<code>2.<em>X</em>-dev</code>'' to ``<code>2.<em>X</em></code>''.
- Then also change <code>APACHE_RELEASE</code> in the same file from
- ``<code>2<em>XXYY0</em>00</code>'' to ``<code>2<em>XXYY1</em>00</code>''.
- </p>
- <p><STRONG>Note:</STRONG> until Apache 2.0 is of general release quality,
- module magic numbers are not enforced. You must edit
- <TT>include/ap_mmn.h</TT> and bump the MODULE_MAGIC_NUMBER_MAJOR prior
- to rolling the tarball, to assure beta testers are testing the
- corresponding .so modules. <I>This policy will be retracted, and
- coders will be reponsible for mmn bumps, once Apache 2.0 is officially
- released.</I>
- </p>
- </li>
- <li>Make sure your PGP keys are already present in the <code>KEYS</code>
- file. If they are not, extract your public key using the
- ``<code>pgp -kxa</code>'' command, add them to the
- <code>KEYS</code> file and commit it before tagging.
- </li>
- <li>Tag the sources for this release:<br />
- (<em>note: be sure to tag the whole thing, not just
- <code>src</code></em>!)<br />
- <code><b>$ cvs tag APACHE_1_<em>X_Y</em></b></code><br />
- For Apache 2.0:<br />
- <code><b>$ cvs tag APACHE_2_<em>X_Y</em></b></code>
- </li>
- <li>Make an export version of the distribution: (this creates a second
- subdirectory <code>apache-Z.<em>X.Y</em></code> for the exported version
- beside the existing CVS tree in <code>apache-Z.<em>X</em></code>)<br />
- <p>For Apache 2.0:<br />
- <code><b>$ cd ..</b></code><br />
- <code><b>$ umask 022</b></code><br />
- <code><b>$ cvs export -r APACHE_2_<em>X_Y</em> -d apache_2.<em>X.Y</em> httpd-2.<em>X</em></b></code><br />
- <code><b>$ cd apache_2.<em>X.Y</em>/srclib</b></code><br />
- <code><b>$ cvs export -r APACHE_2_<i>X_Y</i> apr apr-util</b></code>
- <ul>
- <li><font color="red">Note:</font> There is a known problem
- using <code>cvs export</code> remotely with <code>cvs-1.9</code>
- and later. If this affects you, you will need to do a checkout
- instead:<br />
- <code><b>$ umask 022</b></code><br />
- <code><b>$ cvs checkout -r APACHE_2_<em>X_Y</em> -d apache_2.<em>X.Y</em> httpd-2.<em>X</em></b></code><br />
- <code><b>$ cd apache_2.<em>X.Y</em>/srclib</b></code><br />
- <code><b>$ cvs checkout -r APACHE_2<i>X_Y</i> apr apr-util</b></code>
- </li>
- </ul>
- </p>
- </li>
- <li>Make sure the master site's FAQ is up-to-date:<br />
- <code><b>$ (cd /www/httpd.apache.org/docs/misc ; cvs update)</b></code>
- </li>
- <li>Extract the FAQ as a single file, as it appears on the Web:<br />
- <code><b>$ links -source http://httpd.apache.org/docs/misc/FAQ.html
- > htdocs/manual/misc/FAQ.html</b></code>
- </li>
- <li>Create the configuration files:<br />
- <p>For Apache 2.0:<br />
- Create <code>./configure</code> file, and remove all symlinks<br />
- <code><b>$ ./buildconf</b></code><br />
- <!-- Hmm. Why do we have to do the rm -f if buildconf should do that
- for us? - jre -->
- <code><b>$ rm -f ltconfig ltmain.sh config.sub config.guess</b></code><br />
- <code><b>$ cp /usr/local/share/libtool/ltconfig .</b></code><br />
- <code><b>$ cp /usr/local/share/libtool/ltmain.sh .</b></code><br />
- <code><b>$ cp /usr/local/share/libtool/config.sub .</b></code><br />
- <code><b>$ cp /usr/local/share/libtool/config.guess .</b></code><br />
- </p>
- </li>
- <li>Remove <code>STATUS</code>, <code>RULES.CVS</code>,
- <code>src/INDENT</code>, the multi-part FAQ, various
- <code>.cvsignore</code> and
- the developer's test subdirectories. Depending on which version you
- are releasing, not all of these files will be in the repository:<br />
- <code><b>$ rm STATUS RULES.CVS src/INDENT
- htdocs/manual/misc/FAQ-*.html</b></code><br />
- <code><b>$ find . -name ".cvsignore" -exec rm {} \;</b></code><br />
- <code><b>$ find . -type d -name "test" -exec rm -Rf {} \;</b></code>
- <ul>
- <li><font color="red">Note:</font> If you needed to do a
- <code>checkout</code> instead of a <code>export</code>, you
- will also need to remove the CVS administrative files:<br />
- <code><b>$ find . -type d -name "CVS" -exec rm -rf {} \;</b></code>
- </li>
- </ul>
- </li>
- <li>Roll the distribution tarball:<br />
- <code><b>$ tar cvf apache_<em>Z.X.Y</em>.tar apache_<em>Z.X.Y</em></b></code><br />
- </li>
- <li>Make the final packed distribution files:<br />
- <code><b>$ cp -p apache_<em>Z.X.Y</em>.tar xapache_<em>Z.X.Y</em>.tar</b></code><br />
- <code><b>$ gzip -9 apache_<em>Z.X.Y</em>.tar</b></code><br />
- <code><b>$ mv xapache_<em>Z.X.Y</em>.tar apache_<em>Z.X.Y</em>.tar</b></code><br />
- <code><b>$ compress apache_<em>Z.X.Y</em>.tar</b></code><br />
- </li>
- <li>Test the packed tar files and check for errors:<br />
- <code><b>$ gunzip -c apache_<em>Z.X.Y</em>.tar.gz | tar tvf -</b></code><br />
- (or simply: <code><b>$ tar tvzf apache_<em>Z.X.Y</em>.tar.gz</b></code>)<br />
- <code><b>$ uncompress <apache_<em>Z.X.Y</em>.tar.Z | tar tvf -</b></code><br />
- </li>
- <li>Sign the distribution files:<br />
- <code><b>$ pgp -sba apache_<em>Z.X.Y</em>.tar.gz</b></code><br />
- <code><b>$ pgp -sba apache_<em>Z.X.Y</em>.tar.Z</b></code><br />
-
- <ul>
- <li><font color="red">Note:</font> Be sure your PGP key is already in
- the <code>KEYS</code> file!
- </li>
- </ul>
- </li>
- <li>Test the tarball signatures:<br />
- <code><b>$ pgp apache_<em>Z.X.Y</em>.tar.gz.asc apache_<em>Z.X.Y</em>.tar.gz</b></code><br />
- <code><b>$ pgp apache_<em>Z.X.Y</em>.tar.Z.asc apache_<em>Z.X.Y</em>.tar.Z</b></code><br />
- </li>
- <li>Remember the CHANGES file:<br />
- <code><b>$ cp apache_<em>Z.X.Y</em>/src/CHANGES ./CHANGES_<em>Z.X</em></b></code>
- </li>
- <li>Cleanup:<br />
- (this deletes the export tree: it is now no longer required. We
- still need the CVS tree, see below)<br />
- <code><b>$ rm -fr apache_<em>Z.X.Y</em></b></code>
- </li>
- <li>Make the tarball available for testing purposes
- (in <a href="http://httpd.apache.org/dev/dist/">http://httpd.apache.org/dev/dist/</a>)
- by committing the generated release tarballs and signatures to the
- https://dist.apache.org/repos/dist/dev/httpd/ repository.
- </li>
- <li>Bump the version number to the next version and indicate we are
- in development.<br />
- cd back into the CVS tree location.<br />
- <code><b>$ cd apache-<em>Z.X</em></b></code>
- <p>
- For Apache 2.0:<br />
- Change <code>SERVER_BASEREVERSION</code> in <code>include/httpd.h</code>
- from ``<code>2.<em>X.Y</em></code>'' to
- ``<code>2.<em>X.(Y+1)</em>-dev</code>'' and change
- <code>APACHE_RELEASE</code> to <code>1<em>XX(YY+1)</em>000</code>.<br />
- Edit the <SAMP>STATUS</SAMP> file and update the status for the
- tagged apache_1.<em>X.Y</em> version, and add a header line
- for the new apache_1.<em>X.(Y+1)</em> version<br />
- <code><b>$ vi STATUS</b></code><br />
- <code><b>$ cvs commit STATUS</b></code><br />
- <br />
- <code><b>$ cd ..</b></code><br />
- Finally, add a new line
- ``<code>Changes with Apache 1.<em>X.(Y+1)</em>:</code>'' to the
- head of the <SAMP>CHANGES</SAMP> file for the
- forthcoming fixes in the new version.<br />
- <code><b>$ vi include/httpd.h \<br />
- CHANGES</b></code><br />
- <code><b>$ cvs commit include/httpd.h \<br />
- CHANGES</b></code><br />
- <code><b>$ cd ..</b></code><br />
- </p>
- </li>
- <li>Cleanup:<br />
- (delete the CVS tree, after verification that it does not
- contain any uncommitted changes)<br />
- <code><b>$ cvs release -d apache-<em>Z.X</em></b></code>
- </li>
-</ol>
-
-<p><b>Now wait for the group to test and approve the tarball.</b></p>
-</section>
-
-<section id="release"><title>Final release steps</title>
-<p><em><font color="red">Note:</font> Do not continue with the rest of
-these instructions until the group really approves the tarball!</em></p>
-
-<ol>
- <li>Make the distribution available
- (in <a href="http://www.apache.org/dist/httpd/">http://www.apache.org/dist/httpd/</a>) by
- svn mv'ing the files from https://dist.apache.org/repos/dist/dev/httpd/
- to the https://dist.apache.org/repos/dist/release/httpd/ repository.
- </li>
- <li>If binary builds are already built and tested at this point,
- you can add them in svn under the distribution tree branches
- https://dist.apache.org/repos/dist/release/httpd/binaries/{OS}/.
- </li>
- <li>Checkout the
- <a href="http://www.apache.org/dist/httpd/">httpd-dist site</a>,
- if needed, into a scratch directory:<br />
- <code><b>$ cvs -d cvs.apache.org:/home/cvs checkout -P httpd-dist</b></code>
- </li>
- <li>Change directory into <code>httpd-dist</code><br />
- <code><b>$ cd httpd-dist/</b></code>
- </li>
- <li>Edit the files
- <a href="http://www.apache.org/dist/httpd/README.html"><code>README.html</code></a> and <a href="http://www.apache.org/dist/httpd/HEADER.html"><code>HEADER.html</code></a> as well as
- <a href="http://www.apache.org/dist/httpd/Announcement.html"><code>Announcement.html</code></a> and its plaintext equivalent
- <a href="http://www.apache.org/dist/httpd/Announcement.txt"><code>Announcement.txt</code></a> plus the
- <a href="http://www.apache.org/dist/httpd/.htaccess"><code>.htaccess</code></a> file (which defines the
- <code>AddDescription</code> comments)
- from the <code>httpd-dist</code> CVS tree
- as required (all in the
- <a href="http://www.apache.org/dist/httpd/"><code>.</code></a>
- subdirectory). The <code>Announcement.*</code> files should be based on
- the <code>Announcement</code> file in the tagged CVS tree. For Apache
- 2.0, <code>Announcement</code> should be replaced with
- <code>Announcement2</code>:<br />
- <code><b>$ vi README.html HEADER.html Announcement.html Announcement.txt
- .htaccess</b></code><br />
- </li>
- <li>Commit the changes:<br />
- <code><b>$ cvs commit README.html HEADER.html Announcement.html Announcement.txt .htaccess</b></code><br />
- <code><b>$ cd ../..</b></code>
- </li>
- <li>Checkout the <a href="http://httpd.apache.org/">httpd site</a> if needed into a scratch directory:<br />
- <code><b>$ cvs -d cvs.apache.org:/home/cvs checkout httpd-site</b></code>
- </li>
- <li>cd into the <code>httpd-site</code> xdocs tree.<br />
- <code><b>$ cd httpd-site/xdocs/</b></code>
- </li>
- <li>Edit the <a href="http://httpd.apache.org/"><code>index.xml</code></a>
- page from the <code>httpd-site</code> CVS tree as required:<br />
- <code><b>$ vi index.xml</b></code><br />
- </li>
- <li>Commit the changes:<br />
- <code><b>$ cd ..</b></code><br />
- <code><b>$ ./build.sh # Check result before continuing</b></code><br />
- <code><b>$ cvs commit</b></code><br />
- </li>
- <li>Update the checked-out versions of the <code>httpd-dist</code> documents
- for the web server:<br />
- <code><b>$ umask 002</b></code><br />
- <code><b>$ cd /www/www.apache.org/dist/httpd/</b></code><br />
- <code><b>$ cvs update -dP</b></code>
- </li>
- <li>Create an empty directory for future patches:<br />
- <code><b>$ mkdir patches/apply_to_1.<em>X.Y</em></b></code>
- </li>
- <li>Update the checked-out version of the <code>httpd-site index.html</code>
- page for the web server:<br />
- <code><b>$ umask 002</b></code><br />
- <code><b>$ cd /www/httpd.apache.org/</b></code><br />
- <code><b>$ cvs update -dP</b></code>
- </li>
-</ol>
-
-<p>At this point, the web-sites reflect the existance of the new release.</p>
-
-<p>As it is going to be some 24hrs before any announcement goes out
- (to make sure that the mirror's have at least a chance of grabbing
- a copy) this is also the right time to mail dev@httpd.apache.org
- and ask people to upload and move into position any binaries
- they have build and vetted.
-</p>
-</section>
-
-<section id="announce"><title>Announcing a New Release</title>
-
-<p>Once a release is <a href="#unix">built</a> and
- <a href="#release">released</a>, it is time to announce it to the world.
-</p>
-
-<ol>
- <li>Grab the prepared Announcement:<br />
- <p>You can grab either the <code>Announcement</code> file in the tagged
- tree, or the <code>Announcement.txt</code> file from the
- web-site.</p>
- </li>
- <li>Post the Announcement:<br />
- <p>Once the tarball is built, give the mirrors a good 24 hours
- to get up to sync. This is really important if this this
- a final (i.e.: non-beta) release.</p>
- </li>
- <li>Now, <code>Announcement</code> should be
- posted to the following places (please note that a mail send to
- announce@apache.org <em>must</em> have your apache.org address set
- as its 'From' address, otherwise it won't pass the anti-spam filter):
- <ul>
- <li>Unmoderated UseNet newsgroups (should be crossposted)
- <ul>
- <li><code>comp.infosystems.www.servers.unix</code></li>
- <li><code>comp.infosystems.www.servers.ms-windows</code></li>
- <li><code>comp.infosystems.www.servers.misc</code></li>
- <li><code>de.comm.infosystems.www.servers</code></li>
- </ul>
- </li>
- <li>Moderated UseNet newsgroups (do <b>not</b> crosspost)
- <ul>
- <li><code>comp.infosystems.www.announce</code></li>
- </ul>
- </li>
- <li>Mailing Lists
- <ul>
- <li><code>announce@apache.org</code></li>
- <li><code>announce@httpd.apache.org</code></li>
- <li><code>users@httpd.apache.org</code></li>
- <li><code>users-de@httpd.apache.org</code></li>
- </ul>
- </li>
- </ul>
- </li>
- <li>Make sure that <code>Announcement.txt</code> and
- <code>Announcement.html</code> in <code>httpd-dist</code>
- are updated to include
- these changes.
- </li>
- <li>Bask in the glow</li>
-</ol>
-</section>
+Title: How to build a release of Apache
+Notice: Licensed to the Apache Software Foundation (ASF) under one
+ or more contributor license agreements. See the NOTICE file
+ distributed with this work for additional information
+ regarding copyright ownership. The ASF licenses this file
+ to you under the Apache License, Version 2.0 (the
+ "License"); you may not use this file except in compliance
+ with the License. You may obtain a copy of the License at
+ .
+ http://www.apache.org/licenses/LICENSE-2.0
+ .
+ Unless required by applicable law or agreed to in writing,
+ software distributed under the License is distributed on an
+ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ KIND, either express or implied. See the License for the
+ specific language governing permissions and limitations
+ under the License.
+
+Alexei Kosut <akosut@apache.org><br></br>Ralf S. Engelschall
+<rse@apache.org><br></br>Jim Jagielski
+<jim@apache.org><br></br>Ken Coar
+<coar@apache.org><br></br>Martin Kraemer
+<martin@apache.org><br></br>
+
+**<font color="red">This document has been obsoleted in httpd-2.0 by the
+httpd/site/trunk/tools/release.sh script.</font>** It does everything for
+you. At some point, we may come back and update this document. So, in the
+meantime, ignore this and use that script for Apache 2.0 rolls.
+
+This document describes the typical release cycle the release manager has
+to step through when creating a new Apache release. It is written down as a
+step-by-step instruction list and should be followed exactly as specified
+to avoid problems or inconsistencies both in the created tarballs and the
+source repository.
+
+# How to build an Apache Unix release # {#unix}
+
+<font color="red">Note:</font>The below assumes that you are using `ssh` to
+login to your `httpd.apache.org` account. If you are "rolling the tarball"
+remotely, the differences will be noted.
+
+<font color="red">Important:</font>Once tagged and the tarball is rolled,
+there is **no going back**. If there are problems with the tarball, the
+version number (either the rev-level or beta-level) *must* be bumped
+resulting in a new tag, tarball and release.
+
+----------
+
+1. Checkout the Apache source if needed into a scratch directory:<br></br>
+For Apache 2. *X* :<br></br><code> **$ cvs checkout -r APACHE_2_ *X*
+_BRANCH -Pd httpd-2. *X* ** httpd-2.0</code><br></br><code> **$ cd httpd-2.
+*X* /srclib** </code><br></br><code> **$ cvs checkout apr apr-util**
+</code><br></br>Omit the -r APACHE_2_ *X* _BRANCH flag for the current
+development branch (e.g. 2.1-dev.) The current development branch always
+sits at cvs HEAD.
+
+1. cd into the `apache` CVS tree.<br></br><code> **$ cd apache-1. *X* **
+</code><br></br>or<br></br><code> **$ cd httpd-2. *X* ** </code>
+
+1. Adjust Announcement to taste.<br></br>
+A prototype `Announcement` is included in the main CVS source tree. This
+file should be updated to reflect the current state of affairs concerning
+the release. For example, the Release Version should reflect what is
+actually being announced. Also, the key enhancements of the Release should
+be noted.<br></br><code> **$ vi Announcement** </code><br></br><code> **$
+cvs commit Announcement** </code><br></br>
+**Note:** This document is also present in the `httpd-dist` cvs module,
+both in HTML and plain text form. You may want to create one version out of
+the other.
+
+1. Change the version number to indicate a release.<br></br>
+For Apache 2.0:<br></br>Change `SERVER_BASEREVISION`
+in<TT>include/httpd.h</TT>from ``<code>2. *X* -dev</code>'' to ``<code>2.
+*X* </code>''. Then also change `APACHE_RELEASE` in the same file from
+``<code>2 *XXYY0* 00</code>'' to ``<code>2 *XXYY1* 00</code>''.
+
+<STRONG>Note:</STRONG>until Apache 2.0 is of general release quality,
+module magic numbers are not enforced. You must
+edit<TT>include/ap_mmn.h</TT>and bump the MODULE_MAGIC_NUMBER_MAJOR prior
+to rolling the tarball, to assure beta testers are testing the
+corresponding.so modules.<I>This policy will be retracted, and coders will
+be reponsible for mmn bumps, once Apache 2.0 is officially released.</I>
+
+1. Make sure your PGP keys are already present in the `KEYS` file. If they
+are not, extract your public key using the `` `pgp -kxa` '' command, add
+them to the `KEYS` file and commit it before tagging.
+
+1. Tag the sources for this release:<br></br>( *note: be sure to tag the
+whole thing, not just `src` * !)<br></br><code> **$ cvs tag APACHE_1_ *X_Y*
+** </code><br></br>For Apache 2.0:<br></br><code> **$ cvs tag APACHE_2_
+*X_Y* ** </code>
+
+1. Make an export version of the distribution: (this creates a second
+subdirectory<code>apache-Z. *X.Y* </code>for the exported version beside
+the existing CVS tree in<code>apache-Z. *X* </code>)<br></br>
+For Apache 2.0:<br></br><code> **$ cd..** </code><br></br><code> **$ umask
+022** </code><br></br><code> **$ cvs export -r APACHE_2_ *X_Y* -d apache_2.
+*X.Y* httpd-2. *X* ** </code><br></br><code> **$ cd apache_2. *X.Y*
+/srclib** </code><br></br><code> **$ cvs export -r APACHE_2_ *X_Y* apr
+apr-util** </code>
+
+- <font color="red">Note:</font>There is a known problem using `cvs export`
+remotely with `cvs-1.9` and later. If this affects you, you will need to do
+a checkout instead:<br></br><code> **$ umask 022** </code><br></br><code>
+**$ cvs checkout -r APACHE_2_ *X_Y* -d apache_2. *X.Y* httpd-2. *X* **
+</code><br></br><code> **$ cd apache_2. *X.Y* /srclib**
+</code><br></br><code> **$ cvs checkout -r APACHE_2 *X_Y* apr apr-util**
+</code>
+
+1. Make sure the master site's FAQ is up-to-date:<br></br><code> **$ (cd
+/www/httpd.apache.org/docs/misc ; cvs update)** </code>
+
+1. Extract the FAQ as a single file, as it appears on the
+Web:<br></br><code> **$ links -source
+http://httpd.apache.org/docs/misc/FAQ.html >
+htdocs/manual/misc/FAQ.html** </code>
+
+1. Create the configuration files:<br></br>
+For Apache 2.0:<br></br>Create `./configure` file, and remove all
+symlinks<br></br><code> **$./buildconf** </code><br></br><code> **$ rm -f
+ltconfig ltmain.sh config.sub config.guess** </code><br></br><code> **$ cp
+/usr/local/share/libtool/ltconfig.** </code><br></br><code> **$ cp
+/usr/local/share/libtool/ltmain.sh.** </code><br></br><code> **$ cp
+/usr/local/share/libtool/config.sub.** </code><br></br><code> **$ cp
+/usr/local/share/libtool/config.guess.** </code><br></br>
+
+1. Remove `STATUS` , `RULES.CVS` , `src/INDENT` , the multi-part FAQ,
+various `.cvsignore` and the developer's test subdirectories. Depending on
+which version you are releasing, not all of these files will be in the
+repository:<br></br><code> **$ rm STATUS RULES.CVS src/INDENT
+htdocs/manual/misc/FAQ-*.html** </code><br></br><code> **$ find. -name
+".cvsignore" -exec rm {} \;** </code><br></br><code> **$ find. -type d
+-name "test" -exec rm -Rf {} \;** </code>
+
+- <font color="red">Note:</font>If you needed to do a `checkout` instead of
+a `export` , you will also need to remove the CVS administrative
+files:<br></br><code> **$ find. -type d -name "CVS" -exec rm -rf {} \;**
+</code>
+
+1. Roll the distribution tarball:<br></br><code> **$ tar cvf apache_
+*Z.X.Y*.tar apache_ *Z.X.Y* ** </code><br></br>
+
+1. Make the final packed distribution files:<br></br><code> **$ cp -p
+apache_ *Z.X.Y*.tar xapache_ *Z.X.Y*.tar** </code><br></br><code> **$ gzip
+-9 apache_ *Z.X.Y*.tar** </code><br></br><code> **$ mv xapache_ *Z.X.Y*.tar
+apache_ *Z.X.Y*.tar** </code><br></br><code> **$ compress apache_
+*Z.X.Y*.tar** </code><br></br>
+
+1. Test the packed tar files and check for errors:<br></br><code> **$
+gunzip -c apache_ *Z.X.Y*.tar.gz | tar tvf -** </code><br></br>(or
+simply:<code> **$ tar tvzf apache_ *Z.X.Y*.tar.gz** </code>)<br></br><code>
+**$ uncompress <apache_ *Z.X.Y*.tar.Z | tar tvf -** </code><br></br>
+
+1. Sign the distribution files:<br></br><code> **$ pgp -sba apache_
+*Z.X.Y*.tar.gz** </code><br></br><code> **$ pgp -sba apache_
+*Z.X.Y*.tar.Z** </code><br></br>
+
+- <font color="red">Note:</font>Be sure your PGP key is already in the
+`KEYS` file!
+
+1. Test the tarball signatures:<br></br><code> **$ pgp apache_
+*Z.X.Y*.tar.gz.asc apache_ *Z.X.Y*.tar.gz** </code><br></br><code> **$ pgp
+apache_ *Z.X.Y*.tar.Z.asc apache_ *Z.X.Y*.tar.Z** </code><br></br>
+
+1. Remember the CHANGES file:<br></br><code> **$ cp apache_ *Z.X.Y*
+/src/CHANGES./CHANGES_ *Z.X* ** </code>
+
+1. Cleanup:<br></br>(this deletes the export tree: it is now no longer
+required. We still need the CVS tree, see below)<br></br><code> **$ rm -fr
+apache_ *Z.X.Y* ** </code>
+
+1. Make the tarball available for testing purposes (in
+[http://httpd.apache.org/dev/dist/](http://httpd.apache.org/dev/dist/) ) by
+committing the generated release tarballs and signatures to the
+https://dist.apache.org/repos/dist/dev/httpd/ repository.
+
+1. Bump the version number to the next version and indicate we are in
+development.<br></br>cd back into the CVS tree location.<br></br><code> **$
+cd apache- *Z.X* ** </code>
+For Apache 2.0:<br></br>Change `SERVER_BASEREVERSION` in `include/httpd.h`
+from ``<code>2. *X.Y* </code>'' to ``<code>2. *X.(Y+1)* -dev</code>'' and
+change `APACHE_RELEASE` to<code>1 *XX(YY+1)* 000</code>.<br></br>Edit
+the<SAMP>STATUS</SAMP>file and update the status for the tagged apache_1.
+*X.Y* version, and add a header line for the new apache_1. *X.(Y+1)*
+version<br></br><code> **$ vi STATUS** </code><br></br><code> **$ cvs
+commit STATUS** </code><br></br><br></br><code> **$ cd..**
+</code><br></br>Finally, add a new line ``<code>Changes with Apache 1.
+*X.(Y+1)* :</code>'' to the head of the<SAMP>CHANGES</SAMP>file for the
+forthcoming fixes in the new version.<br></br><code> **$ vi include/httpd.h
+\<br></br>CHANGES** </code><br></br><code> **$ cvs commit include/httpd.h
+\<br></br>CHANGES** </code><br></br><code> **$ cd..** </code><br></br>
+
+1. Cleanup:<br></br>(delete the CVS tree, after verification that it does
+not contain any uncommitted changes)<br></br><code> **$ cvs release -d
+apache- *Z.X* ** </code>
+
+**Now wait for the group to test and approve the tarball.**
+
+# Final release steps # {#release}
+
+*<font color="red">Note:</font>Do not continue with the rest of these
+instructions until the group really approves the tarball!*
+
+1. Make the distribution available (in
+[http://www.apache.org/dist/httpd/](http://www.apache.org/dist/httpd/) ) by
+svn mv'ing the files from https://dist.apache.org/repos/dist/dev/httpd/ to
+the https://dist.apache.org/repos/dist/release/httpd/ repository.
+
+1. If binary builds are already built and tested at this point, you can add
+them in svn under the distribution tree branches
+https://dist.apache.org/repos/dist/release/httpd/binaries/{OS}/.
+
+1. Checkout the [httpd-dist site](http://www.apache.org/dist/httpd/) , if
+needed, into a scratch directory:<br></br><code> **$ cvs -d
+cvs.apache.org:/home/cvs checkout -P httpd-dist** </code>
+
+1. Change directory into `httpd-dist` <br></br><code> **$ cd httpd-dist/**
+</code>
+
+1. Edit the files [](http://www.apache.org/dist/httpd/README.html) and
+[](http://www.apache.org/dist/httpd/HEADER.html) as well as
+[](http://www.apache.org/dist/httpd/Announcement.html) and its plaintext
+equivalent [](http://www.apache.org/dist/httpd/Announcement.txt) plus the
+[](http://www.apache.org/dist/httpd/.htaccess) file (which defines the
+`AddDescription` comments) from the `httpd-dist` CVS tree as required (all
+in the [](http://www.apache.org/dist/httpd/) subdirectory). The
+`Announcement.*` files should be based on the `Announcement` file in the
+tagged CVS tree. For Apache 2.0, `Announcement` should be replaced with
+`Announcement2` :<br></br><code> **$ vi README.html HEADER.html
+Announcement.html Announcement.txt.htaccess** </code><br></br>
+
+1. Commit the changes:<br></br><code> **$ cvs commit README.html
+HEADER.html Announcement.html Announcement.txt.htaccess**
+</code><br></br><code> **$ cd../..** </code>
+
+1. Checkout the [httpd site](http://httpd.apache.org/) if needed into a
+scratch directory:<br></br><code> **$ cvs -d cvs.apache.org:/home/cvs
+checkout httpd-site** </code>
+
+1. cd into the `httpd-site` xdocs tree.<br></br><code> **$ cd
+httpd-site/xdocs/** </code>
+
+1. Edit the [](http://httpd.apache.org/) page from the `httpd-site` CVS
+tree as required:<br></br><code> **$ vi index.xml** </code><br></br>
+
+1. Commit the changes:<br></br><code> **$ cd..** </code><br></br><code>
+**$./build.sh # Check result before continuing** </code><br></br><code> **$
+cvs commit** </code><br></br>
+
+1. Update the checked-out versions of the `httpd-dist` documents for the
+web server:<br></br><code> **$ umask 002** </code><br></br><code> **$ cd
+/www/www.apache.org/dist/httpd/** </code><br></br><code> **$ cvs update
+-dP** </code>
+
+1. Create an empty directory for future patches:<br></br><code> **$ mkdir
+patches/apply_to_1. *X.Y* ** </code>
+
+1. Update the checked-out version of the `httpd-site index.html` page for
+the web server:<br></br><code> **$ umask 002** </code><br></br><code> **$
+cd /www/httpd.apache.org/** </code><br></br><code> **$ cvs update -dP**
+</code>
+
+At this point, the web-sites reflect the existance of the new release.
+
+As it is going to be some 24hrs before any announcement goes out (to make
+sure that the mirror's have at least a chance of grabbing a copy) this is
+also the right time to mail dev@httpd.apache.org and ask people to upload
+and move into position any binaries they have build and vetted.
+
+# Announcing a New Release # {#announce}
+
+Once a release is [built](#unix) and [released](#release) , it is time to
+announce it to the world.
+
+1. Grab the prepared Announcement:<br></br>
+You can grab either the `Announcement` file in the tagged tree, or the
+`Announcement.txt` file from the web-site.
+
+1. Post the Announcement:<br></br>
+Once the tarball is built, give the mirrors a good 24 hours to get up to
+sync. This is really important if this this a final (i.e.: non-beta)
+release.
+
+1. Now, `Announcement` should be posted to the following places (please
+note that a mail send to announce@apache.org *must* have your apache.org
+address set as its 'From' address, otherwise it won't pass the anti-spam
+filter):
+
+- Unmoderated UseNet newsgroups (should be crossposted)
+
+ - `comp.infosystems.www.servers.unix`
+
+ - `comp.infosystems.www.servers.ms-windows`
+
+ - `comp.infosystems.www.servers.misc`
+
+ - `de.comm.infosystems.www.servers`
+
+- Moderated UseNet newsgroups (do **not** crosspost)
+
+ - `comp.infosystems.www.announce`
+
+- Mailing Lists
+
+ - `announce@apache.org`
+
+ - `announce@httpd.apache.org`
+
+ - `users@httpd.apache.org`
+
+ - `users-de@httpd.apache.org`
+
+1. Make sure that `Announcement.txt` and `Announcement.html` in
+`httpd-dist` are updated to include these changes.
+
+1. Bask in the glow
-</body>
-</document>
Copied: httpd/site/trunk/content/dev/index.mdtext (from r1334802, httpd/site/trunk/content/dev/index.xml)
URL: http://svn.apache.org/viewvc/httpd/site/trunk/content/dev/index.mdtext?p2=httpd/site/trunk/content/dev/index.mdtext&p1=httpd/site/trunk/content/dev/index.xml&r1=1334802&r2=1334814&rev=1334814&view=diff
==============================================================================
--- httpd/site/trunk/content/dev/index.xml (original)
+++ httpd/site/trunk/content/dev/index.mdtext Sun May 6 22:53:19 2012
@@ -1,106 +1,82 @@
-<?xml version="1.0"?>
-<document>
- <properties>
- <author email="docs@httpd.apache.org">Documentation Group</author>
- <title>Apache HTTP Server Developer Information</title>
- </properties>
-<body>
-
-<section>
-<title>Developer Resources</title>
-
-<blockquote>
-This section includes many of the reference materials used by the
-Apache HTTP Server Project. Be sure to also check the developer
-information included with the <a
-href="http://httpd.apache.org/docs-project/">documentation</a>.
-</blockquote>
-</section>
-
-<section>
-<title>Developer News</title>
-
-<p>The Apache HTTP Server Project has switched to Subversion for hosting its
-source code.</p>
-
-<p>For more information about the changes, please see the
-<a href="devnotes.html">Apache Development Notes</a>.</p>
-</section>
-
-<section>
-<title>Feedback and contributions</title>
- <ul type="square">
- <li>Contributing <a href="/bug_report.html">bug reports</a></li>
- <li>Contributing <a href="patches.html">code patches</a></li>
- <li>Contributing to the <a href="/docs-project/">documentation</a></li>
- <li>Tips to <a href="debugging.html">debug</a> your server</li>
- </ul>
-</section>
-
-<section>
-<title>General guidelines for the Apache HTTP Server Project</title>
- <ul type="square">
- <li><a href="guidelines.html">Project guidelines</a>
- </li>
- <li><a href="release.html">Release guidelines</a>
- </li>
- <li><a href="styleguide.html">Style guide</a>
- </li>
- </ul>
-</section>
-
-<section>
-<title>Source Repository Information</title>
- <ul type="square">
- <li><a href="devnotes.html">Apache Development Notes</a> about
- using SVN and maintaining the Apache site.
- </li>
- <li>A web-based view of the
- <a href="http://svn.apache.org/viewcvs.cgi/httpd/">SVN history</a>
- of the httpd development effort
- </li>
- </ul>
-</section>
-
-<section>
-<title>Release Instructions</title>
-
- <ul type="square">
- <li><a href="release.html">Release guidelines</a>
- </li>
- <li>Instructions for
- <a href="how-to-release.html">rolling the release tarballs</a>
- </li>
- <li><a href="http://svn.apache.org/repos/asf/httpd/site/trunk/tools"
- >Tools</a> to roll/release tarballs
- </li>
- <li><a href="verification.html">Verifying Apache HTTP Server releases</a>
- </li>
- </ul>
-</section>
-
-<section>
-<title>Historical Documents</title>
-
- <ul type="square">
- <li>An extremely obselete draft of the
- <a href="project-plan.html">project plan</a>
- </li>
- <li>notes on <a href="API.html">the 1.3 API</a>
- </li>
- <li>A prototype <a href="apidoc/">reference dictionary</a>
- for the Apache HTTP Server API
- <br />
- (note: this link may not take you anywhere useful; the
- documents may be missing or in a state of flux.
- <EM>Caveat spectator</EM>.)
- </li>
-
- <li>The old <a href="todo.html">to-do list</a> of the Apache developers.
- </li>
- <li><a href="voting.html">Old voting guidelines</a>
- </li>
- </ul>
-</section>
-</body>
-</document>
+Title: Apache HTTP Server Developer Information
+Notice: Licensed to the Apache Software Foundation (ASF) under one
+ or more contributor license agreements. See the NOTICE file
+ distributed with this work for additional information
+ regarding copyright ownership. The ASF licenses this file
+ to you under the Apache License, Version 2.0 (the
+ "License"); you may not use this file except in compliance
+ with the License. You may obtain a copy of the License at
+ .
+ http://www.apache.org/licenses/LICENSE-2.0
+ .
+ Unless required by applicable law or agreed to in writing,
+ software distributed under the License is distributed on an
+ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ KIND, either express or implied. See the License for the
+ specific language governing permissions and limitations
+ under the License.
+
+>This section includes many of the reference materials used by the Apache
+HTTP Server Project. Be sure to also check the developer information
+included with the [documentation](http://httpd.apache.org/docs-project/).
+
+# Developer News #
+
+The Apache HTTP Server Project has switched to Subversion for hosting its
+source code.
+
+For more information about the changes, please see the [Apache Development
+Notes](devnotes.html).
+
+# Feedback and contributions #
+
+- Contributing [bug reports](/bug_report.html)
+
+- Contributing [code patches](patches.html)
+
+- Contributing to the [documentation](/docs-project/)
+
+- Tips to [debug](debugging.html) your server
+
+# General guidelines for the Apache HTTP Server Project #
+
+- [Project guidelines](guidelines.html)
+
+- [Release guidelines](release.html)
+
+- [Style guide](styleguide.html)
+
+# Source Repository Information #
+
+- [Apache Development Notes](devnotes.html) about using SVN and
+maintaining the Apache site.
+
+- A web-based view of the [SVN
+history](http://svn.apache.org/viewcvs.cgi/httpd/) of the httpd development
+effort
+
+# Release Instructions #
+
+- [Release guidelines](release.html)
+
+- Instructions for [rolling the release tarballs](how-to-release.html)
+
+- [Tools](http://svn.apache.org/repos/asf/httpd/site/trunk/tools) to
+roll/release tarballs
+
+- [Verifying Apache HTTP Server releases](verification.html)
+
+# Historical Documents #
+
+- An extremely obselete draft of the [project plan](project-plan.html)
+
+- notes on [the 1.3 API](API.html)
+
+- A prototype [reference dictionary](apidoc/) for the Apache HTTP Server
+API<br></br>(note: this link may not take you anywhere useful; the
+documents may be missing or in a state of flux.<EM>Caveat spectator</EM>.)
+
+- The old [to-do list](todo.html) of the Apache developers.
+
+- [Old voting guidelines](voting.html)
+