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 2016/12/03 10:46:43 UTC
svn commit: r1002092 - in /websites/staging/httpd/trunk/content: ./
dev/guidelines.html
Author: buildbot
Date: Sat Dec 3 10:46:43 2016
New Revision: 1002092
Log:
Staging update by buildbot for httpd
Modified:
websites/staging/httpd/trunk/content/ (props changed)
websites/staging/httpd/trunk/content/dev/guidelines.html
Propchange: websites/staging/httpd/trunk/content/
------------------------------------------------------------------------------
--- cms:source-revision (original)
+++ cms:source-revision Sat Dec 3 10:46:43 2016
@@ -1 +1 @@
-1772449
+1772450
Modified: websites/staging/httpd/trunk/content/dev/guidelines.html
==============================================================================
--- websites/staging/httpd/trunk/content/dev/guidelines.html (original)
+++ websites/staging/httpd/trunk/content/dev/guidelines.html Sat Dec 3 10:46:43 2016
@@ -111,7 +111,7 @@ continue to produce a quality system in
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<a class="headerlink" href="#people-places-and-things" title="Permanent link">¶</a></h1>
-<h4 id="apache-http-server-project-management-committee">Apache HTTP Server Project Management Committee<a class="headerlink" href="#apache-http-server-project-management-committee" title="Permanent link">¶</a></h4>
+<h3 id="apache-http-server-project-management-committee">Apache HTTP Server Project Management Committee<a class="headerlink" href="#apache-http-server-project-management-committee" title="Permanent link">¶</a></h3>
<p>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
@@ -126,7 +126,7 @@ reversing whichever condition made them
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>
-<h4 id="apache-http-server-committers">Apache HTTP Server Committers<a class="headerlink" href="#apache-http-server-committers" title="Permanent link">¶</a></h4>
+<h3 id="apache-http-server-committers">Apache HTTP Server Committers<a class="headerlink" href="#apache-http-server-committers" title="Permanent link">¶</a></h3>
<p>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
@@ -140,24 +140,24 @@ their earlier declaration or by once aga
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>
-<h4 id="apache-developers">Apache Developers<a class="headerlink" href="#apache-developers" title="Permanent link">¶</a></h4>
+<h3 id="apache-developers">Apache Developers<a class="headerlink" href="#apache-developers" title="Permanent link">¶</a></h3>
<p>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.</p>
-<h4 id="mailing-list">Mailing list<a class="headerlink" href="#mailing-list" title="Permanent link">¶</a></h4>
+<h3 id="mailing-list">Mailing list<a class="headerlink" href="#mailing-list" title="Permanent link">¶</a></h3>
<p>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.</p>
-<h4 id="private-list">Private list<a class="headerlink" href="#private-list" title="Permanent link">¶</a></h4>
+<h3 id="private-list">Private list<a class="headerlink" href="#private-list" title="Permanent link">¶</a></h3>
<p>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
Committee.</p>
-<h4 id="subversion">Subversion<a class="headerlink" href="#subversion" title="Permanent link">¶</a></h4>
+<h3 id="subversion">Subversion<a class="headerlink" href="#subversion" title="Permanent link">¶</a></h3>
<p>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
@@ -225,36 +225,36 @@ item.</p>
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<a class="headerlink" href="#types-of-action-items" title="Permanent link">¶</a></h1>
-<h4 id="long-term-plans">Long Term Plans<a class="headerlink" href="#long-term-plans" title="Permanent link">¶</a></h4>
+<h3 id="long-term-plans">Long Term Plans<a class="headerlink" href="#long-term-plans" title="Permanent link">¶</a></h3>
<p>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.</p>
-<h4 id="short-term-plans">Short Term Plans<a class="headerlink" href="#short-term-plans" title="Permanent link">¶</a></h4>
+<h3 id="short-term-plans">Short Term Plans<a class="headerlink" href="#short-term-plans" title="Permanent link">¶</a></h3>
<p>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.</p>
-<h4 id="release-plan">Release Plan<a class="headerlink" href="#release-plan" title="Permanent link">¶</a></h4>
+<h3 id="release-plan">Release Plan<a class="headerlink" href="#release-plan" title="Permanent link">¶</a></h3>
<p>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 (at least 3 x +1 and more +1 than -1) decides
each issue in the release plan.</p>
-<h4 id="release-testing">Release Testing<a class="headerlink" href="#release-testing" title="Permanent link">¶</a></h4>
+<h3 id="release-testing">Release Testing<a class="headerlink" href="#release-testing" title="Permanent link">¶</a></h3>
<p>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.</p>
-<h4 id="showstoppers">Showstoppers<a class="headerlink" href="#showstoppers" title="Permanent link">¶</a></h4>
+<h3 id="showstoppers">Showstoppers<a class="headerlink" href="#showstoppers" title="Permanent link">¶</a></h3>
<p>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.</p>
-<h4 id="product-changes">Product Changes<a class="headerlink" href="#product-changes" title="Permanent link">¶</a></h4>
+<h3 id="product-changes">Product Changes<a class="headerlink" href="#product-changes" title="Permanent link">¶</a></h3>
<p>Changes to the Apache products, including code and documentation, will
appear as action items under several categories corresponding to the change status:</p>
<ul>
@@ -323,12 +323,12 @@ members and the veto conditions cannot b
equivalent of a "bug fix" commit. The veto must be rescinded before the
change can be included in any public release.</p>
<h1 id="changes-file-and-subversion-logs">CHANGES file and Subversion logs<a class="headerlink" href="#changes-file-and-subversion-logs" title="Permanent link">¶</a></h1>
-<h4 id="changelog">Changelog<a class="headerlink" href="#changelog" title="Permanent link">¶</a></h4>
+<h3 id="changelog">Changelog<a class="headerlink" href="#changelog" title="Permanent link">¶</a></h3>
<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>
-<h4 id="subversion-log">Subversion log<a class="headerlink" href="#subversion-log" title="Permanent link">¶</a></h4>
+<h3 id="subversion-log">Subversion log<a class="headerlink" href="#subversion-log" title="Permanent link">¶</a></h3>
<p>The Subversion commit log message contains any information needed by</p>
<ul>
<li>
@@ -356,7 +356,7 @@ crash if requests contain an invalid con
</blockquote>
<p>Commit messages can be minimal when making routine updates to STATUS, for
example to propose a backport or vote.</p>
-<h4 id="changes">CHANGES<a class="headerlink" href="#changes" title="Permanent link">¶</a></h4>
+<h3 id="changes">CHANGES<a class="headerlink" href="#changes" title="Permanent link">¶</a></h3>
<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>
@@ -395,7 +395,7 @@ CHANGES.</p>
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>
-<h4 id="formatting">Formatting<a class="headerlink" href="#formatting" title="Permanent link">¶</a></h4>
+<h3 id="formatting">Formatting<a class="headerlink" href="#formatting" title="Permanent link">¶</a></h3>
<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
@@ -450,7 +450,7 @@ bug is determined to be exploitable, the
on a case by case basis when to document the security implications and
tracking number.</p>
<h1 id="patch-format">Patch Format<a class="headerlink" href="#patch-format" title="Permanent link">¶</a></h1>
-<h4 id="patch">Patch<a class="headerlink" href="#patch" title="Permanent link">¶</a></h4>
+<h3 id="patch">Patch<a class="headerlink" href="#patch" title="Permanent link">¶</a></h3>
<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
@@ -460,10 +460,10 @@ summary in the STATUS file should be upd
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. one of the following:</p>
-<ul>
-<li><code>diff -u http_main.c.orig http_main.c >> patchfile.txt</code> </li>
-<li><code>svn diff http_main.c >> patchfile.txt</code> </li>
-</ul>
+<blockquote>
+<p><code>diff -u http_main.c.orig http_main.c >> patchfile.txt</code>
+<code>svn diff http_main.c >> patchfile.txt</code> </p>
+</blockquote>
<p>All patches necessary to address an action item should be concatenated
within a single patch message. If later modification of the patch proves
necessary, the entire new patch should be posted and not just the