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 @@ + + + + + + + Apache HTTPD Debugging Guide - The Apache HTTP Server Project + + + + + + + +
+ +

Essentials

+ +

Download!

+ +

Documentation

+ +

Get Support

+ +

Get Involved

+ +

Subprojects

+ +

Miscellaneous

+ + +
+ + + +
+ +

This document is a collection of notes regarding tools and techniques for +debugging Apache httpd and its modules.

+

Got more tips? Send 'em to +docs@httpd.apache.org. Thanks!

+
    +
  1. +

    Using

    +
  2. +
  3. +

    Getting a live backtrace on unix

    +
  4. +
  5. +

    Getting a live backtrace on Windows

    +
  6. +
  7. +

    Debugging intermittent crashes

    +
  8. +
  9. +

    Using '

    +
  10. +
  11. +

    Getting the server to dump core

    +
  12. +
  13. +

    Solaris and coredumps

    +
  14. +
  15. +

    Getting and analyzing a TCP packet trace

    +
  16. +
+

Using gdb

+

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 -g option in CFLAGS to +include the symbol information in the object files.

+

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 -X option for that purpose, which will work fine for most cases. +However, some modules don't like starting up with -X , but are happy if +you force only one child to run (using " MaxClients 1 "); you can then +use gdb's attach command to debug the child server.

+

The following example, withuser input in green, +shows the output of gdb run on a server executable (httpd) in the current +working directory and using the server root of /usr/local/apache : +

+    % 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

