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 [1/2] - in /websites/staging/httpd/trunk/content: ./ dev/
Author: buildbot
Date: Sun May 6 22:53:33 2012
New Revision: 816182
Log:
Staging update by buildbot for httpd
Added:
websites/staging/httpd/trunk/content/dev/debugging.html
websites/staging/httpd/trunk/content/dev/devnotes.html
websites/staging/httpd/trunk/content/dev/guidelines.html
websites/staging/httpd/trunk/content/dev/how-to-release.html
websites/staging/httpd/trunk/content/dev/index.html
websites/staging/httpd/trunk/content/dev/patches.html
websites/staging/httpd/trunk/content/dev/release.html
websites/staging/httpd/trunk/content/dev/styleguide.html
websites/staging/httpd/trunk/content/dev/verification.html
Removed:
websites/staging/httpd/trunk/content/dev/debugging.xml
websites/staging/httpd/trunk/content/dev/devnotes.xml
websites/staging/httpd/trunk/content/dev/guidelines.xml
websites/staging/httpd/trunk/content/dev/how-to-release.xml
websites/staging/httpd/trunk/content/dev/index.xml
websites/staging/httpd/trunk/content/dev/patches.xml
websites/staging/httpd/trunk/content/dev/release.xml
websites/staging/httpd/trunk/content/dev/styleguide.xml
websites/staging/httpd/trunk/content/dev/verification.xml
Modified:
websites/staging/httpd/trunk/content/ (props changed)
Propchange: websites/staging/httpd/trunk/content/
------------------------------------------------------------------------------
--- cms:source-revision (original)
+++ cms:source-revision Sun May 6 22:53:33 2012
@@ -1 +1 @@
-1334788
+1334814
Added: websites/staging/httpd/trunk/content/dev/debugging.html
==============================================================================
--- websites/staging/httpd/trunk/content/dev/debugging.html (added)
+++ websites/staging/httpd/trunk/content/dev/debugging.html Sun May 6 22:53:33 2012
@@ -0,0 +1,506 @@
+<!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 HTTPD Debugging 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>This document is a collection of notes regarding tools and techniques for
+debugging Apache httpd and its modules.</p>
+<p>Got more tips? Send 'em to
+<a href="mailto:docs@httpd.apache.org">docs@httpd.apache.org</a>. Thanks!</p>
+<ol>
+<li>
+<p><a href="#gdb">Using</a> </p>
+</li>
+<li>
+<p><a href="#backtrace">Getting a live backtrace on unix</a> </p>
+</li>
+<li>
+<p><a href="#backtrace-win">Getting a live backtrace on Windows</a> </p>
+</li>
+<li>
+<p><a href="#crashes">Debugging intermittent crashes</a> </p>
+</li>
+<li>
+<p><a href="#truss">Using '</a> </p>
+</li>
+<li>
+<p><a href="#gcore">Getting the server to dump core</a> </p>
+</li>
+<li>
+<p><a href="#sol27">Solaris and coredumps</a> </p>
+</li>
+<li>
+<p><a href="#tcpdump">Getting and analyzing a TCP packet trace</a> </p>
+</li>
+</ol>
+<h1 id="gdb">Using gdb</h1>
+<p>If you use the gcc compiler, it is likely that the best debugger for your
+system is gdb. This is only a brief summary of how to run gdb on Apache --
+you should look at the info and man files for gdb to get more information
+on gdb commands and common debugging techniques. Before running gdb, be
+sure that the server is compiled with the <code>-g</code> option in <code>CFLAGS</code> to
+include the symbol information in the object files.</p>
+<p>The only tricky part of running gdb on Apache is forcing the server into a
+single-process mode so that the parent process being debugged does the
+request-handling work instead of forking child processes. We have provided
+the <code>-X</code> option for that purpose, which will work fine for most cases.
+However, some modules don't like starting up with <code>-X</code> , but are happy if
+you force only one child to run (using " <code>MaxClients 1</code> "); you can then
+use gdb's attach command to debug the child server.</p>
+<p>The following example, with<font color="green">user input in green</font>,
+shows the output of gdb run on a server executable (httpd) in the current
+working directory and using the server root of <code>/usr/local/apache</code> :
+<pre>
+ % gdb httpd
+ GDB is free software and you are welcome to distribute copies of it
+ under certain conditions; type "show copying" to see the conditions.
+ There is absolutely no warranty for GDB; type "show warranty" for
+ details.
+ GDB 4.16.gnat.1.13 (sparc-sun-solaris2.5),
+ Copyright 1996 Free Software Foundation, Inc...
+ (gdb) b ap_process_request
+ Breakpoint 1 at 0x49fb4: file http_request.c, line 1164.
+ (gdb) run -X -d /usr/local/apache
+ Starting program: /usr/local/apache/src/httpd -X -d /usr/local/apache</p>
+<div class="codehilite"><pre><span class="k">[at this point I make a request from another window]</span>
+
+<span class="na">Breakpoint 1, ap_process_request (r</span><span class="o">=</span><span class="s">0x95250) at http_request.c:1164</span>
+<span class="err">1164</span> <span class="err">if</span> <span class="err">(ap_extended_status)</span>
+<span class="err">(gdb)</span> <span class="err">s</span>
+<span class="err">1165</span>
+<span class="err">ap_time_process_request(r-&gt</span><span class="c">;connection-&gt;child_num,...</span>
+<span class="err">(gdb)</span> <span class="err">n</span>
+<span class="err">1167</span> <span class="err">process_request_internal(r)</span><span class="c">;</span>
+<span class="err">(gdb)</span> <span class="err">s</span>
+<span class="na">process_request_internal (r</span><span class="o">=</span><span class="s">0x95250) at http_request.c:1028</span>
+<span class="err">1028</span> <span class="err">if</span> <span class="err">(!r-&gt</span><span class="c">;proxyreq &amp;&amp; r-&gt;parsed_uri.path) {</span>
+<span class="err">(gdb)</span> <span class="err">s</span>
+<span class="na">1029 access_status</span> <span class="o">=</span> <span class="s">ap_unescape_url(r-&gt;parsed_uri.path);</span>
+<span class="err">(gdb)</span> <span class="err">n</span>
+<span class="err">1030</span> <span class="err">if</span> <span class="err">(access_status)</span> <span class="err">{</span>
+<span class="err">(gdb)</span> <span class="err">s</span>
+<span class="err">1036</span> <span class="err">ap_getparents(r-&gt</span><span class="c">;uri); /* OK...</span>
+<span class="err">(gdb)</span> <span class="err">n</span>
+<span class="na">1038 if ((access_status</span> <span class="o">=</span> <span class="s">location_walk(r))) {</span>
+<span class="err">(gdb)</span> <span class="err">n</span>
+<span class="na">1043 if ((access_status</span> <span class="o">=</span> <span class="s">ap_translate_name(r))) {</span>
+<span class="err">(gdb)</span> <span class="err">n</span>
+<span class="err">1048</span> <span class="err">if</span> <span class="err">(!r-&gt</span><span class="c">;proxyreq) {</span>
+<span class="err">(gdb)</span> <span class="err">n</span>
+<span class="na">1053 if (r-&gt;method_number</span> <span class="o">=</span><span class="s">= M_TRACE) {</span>
+<span class="err">(gdb)</span> <span class="err">n</span>
+<span class="err">1062</span> <span class="err">if</span> <span class="err">(r-&gt</span><span class="c">;proto_num &gt; HTTP_VERSION(1,0) &amp;&amp;</span>
+<span class="err">ap_...</span>
+<span class="err">(gdb)</span> <span class="err">n</span>
+<span class="na">1071 if ((access_status</span> <span class="o">=</span> <span class="s">directory_walk(r))) {</span>
+<span class="err">(gdb)</span> <span class="err">s</span>
+<span class="na">directory_walk (r</span><span class="o">=</span><span class="s">0x95250) at http_request.c:288</span>
+<span class="na">288 core_server_config *sconf</span> <span class="o">=</span> <span class="s">ap_get_module_...</span>
+<span class="err">(gdb)</span> <span class="err">b</span> <span class="err">ap_send_error_response</span>
+<span class="err">Breakpoint</span> <span class="err">2</span> <span class="err">at</span> <span class="err">0x47dcc:</span> <span class="err">file</span> <span class="err">http_protocol.c,</span> <span class="err">line</span> <span class="err">2090.</span>
+<span class="err">(gdb)</span> <span class="err">c</span>
+<span class="err">Continuing.</span>
+
+<span class="na">Breakpoint 2, ap_send_error_response (r</span><span class="o">=</span><span class="s">0x95250, recursive_error=0)</span>
+<span class="err">at</span> <span class="err">http_protocol.c:2090</span>
+<span class="na">2090 BUFF *fd</span> <span class="o">=</span> <span class="s">r-&gt;connection-&gt;client;</span>
+<span class="err">(gdb)</span> <span class="err">where</span>
+<span class="c">#0 ap_send_error_response (r=0x95250, recursive_error=0)</span>
+<span class="err">at</span> <span class="err">http_protocol.c:2090</span>
+<span class="c">#1 0x49b10 in ap_die (type=403, r=0x95250) at http_request.c:989</span>
+<span class="c">#2 0x49b60 in decl_die (status=403, phase=0x62db8 "check access",</span>
+<span class="na">r</span><span class="o">=</span><span class="s">0x95250)</span>
+<span class="err">at</span> <span class="err">http_request.c:1000</span>
+<span class="c">#3 0x49f68 in process_request_internal (r=0x95250) at</span>
+<span class="err">http_request.c:1141</span>
+<span class="c">#4 0x49fe0 in ap_process_request (r=0x95250) at http_request.c:1167</span>
+<span class="c">#5 0x439d8 in child_main (child_num_arg=550608) at http_main.c:3826</span>
+<span class="c">#6 0x43b5c in make_child (s=0x7c3e8, slot=0, now=907958743)</span>
+<span class="err">at</span> <span class="err">http_main.c:3898</span>
+<span class="c">#7 0x43ca8 in startup_children (number_to_start=6) at http_main.c:3972</span>
+<span class="c">#8 0x44260 in standalone_main (argc=392552, argv=0x75800) at</span>
+<span class="err">http_main.c:4250</span>
+<span class="c">#9 0x449fc in main (argc=4, argv=0xefffee8c) at http_main.c:4534</span>
+<span class="err">(gdb)</span> <span class="err">s</span>
+<span class="na">2091 int status</span> <span class="o">=</span> <span class="s">r-&gt;status;</span>
+<span class="err">(gdb)</span> <span class="err">p</span> <span class="err">status</span>
+<span class="na">$1</span> <span class="o">=</span> <span class="s">403</span>
+<span class="err">(gdb)</span>
+</pre></div>
+
+
+<p></pre>
+There are a few things to note about the above example:</p>
+<ol>
+<li>
+<p>the " <code>gdb httpd</code> " command does not include any command-line options
+for httpd: those are provided when the " <code>run</code> " command is done within
+gdb;</p>
+</li>
+<li>
+<p>I set a breakpoint before starting the run so that execution would stop
+at the top of ap_process_request();</p>
+</li>
+<li>
+<p>the " <code>s</code> " command steps through the code and into called procedures,
+whereas the " <code>n</code> " (next) command steps through the code but not into
+called procedures.</p>
+</li>
+<li>
+<p>additional breakpoints can be set with the " <code>b</code> " command, and the run
+continued with the " <code>c</code> " command.</p>
+</li>
+<li>
+<p>use the " <code>where</code> " command (a.k.a. " <code>bt</code> ") to see a stack backtrace
+that shows the order of called procedures and their parameter values.</p>
+</li>
+<li>
+<p>use the " <code>p</code> " command to print the value of a variable.</p>
+</li>
+</ol>
+<p>A file in the the root directory called <code>.gdbinit</code> provides useful macros
+for printing out various internal structures of httpd like tables (
+<code>dump_table</code> ), brigades ( <code>dump_brigade</code> ) and filter chains (
+<code>dump_filters</code> ).</p>
+<p>If you are debugging a repeatable crash, simply run gdb as above and make
+the request -- gdb should capture the crash and provide a prompt where it
+occurs.</p>
+<p>If you are debugging an apparent infinite loop, simply run gdb as above and
+type a Control-C -- gdb will interrupt the process and provide a prompt
+where it was stopped.</p>
+<p>If you are debugging a system crash and you have a core file from the
+crash, then do the following:
+<pre>
+ % gdb httpd -c core
+ (gdb) where</pre>
+and it will (hopefully) print a stack backtrace of where the core dump
+occurred during processing.</p>
+<h1 id="backtrace">Getting a live backtrace on unix</h1>
+<p>A backtrace will let you know the hierarchy of procedures that were called
+to get to a particular point in the process. On some platforms you can get
+a live backtrace of any process.</p>
+<p>For SVR4-based variants of Unix, the <code>pstack</code> command for proc can be used
+to display a a live backtrace. For example, on Solaris it looks like
+<pre>
+ % /usr/proc/bin/pstack 10623
+ 10623: httpd -d /usr/local/apache
+ ef5b68d8 poll (efffcd08, 0, 3e8)
+ ef5d21e0 select (0, ef612c28, 0, 0, 3e8, efffcd08) + 288
+ 00042574 wait_or_timeout (0, 75000, 75000, 7c3e8, 60f40, 52c00) + 78
+ 00044310 standalone_main (5fd68, 75800, 75c00, 75000, 2, 64) + 240
+ 000449f4 main (3, efffeee4, efffeef4, 75fe4, 1, 0) + 374
+ 000162fc _start (0, 0, 0, 0, 0, 0) + 5c
+</pre>
+Another technique is to use gdb to attach to the running process and then
+using "where" to print the backtrace, as in
+<pre>
+ % gdb httpd 10623
+ GDB is free software and you are welcome to distribute copies of it
+ under certain conditions; type "show copying" to see the conditions.
+ There is absolutely no warranty for GDB; type "show warranty" for
+ details.
+ GDB 4.16.gnat.1.13 (sparc-sun-solaris2.5),
+ Copyright 1996 Free Software Foundation, Inc...</p>
+<div class="codehilite"><pre><span class="sr">/usr/</span><span class="nb">local</span><span class="sr">/apache/s</span><span class="n">rc</span><span class="o">/</span><span class="mi">10623</span><span class="p">:</span> <span class="n">No</span> <span class="n">such</span> <span class="n">file</span> <span class="ow">or</span> <span class="n">directory</span><span class="o">.</span>
+<span class="n">Attaching</span> <span class="n">to</span> <span class="n">program</span> <span class="err">`</span><span class="sr">/usr/</span><span class="nb">local</span><span class="sr">/apache/s</span><span class="n">rc</span><span class="o">/</span><span class="n">httpd</span><span class="err">'</span><span class="p">,</span> <span class="n">process</span> <span class="mi">10623</span>
+<span class="n">Reading</span> <span class="n">symbols</span> <span class="n">from</span> <span class="sr">/usr/</span><span class="n">lib</span><span class="o">/</span><span class="n">libsocket</span><span class="o">.</span><span class="n">so</span><span class="mf">.1</span><span class="o">...</span><span class="n">done</span><span class="o">.</span>
+<span class="n">Reading</span> <span class="n">symbols</span> <span class="n">from</span> <span class="sr">/usr/</span><span class="n">lib</span><span class="o">/</span><span class="n">libnsl</span><span class="o">.</span><span class="n">so</span><span class="mf">.1</span><span class="o">...</span><span class="n">done</span><span class="o">.</span>
+<span class="n">Reading</span> <span class="n">symbols</span> <span class="n">from</span> <span class="sr">/usr/</span><span class="n">lib</span><span class="o">/</span><span class="n">libc</span><span class="o">.</span><span class="n">so</span><span class="mf">.1</span><span class="o">...</span><span class="n">done</span><span class="o">.</span>
+<span class="n">Reading</span> <span class="n">symbols</span> <span class="n">from</span> <span class="sr">/usr/</span><span class="n">lib</span><span class="o">/</span><span class="n">libdl</span><span class="o">.</span><span class="n">so</span><span class="mf">.1</span><span class="o">...</span><span class="n">done</span><span class="o">.</span>
+<span class="n">Reading</span> <span class="n">symbols</span> <span class="n">from</span> <span class="sr">/usr/</span><span class="n">lib</span><span class="o">/</span><span class="n">libintl</span><span class="o">.</span><span class="n">so</span><span class="mf">.1</span><span class="o">...</span><span class="n">done</span><span class="o">.</span>
+<span class="n">Reading</span> <span class="n">symbols</span> <span class="n">from</span> <span class="sr">/usr/</span><span class="n">lib</span><span class="o">/</span><span class="n">libmp</span><span class="o">.</span><span class="n">so</span><span class="mf">.1</span><span class="o">...</span><span class="n">done</span><span class="o">.</span>
+<span class="n">Reading</span> <span class="n">symbols</span> <span class="n">from</span> <span class="sr">/usr/</span><span class="n">lib</span><span class="o">/</span><span class="n">libw</span><span class="o">.</span><span class="n">so</span><span class="mf">.1</span><span class="o">...</span><span class="n">done</span><span class="o">.</span>
+<span class="n">Reading</span> <span class="n">symbols</span> <span class="n">from</span>
+<span class="sr">/usr/</span><span class="n">platform</span><span class="sr">/SUNW,Ultra-1/</span><span class="n">lib</span><span class="o">/</span><span class="n">libc_psr</span><span class="o">.</span><span class="n">so</span><span class="mf">.1</span><span class="o">...</span><span class="n">done</span><span class="o">.</span>
+<span class="mh">0xef5b68d8</span> <span class="n">in</span> <span class="p">()</span>
+<span class="p">(</span><span class="n">gdb</span><span class="p">)</span> <span class="n">where</span>
+<span class="c1">#0 0xef5b68d8 in ()</span>
+<span class="c1">#1 0xef5d21e8 in select ()</span>
+<span class="c1">#2 0x4257c in wait_or_timeout (status=0x0) at http_main.c:2357</span>
+<span class="c1">#3 0x44318 in standalone_main (argc=392552, argv=0x75800) at...</span>
+<span class="c1">#4 0x449fc in main (argc=3, argv=0xefffeee4) at http_main.c:4534</span>
+<span class="p">(</span><span class="n">gdb</span><span class="p">)</span>
+</pre></div>
+
+
+</pre>
+
+<h1 id="backtrace-win">Getting a live backtrace on Windows</h1>
+<ol>
+<li>
+<p>Unzip the <code>-symbols.zip</code> files (obtained from the Apache download site)
+in the root Apache2 directory tree (where bin\, htdocs\, modules\ etc. are
+usually found.) These.pdb files should unpack alongside the.exe,.dll,.so
+binary files they represent, e.g., mod_usertrack.pdb will unpack alongside
+mod_usertrack.so.</p>
+</li>
+<li>
+<p>Invoke <code>drwtsn32</code> and ensure you are creating a crash dump file, you are
+dumping all thread contexts, your log and crash dump paths make sense, and
+(depending on the nature of the bug) you pick an appropriate crash dump
+type. (Full is quite large, but necessary sometimes for a programmer-type
+to load your crash dump into a debugger and begin unwinding exactly what
+has happened. Mini is sufficient for your first pass through the process.)</p>
+</li>
+<li>
+<p>Note that if you previously installed and then uninstalled other
+debugging software, you may need to invoke <code>drwtsn32 -i</code> in order to make
+Dr Watson your default crash dump tool. This will replace the 'report
+problem to MS' dialogs. (Don't do this if you have a full debugger such as
+Visual Studio or windbg installed on the machine, unless you back up the
+registry value for <code>Debugger</code> under the <code>HKLM\SOFTWARE\Microsoft\Windows
+NT\CurrentVersion\AeDebug</code> registry tree. Developers using multiple tools
+might want to keep copies of their different tools Debugger entries there,
+for fast switching.)</p>
+</li>
+<li>
+<p>Invoke the Task Manager, Choose 'show processes from all users', and
+modify the <code>View -&gt; Select Columns</code> to include <strong>at least</strong> the <code>PID</code>
+and <code>Thread
+ Count</code>. You can change this just once and Task Manager should keep your
+ preference.</p>
+</li>
+<li>
+<p>Now, track down the errant Apache that is hanging. The parent process
+has about three threads, we don't care about that one. The child worker
+process we want has many more threads (a few more than you configured with
+the ThreadsPerChild directive.) The process name is Apache (for 1.3 and
+2.0) or httpd (for 2.2 and 2.4). Make note of the child worker's PID.</p>
+</li>
+<li>
+<p>Using the {pid} number you noted above, invoke the command</p>
+<blockquote>
+<p><code>drwtsn32 -p {pid}</code> </p>
+</blockquote>
+</li>
+</ol>
+<p>Voila, you will find in your 'log file path' a <code>drwtsn32.log</code> file, and if
+you choose to 'append to existing log file', jump through the 'App:'
+sections until you find the one for the process you just killed. Now you
+can identify about where 'Stack Back Trace' points to help identify what
+the server is doing.</p>
+<p>You will note that many threads look identical, almost all of them polling
+for the next connection, and you don't care about those. You will want to
+see the ones that are deep inside of a request at the time you kill them,
+and only the stack back trace entries for those. This can give folks a clue
+of where that request is hanging, which handler module picked up the
+request, and what filter it might be stuck in.</p>
+<h1 id="crashes">Debugging intermittent crashes</h1>
+<p>For situations where a child process is crashing intermittently, the server
+must be configured and started such that it produces core dumps which can
+be analyzed further.</p>
+<p>To ensure that a core dump is written to a directory which is writable by
+the user which child processes run as (such as <code>apache</code> ), the
+<a href="http://httpd.apache.org/docs/current/mod/mpm_common.html#coredumpdirectory"></a>
+directive must be added to <code>httpd.conf</code> ; for example:
+<code>CoreDumpDirectory /tmp</code>
+Before starting up the server, any process limits on core dump file size
+must be lifted; for example:
+<code># ulimit -c unlimited
+ # apachectl start</code>
+On some platforms, further steps might be needed to enable core dumps - see
+<a href="#sol27">Solaris and coredumps</a> below.</p>
+<p>When a child process crashes, a message like the following will be logged
+to the error_log:</p>
+<blockquote>
+<p><code>[Mon Sep 05 13:35:39 2005] [notice] child pid 2027 exit signal Segmentation
+fault (11), possible coredump in /tmp</code> </p>
+</blockquote>
+<p>If the text "possible coredump in /tmp" does not appear in the error line,
+check that the ulimit was set correctly, that the permissions on the
+configured <code>CoreDumpDirectory</code> are suitable and that platform specific
+steps ( <a href="#sol27">Solaris and coredumps</a> ) have been done if needed.</p>
+<p>To analyse the core dump, pass the core dump filename on the gdb
+command-line, and enter the command <code>bt full</code> at the gdb prompt:
+<pre>
+ % gdb /usr/local/apache2/bin/httpd /tmp/core.2027
+...
+ Core was generated by <code>/usr/local/apache2/bin/httpd -k start'
+...
+ (gdb) bt full</pre>
+If attempting to debug a threaded server, for example when using the</code>worker` MPM, use the following gdb command:
+<pre>
+ (gdb) thread apply all bt full</pre></p>
+<h1 id="truss">Using 'truss/trace/strace' to trace system calls and signals</h1>
+<p>Most Unix-based systems have at least one command for displaying a trace of
+system calls and signals as they are accessed by a running process. This
+command is called <code>truss</code> on most SVR4-based systems and either <code>trace</code> or
+<code>strace</code> on many other systems.</p>
+<p>A useful tip for using the <code>truss</code> command on Solaris is the <code>-f</code> option
+(often also works with <code>strace</code> ); it tells truss to follow and continue
+tracing any child processes forked by the main process. The easiest way to
+get a full trace of a server is to do something like:
+<pre>
+ % truss -f httpd -d /usr/local/apache >& outfile</pre><pre>
+ % egrep '^10698:' outfile</pre>
+to view just the trace of the process id 10698.</p>
+<p>If attempting to truss a threaded server, for example when using the
+<code>worker</code> MPM, the <code>truss</code> option <code>-l</code> is very useful as it prints also the
+LWP id after the process id. You can use something like
+<pre>
+ % egrep '^10698/1:' outfile</pre>
+to view just the trace of the process id 10698 and LWP id 1.</p>
+<p>Other useful options for truss are</p>
+<ul>
+<li>
+<p><code>-a</code> to print all command line parameters used for this executable.</p>
+</li>
+<li>
+<p><code>-e</code> to print all environment variables used for this executable.</p>
+</li>
+<li>
+<p><code>-d</code> to print timestamps.</p>
+</li>
+</ul>
+<h1 id="gcore">Getting the server to dump core</h1>
+<p>Strangely enough, sometimes you actually want to force the server to crash
+so that you can get a look at some nutty behavior. Normally this can be
+done simply by using the <code>gcore</code> command. However, for security reasons,
+most Unix systems do not allow a setuid process to dump core, since the
+file contents might reveal something that is supposed to be protected in
+memory.</p>
+<p>Here is one way to get a core file from a setuid Apache httpd process on
+Solaris, without knowing which httpd child might be the one to die [note:
+it is probably easier to use the MaxClients trick in the first section
+above].
+<code># for pid in</code>ps -eaf | fgrep httpd | cut -d' ' -f4<code>do
+ truss -f -l -t\!all -S SIGSEGV -p $pid 2&gt;&amp;1 | egrep SIGSEGV
+ &amp;
+ done</code>
+The <a href="http://www.dejanews.com/=zzz_maf/getdoc.xp?AN=352257973">undocumented '-S'
+flag</a> to truss
+will halt the process in place upon receipt of a given signal (SIGSEGV in
+this case). At this point you can use:
+<pre>
+ # gcore PID</pre>
+and then look at the backtrace as discussed above for <a href="#gdb">gdb</a>.</p>
+<h1 id="sol27">Solaris and coredumps</h1>
+<p>On Solaris use <a href="http://docs.sun.com/app/docs/doc/816-5166/coreadm-1m"></a> to
+make <code>setuid()</code> processes actually dump core. By default a setuid() process
+does not dump core. This is the reason why httpd servers started as root
+with child processes running as a different user (such as <code>apache</code> ) do not
+coredump even when the
+<a href="http://httpd.apache.org/docs/current/mod/mpm_common.html#coredumpdirectory"></a>
+directive had been set to an appropriate and writable directory and <strong>
+<code>ulimit -c</code> </strong> has a sufficient size. See also <a href="#crashes">Debugging intermittent
+crashes</a> above.</p>
+<p>Example:
+<code>-bash-3.00# coreadm
+ global core file pattern: /var/core/core.%f.%p.u%u
+ global core file content: default
+ init core file pattern: core
+ init core file content: default
+ global core dumps: disabled
+ per-process core dumps: enabled
+ global setid core dumps: enabled
+per-process setid core dumps: enabled
+ global core dump logging: disabled</code> </p>
+<h1 id="tcpdump">Getting and analyzing a TCP packet trace</h1>
+<p>This is too deep a subject to fully describe in this documentation. Here
+are some pointers to useful discussions and tools:</p>
+<ul>
+<li>
+<p><code>snoop</code> is a packet sniffer that is part of Solaris.</p>
+</li>
+<li>
+<p><a href="http://www.tcpdump.org/">tcpdump</a> is a packet sniffer that is available
+for Unix-based systems and Windows (
+<a href="http://www.winpcap.org/windump/">windump</a> ). It is part of many free
+Unix-based distributions.</p>
+</li>
+<li>
+<p><a href="http://www.wireshark.org/">Wireshark</a> is another packet sniffer that is
+available for Unix-based systems and Windows. It has a nice GUI and allows
+the analysis of the sniffed data.</p>
+</li>
+<li>
+<p><a href="http://jarok.cs.ohiou.edu/software/tcptrace/">tcptrace</a> is a TCP dump
+file analysis tool.</p>
+</li>
+<li>
+<p><a href="http://www.tcpshow.org/">tcpshow</a> is another one.</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/devnotes.html
==============================================================================
--- websites/staging/httpd/trunk/content/dev/devnotes.html (added)
+++ websites/staging/httpd/trunk/content/dev/devnotes.html Sun May 6 22:53:33 2012
@@ -0,0 +1,224 @@
+<!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 Development Notes - 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 page is intended to provide some basic background about development
+nits and the maintenance of the developer site.</p>
+<h1 id="overview">Overview</h1>
+<p>The Apache HTTP Server Project has switched to
+<a href="http://subversion.apache.org/">Subversion</a> for hosting its source code.</p>
+<p>To check out the 2.4.x branch:</p>
+<blockquote>
+<p><code>svn checkout http://svn.apache.org/repos/asf/httpd/httpd/branches/2.4.x
+httpd-2.4.x</code> </p>
+</blockquote>
+<p>To check out the current development version (as of this writing, 2.5.x),
+use:</p>
+<blockquote>
+<p><code>svn checkout http://svn.apache.org/repos/asf/httpd/httpd/trunk httpd-trunk</code> </p>
+</blockquote>
+<p>Committers should check out via https instead of http (so that they can
+commit their changes). For more info about Subversion, please read <a href="http://www.apache.org/dev/version-control.html">the ASF
+version control FAQ</a>.</p>
+<p>The developers continue to seek to maintain module compatibility between
+2.4.1 and future 2.4 releases for administrators and end users, while
+continuing the forward progress that has made the 2.2 server faster and
+more scalable.</p>
+<h1 id="maintaining-the-sources">Maintaining the Sources</h1>
+<p>Almost all files relating to Apache, both the actual sources and the files
+that aren't part of the distribution, are now maintained in an
+<a href="http://subversion.apache.org/">SVN</a> repository. Here is the way in which
+changes are applied:</p>
+<ol>
+<li>Developer checks out a copy of the files on which he wants to work (in
+this case, the trunk), into a private working directory
+called<samp>httpd-trunk</samp>:</li>
+</ol>
+<dl>
+<dd><samp>% svn checkout http://svn.apache.org/repos/asf/httpd/httpd/trunk
+ httpd-trunk</samp></dd>
+</dl>
+<p>This step only needs to be performed once (unless the private working
+directory is tainted or deleted.) Committers should use a URL prefix
+of<samp>https</samp>on the checkout, to save themselves headaches later.</p>
+<ol>
+<li>Developer keeps his working directory synchronised with changes made to
+the repository:</li>
+</ol>
+<dl>
+<dd><samp>% svn update httpd-trunk</samp></dd>
+</dl>
+<p>This should probably be done daily or even more frequently during periods
+of high activity.</p>
+<ol>
+<li>Developer makes changes to his working copies, makes sure they work, and
+generates a patch so others can apply the changes to test them:</li>
+</ol>
+<dl>
+<dd><samp>% svn diff httpd-trunk/modules/http/mod_mime.c >
+ /tmp/foo</samp></dd>
+</dl>
+<p>The<samp>/tmp/foo</samp>file is mailed to the <a href="http://httpd.apache.org/lists.html#http-dev">developers
+list</a> so they can consider the
+value/validity of the patch. It is worth making sure your code follows the
+Apache style, as described in the <a href="styleguide.html">style guide</a>.</p>
+<ol>
+<li>Once other developers have agreed that the change is a Good Thing, the
+developer checks the changes into the repository:</li>
+</ol>
+<dl>
+<dd><samp>% svn commit httpd-trunk/modules/http/mod_mime.c</samp></dd>
+</dl>
+<h1 id="svn-subtrees">SVN Subtrees</h1>
+<p>There are several different branches under the<samp>httpd</samp>subtree in
+the Apache SVN repository that pertain to the different releases. The top
+level can be perused with the <a href="http://svn.apache.org/viewcvs.cgi/">SVN
+ViewCVS</a> pages. The main subtrees
+pertaining to the<samp>httpd</samp>server source are:</p>
+<h2 id="httpd-22">httpd-2.2</h2>
+<p>To create a directory tree containing the 2.2 sources, and call
+it<samp>httpd-2.2</samp>, change your current directory to the <em>parent</em> of
+the tree and then check the 2.2 sources out as follows:
+<pre>
+% cd /usr/local/apache
+% svn checkout http://svn.apache.org/repos/asf/httpd/httpd/branches/2.2.x
+ httpd-2.2</pre></p>
+<h2 id="httpd-24">httpd-2.4</h2>
+<p>To create a directory tree containing the 2.4 sources, and call
+it<samp>httpd-2.4</samp>, change your current directory to the <em>parent</em> of
+the tree and then check the 2.4 sources out as follows:
+<pre>
+% cd /usr/local/apache
+% svn checkout http://svn.apache.org/repos/asf/httpd/httpd/branches/2.4.x
+ httpd-2.4</pre></p>
+<h2 id="httpd-25">httpd-2.5</h2>
+<p>If you want to check out the bleeding edge of development, the httpd-2.5
+development tree (slated for a release 2.6), and call
+it<samp>httpd-trunk</samp>, checkout as follows:
+<pre>
+% cd /usr/local/apache
+% svn checkout http://svn.apache.org/repos/asf/httpd/httpd/trunk
+httpd-trunk</pre></p>
+<h2 id="httpd-site">httpd-site</h2>
+<p>This subtree contains the files that live
+at<samp>http://httpd.apache.org/</samp>. The directory on the host that
+maps to that URL is actually a set of checked-out working copies of the SVN
+files.</p>
+<p>The SVN URL
+is<samp>https://svn.apache.org/repos/asf/httpd/site/trunk/docs</samp>.
+<make_note>It is important that the files on the Web host not be modified
+directly. If you want or need to change one, check it out into a private
+working copy, modify <strong>that</strong> , commit the change into SVN, and then
+perform a<samp>svn update</samp>to bring the host directory into sync with
+the SVN sources.</make_note>
+The Web site <em>directories</em> (as opposed to files) are not maintained in
+synch with the SVN files automatically. They are manually updated from SVN
+by various people as they consider appropriate. This is usually not an
+issue, unless a group of files are being updated according to an ongoing
+group discussion.</p>
+<h2 id="httpd-dist">httpd-dist</h2>
+<p>Like the<samp>httpd-site</samp>subtree, this one is used to maintain the
+files that comprise a website - in this
+case,<samp>http://www.apache.org/dist/httpd/</samp>. Also like the previous
+subtree, the directory on the server is a checked-out working copy of this
+subtree. However, since this is a distribution directory, we only have the
+surrounding documentation and control files checked into this subtree --
+the actual tarballs are simply copied to www.apache.org.</p>
+<p>The SVN URL
+is<samp>https://svn.apache.org/repos/asf/httpd/httpd/dist</samp>.</p>
+<p>Committers will generally deal with this subtree when "rolling" a release.
+This is a series of steps taken to create a complete new release of the
+Apache httpd software. Amongst other things, the key to this subtree is
+the<samp>tools/</samp>directory, which contains
+the<samp>release.sh</samp>shell script. More information on the policies
+and procedures relating to rolling releases can be found on the <a href="release.html">Release
+Guidelines</a> page.</p>
+<h1 id="setting-up-remote-svn">Setting Up Remote SVN</h1>
+<p>A brief overview of getting started with SVN committer access can be found
+<a href="http://www.apache.org/dev/version-control.html#https-svn">here</a>. One key
+change to note is that SSH is not used anymore for committer access, due to
+the functional differences with SVN.</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/guidelines.html
==============================================================================
--- websites/staging/httpd/trunk/content/dev/guidelines.html (added)
+++ websites/staging/httpd/trunk/content/dev/guidelines.html Sun May 6 22:53:33 2012
@@ -0,0 +1,445 @@
+<!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 Project Guidelines and Voting Rules - 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 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>
+<h1 id="people-places-and-things">People, Places, and Things</h1>
+<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.</dd>
+</dl>
+<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>
+<dl>
+<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.</dd>
+</dl>
+<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>
+<dl>
+<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</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>
+<h1 id="status">STATUS</h1>
+<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>
+<h1 id="voting">Voting</h1>
+<p>Any of the Apache Developers may vote on any issue or action item. However,
+the only binding votes are those cast by active members of the Apache 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>
+<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>
+<h1 id="types-of-action-items">Types of Action Items</h1>
+<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:</dd>
+<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>
+<dl>
+<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>
+<h1 id="when-to-commit-a-change">When to Commit a Change</h1>
+<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
+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>
+<h1 id="changelogs">CHANGES file and Subversion logs</h1>
+<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>
+<h2 id="subversion-log">Subversion log</h2>
+<p>The Subversion commit log message contains any information needed by</p>
+<ul>
+<li>
+<p>fellow developers or other people researching source code changes/fixes</p>
+</li>
+<li>
+<p>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)</p>
+</li>
+</ul>
+<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>
+<p>Example log message: `
+Check the return code from parsing the content length, to avoid a
+crash if requests contain an invalid content length.</p>
+<p>PR: 99999
+Submitted by: Jane Doe <janedoe example.com>
+Reviewed by: susiecommitter
+` </p>
+<p>Commit messages can be minimal when making routine updates to STATUS, for
+example to propose a backport or vote.</p>
+<h2 id="changes">CHANGES</h2>
+<p>CHANGES is the subset of the information that end users need to see when
+they upgrade from one release to the next:</p>
+<ul>
+<li>
+<p>what can I now do that I couldn't do before</p>
+</li>
+<li>
+<p>what problems that we anticipate a user could have suffered from are now
+fixed</p>
+</li>
+<li>
+<p>all security fixes included, with CVE number. (If not available at the
+time of the commit, add later.)</p>
+</li>
+</ul>
+<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:</p>
+<ul>
+<li>
+<p>Fixes for bugs introduced after the last release don't belong in CHANGES.</p>
+</li>
+<li>
+<p>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.)</p>
+</li>
+<li>
+<p>Documentation fixes, whether for end users or developers, don't belong in
+CHANGES.</p>
+</li>
+</ul>
+<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>
+<h2 id="formatting">Formatting</h2>
+<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
+<code>user@example.com</code> to <code>&lt;user example.com&gt;</code>.</p>
+<p>Identify committers with their Apache userid, e.g. <code>xyz</code> (no domain name
+needed).</p>
+<p>If the change is related to a bugzilla issue, include the PR number in the
+log in the format: <code>PR nnnnn</code> </p>
+<p>Security-related changes should start like this: <code>*) SECURITY: CVE-YYYY-NNNN (cve.mitre.org)
+ xxxxxxxxxx</code> </p>
+<p>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>
+<p>Example CHANGES entries: `
+ *) SECURITY: CVE-2009-3095 (cve.mitre.org)
+ mod_proxy_ftp: sanity check authn credentials.
+ [Stefan Fritsch <sf fritsch.de>, Joe Orton]</p>
+<p>*) 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.<br />
+ (See util_mutex.h.) Build-time setting DEFAULT_LOCKFILE is no longer
+ respected; set DEFAULT_REL_RUNTIMEDIR instead. [Jeff Trawick]
+` </p>
+<h1 id="patch">Patch Format</h1>
+<p>When a specific change to the software is proposed for discussion or voting
+on the mailing list, it should be presented in the form of input to the
+patch command. When sent to the mailing list, the message should contain a
+Subject beginning with <code>[PATCH]</code> and a distinctive one-line summary
+corresponding to the action item for that patch. 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.,
+<code>diff -u http_main.c.orig http_main.c &gt;&gt; patchfile.txt</code>
+or
+<code>svn diff http_main.c &gt;&gt; patchfile.txt</code>
+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,
+<code>patch -s &lt; patchfile</code>
+is issued in the target repository.</p>
+<h1 id="addendum">Addendum</h1>
+<p>Outstanding issues with this document</p>
+<ul>
+<li>
+<p>We may need a better definition for "lazy consensus".</p>
+</li>
+<li>
+<p>We should clarify under what conditions a veto can be rescinded or
+overridden.</p>
+</li>
+<li>
+<p>Should we set a time limit on vetos of patches? Two weeks?</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/how-to-release.html
==============================================================================
--- websites/staging/httpd/trunk/content/dev/how-to-release.html (added)
+++ websites/staging/httpd/trunk/content/dev/how-to-release.html Sun May 6 22:53:33 2012
@@ -0,0 +1,437 @@
+<!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 build a release of 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>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></p>
+<p><strong><font color="red">This document has been obsoleted in httpd-2.0 by the
+httpd/site/trunk/tools/release.sh script.</font></strong> 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>
+<h1 id="unix">How to build an Apache Unix release</h1>
+<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 <strong>no going back</strong>. 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>
+<p>Checkout the Apache source if needed into a scratch directory:<br></br>
+For Apache 2. <em>X</em> :<br></br><code> <strong>$ cvs checkout -r APACHE_2_ <em>X</em>
+_BRANCH -Pd httpd-2. <em>X</em> </strong> httpd-2.0</code><br></br><code> <strong>$ cd httpd-2.
+<em>X</em> /srclib</strong> </code><br></br><code> <strong>$ cvs checkout apr apr-util</strong>
+</code><br></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>
+<p>cd into the <code>apache</code> CVS tree.<br></br><code> <strong>$ cd apache-1. <em>X</em> </strong>
+</code><br></br>or<br></br><code> <strong>$ cd httpd-2. <em>X</em> </strong> </code></p>
+</li>
+<li>
+<p>Adjust Announcement to taste.<br></br>
+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></br><code> <strong>$ vi Announcement</strong> </code><br></br><code> <strong>$
+cvs commit Announcement</strong> </code><br></br>
+<strong>Note:</strong> 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>
+</li>
+<li>
+<p>Change the version number to indicate a release.<br></br>
+For Apache 2.0:<br></br>Change <code>SERVER_BASEREVISION</code>
+in<TT>include/httpd.h</TT>from <code><code>2. *X* -dev</code>'' to</code><code>2.
+<em>X</em> </code>''. Then also change <code>APACHE_RELEASE</code> in the same file from
+<code><code>2 *XXYY0* 00</code>'' to</code><code>2 <em>XXYY1</em> 00</code>''.</p>
+</li>
+</ol>
+<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>
+<ol>
+<li>
+<p>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>`</code>pgp -kxa<code>'' command, add
+them to the</code>KEYS` file and commit it before tagging.</p>
+</li>
+<li>
+<p>Tag the sources for this release:<br></br>( *note: be sure to tag the
+whole thing, not just <code>src</code> * !)<br></br><code> <strong>$ cvs tag APACHE_1_ <em>X_Y</em></strong> </code><br></br>For Apache 2.0:<br></br><code> <strong>$ cvs tag APACHE_2_
+<em>X_Y</em> </strong> </code></p>
+</li>
+<li>
+<p>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></br>
+For Apache 2.0:<br></br><code> <strong>$ cd..</strong> </code><br></br><code> <strong>$ umask
+022</strong> </code><br></br><code> <strong>$ cvs export -r APACHE_2_ <em>X_Y</em> -d apache_2.
+<em>X.Y</em> httpd-2. <em>X</em> </strong> </code><br></br><code> <strong>$ cd apache_2. <em>X.Y</em>
+/srclib</strong> </code><br></br><code> <strong>$ cvs export -r APACHE_2_ <em>X_Y</em> apr
+apr-util</strong> </code></p>
+</li>
+<li>
+<p><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></br><code> <strong>$ umask 022</strong> </code><br></br><code>
+<strong>$ cvs checkout -r APACHE_2_ <em>X_Y</em> -d apache_2. <em>X.Y</em> httpd-2. <em>X</em> </strong>
+</code><br></br><code> <strong>$ cd apache_2. <em>X.Y</em> /srclib</strong>
+</code><br></br><code> <strong>$ cvs checkout -r APACHE_2 <em>X_Y</em> apr apr-util</strong>
+</code></p>
+</li>
+<li>
+<p>Make sure the master site's FAQ is up-to-date:<br></br><code> <strong>$ (cd
+/www/httpd.apache.org/docs/misc ; cvs update)</strong> </code></p>
+</li>
+<li>
+<p>Extract the FAQ as a single file, as it appears on the
+Web:<br></br><code> <strong>$ links -source
+http://httpd.apache.org/docs/misc/FAQ.html >
+htdocs/manual/misc/FAQ.html</strong> </code></p>
+</li>
+<li>
+<p>Create the configuration files:<br></br>
+For Apache 2.0:<br></br>Create <code>./configure</code> file, and remove all
+symlinks<br></br><code> <strong>$./buildconf</strong> </code><br></br><code> <strong>$ rm -f
+ltconfig ltmain.sh config.sub config.guess</strong> </code><br></br><code> <strong>$ cp
+/usr/local/share/libtool/ltconfig.</strong> </code><br></br><code> <strong>$ cp
+/usr/local/share/libtool/ltmain.sh.</strong> </code><br></br><code> <strong>$ cp
+/usr/local/share/libtool/config.sub.</strong> </code><br></br><code> <strong>$ cp
+/usr/local/share/libtool/config.guess.</strong> </code><br></br></p>
+</li>
+<li>
+<p>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></br><code> <strong>$ rm STATUS RULES.CVS src/INDENT
+htdocs/manual/misc/FAQ-*.html</strong> </code><br></br><code> <strong>$ find. -name
+".cvsignore" -exec rm {} \;</strong> </code><br></br><code> <strong>$ find. -type d
+-name "test" -exec rm -Rf {} \;</strong> </code></p>
+</li>
+<li>
+<p><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></br><code> <strong>$ find. -type d -name "CVS" -exec rm -rf {} \;</strong>
+</code></p>
+</li>
+<li>
+<p>Roll the distribution tarball:<br></br><code> <strong>$ tar cvf apache_
+<em>Z.X.Y</em>.tar apache_ <em>Z.X.Y</em> </strong> </code><br></br></p>
+</li>
+<li>
+<p>Make the final packed distribution files:<br></br><code> <strong>$ cp -p
+apache_ <em>Z.X.Y</em>.tar xapache_ <em>Z.X.Y</em>.tar</strong> </code><br></br><code> <strong>$ gzip
+-9 apache_ <em>Z.X.Y</em>.tar</strong> </code><br></br><code> <strong>$ mv xapache_ <em>Z.X.Y</em>.tar
+apache_ <em>Z.X.Y</em>.tar</strong> </code><br></br><code> <strong>$ compress apache_
+<em>Z.X.Y</em>.tar</strong> </code><br></br></p>
+</li>
+<li>
+<p>Test the packed tar files and check for errors:<br></br><code> <strong>$
+gunzip -c apache_ <em>Z.X.Y</em>.tar.gz | tar tvf -</strong> </code><br></br>(or
+simply:<code> <strong>$ tar tvzf apache_ <em>Z.X.Y</em>.tar.gz</strong> </code>)<br></br><code>
+<strong>$ uncompress <apache_ <em>Z.X.Y</em>.tar.Z | tar tvf -</strong> </code><br></br></p>
+</li>
+<li>
+<p>Sign the distribution files:<br></br><code> <strong>$ pgp -sba apache_
+<em>Z.X.Y</em>.tar.gz</strong> </code><br></br><code> <strong>$ pgp -sba apache_
+<em>Z.X.Y</em>.tar.Z</strong> </code><br></br></p>
+</li>
+<li>
+<p><font color="red">Note:</font>Be sure your PGP key is already in the
+<code>KEYS</code> file!</p>
+</li>
+<li>
+<p>Test the tarball signatures:<br></br><code> <strong>$ pgp apache_
+<em>Z.X.Y</em>.tar.gz.asc apache_ <em>Z.X.Y</em>.tar.gz</strong> </code><br></br><code> <strong>$ pgp
+apache_ <em>Z.X.Y</em>.tar.Z.asc apache_ <em>Z.X.Y</em>.tar.Z</strong> </code><br></br></p>
+</li>
+<li>
+<p>Remember the CHANGES file:<br></br><code> <strong>$ cp apache_ <em>Z.X.Y</em>
+/src/CHANGES./CHANGES_ <em>Z.X</em> </strong> </code></p>
+</li>
+<li>
+<p>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> <strong>$ rm -fr
+apache_ <em>Z.X.Y</em> </strong> </code></p>
+</li>
+<li>
+<p>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.</p>
+</li>
+<li>
+<p>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> <strong>$
+cd apache- <em>Z.X</em> </strong> </code>
+For Apache 2.0:<br></br>Change <code>SERVER_BASEREVERSION</code> in <code>include/httpd.h</code>
+from <code><code>2. *X.Y* </code>'' to</code><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></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></br><code> <strong>$ vi STATUS</strong> </code><br></br><code> <strong>$ cvs
+commit STATUS</strong> </code><br></br><br></br><code> <strong>$ cd..</strong>
+</code><br></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></br><code> <strong>$ vi include/httpd.h
+\<br></br>CHANGES</strong> </code><br></br><code> <strong>$ cvs commit include/httpd.h
+\<br></br>CHANGES</strong> </code><br></br><code> <strong>$ cd..</strong> </code><br></br></p>
+</li>
+<li>
+<p>Cleanup:<br></br>(delete the CVS tree, after verification that it does
+not contain any uncommitted changes)<br></br><code> <strong>$ cvs release -d
+apache- <em>Z.X</em> </strong> </code></p>
+</li>
+</ol>
+<p><strong>Now wait for the group to test and approve the tarball.</strong> </p>
+<h1 id="release">Final release steps</h1>
+<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>
+<p>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.</p>
+</li>
+<li>
+<p>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}/.</p>
+</li>
+<li>
+<p>Checkout the <a href="http://www.apache.org/dist/httpd/">httpd-dist site</a> , if
+needed, into a scratch directory:<br></br><code> <strong>$ cvs -d
+cvs.apache.org:/home/cvs checkout -P httpd-dist</strong> </code></p>
+</li>
+<li>
+<p>Change directory into <code>httpd-dist</code> <br></br><code> <strong>$ cd httpd-dist/</strong>
+</code></p>
+</li>
+<li>
+<p>Edit the files <a href="http://www.apache.org/dist/httpd/README.html"></a> and
+<a href="http://www.apache.org/dist/httpd/HEADER.html"></a> as well as
+<a href="http://www.apache.org/dist/httpd/Announcement.html"></a> and its plaintext
+equivalent <a href="http://www.apache.org/dist/httpd/Announcement.txt"></a> plus the
+<a href="http://www.apache.org/dist/httpd/.htaccess"></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/"></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></br><code> <strong>$ vi README.html HEADER.html
+Announcement.html Announcement.txt.htaccess</strong> </code><br></br></p>
+</li>
+<li>
+<p>Commit the changes:<br></br><code> <strong>$ cvs commit README.html
+HEADER.html Announcement.html Announcement.txt.htaccess</strong>
+</code><br></br><code> <strong>$ cd../..</strong> </code></p>
+</li>
+<li>
+<p>Checkout the <a href="http://httpd.apache.org/">httpd site</a> if needed into a
+scratch directory:<br></br><code> <strong>$ cvs -d cvs.apache.org:/home/cvs
+checkout httpd-site</strong> </code></p>
+</li>
+<li>
+<p>cd into the <code>httpd-site</code> xdocs tree.<br></br><code> <strong>$ cd
+httpd-site/xdocs/</strong> </code></p>
+</li>
+<li>
+<p>Edit the <a href="http://httpd.apache.org/"></a> page from the <code>httpd-site</code> CVS
+tree as required:<br></br><code> <strong>$ vi index.xml</strong> </code><br></br></p>
+</li>
+<li>
+<p>Commit the changes:<br></br><code> <strong>$ cd..</strong> </code><br></br><code>
+<strong>$./build.sh # Check result before continuing</strong> </code><br></br><code> <strong>$
+cvs commit</strong> </code><br></br></p>
+</li>
+<li>
+<p>Update the checked-out versions of the <code>httpd-dist</code> documents for the
+web server:<br></br><code> <strong>$ umask 002</strong> </code><br></br><code> <strong>$ cd
+/www/www.apache.org/dist/httpd/</strong> </code><br></br><code> <strong>$ cvs update
+-dP</strong> </code></p>
+</li>
+<li>
+<p>Create an empty directory for future patches:<br></br><code> <strong>$ mkdir
+patches/apply_to_1. <em>X.Y</em> </strong> </code></p>
+</li>
+<li>
+<p>Update the checked-out version of the <code>httpd-site index.html</code> page for
+the web server:<br></br><code> <strong>$ umask 002</strong> </code><br></br><code> <strong>$
+cd /www/httpd.apache.org/</strong> </code><br></br><code> <strong>$ cvs update -dP</strong>
+</code></p>
+</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>
+<h1 id="announce">Announcing a New Release</h1>
+<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>
+<p>Grab the prepared Announcement:<br></br>
+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>
+<p>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.</p>
+</li>
+<li>
+<p>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):</p>
+</li>
+<li>
+<p>Unmoderated UseNet newsgroups (should be crossposted)</p>
+<ul>
+<li>
+<p><code>comp.infosystems.www.servers.unix</code> </p>
+</li>
+<li>
+<p><code>comp.infosystems.www.servers.ms-windows</code> </p>
+</li>
+<li>
+<p><code>comp.infosystems.www.servers.misc</code> </p>
+</li>
+<li>
+<p><code>de.comm.infosystems.www.servers</code> </p>
+</li>
+</ul>
+</li>
+<li>
+<p>Moderated UseNet newsgroups (do <strong>not</strong> crosspost)</p>
+<ul>
+<li><code>comp.infosystems.www.announce</code> </li>
+</ul>
+</li>
+<li>
+<p>Mailing Lists</p>
+<ul>
+<li>
+<p><code>announce@apache.org</code> </p>
+</li>
+<li>
+<p><code>announce@httpd.apache.org</code> </p>
+</li>
+<li>
+<p><code>users@httpd.apache.org</code> </p>
+</li>
+<li>
+<p><code>users-de@httpd.apache.org</code> </p>
+</li>
+</ul>
+</li>
+<li>
+<p>Make sure that <code>Announcement.txt</code> and <code>Announcement.html</code> in
+<code>httpd-dist</code> are updated to include these changes.</p>
+</li>
+<li>
+<p>Bask in the glow</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>