You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@httpd.apache.org by bu...@apache.org on 2012/05/07 00:53:33 UTC
svn commit: r816182 [2/2] - in /websites/staging/httpd/trunk/content: ./ dev/
Added: websites/staging/httpd/trunk/content/dev/index.html
==============================================================================
--- websites/staging/httpd/trunk/content/dev/index.html (added)
+++ websites/staging/httpd/trunk/content/dev/index.html Sun May 6 22:53:33 2012
@@ -0,0 +1,173 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
+ <link href="/css/apsite.css" rel="stylesheet" media="all" type="text/css" title="Main stylesheet" />
+ <meta name="author" content="Documentation Group" /><meta name="email" content="docs@httpd.apache.org" />
+ <title>Apache HTTP Server Developer Information - The Apache HTTP Server Project</title>
+ </head>
+ <body>
+
+ <div id="page-header">
+ <p class="menu"> </p>
+ <p class="apache"> </p>
+ <a href="/">
+ <img alt="" width="800" height="72" src="/images/httpd_logo_wide_new.png" border="0" />
+ </a>
+ </div>
+
+
+ <!-- LEFT SIDE NAVIGATION -->
+ <div id="apmenu">
+
+ <h1 id="essentials">Essentials</h1>
+<ul>
+<li><a href="/ABOUT_APACHE.html">About</a></li>
+<li><a href="http://www.apache.org/licenses/">License</a></li>
+<li><a href="http://wiki.apache.org/httpd/FAQ">FAQ</a></li>
+<li><a href="/security_report.html">Security Reports</a></li>
+</ul>
+<h1 id="download">Download!</h1>
+<ul>
+<li><a href="/download.cgi">From a Mirror</a></li>
+</ul>
+<h1 id="documentation"><a href="/docs/">Documentation</a></h1>
+<ul>
+<li><a href="/docs/2.4/">Version 2.4</a></li>
+<li><a href="/docs/2.2/">Version 2.2</a></li>
+<li><a href="/docs/2.0/">Version 2.0</a></li>
+<li><a href="/docs/trunk/">Trunk (dev)</a></li>
+</ul>
+<h1 id="get-support">Get Support</h1>
+<ul>
+<li><a href="/support.html">Support</a></li>
+</ul>
+<h1 id="get-involved">Get Involved</h1>
+<ul>
+<li><a href="/lists.html">Mailing Lists</a></li>
+<li><a href="/bug_report.html">Bug Reports</a></li>
+<li><a href="/dev/">Developer Info</a></li>
+</ul>
+<h1 id="subprojects">Subprojects</h1>
+<ul>
+<li><a href="/docs-project/">Docs</a></li>
+<li><a href="/test/">Test</a></li>
+<li><a href="/test/flood/">Flood</a></li>
+<li><a href="/apreq/">libapreq</a></li>
+<li><a href="/modules">Modules</a></li>
+<li><a href="/mod_fcgid/">mod_fcgid</a></li>
+<li><a href="/mod_ftp/">mod_ftp</a></li>
+</ul>
+<h1 id="miscellaneous"><a href="/info/">Miscellaneous</a></h1>
+<ul>
+<li><a href="/contributors/">Contributors</a></li>
+<li><a href="http://www.apache.org/foundation/thanks.html">Sponsors</a></li>
+<li><a href="http://www.apache.org/foundation/sponsorship.html">Sponsorship</a></li>
+</ul>
+
+ </div>
+
+
+ <!-- RIGHT SIDE INFORMATION -->
+ <div id="apcontents">
+
+ <blockquote>
+<p>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>.</p>
+</blockquote>
+<h1 id="developer-news">Developer News</h1>
+<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>
+<h1 id="feedback-and-contributions">Feedback and contributions</h1>
+<ul>
+<li>
+<p>Contributing <a href="/bug_report.html">bug reports</a> </p>
+</li>
+<li>
+<p>Contributing <a href="patches.html">code patches</a> </p>
+</li>
+<li>
+<p>Contributing to the <a href="/docs-project/">documentation</a> </p>
+</li>
+<li>
+<p>Tips to <a href="debugging.html">debug</a> your server</p>
+</li>
+</ul>
+<h1 id="general-guidelines-for-the-apache-http-server-project">General guidelines for the Apache HTTP Server Project</h1>
+<ul>
+<li>
+<p><a href="guidelines.html">Project guidelines</a> </p>
+</li>
+<li>
+<p><a href="release.html">Release guidelines</a> </p>
+</li>
+<li>
+<p><a href="styleguide.html">Style guide</a> </p>
+</li>
+</ul>
+<h1 id="source-repository-information">Source Repository Information</h1>
+<ul>
+<li>
+<p><a href="devnotes.html">Apache Development Notes</a> about using SVN and
+maintaining the Apache site.</p>
+</li>
+<li>
+<p>A web-based view of the <a href="http://svn.apache.org/viewcvs.cgi/httpd/">SVN
+history</a> of the httpd development
+effort</p>
+</li>
+</ul>
+<h1 id="release-instructions">Release Instructions</h1>
+<ul>
+<li>
+<p><a href="release.html">Release guidelines</a> </p>
+</li>
+<li>
+<p>Instructions for <a href="how-to-release.html">rolling the release tarballs</a> </p>
+</li>
+<li>
+<p><a href="http://svn.apache.org/repos/asf/httpd/site/trunk/tools">Tools</a> to
+roll/release tarballs</p>
+</li>
+<li>
+<p><a href="verification.html">Verifying Apache HTTP Server releases</a> </p>
+</li>
+</ul>
+<h1 id="historical-documents">Historical Documents</h1>
+<ul>
+<li>
+<p>An extremely obselete draft of the <a href="project-plan.html">project plan</a> </p>
+</li>
+<li>
+<p>notes on <a href="API.html">the 1.3 API</a> </p>
+</li>
+<li>
+<p>A prototype <a href="apidoc/">reference dictionary</a> 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>.)</p>
+</li>
+<li>
+<p>The old <a href="todo.html">to-do list</a> of the Apache developers.</p>
+</li>
+<li>
+<p><a href="voting.html">Old voting guidelines</a> </p>
+</li>
+</ul>
+
+
+ <!-- FOOTER -->
+ <div id="footer">
+ <p class="apache">
+
+ <p>Copyright © 2012 The Apache Software Foundation
+Apache HTTP Server, Apache, and the Apache feather logo are trademarks of The Apache Software Foundation.</p>
+
+ </p>
+ </div>
+ </div>
+ </body>
+ </html>
Added: websites/staging/httpd/trunk/content/dev/patches.html
==============================================================================
--- websites/staging/httpd/trunk/content/dev/patches.html (added)
+++ websites/staging/httpd/trunk/content/dev/patches.html Sun May 6 22:53:33 2012
@@ -0,0 +1,245 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
+ <link href="/css/apsite.css" rel="stylesheet" media="all" type="text/css" title="Main stylesheet" />
+ <meta name="author" content="Documentation Group" /><meta name="email" content="docs@httpd.apache.org" />
+ <title>How to Contribute Patches to Apache - The Apache HTTP Server Project</title>
+ </head>
+ <body>
+
+ <div id="page-header">
+ <p class="menu"> </p>
+ <p class="apache"> </p>
+ <a href="/">
+ <img alt="" width="800" height="72" src="/images/httpd_logo_wide_new.png" border="0" />
+ </a>
+ </div>
+
+
+ <!-- LEFT SIDE NAVIGATION -->
+ <div id="apmenu">
+
+ <h1 id="essentials">Essentials</h1>
+<ul>
+<li><a href="/ABOUT_APACHE.html">About</a></li>
+<li><a href="http://www.apache.org/licenses/">License</a></li>
+<li><a href="http://wiki.apache.org/httpd/FAQ">FAQ</a></li>
+<li><a href="/security_report.html">Security Reports</a></li>
+</ul>
+<h1 id="download">Download!</h1>
+<ul>
+<li><a href="/download.cgi">From a Mirror</a></li>
+</ul>
+<h1 id="documentation"><a href="/docs/">Documentation</a></h1>
+<ul>
+<li><a href="/docs/2.4/">Version 2.4</a></li>
+<li><a href="/docs/2.2/">Version 2.2</a></li>
+<li><a href="/docs/2.0/">Version 2.0</a></li>
+<li><a href="/docs/trunk/">Trunk (dev)</a></li>
+</ul>
+<h1 id="get-support">Get Support</h1>
+<ul>
+<li><a href="/support.html">Support</a></li>
+</ul>
+<h1 id="get-involved">Get Involved</h1>
+<ul>
+<li><a href="/lists.html">Mailing Lists</a></li>
+<li><a href="/bug_report.html">Bug Reports</a></li>
+<li><a href="/dev/">Developer Info</a></li>
+</ul>
+<h1 id="subprojects">Subprojects</h1>
+<ul>
+<li><a href="/docs-project/">Docs</a></li>
+<li><a href="/test/">Test</a></li>
+<li><a href="/test/flood/">Flood</a></li>
+<li><a href="/apreq/">libapreq</a></li>
+<li><a href="/modules">Modules</a></li>
+<li><a href="/mod_fcgid/">mod_fcgid</a></li>
+<li><a href="/mod_ftp/">mod_ftp</a></li>
+</ul>
+<h1 id="miscellaneous"><a href="/info/">Miscellaneous</a></h1>
+<ul>
+<li><a href="/contributors/">Contributors</a></li>
+<li><a href="http://www.apache.org/foundation/thanks.html">Sponsors</a></li>
+<li><a href="http://www.apache.org/foundation/sponsorship.html">Sponsorship</a></li>
+</ul>
+
+ </div>
+
+
+ <!-- RIGHT SIDE INFORMATION -->
+ <div id="apcontents">
+
+ <p>Third-party patches are essential to the success of Apache - the "core"
+developers don't have access to all platforms, and we certainly aren't
+using Apache in all the different ways it can be used. To that end, we try
+to make it as easy as possible to contribute code. However, we do have some
+expectations of contributors, and a process to all this, simply to help us
+manage the flood of contributions we could get. This page describes that
+process.</p>
+<h1 id="code-style">Code Style</h1>
+<p>We have a fairly firmly-set code format we use in our code; it was one we
+arrived at through no small amount of debate. The format is described in
+our official <a href="styleguide.html">style guide</a>. While there is some code in
+the project that does not follow the style guide, it is generally safe to
+assume that your code is wrong if it is not formatted like the other code
+in the file.</p>
+<p>We also have very high expectations for code quality; and to us this means
+the avoidance of excessive static buffers, using the memory pool mechanism
+(which ensures proper cleanup), and otherwise writing thread-safe code. We
+also expect one or two levels of optimizations to be applied, too - is a
+bitmask faster for this? Is a strchr() faster than an index()? Etc. Of
+course it'd be nice if we had a real document describing this all, but we
+don't yet.</p>
+<h1 id="documentation">Documentation</h1>
+<p>The Apache documentation needs to be updated for some patches, most often
+for enhancements. You may wish to see if your patch is considered generally
+acceptable before updating the documentation. Patches for the documentation
+are submitted with any code changes in the same patch format.</p>
+<p>Please note that for Apache 2.0 and above, most of the documentation is
+generated from XML. Your changes need to be made to the XML version. See
+<a href="http://httpd.apache.org/docs-project/docsformat.html">http://httpd.apache.org/docs-project/docsformat.html</a>
+for more information.</p>
+<h1 id="choosing-a-level-of-apache-code-for-comparison">Choosing a level of Apache code for comparison</h1>
+<p>Currently, there are three active Apache httpd source trees:</p>
+<ol>
+<li>
+<p>Apache httpd 2.0.x (legacy/maintenance)</p>
+</li>
+<li>
+<p>Apache httpd 2.2.x (previous release)</p>
+</li>
+<li>
+<p>Apache httpd 2.4.x (current release, GA)</p>
+</li>
+<li>
+<p>Apache httpd 2.5.x (development/beta version)</p>
+</li>
+</ol>
+<p>A patch should be created against the last public release or, if practical,
+the latest code in subversion for the relevant source tree. Patches created
+against older releases may not apply to current sources.</p>
+<p>Instructions for obtaining a source tree from subversion are at <a href="http://httpd.apache.org/dev/devnotes.html">Apache
+Development Notes</a> </p>
+<h1 id="patch-format">Patch Format</h1>
+<p>We prefer that patches be submitted in unified diff format:
+<BLOCKQUOTE><CODE>diff -u file-old.c file.c</CODE></BLOCKQUOTE>
+but that isn't available on all platforms. If your platform doesn't support
+unified diffs, please use a context diff instead:
+<BLOCKQUOTE><CODE>diff -C3 file-old.c file.c</CODE></BLOCKQUOTE>
+where<CODE>file.c</CODE>is the file affected. We should be able to feed the
+patch directly into the "patch" program and have it update the file or set
+of files. The <code>-C3</code> is very important - line numbers can change on a daily
+basis in some code files, so having context is crucial to knowing where it
+all really goes.</p>
+<p>If multiple files are modified, the following setup can simplify the
+management of original and modified files:</p>
+<ol>
+<li>
+<p><BLOCKQUOTE><CODE>cd /sources</CODE></BLOCKQUOTE></p>
+</li>
+<li>
+<p><BLOCKQUOTE><CODE>tar xvzf httpd-2.0.x.tar.gz</CODE></BLOCKQUOTE></p>
+</li>
+<li>
+<p><BLOCKQUOTE><CODE>cp -ax httpd-2.0.x httpd-2.0.x.new</CODE></BLOCKQUOTE></p>
+</li>
+<li>
+<p>edit files in httpd-2.0.x.new and build/test</p>
+</li>
+<li>
+<p><BLOCKQUOTE><CODE>cd /sources</CODE></BLOCKQUOTE></p>
+</li>
+<li>
+<p><BLOCKQUOTE><CODE>diff -ru httpd-2.0.x httpd-2.0.x.new
+>my.unified.diff.patch</CODE></BLOCKQUOTE></p>
+</li>
+</ol>
+<p>If your source tree was checked out of subversion,<BLOCKQUOTE><CODE>svn
+diff</CODE></BLOCKQUOTE>will create the patch in the correct format.</p>
+<h1 id="submitting-your-patch">Submitting your Patch</h1>
+<p>Traditionally, patches have been submitted on the developer's mailing list
+as well as through the bug database. Unfortunately, this has made it hard
+to easily track the patches. And without being able to easily track them,
+too many of them have been ignored.</p>
+<p>Patches must now be submitted through the bug database, at
+<a href="http://issues.apache.org/bugzilla/">http://issues.apache.org/bugzilla/</a>.
+You'll need to create a Bugzilla account there if you don't already have
+one. Submit the patch by first entering a new bug report. Be sure to
+specify APR for the product if the patch is for a file in srclib/apr or
+srclib/apr-util. The following information is very helpful, when it is
+available:</p>
+<ol>
+<li>explain how to reproduce the problem and how the patch has been tested</li>
+</ol>
+<p>After the bug report has been created, edit it again and specify
+<strong>PatchAvailable</strong> as a keyword and then add your patch as a new
+attachment.</p>
+<p>If you wish to discuss the patch on the developer's mailing list, prefix
+your subject line with "[PATCH <PR-number>]" to reference your patch
+submission.</p>
+<p>Be aware that the core developers tend to be very conservative about what
+makes it into the core of Apache. Apache has a very flexible API, and any
+advanced functionality is likely to be pushed to be a third-party module.
+Portability fixes are the most important; protocol correctness is also
+critical for us; and we're sure there's more dumb mistakes in the code than
+we could shake a stick at. Those will get priority; new functionality may
+not.</p>
+<h1 id="ignored">What if my patch gets ignored?</h1>
+<p>Because Apache has only a small number of volunteer developers, and these
+developers are often very busy, it is possible that your patch will not
+receive any immediate feedback. Developers must prioritize their time,
+dealing first with serious bugs and with parts of the code in which they
+have interest and knowledge. Here are some suggestions on what you can do
+to encourage action on your patch:</p>
+<ol>
+<li>
+<p>Be persistent but polite. Post to the developers list pointing out your
+patch and why you feel it is important. Feel free to do this about once a
+week and continue until you get a response. Just be sure to be polite about
+it, since the developers are unlikely to respond to rude messages.</p>
+</li>
+<li>
+<p>Encourage other Apache users to review and test your patch, and then
+append a note to the bug report with the details. Developers are much more
+likely to review and commit a patch if they see that it has been widely
+tested.</p>
+</li>
+<li>
+<p>Make sure your patch is easy to read and apply. Follow all the style
+suggestions in the above sections and include any necessary documentation
+changes.</p>
+</li>
+<li>
+<p>Review the bugs database for similar errors. If there are duplicates,
+close them as duplicates of the initial report (this cross references the
+two bugs to each other.) Add an extra note when closing well documented
+dups if the particular bug report contains useful unique details. If there
+is a report that isn't identical, but might be helped by your patch, mark
+it as 'depends on' the bug report containing your patch. Finally mark the
+original incident as 'depends on' your bug report, with patch.</p>
+</li>
+<li>
+<p>Earn "brownie points" by dealing with other bug reports that you can
+politely and correctly address. As ugly as this job is -- sort of like the
+poop crew following a parade -- it leaves the principal committers with
+time to address the real bugs and their solutions instead of sweeping up
+the droppings.</p>
+</li>
+</ol>
+
+
+ <!-- FOOTER -->
+ <div id="footer">
+ <p class="apache">
+
+ <p>Copyright © 2012 The Apache Software Foundation
+Apache HTTP Server, Apache, and the Apache feather logo are trademarks of The Apache Software Foundation.</p>
+
+ </p>
+ </div>
+ </div>
+ </body>
+ </html>
Added: websites/staging/httpd/trunk/content/dev/release.html
==============================================================================
--- websites/staging/httpd/trunk/content/dev/release.html (added)
+++ websites/staging/httpd/trunk/content/dev/release.html Sun May 6 22:53:33 2012
@@ -0,0 +1,333 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
+ <link href="/css/apsite.css" rel="stylesheet" media="all" type="text/css" title="Main stylesheet" />
+ <meta name="author" content="Documentation Group" /><meta name="email" content="docs@httpd.apache.org" />
+ <title>Apache HTTP Server Release Guidelines - The Apache HTTP Server Project</title>
+ </head>
+ <body>
+
+ <div id="page-header">
+ <p class="menu"> </p>
+ <p class="apache"> </p>
+ <a href="/">
+ <img alt="" width="800" height="72" src="/images/httpd_logo_wide_new.png" border="0" />
+ </a>
+ </div>
+
+
+ <!-- LEFT SIDE NAVIGATION -->
+ <div id="apmenu">
+
+ <h1 id="essentials">Essentials</h1>
+<ul>
+<li><a href="/ABOUT_APACHE.html">About</a></li>
+<li><a href="http://www.apache.org/licenses/">License</a></li>
+<li><a href="http://wiki.apache.org/httpd/FAQ">FAQ</a></li>
+<li><a href="/security_report.html">Security Reports</a></li>
+</ul>
+<h1 id="download">Download!</h1>
+<ul>
+<li><a href="/download.cgi">From a Mirror</a></li>
+</ul>
+<h1 id="documentation"><a href="/docs/">Documentation</a></h1>
+<ul>
+<li><a href="/docs/2.4/">Version 2.4</a></li>
+<li><a href="/docs/2.2/">Version 2.2</a></li>
+<li><a href="/docs/2.0/">Version 2.0</a></li>
+<li><a href="/docs/trunk/">Trunk (dev)</a></li>
+</ul>
+<h1 id="get-support">Get Support</h1>
+<ul>
+<li><a href="/support.html">Support</a></li>
+</ul>
+<h1 id="get-involved">Get Involved</h1>
+<ul>
+<li><a href="/lists.html">Mailing Lists</a></li>
+<li><a href="/bug_report.html">Bug Reports</a></li>
+<li><a href="/dev/">Developer Info</a></li>
+</ul>
+<h1 id="subprojects">Subprojects</h1>
+<ul>
+<li><a href="/docs-project/">Docs</a></li>
+<li><a href="/test/">Test</a></li>
+<li><a href="/test/flood/">Flood</a></li>
+<li><a href="/apreq/">libapreq</a></li>
+<li><a href="/modules">Modules</a></li>
+<li><a href="/mod_fcgid/">mod_fcgid</a></li>
+<li><a href="/mod_ftp/">mod_ftp</a></li>
+</ul>
+<h1 id="miscellaneous"><a href="/info/">Miscellaneous</a></h1>
+<ul>
+<li><a href="/contributors/">Contributors</a></li>
+<li><a href="http://www.apache.org/foundation/thanks.html">Sponsors</a></li>
+<li><a href="http://www.apache.org/foundation/sponsorship.html">Sponsorship</a></li>
+</ul>
+
+ </div>
+
+
+ <!-- RIGHT SIDE INFORMATION -->
+ <div id="apcontents">
+
+ <p>This document describes the general release policies used by the Apache
+HTTP Server Project to create releases of httpd-2.2 (the current Apache 2.2
+branch). Aside from the voting guidelines, this policy may be adjusted by
+the Release Manager.</p>
+<p>With the introduction of Apache 2.1, the Apache httpd project has adopted
+an odd-even release strategy, where development happens with alpha and beta
+releases assigned an odd-numbered minor version, and its general
+availability (stable) release is designed with the subsequent even-numbered
+minor version. E.g. 2.1.0-alpha through 2.1.6-alpha were followed by
+2.1.7-beta through 2.1.9 beta, and cumulated in the 2.2.0 general
+availability release.</p>
+<h1 id="who-can-make-a-release">Who can make a release?</h1>
+<p>Technically, anyone can make a release of the source code due to the
+<a href="http://www.apache.org/licenses/">Apache Software License</a>. However, only
+members of the Apache HTTP Server Project (committers) can make a release
+designated as Apache HTTP Server (httpd). Other people must call their
+release something other than "Apache" unless they obtain written permission
+from the Apache Software Foundation.</p>
+<p>Following our official release policies, we will only accept release
+binaries from members of the Apache HTTP Server Project for inclusion on
+our website. This ensures that our binaries can be supported by members of
+the project. Other people are free to make binaries, but we will not post
+them on our website.</p>
+<h1 id="who-is-in-charge-of-a-release">Who is in charge of a release?</h1>
+<p>The release is coordinated by a Release Manager (hereafter, abbreviated as
+RM). Since this job requires trust, coordination of the development
+community, and access to subversion, only committers to the project can be
+RM. However, there is no set RM, and more than one RM can be active at a
+time. Any committer may create a release candidate, provided that it is
+based on a releasable (non-vetoed) tag of our current subversion repository
+corresponding to the target version number. In order to facilitate
+communication, it is deemed nice to alert the community to your planned
+release schedule before creating the release candidate, since some other
+folks may be on the verge of committing an important change (or backing out
+an error). A release candidate should only be made when there is an
+intention to propose it for a vote on public release. There are no
+"private" releases at Apache.</p>
+<h1 id="who-may-make-a-good-candidate-for-an-rm">Who may make a good candidate for an RM?</h1>
+<p>Someone with lots of time to kill. Being an RM is a very important job in
+our community because it takes a fair amount of time to produce a stable
+release. If you feel lucky, a release could be distributed without testing,
+but our experience has shown that this leads to a higher number of <em>dud</em>
+releases. In general, our experience has shown that a well-coordinated
+release fares better than non-coordinated releases.</p>
+<h1 id="when-do-i-know-if-it-is-a-good-time-to-release">When do I know if it is a good time to release?</h1>
+<p>Generally speaking, when some useful changes have been applied since the
+last release and there are no showstoppers left to be resolved. It is our
+convention to indicate <em>showstoppers</em> in the STATUS file in the repository.
+A showstopper entry does not imply that a release cannot be made -- it is
+more of an indication of current project consensus and a reminder of what
+fixes are on the critical path. Each RM gets to choose when to cut a
+release candidate based on the current content of subversion. The entire
+PMC gets to decide whether or not that candidate deserves to be released.</p>
+<p>An item being denoted in STATUS as a <em>showstopper</em> indicates that someone
+believes the issue must be resolved before the next release, and the RM is
+going to hold off until it is resolved or moved out of the showstopper
+category. These items may be bugs, outstanding vetos that have not yet been
+resolved, or enhancements that must make it into the release. Note that the
+RM may also add showstopper entries to indicate what issues must be
+resolved before they personally are willing to cut a release candidate,
+though they cannot prevent others from taking on the RM job and proposing a
+release candidate of their own.</p>
+<h1 id="what-power-does-the-rm-yield">What power does the RM yield?</h1>
+<p>The only power held by the RM is the right to determine when the current
+content of subversion is worth their own effort in cutting a release
+candidate. The only thing the RM has authority over is the building of a
+source package, based on the contents of our subversion, that can then be
+put up for vote. They can decide what snapshot revision to tag for a
+candidate. They can decide to branch early and build candidates based on
+the branch rather than a more active development tree, but they cannot
+prevent others from working on that branch as well. They can also decide
+not to build anything at all. They can do all sorts of organizational
+support, advocacy, pleading, or whatever in order to encourage the rest of
+the project committers to apply changes, test the candidate, vote for
+things under issue, etc.</p>
+<p>The RM is not a dictator (benevolent or not). They do not have the right to
+pick apart or select any variation of the product they might like to
+release: it has to be a specific tag or revision (moment in time) that is
+present in our subversion and applicable to the version number targeted for
+the release. If there is something they don't like in the tree, then they
+have the same right as other PMC members to change or veto that code first,
+make the change to subversion, and then build the release candidate.
+Likewise, the RM cannot include in the candidate any change that has been
+vetoed by others, and their candidate cannot be released if it contains any
+changes that have been vetoed since it was built. The RM has the right to
+kill their own candidate if they learn something during the release process
+that they think, for whatever reason, causes the build to be unreleasable.
+But the RM can't stop anyone else on the PMC from taking the same candidate
+and calling for its release under their own management as RM.</p>
+<h1 id="how-can-an-rm-be-confident-in-a-release">How can an RM be confident in a release?</h1>
+<p>The RM may perform sanity checks on release candidates. One highly
+recommended suggestion is to run the httpd-test suite against the
+candidate. The release candidate should pass all of the relevant tests
+before making it official, and certainly avoid new regressions (tests that
+previously passed, and now fail).</p>
+<p>Another good idea is to coordinate running a candidate on apache.org for a
+period of time. This will require coordination with the infrastructure
+team. In the past, the group has liked to see approximately 48-72 hours of
+usage in production to certify that the release is functional in the real
+world. Note that some committers may choose to not vote on a release until
+feedback has been gathered from the apache.org instance running the
+release. This is not a requirement (each committer is free to come up with
+their own personal voting guidelines), but it produces a feeling of
+confidence in the release that it will not be a <em>dud</em>.</p>
+<h1 id="how-to-do-a-release">How to do a release?</h1>
+<p>Once the tree has been suitably tested by the RM and any other interested
+parties, they should "roll" a candidate tarball for potential release.</p>
+<p>Key points:</p>
+<ol>
+<li>
+<p>Execute <code>./build.sh all</code> in case of the 2.2.x documentation and
+<code>./build.sh all convmap</code> in case of the 2.2.x documentation to ensure that
+the documentation transformations are up to date.</p>
+</li>
+<li>
+<p>Ensure that the RM's PGP/GPG key is in the httpd-dist/KEYS file.</p>
+</li>
+<li>
+<p>Set <code>AP_SERVER_DEVBUILD_BOOLEAN</code> to <code>0</code> in <code>include/ap_release.h</code> in
+case of 2.2.x and set <code>AP_SERVER_ADD_STRING</code> to <code>""</code> in case of 2.2.x.</p>
+</li>
+<li>
+<p>Create an official X.Y.Z tag based on the candidate tree.</p>
+</li>
+<li>
+<p>Revert the changes done to <code>include/ap_release.h</code> and bump
+<code>AP_SERVER_PATCHLEVEL_NUMBER</code>.</p>
+</li>
+<li>
+<p>Bump <code>ENTITY httpd.patch</code> in <code>docs/manual/style/version.ent</code>.</p>
+</li>
+<li>
+<p>Note the tag date in the STATUS file.</p>
+</li>
+<li>
+<p>Run the httpd/site/trunk/tools/release.sh script.</p>
+</li>
+<li>
+<p>Commit the generated release tarballs and signatures to the subversion
+https://dist.apache.org/repos/dist/dev/httpd/ repository.</p>
+</li>
+<li>
+<p>Email dev@httpd.apache.org with a [VOTE] Release X.Y.Z to call for
+testing and votes on this candidate.</p>
+</li>
+</ol>
+<h1 id="what-can-i-call-this-release">What can I call this release?</h1>
+<p>At this point, this tarball/archive is not yet a release.</p>
+<p>Based on the communities confidence in the code, the next step is to issue
+a release vote as alpha, beta or general availability (GA) candidate. The
+Apache HTTP Server Project has three classifications for its releases:</p>
+<ul>
+<li>
+<p>Alpha</p>
+</li>
+<li>
+<p>Beta</p>
+</li>
+<li>
+<p>General Availability (GA)</p>
+</li>
+</ul>
+<p>Alpha indicates that the release is not meant for mainstream usage or may
+have serious problems that prohibits its use. The initial releases off of
+the x.{odd}.z development branches are considered alpha quality.</p>
+<p>Beta indicates that the x.{odd}.z development branch is nearing completion
+and will soon ship as a x.{even}.0 GA release. This indicates that it is
+expected to compile and perform basic tasks. However, there may be problems
+with this release that inhibit its widespread adoption.</p>
+<p>General Availability (GA) indicates that this release is the best available
+version and is recommended for all usage. It also indicates that this
+release replaces all previous GA versions, and it's interfaces should
+remain stable throughout the life of this x.y version. (Those interfaces
+that are in flux are designated <em>experimental</em>.)</p>
+<p>Finally, remember version numbers are cheap. If x.y.13 is retracted due to
+a flaw or prior veto or simply because of 'one more change' to add to this
+next release, then the RM should designate x.y.14. Don't attempt to
+overload an earlier tarball with additional changes, simply keep moving.</p>
+<h1 id="who-can-vote">Who can vote?</h1>
+<p>For the ASF to release the candidate tarball/archive, at least three
+project members must vote affirmatively for release, and there must be more
+positive than negative votes for the release. There is no 'veto' to a
+release vote. A previous veto of specific code can and should be called out
+to the RM if it was mistakenly included. A new tarball release candidate
+should be rolled without the offending code if this is the case.</p>
+<p>Non-committers may cast a vote for a release's quality. In fact, this is
+extremely encouraged as it provides much-needed feedback to the community
+about the release's quality. However, only binding votes cast by PMC
+members count towards the designation.</p>
+<p>Finally, note that votes are on <em>source code</em> tarballs, and only the source
+code is authoritative. Binaries, while helpful, are considered other
+artifacts and must be generated from the exact source code contained in the
+release. If a patch is unavoidable for a specific platform, the applicable
+patches MUST be made available alongside the platform binaries.</p>
+<h1 id="how-do-we-make-it-public">How do we make it public?</h1>
+<p>Once the release has reached the highest-available designation (as deemed
+by the RM), the release can be moved to the httpd distribution directory on
+apache.org. The release tarballs and signatures can be svn mv'ed from the
+https://dist.apache.org/repos/dist/dev/httpd/ repository across to the
+https://dist.apache.org/repos/dist/release/httpd/ repository. In that
+release tree are also the patches/, subproject/ and binaries/ distribution
+trees.</p>
+<p>It should be ensured that the release is also added to Bugzilla by sending
+a mail to dev@httpd.apache.org requesting the same. The request is picked
+up there by one of the project members with Bugzilla administrator
+permissions and the release is added to Bugzilla. Also do not forget to
+bump the version number in the projects doap file (
+<code>httpd/site/trunk/docs/doap.rdf</code> ). Approximately 24 to 48 hours after the
+files have been moved, a public announcement can be made. We wait this
+period so that the mirrors can receive the new release before the
+announcement. An email can then be sent to the announcements lists
+(announce@apache.org, announce@httpd.apache.org). Drafts of the
+announcement are usually posted on the development list before sending the
+announcement to let the community clarify any issues that we feel should be
+addressed in the announcement.</p>
+<h1 id="should-the-announcement-wait-for-binaries">Should the announcement wait for binaries?</h1>
+<p>In short, no. The only files that are required for a public release are the
+source tarballs (.tar.Z,.tar.gz). Volunteers can provide the Win32 source
+distribution and binaries, and other esoteric binaries.</p>
+<p>Note that the typical Win32 source distribution differs from the original
+tarball in that it has generated project files as well as the CRLF line
+endings required for that platform. More information can be found
+<a href="http://httpd.apache.org/docs-2.0/platform/win_compiling.html">here</a>.</p>
+<h1 id="oops-we-found-a-problem">Oops. We found a problem.</h1>
+<p>At this point, the release has been created. No code changes can be made in
+this release. If a problem is found, it will have to be addressed in the
+next release or a patch can be made available. No changes can be made
+between alpha, beta, and GA status. The only difference is the file name
+that is downloaded by the users. If an alpha tarball is created, but there
+was an error that can be resolved by re-rolling the tarball, it may be
+permissible to re-roll the release. But, the code itself may<font
+color="red">not</font>change from designation to designation.</p>
+<p>There are two courses of action:</p>
+<p>Revoke the release and immediately create another one that has a fix to
+this problem. You can take the old release, apply the single patch, and
+start the voting process again. This is only recommended for critical
+problems found early on in the release cycle.</p>
+<p>If the problem is less severe, place the patch to the problem in the
+/dist/httpd/patches/apply_to_X.Y.Z directory. A link to this directory
+should be included in the release notes with descriptions as to what
+problem each patch addresses.</p>
+<h1 id="suggestions">Suggestions?</h1>
+<p>As always, if you have any suggestions or comments on our process, please
+feel free to email our developer mailing list with your comments. We hope
+you found this document useful.</p>
+
+
+ <!-- FOOTER -->
+ <div id="footer">
+ <p class="apache">
+
+ <p>Copyright © 2012 The Apache Software Foundation
+Apache HTTP Server, Apache, and the Apache feather logo are trademarks of The Apache Software Foundation.</p>
+
+ </p>
+ </div>
+ </div>
+ </body>
+ </html>
Added: websites/staging/httpd/trunk/content/dev/styleguide.html
==============================================================================
--- websites/staging/httpd/trunk/content/dev/styleguide.html (added)
+++ websites/staging/httpd/trunk/content/dev/styleguide.html Sun May 6 22:53:33 2012
@@ -0,0 +1,248 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
+ <link href="/css/apsite.css" rel="stylesheet" media="all" type="text/css" title="Main stylesheet" />
+ <meta name="author" content="Documentation Group" /><meta name="email" content="docs@httpd.apache.org" />
+ <title>Apache Developers' C Language Style Guide - The Apache HTTP Server Project</title>
+ </head>
+ <body>
+
+ <div id="page-header">
+ <p class="menu"> </p>
+ <p class="apache"> </p>
+ <a href="/">
+ <img alt="" width="800" height="72" src="/images/httpd_logo_wide_new.png" border="0" />
+ </a>
+ </div>
+
+
+ <!-- LEFT SIDE NAVIGATION -->
+ <div id="apmenu">
+
+ <h1 id="essentials">Essentials</h1>
+<ul>
+<li><a href="/ABOUT_APACHE.html">About</a></li>
+<li><a href="http://www.apache.org/licenses/">License</a></li>
+<li><a href="http://wiki.apache.org/httpd/FAQ">FAQ</a></li>
+<li><a href="/security_report.html">Security Reports</a></li>
+</ul>
+<h1 id="download">Download!</h1>
+<ul>
+<li><a href="/download.cgi">From a Mirror</a></li>
+</ul>
+<h1 id="documentation"><a href="/docs/">Documentation</a></h1>
+<ul>
+<li><a href="/docs/2.4/">Version 2.4</a></li>
+<li><a href="/docs/2.2/">Version 2.2</a></li>
+<li><a href="/docs/2.0/">Version 2.0</a></li>
+<li><a href="/docs/trunk/">Trunk (dev)</a></li>
+</ul>
+<h1 id="get-support">Get Support</h1>
+<ul>
+<li><a href="/support.html">Support</a></li>
+</ul>
+<h1 id="get-involved">Get Involved</h1>
+<ul>
+<li><a href="/lists.html">Mailing Lists</a></li>
+<li><a href="/bug_report.html">Bug Reports</a></li>
+<li><a href="/dev/">Developer Info</a></li>
+</ul>
+<h1 id="subprojects">Subprojects</h1>
+<ul>
+<li><a href="/docs-project/">Docs</a></li>
+<li><a href="/test/">Test</a></li>
+<li><a href="/test/flood/">Flood</a></li>
+<li><a href="/apreq/">libapreq</a></li>
+<li><a href="/modules">Modules</a></li>
+<li><a href="/mod_fcgid/">mod_fcgid</a></li>
+<li><a href="/mod_ftp/">mod_ftp</a></li>
+</ul>
+<h1 id="miscellaneous"><a href="/info/">Miscellaneous</a></h1>
+<ul>
+<li><a href="/contributors/">Contributors</a></li>
+<li><a href="http://www.apache.org/foundation/thanks.html">Sponsors</a></li>
+<li><a href="http://www.apache.org/foundation/sponsorship.html">Sponsorship</a></li>
+</ul>
+
+ </div>
+
+
+ <!-- RIGHT SIDE INFORMATION -->
+ <div id="apcontents">
+
+ <p><strong>Compiled by Paul Sutton <a href="mailto:paul@awe.com">paul@awe.com</a> </strong>. Based on
+a vote taken in November, 1996.<br></br>Further refinements voted upon in
+July 1997.</p>
+<h1 id="introduction">Introduction</h1>
+<p>[This bit could state that code should be laid out to be clear to someone
+else familiar with Apache. Functions should be short and easily understood.
+Comments should be provided to explain the rationale for code which is not
+obvious, and to document behavior of functions. The guidelines can be
+broken if necessary to achieve a clearer layout]</p>
+<p>This style can be generated with the following arguments to GNU indent:</p>
+<p><code>-i4 -npsl -di0 -br -nce -d0 -cli0 -npcs -nfc1 -nut</code> </p>
+<h1 id="the-guidelines">The Guidelines</h1>
+<p><UL><li>Opening braces are given on the same lines as statements, or on the
+following line at the start of a function definition.</li><li>Code inside a
+block (whether surrounded by braces or not) is indented by four space
+characters. Tab characters are not used. Comments are indented to the same
+level as the surrounding code.</li><li>Closing braces are always on a
+separate line from surrounding code, and are indented to line up with the
+start of the text on the line containing the corresponding opening
+brace.</li><li>Functions are declared with ANSI-style
+arguments.</li><li>There is no space between the function name and the
+opening bracket of the arguments to the function. There is a single space
+following commas in argument lists and the semi-colons in for
+statements.</li><li>Inside a<samp>switch()</samp>statement,
+the<samp>case</samp>keywords are indented to the same level as
+the<samp>switch</samp>line.</li><li>Operators in expressions should be
+surrounded by a single space before and after, except for unary increment
+(++), decrement (--), and negation (!) operators.</li><li>There is no
+whitespace between a cast and the item modified (<EM>e.g.</EM>,
+"<samp>(int)j</samp>" and not "<samp>(int) j</samp>").</li><li>If a cast is
+to a pointer type, there is a space between the type and
+the<samp><em></samp>character (<EM>e.g.</EM>, "<samp>(char </em>)i</samp>" instead
+of "<samp>(char*)i</samp>")</li></UL></p>
+<h1 id="details-and-examples">Details and Examples</h1>
+<ol>
+<li><strong>Indentation, General Style</strong>
+Each level of indentation of code is four spaces. Tab characters should
+never be used. Specific indentation rules for function declarations and
+control-flow keywords are given below.</li>
+</ol>
+<p>Example:
+<code>main(int argc, char **argc)
+ {
+ if (argc != 0) {
+ fprintf(stderr, "No arguments allowed\n");
+ exit(1);
+ }
+ exit(0);
+ }</code>
+<A NAME="long-exps">If an expression</A>(or a routine declaration or
+invocation) would extend past column 80, the terms or arguments are wrapped
+at a convenient spot and the wrapped portion is indented under the first
+term in the expression (or the first argument to the function). Conditional
+expressions should be wrapped to keep single or parenthesized terms as
+atomic as possible, and place Boolean operators at either the start
+(preferable) or end of the line.</p>
+<p>Example:
+`
+ static const char <em>really_long_name(int i, int j,
+ const char </em>args, void *foo,
+ int k)</p>
+<div class="codehilite"><pre> <span class="k">if</span> <span class="p">(</span><span class="n">cond1</span> <span class="o">&</span><span class="n">amp</span><span class="p">;</span><span class="o">&</span><span class="n">amp</span><span class="p">;</span> <span class="p">(</span><span class="n">item2</span> <span class="o">||</span> <span class="n">item3</span><span class="p">)</span> <span class="o">&</span><span class="n">amp</span><span class="p">;</span><span class="o">&</span><span class="n">amp</span><span class="p">;</span> <span class="p">(</span><span class="o">!</span><span class="n">item4</span><span class="p">)</span>
+ <span class="o">&</span><span class="n">amp</span><span class="p">;</span><span class="o">&</span><span class="n">amp</span><span class="p">;</span> <span class="p">(</span><span class="n">item5</span> <span class="o">||</span> <span class="n">item6</span><span class="p">)</span> <span class="o">&</span><span class="n">amp</span><span class="p">;</span><span class="o">&</span><span class="n">amp</span><span class="p">;</span> <span class="n">item7</span><span class="p">)</span> <span class="p">{</span>
+ <span class="n">do_a_thing</span><span class="p">();</span>
+ <span class="p">}</span>
+</pre></div>
+
+
+<p>` </p>
+<ol>
+<li><strong>Comments</strong>
+Provide comments which explain the function of code where it is not clear
+from the code itself. Provide rationale where necessary for particular bits
+of code.</li>
+</ol>
+<p>Comments should be indented to same level as the surrounding text.</p>
+<p>Example:
+<code>code;
+ /* comment */
+ code;</code> </p>
+<ol>
+<li>
+<p><strong>Function Declaration and Layout</strong>
+Functions are laid out as follows:
+<code>int main(int argc, char **argv)
+ {
+ code;
+ }</code>
+The return type is placed on the same line as the function. Arguments (if
+any) are given in ANSI style. If no arguments, declare function
+as<samp>void</samp>. No space between function name and opening bracket,
+single space after comma separating each argument. The opening brace is
+placed on the line after the definition, indented to line up with the start
+of the return type text. The code is indented with four spaces, and the
+closing brace is indented to line up with the opening brace. <strong>Also see the
+section on indenting<A HREF="#long-exps">long declarations and
+invocations</A>.</strong> </p>
+</li>
+<li>
+<p><strong>Function Calls</strong>
+Space after commas in function calls. No space between function name and
+opening bracket.
+<code>f(a, b);</code>
+<strong>Also see the section on indenting<A HREF="#long-exps">long declarations
+and invocations</A>.</strong> </p>
+</li>
+<li>
+<p><strong>Flow-Control Layout</strong>
+Flow-control statements
+(<samp>if</samp>,<samp>while</samp>,<samp>for</samp>,<EM>etc.</EM>) are
+laid out as in this example:
+<code>if (expr) {
+ code;
+ }
+ else {
+ code;
+ }</code>
+There is a space between the keyword and the opening bracket. Opening brace
+placed on same line as the flow keyword. The code itself is indented by
+four spaces. The closing brace is indented to line up with the opening
+brace. If an<samp>else</samp>clause is used, the<samp>else</samp>keyword is
+placed on the line following the closing brace and is indented to line up
+with the corresponding<samp>if</samp>. <strong>Also see the section on
+indenting<A HREF="#long-exps">long expressions</A>.</strong> </p>
+</li>
+<li>
+<p><strong><samp>for</samp>Layout</strong>
+Space after the semi-colons. Example:
+<code>for (a; b; c)</code> </p>
+</li>
+<li>
+<p><strong><samp>switch</samp>Layout</strong>
+<samp>case</samp>lines within a<samp>switch()</samp>are indented to same
+level as the switch statement itself. The code for each case is indented by
+four spaces. Braces are laid out as for other control-flow keywords.
+Example:
+<code>switch (x) {
+ case a:
+ code;
+ case b:
+ code;
+ }</code> </p>
+</li>
+<li>
+<p><strong>Expressions</strong>
+Space before and after assignment and other and operators. No space between
+unary operators (increment, decrement, and negation) and the lvalue.
+Examples:
+<code>a = b
+ a + b
+ a &lt; b
+ a = -b
+ a = !b
+ ++a</code> </p>
+</li>
+<li>
+<p><strong>Capitalisation of Enums</strong>
+No rule.</p>
+</li>
+</ol>
+
+
+ <!-- FOOTER -->
+ <div id="footer">
+ <p class="apache">
+
+ <p>Copyright © 2012 The Apache Software Foundation
+Apache HTTP Server, Apache, and the Apache feather logo are trademarks of The Apache Software Foundation.</p>
+
+ </p>
+ </div>
+ </div>
+ </body>
+ </html>
Added: websites/staging/httpd/trunk/content/dev/verification.html
==============================================================================
--- websites/staging/httpd/trunk/content/dev/verification.html (added)
+++ websites/staging/httpd/trunk/content/dev/verification.html Sun May 6 22:53:33 2012
@@ -0,0 +1,206 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
+ <link href="/css/apsite.css" rel="stylesheet" media="all" type="text/css" title="Main stylesheet" />
+ <meta name="author" content="Documentation Group" /><meta name="email" content="docs@httpd.apache.org" />
+ <title>Verifying Apache HTTP Server Releases - The Apache HTTP Server Project</title>
+ </head>
+ <body>
+
+ <div id="page-header">
+ <p class="menu"> </p>
+ <p class="apache"> </p>
+ <a href="/">
+ <img alt="" width="800" height="72" src="/images/httpd_logo_wide_new.png" border="0" />
+ </a>
+ </div>
+
+
+ <!-- LEFT SIDE NAVIGATION -->
+ <div id="apmenu">
+
+ <h1 id="essentials">Essentials</h1>
+<ul>
+<li><a href="/ABOUT_APACHE.html">About</a></li>
+<li><a href="http://www.apache.org/licenses/">License</a></li>
+<li><a href="http://wiki.apache.org/httpd/FAQ">FAQ</a></li>
+<li><a href="/security_report.html">Security Reports</a></li>
+</ul>
+<h1 id="download">Download!</h1>
+<ul>
+<li><a href="/download.cgi">From a Mirror</a></li>
+</ul>
+<h1 id="documentation"><a href="/docs/">Documentation</a></h1>
+<ul>
+<li><a href="/docs/2.4/">Version 2.4</a></li>
+<li><a href="/docs/2.2/">Version 2.2</a></li>
+<li><a href="/docs/2.0/">Version 2.0</a></li>
+<li><a href="/docs/trunk/">Trunk (dev)</a></li>
+</ul>
+<h1 id="get-support">Get Support</h1>
+<ul>
+<li><a href="/support.html">Support</a></li>
+</ul>
+<h1 id="get-involved">Get Involved</h1>
+<ul>
+<li><a href="/lists.html">Mailing Lists</a></li>
+<li><a href="/bug_report.html">Bug Reports</a></li>
+<li><a href="/dev/">Developer Info</a></li>
+</ul>
+<h1 id="subprojects">Subprojects</h1>
+<ul>
+<li><a href="/docs-project/">Docs</a></li>
+<li><a href="/test/">Test</a></li>
+<li><a href="/test/flood/">Flood</a></li>
+<li><a href="/apreq/">libapreq</a></li>
+<li><a href="/modules">Modules</a></li>
+<li><a href="/mod_fcgid/">mod_fcgid</a></li>
+<li><a href="/mod_ftp/">mod_ftp</a></li>
+</ul>
+<h1 id="miscellaneous"><a href="/info/">Miscellaneous</a></h1>
+<ul>
+<li><a href="/contributors/">Contributors</a></li>
+<li><a href="http://www.apache.org/foundation/thanks.html">Sponsors</a></li>
+<li><a href="http://www.apache.org/foundation/sponsorship.html">Sponsorship</a></li>
+</ul>
+
+ </div>
+
+
+ <!-- RIGHT SIDE INFORMATION -->
+ <div id="apcontents">
+
+ <p>All official releases of code distributed by the Apache HTTP Server Project
+are signed by the release manager for the release. PGP signatures and MD5
+hashes are available along with the distribution.</p>
+<p>You should download the PGP signatures and MD5 hashes directly from the
+Apache Software Foundation rather than our mirrors. This is to help ensure
+the integrity of the signature files. However, you are encouraged to
+download the releases from our mirrors. (Our download page points you at
+the mirrors for the release and the official site for the signatures, so
+this happens automatically for you.)</p>
+<h1 id="Checking">Checking Signatures</h1>
+<p>The following example details how signature interaction works. In this
+example, you are already assumed to have downloaded <code>httpd-2.0.44.tar.gz</code>
+(the release) and <code>httpd-2.0.44.tar.gz.asc</code> (the detached signature).</p>
+<p>This example uses <a href="http://www.gnupg.org/">The GNU Privacy Guard</a>. Any
+<a href="http://www.openpgp.org/">OpenPGP</a> -compliant program should work
+successfully.</p>
+<p>First, we will check the detached signature ( <code>httpd-2.0.44.tar.gz.asc</code> )
+against our release ( <code>httpd-2.0.44.tar.gz</code> ).
+<code>% gpg httpd-2.0.44.tar.gz.asc
+gpg: Signature made Sat Jan 18 07:21:28 2003 PST using DSA key ID DE885DD3
+gpg: Can't check signature: public key not found</code>
+We don't have the release manager's public key ( <code>DE885DD3</code> ) in our local
+system. You now need to retrieve the public key from a key server. One
+popular server is <code>pgpkeys.mit.edu</code> (which has a <a href="http://pgp.mit.edu/">web
+interface</a> ). The public key servers are linked
+together, so you should be able to connect to any key server.
+<code>% gpg --keyserver pgpkeys.mit.edu --recv-key DE885DD3
+gpg: requesting key DE885DD3 from HKP keyserver pgpkeys.mit.edu
+gpg: trustdb created
+gpg: key DE885DD3: public key "Sander Striker &lt;striker@apache.org&gt;"
+imported
+gpg: Total number processed: 1
+gpg: imported: 1</code>
+In this example, you have now received a public key for an entity known as
+'Sander Striker <striker@apache.org>' However, you have no way of
+verifying this key was created by the person known as Sander Striker. But,
+let's try to verify the release signature again.
+<code>% gpg httpd-2.0.44.tar.gz.asc
+gpg: Signature made Sat Jan 18 07:21:28 2003 PST using DSA key ID DE885DD3
+gpg: Good signature from "Sander Striker &lt;striker@apache.org&gt;"
+gpg: aka "Sander Striker &lt;striker@striker.nl&gt;"
+gpg: checking the trustdb
+gpg: no ultimately trusted keys found
+gpg: WARNING: This key is not certified with a trusted signature!
+gpg: There is no indication that the signature belongs to the
+owner.
+Fingerprint: 4C1E ADAD B4EF 5007 579C 919C 6635 B6C0 DE88 5DD3</code>
+At this point, the signature is good, but we don't trust this key. A good
+signature means that the file has not been tampered. However, due to the
+nature of public key cryptography, you need to additionally verify that key
+DE885DD3 was created by the <strong>real</strong> Sander Striker.</p>
+<p>Any attacker can create a public key and upload it to the public key
+servers. They can then create a malicious release signed by this fake key.
+Then, if you tried to verify the signature of this corrupt release, it
+would succeed because the key was not the 'real' key. Therefore, you need
+to validate the authenticity of this key.</p>
+<h1 id="Validating">Validating Authenticity of a Key</h1>
+<p>You may download <a href="http://www.apache.org/dist/httpd/KEYS">public keys for the Apache HTTP Server
+developers</a> from our website or
+retrieve them off the public PGP keyservers (see above). However, importing
+these keys is not enough to verify the integrity of the signatures. If a
+release verifies as good, you need to validate that the key was created by
+an official representative of the Apache HTTP Server Project.</p>
+<p>The crucial step to validation is to confirm the key fingerprint of the
+public key.
+<code>% gpg --fingerprint DE885DD3
+pub 1024D/DE885DD3 2002-04-10 Sander Striker &lt;striker@apache.org&gt;
+ Key fingerprint = 4C1E ADAD B4EF 5007 579C 919C 6635 B6C0 DE88 5DD3
+uid Sander Striker &lt;striker@striker.nl&gt;
+sub 2048g/532D14CA 2002-04-10</code>
+A good start to validating a key is by face-to-face communication with
+multiple government-issued photo identification confirmations. However,
+each person is free to have their own standards for determining the
+authenticity of a key. Some people are satisfied by reading the key
+signature over a telephone (voice verification). For more information on
+determining what level of trust works best for you, please read the GNU
+Privacy Handbook section on <a href="http://www.gnupg.org/gph/en/manual.html#AEN335">Validating other keys on your public
+keyring</a>.</p>
+<p>Most of the Apache HTTP Server developers have attempted to sign each
+others' keys (usually with face-to-face validation). Therefore, in order to
+enter the web of trust, you should only need to validate one person in our
+web of trust. (Hint: all of our developers' keys are in the KEYS file.)</p>
+<p>For example, the following people have signed the public key for Sander
+Striker. If you verify any key on this list, you will have a trust path to
+the DE885DD3 key. If you verify a key that verifies one of the signatories
+for DE885DD3, then you will have a trust path. (So on, and so on.)
+<code>pub 1024D/DE885DD3 2002-04-10 Sander Striker &lt;striker@apache.org&gt;
+sig E2226795 2002-05-01 Justin R. Erenkrantz
+sig 3 DE885DD3 2002-04-10 Sander Striker
+sig CD4DF205 2002-05-28 Wolfram Schlich
+sig E005C9CB 2002-11-17 Greg Stein
+sig CC8B0F7E 2002-11-18 Aaron Bannert
+sig DFEAC4B9 2002-11-19 David N. Welton
+sig 2 82AB7BD1 2002-11-17 Cliff Woolley
+sig 2 13046155 2002-11-28 Thom May
+sig 3 19311B00 2002-11-17 Chuck Murcko
+sig 3 F894BE12 2002-11-17 Brian William Fitzpatrick
+sig 3 5C1C3AD7 2002-11-18 David Reid
+sig 3 E04F9A89 2002-11-18 Roy T. Fielding
+sig 3 CC78C893 2002-11-19 Rich Bowen
+sig 3 08C975E5 2002-11-21 Jim Jagielski
+sig 3 F88341D9 2002-11-18 Lars Eilebrecht
+sig 3 187BD68D 2002-11-21 Ben Hyde
+sig 3 49A563D9 2002-11-23 Mark Cox
+...more signatures redacted...</code>
+Since the developers are usually quite busy, you may not immediately find
+success in someone who is willing to meet face-to-face (they may not even
+respond to your emails because they are so busy!). If you do not have a
+developer nearby or have trouble locating a suitable person, please send an
+email to the address of the key you are attempting to verify. They may be
+able to find someone who will be willing to validate their key or arrange
+alternate mechanisms for validation.</p>
+<p>Once you have entered the web of trust, you should see the following upon
+verifying the signature of a release.
+<code>% gpg httpd-2.0.44.tar.gz.asc
+gpg: Signature made Sat Jan 18 07:21:28 2003 PST using DSA key ID DE885DD3
+gpg: Good signature from "Sander Striker &lt;striker@apache.org&gt;"
+gpg: aka "Sander Striker &lt;striker@striker.nl&gt;"</code> </p>
+
+
+ <!-- FOOTER -->
+ <div id="footer">
+ <p class="apache">
+
+ <p>Copyright © 2012 The Apache Software Foundation
+Apache HTTP Server, Apache, and the Apache feather logo are trademarks of The Apache Software Foundation.</p>
+
+ </p>
+ </div>
+ </div>
+ </body>
+ </html>