+
[at this point I make a request from another window]
+
+Breakpoint 1, ap_process_request (r=0x95250) at http_request.c:1164
+1164    if (ap_extended_status)
+(gdb) s
+1165       
+ap_time_process_request(r->connection->child_num,...
+(gdb) n
+1167    process_request_internal(r);
+(gdb) s
+process_request_internal (r=0x95250) at http_request.c:1028
+1028    if (!r->proxyreq && r->parsed_uri.path) {
+(gdb) s
+1029        access_status = ap_unescape_url(r->parsed_uri.path);
+(gdb) n
+1030        if (access_status) {
+(gdb) s
+1036    ap_getparents(r->uri);     /* OK...
+(gdb) n
+1038    if ((access_status = location_walk(r))) {
+(gdb) n
+1043    if ((access_status = ap_translate_name(r))) {
+(gdb) n
+1048    if (!r->proxyreq) {
+(gdb) n
+1053        if (r->method_number == M_TRACE) {
+(gdb) n
+1062    if (r->proto_num > HTTP_VERSION(1,0) &&
+ap_...
+(gdb) n
+1071    if ((access_status = directory_walk(r))) {
+(gdb) s
+directory_walk (r=0x95250) at http_request.c:288
+288     core_server_config *sconf = ap_get_module_...
+(gdb) b ap_send_error_response
+Breakpoint 2 at 0x47dcc: file http_protocol.c, line 2090.
+(gdb) c
+Continuing.
+
+Breakpoint 2, ap_send_error_response (r=0x95250, recursive_error=0)
+at http_protocol.c:2090
+2090    BUFF *fd = r->connection->client;
+(gdb) where
+#0  ap_send_error_response (r=0x95250, recursive_error=0)
+at http_protocol.c:2090
+#1  0x49b10 in ap_die (type=403, r=0x95250) at http_request.c:989
+#2  0x49b60 in decl_die (status=403, phase=0x62db8 "check access",
+r=0x95250)
+at http_request.c:1000
+#3  0x49f68 in process_request_internal (r=0x95250) at
+http_request.c:1141
+#4  0x49fe0 in ap_process_request (r=0x95250) at http_request.c:1167
+#5  0x439d8 in child_main (child_num_arg=550608) at http_main.c:3826
+#6  0x43b5c in make_child (s=0x7c3e8, slot=0, now=907958743)
+at http_main.c:3898
+#7  0x43ca8 in startup_children (number_to_start=6) at http_main.c:3972
+#8  0x44260 in standalone_main (argc=392552, argv=0x75800) at
+http_main.c:4250
+#9  0x449fc in main (argc=4, argv=0xefffee8c) at http_main.c:4534
+(gdb) s
+2091    int status = r->status;
+(gdb) p status
+$1 = 403
+(gdb)
+
+ + +

+There are a few things to note about the above example:

+
    +
  1. +

    the " gdb httpd " command does not include any command-line options +for httpd: those are provided when the " run " command is done within +gdb;

    +
  2. +
  3. +

    I set a breakpoint before starting the run so that execution would stop +at the top of ap_process_request();

    +
  4. +
  5. +

    the " s " command steps through the code and into called procedures, +whereas the " n " (next) command steps through the code but not into +called procedures.

    +
  6. +
  7. +

    additional breakpoints can be set with the " b " command, and the run +continued with the " c " command.

    +
  8. +
  9. +

    use the " where " command (a.k.a. " bt ") to see a stack backtrace +that shows the order of called procedures and their parameter values.

    +
  10. +
  11. +

    use the " p " command to print the value of a variable.

    +
  12. +
+

A file in the the root directory called .gdbinit provides useful macros +for printing out various internal structures of httpd like tables ( +dump_table ), brigades ( dump_brigade ) and filter chains ( +dump_filters ).

+

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.

+

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.

+

If you are debugging a system crash and you have a core file from the +crash, then do the following: +

+    % gdb httpd -c core
+    (gdb) where
+and it will (hopefully) print a stack backtrace of where the core dump +occurred during processing.

+

Getting a live backtrace on unix

+

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.

+

For SVR4-based variants of Unix, the pstack command for proc can be used +to display a a live backtrace. For example, on Solaris it looks like +

+    % /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
+
+Another technique is to use gdb to attach to the running process and then +using "where" to print the backtrace, as in +
+    % 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...

+
/usr/local/apache/src/10623: No such file or directory.
+Attaching to program `/usr/local/apache/src/httpd', process 10623
+Reading symbols from /usr/lib/libsocket.so.1...done.
+Reading symbols from /usr/lib/libnsl.so.1...done.
+Reading symbols from /usr/lib/libc.so.1...done.
+Reading symbols from /usr/lib/libdl.so.1...done.
+Reading symbols from /usr/lib/libintl.so.1...done.
+Reading symbols from /usr/lib/libmp.so.1...done.
+Reading symbols from /usr/lib/libw.so.1...done.
+Reading symbols from
+/usr/platform/SUNW,Ultra-1/lib/libc_psr.so.1...done.
+0xef5b68d8 in   ()
+(gdb) where
+#0  0xef5b68d8 in   ()
+#1  0xef5d21e8 in select ()
+#2  0x4257c in wait_or_timeout (status=0x0) at http_main.c:2357
+#3  0x44318 in standalone_main (argc=392552, argv=0x75800) at...
+#4  0x449fc in main (argc=3, argv=0xefffeee4) at http_main.c:4534
+(gdb)
+
+ + +
+ +

Getting a live backtrace on Windows

+
    +
  1. +

    Unzip the -symbols.zip 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.

    +
  2. +
  3. +

    Invoke drwtsn32 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.)

    +
  4. +
  5. +

    Note that if you previously installed and then uninstalled other +debugging software, you may need to invoke drwtsn32 -i 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 Debugger under the HKLM\SOFTWARE\Microsoft\Windows +NT\CurrentVersion\AeDebug registry tree. Developers using multiple tools +might want to keep copies of their different tools Debugger entries there, +for fast switching.)

    +
  6. +
  7. +

    Invoke the Task Manager, Choose 'show processes from all users', and +modify the View -> Select Columns to include at least the PID +and Thread + Count. You can change this just once and Task Manager should keep your + preference.

    +
  8. +
  9. +

    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.

    +
  10. +
  11. +

    Using the {pid} number you noted above, invoke the command

    +
    +

    drwtsn32 -p {pid}

    +
    +
  12. +
+

Voila, you will find in your 'log file path' a drwtsn32.log 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.

+

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.

+

Debugging intermittent crashes

+

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.

+

To ensure that a core dump is written to a directory which is writable by +the user which child processes run as (such as apache ), the + +directive must be added to httpd.conf ; for example: +CoreDumpDirectory /tmp +Before starting up the server, any process limits on core dump file size +must be lifted; for example: +# ulimit -c unlimited + # apachectl start +On some platforms, further steps might be needed to enable core dumps - see +Solaris and coredumps below.

+

When a child process crashes, a message like the following will be logged +to the error_log:

+
+

[Mon Sep 05 13:35:39 2005] [notice] child pid 2027 exit signal Segmentation +fault (11), possible coredump in /tmp

+
+

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 CoreDumpDirectory are suitable and that platform specific +steps ( Solaris and coredumps ) have been done if needed.

+

To analyse the core dump, pass the core dump filename on the gdb +command-line, and enter the command bt full at the gdb prompt: +

+  % gdb /usr/local/apache2/bin/httpd /tmp/core.2027
+...
+  Core was generated by /usr/local/apache2/bin/httpd -k start'
+...
+  (gdb) bt full</pre>
+If attempting to debug a threaded server, for example when using theworker` MPM, use the following gdb command:
+
+  (gdb) thread apply all bt full

+

Using 'truss/trace/strace' to trace system calls and signals

+

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 truss on most SVR4-based systems and either trace or +strace on many other systems.

+

A useful tip for using the truss command on Solaris is the -f option +(often also works with strace ); 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: +

+    % truss -f httpd -d /usr/local/apache >& outfile
+    % egrep '^10698:' outfile
+to view just the trace of the process id 10698.

+

If attempting to truss a threaded server, for example when using the +worker MPM, the truss option -l is very useful as it prints also the +LWP id after the process id. You can use something like +

+    % egrep '^10698/1:' outfile
+to view just the trace of the process id 10698 and LWP id 1.

+

Other useful options for truss are

+ +

Getting the server to dump core

+

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 gcore 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.

+

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]. +# for pid inps -eaf | fgrep httpd | cut -d' ' -f4do + truss -f -l -t\!all -S SIGSEGV -p $pid 2&gt;&amp;1 | egrep SIGSEGV + &amp; + done +The undocumented '-S' +flag to truss +will halt the process in place upon receipt of a given signal (SIGSEGV in +this case). At this point you can use: +

+    # gcore PID
+and then look at the backtrace as discussed above for gdb.

+

Solaris and coredumps

+

On Solaris use to +make setuid() 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 apache ) do not +coredump even when the + +directive had been set to an appropriate and writable directory and +ulimit -c has a sufficient size. See also Debugging intermittent +crashes above.

+

Example: +-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

+

Getting and analyzing a TCP packet trace

+

This is too deep a subject to fully describe in this documentation. Here +are some pointers to useful discussions and tools:

+ + + + + +
+ + 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 @@ + + + + + + + Apache Development Notes - The Apache HTTP Server Project + + + + + + + +
+ +

Essentials

+ +

Download!

+ +

Documentation

+ +

Get Support

+ +

Get Involved

+ +

Subprojects

+ +

Miscellaneous

+ + +
+ + + +
+ +

This page is intended to provide some basic background about development +nits and the maintenance of the developer site.

+

Overview

+

The Apache HTTP Server Project has switched to +Subversion for hosting its source code.

+

To check out the 2.4.x branch:

+
+

svn checkout http://svn.apache.org/repos/asf/httpd/httpd/branches/2.4.x +httpd-2.4.x

+
+

To check out the current development version (as of this writing, 2.5.x), +use:

+
+

svn checkout http://svn.apache.org/repos/asf/httpd/httpd/trunk httpd-trunk

+
+

Committers should check out via https instead of http (so that they can +commit their changes). For more info about Subversion, please read the ASF +version control FAQ.

+

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.

+

Maintaining the Sources

+

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 +SVN repository. Here is the way in which +changes are applied:

+
    +
  1. Developer checks out a copy of the files on which he wants to work (in +this case, the trunk), into a private working directory +calledhttpd-trunk:
  2. +
+
+
% svn checkout http://svn.apache.org/repos/asf/httpd/httpd/trunk + httpd-trunk
+
+

This step only needs to be performed once (unless the private working +directory is tainted or deleted.) Committers should use a URL prefix +ofhttpson the checkout, to save themselves headaches later.

+
    +
  1. Developer keeps his working directory synchronised with changes made to +the repository:
  2. +
+
+
% svn update httpd-trunk
+
+

This should probably be done daily or even more frequently during periods +of high activity.

+
    +
  1. Developer makes changes to his working copies, makes sure they work, and +generates a patch so others can apply the changes to test them:
  2. +
+
+
% svn diff httpd-trunk/modules/http/mod_mime.c > + /tmp/foo
+
+

The/tmp/foofile is mailed to the developers +list 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 style guide.

+
    +
  1. Once other developers have agreed that the change is a Good Thing, the +developer checks the changes into the repository:
  2. +
+
+
% svn commit httpd-trunk/modules/http/mod_mime.c
+
+

SVN Subtrees

+

There are several different branches under thehttpdsubtree in +the Apache SVN repository that pertain to the different releases. The top +level can be perused with the SVN +ViewCVS pages. The main subtrees +pertaining to thehttpdserver source are:

+

httpd-2.2

+

To create a directory tree containing the 2.2 sources, and call +ithttpd-2.2, change your current directory to the parent of +the tree and then check the 2.2 sources out as follows: +

+% cd /usr/local/apache
+% svn checkout http://svn.apache.org/repos/asf/httpd/httpd/branches/2.2.x
+   httpd-2.2

+

httpd-2.4

+

To create a directory tree containing the 2.4 sources, and call +ithttpd-2.4, change your current directory to the parent of +the tree and then check the 2.4 sources out as follows: +

+% cd /usr/local/apache
+% svn checkout http://svn.apache.org/repos/asf/httpd/httpd/branches/2.4.x
+   httpd-2.4

+

httpd-2.5

+

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 +ithttpd-trunk, checkout as follows: +

+% cd /usr/local/apache
+% svn checkout http://svn.apache.org/repos/asf/httpd/httpd/trunk
+httpd-trunk

+

httpd-site

+

This subtree contains the files that live +athttp://httpd.apache.org/. The directory on the host that +maps to that URL is actually a set of checked-out working copies of the SVN +files.

+

The SVN URL +ishttps://svn.apache.org/repos/asf/httpd/site/trunk/docs. +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 that , commit the change into SVN, and then +perform asvn updateto bring the host directory into sync with +the SVN sources. +The Web site directories (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.

+

httpd-dist

+

Like thehttpd-sitesubtree, this one is used to maintain the +files that comprise a website - in this +case,http://www.apache.org/dist/httpd/. 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.

+

The SVN URL +ishttps://svn.apache.org/repos/asf/httpd/httpd/dist.

+

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 +thetools/directory, which contains +therelease.shshell script. More information on the policies +and procedures relating to rolling releases can be found on the Release +Guidelines page.

+

Setting Up Remote SVN

+

A brief overview of getting started with SVN committer access can be found +here. One key +change to note is that SSH is not used anymore for committer access, due to +the functional differences with SVN.

+ + + + +
+ + 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 @@ + + + + + + + Apache HTTP Server Project Guidelines and Voting Rules - The Apache HTTP Server Project + + + + + + + +
+ +

Essentials

+ +

Download!

+ +

Documentation

+ +

Get Support

+ +

Get Involved

+ +

Subprojects

+ +

Miscellaneous

+ + +
+ + + +
+ +

This document defines the guidelines for the Apache HTTP Server +Project. It includes definitions of how conflict +is resolved by voting, who is able to vote, and the procedures to follow +for proposing and making changes to the Apache products.

+

The objective here is to avoid unnecessary conflict over changes and +continue to produce a quality system in a timely manner. Not all conflict +can be avoided, but at least we can agree on the procedures for conflict to +be resolved.

+

People, Places, and Things

+
+
Apache HTTP Server Project Management Committee
+
The group of volunteers who are responsible for managing the Apache + HTTP Server Project. This includes deciding what is distributed as + products of the Apache HTTP Server Project, maintaining the Project's + shared resources, speaking on behalf of the Project, resolving license + disputes regarding Apache products, nominating new PMC members or + committers, and establishing these guidelines.
+
+

Membership in the Apache PMC is by invitation only and must be approved by +consensus of the active Apache PMC members. A PMC member is considered +inactive by their own declaration or by not contributing in any form to the +project for over six months. An inactive member can become active again by +reversing whichever condition made them inactive ( i.e. , by reversing +their earlier declaration or by once again contributing toward the +project's work). Membership can be revoked by a unanimous vote of all the +active PMC members other than the member in question.

+
+
Apache HTTP Server Committers
+
The group of volunteers who are responsible for the technical aspects + of the Apache HTTP Server Project. This group has write access to the + appropriate source repositories and these volunteers may cast binding + votes on any technical discussion.
+
+

Membership as a Committer is by invitation only and must be approved by +consensus of the active Apache PMC members. A Committer is considered +inactive by their own declaration or by not contributing in any form to the +project for over six months. An inactive member can become active again by +reversing whichever condition made them inactive ( i.e. , by reversing +their earlier declaration or by once again contributing toward the +project's work). Membership can be revoked by a unanimous vote of all the +active PMC members (except the member in question if they are a PMC +member).

+
+
Apache Developers
+
All of the volunteers who are contributing time, code, documentation, + or resources to the Apache Project. A developer that makes sustained, + welcome contributions to the project for over six months is usually + invited to become a Committer, though the exact timing of such + invitations depends on many factors.
+
mailing list
+
The Apache developers' primary mailing list for discussion of issues + and changes related to the project ( dev@httpd.apache.org ). + Subscription to the list is open, but only subscribers can post + directly to the list.
+
private list
+
The Apache PMC's private mailing list for discussion of issues that + are inappropriate for public discussion, such as legal, personal, or + security issues prior to a published fix. Subscription to the list is + only open (actually: mandatory) to Apache httpd's Project Management + Comittee.
+
Subversion
+
All of the Apache products are maintained in shared information + repositories using Subversion on. Only some of the + Apache developers have write access to these repositories; everyone + has read access.
+
+

STATUS

+

Each of the Apache Project's active source code repositories contain a file +called "STATUS" which is used to keep track of the agenda and plans for +work within that repository. The STATUS file includes information about +release plans, a summary of code changes committed since the last release, +a list of proposed changes that are under discussion, brief notes about +items that individual developers are working on or want discussion about, +and anything else that might be useful to help the group track progress. +The active STATUS files are automatically posted to the mailing list each +week.

+

Many issues will be encountered by the project, each resulting in zero or +more proposed action items. Issues should be raised on the mailing list as +soon as they are identified. Action items must be raised on the mailing +list and added to the relevant STATUS file. All action items may be voted +on, but not all of them will require a formal vote.

+

Voting

+

Any of the Apache Developers may vote on any issue or action item. However, +the only binding votes are those cast by active members of the Apache HTTP +Server; if the vote is about a change to source code or documentation, the +primary author of what is being changed may also cast a binding vote on +that issue. All other votes are non-binding. All developers are encouraged +to participate in decisions, but the decision itself is made by those who +have been long-time contributors to the project. In other words, the Apache +httpd Project is a minimum-threshold meritocracy.

+

The act of voting carries certain obligations -- voting members are not +only stating their opinion, they are agreeing to help do the work of the +Apache Project. Since we are all volunteers, members often become inactive +for periods of time in order to take care of their "real jobs" or devote +more time to other projects. It is therefore unlikely that the entire group +membership will vote on every issue. To account for this, all voting +decisions are based on a minimum quorum.

+

Each vote can be made in one of three flavors:

+
+
+1
+
Yes, agree, or the action should be performed. On some issues, this + vote is only binding if the voter has tested the action on their own + system(s).
+
±0
+
Abstain, no opinion, or I am happy to let the other group members + decide this issue. An abstention may have detrimental effects if too + many people abstain.
+
-1
+
No. On issues where consensus is required, this vote counts as a + veto. All vetos must include an explanation of why the veto is + appropriate. A veto with no explanation is void. No veto can be + overruled. If you disagree with the veto, you should lobby the person + who cast the veto. Voters intending to veto an action item should make + their opinions known to the group immediately, so that the problem can + be remedied as early as possible.
+
+

An action item requiring consensus approval must receive at least 3 +binding +1 votes and no vetos. An action item requiring majority +approval must receive at least 3 binding +1 votes and more +1 +votes than -1 votes ( i.e. , a majority with a minimum quorum of +three positive votes). All other action items are considered to have lazy +approval until someone votes -1 , after which point they are decided +by either consensus or a majority vote, depending upon the type of action +item.

+

Votes are tallied within the STATUS file, adjacent to the action item under +vote. All votes must be either sent to the mailing list or added directly +to the STATUS file entry for that action item.

+

Types of Action Items

+
+
Long Term Plans
+
Long term plans are simply announcements that group members are + working on particular issues related to the Apache software. These are + not voted on, but group members who do not agree with a particular + plan, or think an alternate plan would be better, are obligated to + inform the group of their feelings. In general, it is always better to + hear about alternate plans prior to spending time on less adequate + solutions.
+
Short Term Plans
+
Short term plans are announcements that a developer is working on a + particular set of documentation or code files, with the implication + that other developers should avoid them or try to coordinate their + changes. This is a good way to proactively avoid conflict and possible + duplication of work.
+
Release Plan
+
A release plan is used to keep all the developers aware of when a + release is desired, who will be the release manager, when the + repository will be frozen in order to create the release, and assorted + other trivia to keep us from tripping over ourselves during the final + moments. Lazy majority decides each issue in the release plan.
+
Release Testing
+
After a new release is built, colloquially termed a tarball, it must + be tested before being released to the public. Majority approval is + required before the tarball can be publically released.
+
Showstoppers
+
Showstoppers are issues that require a fix be in place before the next + public release. They are listed in the STATUS file in order to focus + special attention on the problem. An issue becomes a showstopper when + it is listed as such in STATUS and remains so by lazy consensus.
+
Product Changes
+
Changes to the Apache products, including code and documentation, will + appear as action items under several categories corresponding to the + change status:
+
concept/plan
+
An idea or plan for a change. These are usually only listed in STATUS + when the change is substantial, significantly impacts the API, or is + likely to be controversial. Votes are being requested early so as to + uncover conflicts before too much work is done.
+
proposed patch
+
A specific set of changes to the current product in the form of input + to the patch command (a diff output).
+
committed change
+
A one-line summary of a change that has been committed to the + repository since the last public release.
+
+

All product changes to the currently active repository are subject to lazy +consensus. All product changes to a prior-branch (old version) repository +require consensus before the change is committed.

+
+
Backport
+
A backport is the application of a change on the Subversion repository + trunk to the a maintenance branch of the project. This is necessary in + cases where an issue exists in multiple versions of the Apache HTTP + Server. A fix for such an issue will typically be developed for the + trunk, which is under active development.
+
+

When to Commit a Change

+

Ideas must be review-then-commit; patches can be commit-then-review. With a +commit-then-review process, we trust that the developer doing the commit +has a high degree of confidence in the change. Doubtful changes, new +features, and large-scale overhauls need to be discussed before being +committed to a repository. Any change that affects the semantics of +arguments to configurable directives, significantly adds to the runtime +size of the program, or changes the semantics of an existing API function +must receive consensus approval on the mailing list before being committed.

+

Each developer is responsible for notifying the mailing list and adding an +action item to STATUS when they have an idea for a new feature or major +change to propose for the product. The distributed nature of the Apache +project requires an advance notice of 48 hours in order to properly review +a major change -- consensus approval of either the concept or a specific +patch is required before the change can be committed. Note that a member +might veto the concept (with an adequate explanation), but later rescind +that veto if a specific patch satisfies their objections. No advance notice +is required to commit singular bug fixes.

+

Related changes should be committed as a group, or very closely together. +Half-completed projects should not be committed unless doing so is +necessary to pass the baton to another developer who has agreed to complete +the project in short order. All code changes must be successfully compiled +on the developer's platform before being committed.

+

The current source code tree should be capable of complete compilation at +all times. However, it is sometimes impossible for a developer on one +platform to avoid breaking some other platform when a change is committed, +particularly when completing the change requires access to a special +development tool on that other platform. If it is anticipated that a given +change will break some other platform, the committer must indicate that in +the commit log.

+

The committer is responsible for the quality of any third-party code or +documentation they commit to the repository. All software committed to the +repository must be covered by the Apache LICENSE or contain a copyright and +license that allows redistribution under the same conditions as the Apache +LICENSE.

+

A committed change must be reversed if it is vetoed by one of the voting +members and the veto conditions cannot be immediately satisfied by the +equivalent of a "bug fix" commit. The veto must be rescinded before the +change can be included in any public release.

+

CHANGES file and Subversion logs

+

Many code changes should be noted in the CHANGES file, and all should be +documented in Subversion commit messages. Often the text of the Subversion +log and the CHANGES entry are the same, but the distinct requirements +sometimes result in different information.

+

Subversion log

+

The Subversion commit log message contains any information needed by

+ +

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.

+

Example log message: ` +Check the return code from parsing the content length, to avoid a +crash if requests contain an invalid content length.

+

PR: 99999 +Submitted by: Jane Doe <janedoe example.com> +Reviewed by: susiecommitter +`

+

Commit messages can be minimal when making routine updates to STATUS, for +example to propose a backport or vote.

+

CHANGES

+

CHANGES is the subset of the information that end users need to see when +they upgrade from one release to the next:

+ +

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:

+ +

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.

+

The attribution for the change is anyone responsible for the code changes.

+

Formatting

+

Identify non-committers by name, and their email in obfuscated form if +available. The obfuscation is done by replacing "@" with a space and adding +"<" and ">" around the address. For example, change +user@example.com to &lt;user example.com&gt;.

+

Identify committers with their Apache userid, e.g. xyz (no domain name +needed).

+

If the change is related to a bugzilla issue, include the PR number in the +log in the format: PR nnnnn

+

Security-related changes should start like this: *) SECURITY: CVE-YYYY-NNNN (cve.mitre.org) + xxxxxxxxxx

+

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.

+

Example CHANGES entries: ` + *) SECURITY: CVE-2009-3095 (cve.mitre.org) + mod_proxy_ftp: sanity check authn credentials. + [Stefan Fritsch <sf fritsch.de>, Joe Orton]

+

*) Replace AcceptMutex, LockFile, RewriteLock, SSLMutex, + SSLStaplingMutex, + and WatchdogMutexPath with a single Mutex directive. Add APIs to + simplify setup and user customization of APR proc and global mutexes.
+ (See util_mutex.h.) Build-time setting DEFAULT_LOCKFILE is no longer + respected; set DEFAULT_REL_RUNTIMEDIR instead. [Jeff Trawick] +`

+

Patch Format

+

When a specific change to the software is proposed for discussion or voting +on the mailing list, it should be presented in the form of input to the +patch command. When sent to the mailing list, the message should contain a +Subject beginning with [PATCH] and a distinctive one-line summary +corresponding to the action item for that patch. Afterwords, the patch +summary in the STATUS file should be updated to point to the Message-ID of +that message.

+

The patch should be created by using thediff -ucommand from +the original software file(s) to the modified software file(s). E.g., +diff -u http_main.c.orig http_main.c &gt;&gt; patchfile.txt +or +svn diff http_main.c &gt;&gt; patchfile.txt +All patches necessary to address an action item should be concatenated +within a single patch message. If later modification of the patch proves +necessary, the entire new patch should be posted and not just the +difference between two patches. The STATUS file entry should then be +updated to point to the new patch message.

+

The completed patchfile should produce no errors or prompts when the +command, +patch -s &lt; patchfile +is issued in the target repository.

+

Addendum

+

Outstanding issues with this document

+ + + + + +
+ + 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 @@ + + + + + + + How to build a release of Apache - The Apache HTTP Server Project + + + + + + + +
+ +

Essentials

+ +

Download!

+ +

Documentation

+ +

Get Support

+ +

Get Involved

+ +

Subprojects

+ +

Miscellaneous

+ + +
+ + + +
+ +

Alexei Kosut <akosut@apache.org>

Ralf S. Engelschall +<rse@apache.org>

Jim Jagielski +<jim@apache.org>

Ken Coar +<coar@apache.org>

Martin Kraemer +<martin@apache.org>

+

This document has been obsoleted in httpd-2.0 by the +httpd/site/trunk/tools/release.sh script. It does everything for +you. At some point, we may come back and update this document. So, in the +meantime, ignore this and use that script for Apache 2.0 rolls.

+

This document describes the typical release cycle the release manager has +to step through when creating a new Apache release. It is written down as a +step-by-step instruction list and should be followed exactly as specified +to avoid problems or inconsistencies both in the created tarballs and the +source repository.

+

How to build an Apache Unix release

+

Note:The below assumes that you are using ssh to +login to your httpd.apache.org account. If you are "rolling the tarball" +remotely, the differences will be noted.

+

Important:Once tagged and the tarball is rolled, +there is no going back. If there are problems with the tarball, the +version number (either the rev-level or beta-level) must be bumped +resulting in a new tag, tarball and release.

+
+
    +
  1. +

    Checkout the Apache source if needed into a scratch directory:

    +For Apache 2. X :

    $ cvs checkout -r APACHE_2_ X +_BRANCH -Pd httpd-2. X httpd-2.0

    $ cd httpd-2. +X /srclib

    $ cvs checkout apr apr-util +

    Omit the -r APACHE_2_ X _BRANCH flag for the current +development branch (e.g. 2.1-dev.) The current development branch always +sits at cvs HEAD.

    +
  2. +
  3. +

    cd into the apache CVS tree.

    $ cd apache-1. X +

    or

    $ cd httpd-2. X

    +
  4. +
  5. +

    Adjust Announcement to taste.

    +A prototype Announcement is included in the main CVS source tree. This +file should be updated to reflect the current state of affairs concerning +the release. For example, the Release Version should reflect what is +actually being announced. Also, the key enhancements of the Release should +be noted.

    $ vi Announcement

    $ +cvs commit Announcement

    +Note: This document is also present in the httpd-dist cvs module, +both in HTML and plain text form. You may want to create one version out of +the other.

    +
  6. +
  7. +

    Change the version number to indicate a release.

    +For Apache 2.0:

    Change SERVER_BASEREVISION +ininclude/httpd.hfrom <code>2. *X* -dev</code>'' to2. +X ''. Then also change APACHE_RELEASE in the same file from +<code>2 *XXYY0* 00</code>'' to2 XXYY1 00''.

    +
  8. +
+

Note:until Apache 2.0 is of general release quality, +module magic numbers are not enforced. You must +editinclude/ap_mmn.hand bump the MODULE_MAGIC_NUMBER_MAJOR prior +to rolling the tarball, to assure beta testers are testing the +corresponding.so modules.This policy will be retracted, and coders will +be reponsible for mmn bumps, once Apache 2.0 is officially released.

+
    +
  1. +

    Make sure your PGP keys are already present in the KEYS file. If they +are not, extract your public key using the `pgp -kxa'' command, add +them to theKEYS` file and commit it before tagging.

    +
  2. +
  3. +

    Tag the sources for this release:

    ( *note: be sure to tag the +whole thing, not just src * !)

    $ cvs tag APACHE_1_ X_Y

    For Apache 2.0:

    $ cvs tag APACHE_2_ +X_Y

    +
  4. +
  5. +

    Make an export version of the distribution: (this creates a second +subdirectoryapache-Z. X.Y for the exported version beside +the existing CVS tree inapache-Z. X )

    +For Apache 2.0:

    $ cd..

    $ umask +022

    $ cvs export -r APACHE_2_ X_Y -d apache_2. +X.Y httpd-2. X

    $ cd apache_2. X.Y +/srclib

    $ cvs export -r APACHE_2_ X_Y apr +apr-util

    +
  6. +
  7. +

    Note:There is a known problem using cvs export +remotely with cvs-1.9 and later. If this affects you, you will need to do +a checkout instead:

    $ umask 022

    +$ cvs checkout -r APACHE_2_ X_Y -d apache_2. X.Y httpd-2. X +

    $ cd apache_2. X.Y /srclib +

    $ cvs checkout -r APACHE_2 X_Y apr apr-util +

    +
  8. +
  9. +

    Make sure the master site's FAQ is up-to-date:

    $ (cd +/www/httpd.apache.org/docs/misc ; cvs update)

    +
  10. +
  11. +

    Extract the FAQ as a single file, as it appears on the +Web:

    $ links -source +http://httpd.apache.org/docs/misc/FAQ.html > +htdocs/manual/misc/FAQ.html

    +
  12. +
  13. +

    Create the configuration files:

    +For Apache 2.0:

    Create ./configure file, and remove all +symlinks

    $./buildconf

    $ rm -f +ltconfig ltmain.sh config.sub config.guess

    $ cp +/usr/local/share/libtool/ltconfig.

    $ cp +/usr/local/share/libtool/ltmain.sh.

    $ cp +/usr/local/share/libtool/config.sub.

    $ cp +/usr/local/share/libtool/config.guess.

    +
  14. +
  15. +

    Remove STATUS , RULES.CVS , src/INDENT , the multi-part FAQ, +various .cvsignore and the developer's test subdirectories. Depending on +which version you are releasing, not all of these files will be in the +repository:

    $ rm STATUS RULES.CVS src/INDENT +htdocs/manual/misc/FAQ-*.html

    $ find. -name +".cvsignore" -exec rm {} \;

    $ find. -type d +-name "test" -exec rm -Rf {} \;

    +
  16. +
  17. +

    Note:If you needed to do a checkout instead of +a export , you will also need to remove the CVS administrative +files:

    $ find. -type d -name "CVS" -exec rm -rf {} \; +

    +
  18. +
  19. +

    Roll the distribution tarball:

    $ tar cvf apache_ +Z.X.Y.tar apache_ Z.X.Y

    +
  20. +
  21. +

    Make the final packed distribution files:

    $ cp -p +apache_ Z.X.Y.tar xapache_ Z.X.Y.tar

    $ gzip +-9 apache_ Z.X.Y.tar

    $ mv xapache_ Z.X.Y.tar +apache_ Z.X.Y.tar

    $ compress apache_ +Z.X.Y.tar

    +
  22. +
  23. +

    Test the packed tar files and check for errors:

    $ +gunzip -c apache_ Z.X.Y.tar.gz | tar tvf -

    (or +simply: $ tar tvzf apache_ Z.X.Y.tar.gz )

    +$ uncompress <apache_ Z.X.Y.tar.Z | tar tvf -

    +
  24. +
  25. +

    Sign the distribution files:

    $ pgp -sba apache_ +Z.X.Y.tar.gz

    $ pgp -sba apache_ +Z.X.Y.tar.Z

    +
  26. +
  27. +

    Note:Be sure your PGP key is already in the +KEYS file!

    +
  28. +
  29. +

    Test the tarball signatures:

    $ pgp apache_ +Z.X.Y.tar.gz.asc apache_ Z.X.Y.tar.gz

    $ pgp +apache_ Z.X.Y.tar.Z.asc apache_ Z.X.Y.tar.Z

    +
  30. +
  31. +

    Remember the CHANGES file:

    $ cp apache_ Z.X.Y +/src/CHANGES./CHANGES_ Z.X

    +
  32. +
  33. +

    Cleanup:

    (this deletes the export tree: it is now no longer +required. We still need the CVS tree, see below)

    $ rm -fr +apache_ Z.X.Y

    +
  34. +
  35. +

    Make the tarball available for testing purposes (in +http://httpd.apache.org/dev/dist/ ) by +committing the generated release tarballs and signatures to the +https://dist.apache.org/repos/dist/dev/httpd/ repository.

    +
  36. +
  37. +

    Bump the version number to the next version and indicate we are in +development.

    cd back into the CVS tree location.

    $ +cd apache- Z.X +For Apache 2.0:

    Change SERVER_BASEREVERSION in include/httpd.h +from <code>2. *X.Y* </code>'' to2. X.(Y+1) -dev'' and +change APACHE_RELEASE to1 XX(YY+1) 000.

    Edit +theSTATUSfile and update the status for the tagged apache_1. +X.Y version, and add a header line for the new apache_1. X.(Y+1) +version

    $ vi STATUS

    $ cvs +commit STATUS



    $ cd.. +

    Finally, add a new line ``Changes with Apache 1. +X.(Y+1) :'' to the head of theCHANGESfile for the +forthcoming fixes in the new version.

    $ vi include/httpd.h +\<br>
    CHANGES


    $ cvs commit include/httpd.h +\<br>
    CHANGES


    $ cd..

    +
  38. +
  39. +

    Cleanup:

    (delete the CVS tree, after verification that it does +not contain any uncommitted changes)

    $ cvs release -d +apache- Z.X

    +
  40. +
+

Now wait for the group to test and approve the tarball.

+

Final release steps

+

Note:Do not continue with the rest of these +instructions until the group really approves the tarball!

+
    +
  1. +

    Make the distribution available (in +http://www.apache.org/dist/httpd/ ) 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.

    +
  2. +
  3. +

    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}/.

    +
  4. +
  5. +

    Checkout the httpd-dist site , if +needed, into a scratch directory:

    $ cvs -d +cvs.apache.org:/home/cvs checkout -P httpd-dist

    +
  6. +
  7. +

    Change directory into httpd-dist

    $ cd httpd-dist/ +

    +
  8. +
  9. +

    Edit the files and + as well as + and its plaintext +equivalent plus the + file (which defines the +AddDescription comments) from the httpd-dist CVS tree as required (all +in the subdirectory). The +Announcement.* files should be based on the Announcement file in the +tagged CVS tree. For Apache 2.0, Announcement should be replaced with +Announcement2 :

    $ vi README.html HEADER.html +Announcement.html Announcement.txt.htaccess

    +
  10. +
  11. +

    Commit the changes:

    $ cvs commit README.html +HEADER.html Announcement.html Announcement.txt.htaccess +

    $ cd../..

    +
  12. +
  13. +

    Checkout the httpd site if needed into a +scratch directory:

    $ cvs -d cvs.apache.org:/home/cvs +checkout httpd-site

    +
  14. +
  15. +

    cd into the httpd-site xdocs tree.

    $ cd +httpd-site/xdocs/

    +
  16. +
  17. +

    Edit the page from the httpd-site CVS +tree as required:

    $ vi index.xml

    +
  18. +
  19. +

    Commit the changes:

    $ cd..

    +$./build.sh # Check result before continuing

    $ +cvs commit

    +
  20. +
  21. +

    Update the checked-out versions of the httpd-dist documents for the +web server:

    $ umask 002

    $ cd +/www/www.apache.org/dist/httpd/

    $ cvs update +-dP

    +
  22. +
  23. +

    Create an empty directory for future patches:

    $ mkdir +patches/apply_to_1. X.Y

    +
  24. +
  25. +

    Update the checked-out version of the httpd-site index.html page for +the web server:

    $ umask 002

    $ +cd /www/httpd.apache.org/

    $ cvs update -dP +

    +
  26. +
+

At this point, the web-sites reflect the existance of the new release.

+

As it is going to be some 24hrs before any announcement goes out (to make +sure that the mirror's have at least a chance of grabbing a copy) this is +also the right time to mail dev@httpd.apache.org and ask people to upload +and move into position any binaries they have build and vetted.

+

Announcing a New Release

+

Once a release is built and released , it is time to +announce it to the world.

+
    +
  1. +

    Grab the prepared Announcement:

    +You can grab either the Announcement file in the tagged tree, or the +Announcement.txt file from the web-site.

    +
  2. +
  3. +

    Post the Announcement:

    +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.

    +
  4. +
  5. +

    Now, Announcement should be posted to the following places (please +note that a mail send to announce@apache.org must have your apache.org +address set as its 'From' address, otherwise it won't pass the anti-spam +filter):

    +
  6. +
  7. +

    Unmoderated UseNet newsgroups (should be crossposted)

    +
      +
    • +

      comp.infosystems.www.servers.unix

      +
    • +
    • +

      comp.infosystems.www.servers.ms-windows

      +
    • +
    • +

      comp.infosystems.www.servers.misc

      +
    • +
    • +

      de.comm.infosystems.www.servers

      +
    • +
    +
  8. +
  9. +

    Moderated UseNet newsgroups (do not crosspost)

    +
      +
    • comp.infosystems.www.announce
    • +
    +
  10. +
  11. +

    Mailing Lists

    +
      +
    • +

      announce@apache.org

      +
    • +
    • +

      announce@httpd.apache.org

      +
    • +
    • +

      users@httpd.apache.org

      +
    • +
    • +

      users-de@httpd.apache.org

      +
    • +
    +
  12. +
  13. +

    Make sure that Announcement.txt and Announcement.html in +httpd-dist are updated to include these changes.

    +
  14. +
  15. +

    Bask in the glow

    +
  16. +
+ + + + +
+ +