httpd-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From build...@apache.org
Subject svn commit: r1002091 - in /websites/staging/httpd/trunk/content: ./ dev/guidelines.html
Date Sat, 03 Dec 2016 10:42:48 GMT
Author: buildbot
Date: Sat Dec  3 10:42:48 2016
New Revision: 1002091

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:42:48 2016
@@ -1 +1 @@
-1770029
+1772449

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:42:48 2016
@@ -111,16 +111,14 @@ 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">&para;</a></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
+<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">&para;</a></h4>
+<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
+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
@@ -128,14 +126,12 @@ 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>
-<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
+<h4 id="apache-http-server-committers">Apache HTTP Server Committers<a class="headerlink"
href="#apache-http-server-committers" title="Permanent link">&para;</a></h4>
+<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
+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
@@ -144,30 +140,28 @@ 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>
-<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>
+<h4 id="apache-developers">Apache Developers<a class="headerlink" href="#apache-developers"
title="Permanent link">&para;</a></h4>
+<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">&para;</a></h4>
+<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">&para;</a></h4>
+<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">&para;</a></h4>
+<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
+has <a href="http://svn.apache.org/repos/asf/httpd/httpd">read access</a>.</p>
 <h1 id="status">STATUS<a class="headerlink" href="#status" title="Permanent link">&para;</a></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
@@ -200,24 +194,25 @@ more time to other projects. It is there
 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>
+<ul>
+<li>
+<p><strong>+1</strong> : 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).</p>
+</li>
+<li>
+<p><strong>±0</strong> : 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.</p>
+</li>
+<li>
+<p><strong>-1</strong> : 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.</p>
+</li>
+</ul>
 <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>
@@ -230,64 +225,64 @@ 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">&para;</a></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 (at least 3 x +1 and more +1 than -1) 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>
+<h4 id="long-term-plans">Long Term Plans<a class="headerlink" href="#long-term-plans"
title="Permanent link">&para;</a></h4>
+<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">&para;</a></h4>
+<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">&para;</a></h4>
+<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">&para;</a></h4>
+<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">&para;</a></h4>
+<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">&para;</a></h4>
+<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>
+<li>
+<p><strong>Concept/Plan</strong> : 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.</p>
+</li>
+<li>
+<p><strong>Proposed patch</strong>: 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).</p>
+</li>
+<li>
+<p><strong>Committed change</strong> : 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.</p>
+</li>
+<li>
+<p><strong>Backport</strong>:  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.</p>
+</li>
+</ul>
 <h1 id="when-to-commit-a-change">When to Commit a Change<a class="headerlink" href="#when-to-commit-a-change"
title="Permanent link">&para;</a></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
@@ -327,12 +322,13 @@ LICENSE.</p>
 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<a class="headerlink" href="#changelogs"
title="Permanent link">&para;</a></h1>
+<h1 id="changes-file-and-subversion-logs">CHANGES file and Subversion logs<a class="headerlink"
href="#changes-file-and-subversion-logs" title="Permanent link">&para;</a></h1>
+<h4 id="changelog">Changelog<a class="headerlink" href="#changelog" title="Permanent
link">&para;</a></h4>
 <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<a class="headerlink" href="#subversion-log"
title="Permanent link">&para;</a></h2>
+<h4 id="subversion-log">Subversion log<a class="headerlink" href="#subversion-log"
title="Permanent link">&para;</a></h4>
 <p>The Subversion commit log message contains any information needed by</p>
 <ul>
 <li>
@@ -350,16 +346,17 @@ with modifications, use the appropriate
 "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
+<p>Example log message:</p>
+<blockquote>
+<p>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 &lt;janedoe example.com&gt;
-Reviewed by: susiecommitter
-` </p>
+<p>PR: 99999</p>
+<p>Submitted by: Jane Doe &lt;janedoe example.com&gt;</p>
+<p>Reviewed by: susiecommitter</p>
+</blockquote>
 <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<a class="headerlink" href="#changes" title="Permanent link">&para;</a></h2>
+<h4 id="changes">CHANGES<a class="headerlink" href="#changes" title="Permanent link">&para;</a></h4>
 <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>
@@ -398,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>
-<h2 id="formatting">Formatting<a class="headerlink" href="#formatting" title="Permanent
link">&para;</a></h2>
+<h4 id="formatting">Formatting<a class="headerlink" href="#formatting" title="Permanent
link">&para;</a></h4>
 <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
 "&lt;" and "&gt;" around the address. For example, change
@@ -406,24 +403,28 @@ available. The obfuscation is done by re
 <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>
+log in the format:</p>
+<blockquote>
+<p>PR 1234</p>
+</blockquote>
+<p>Security-related changes should start like this:</p>
+<blockquote>
+<p>*) SECURITY: CVE-YYYY-NNNN (cve.mitre.org) xxxxx</p>
+</blockquote>
 <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 &lt;sf fritsch.de&gt;, 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>
+<p>Example CHANGES entries: </p>
+<blockquote>
+<p>*) SECURITY: CVE-2009-3095 (cve.mitre.org) mod_proxy_ftp: sanity check authn credentials.
+    [Stefan Fritsch &lt;sf fritsch.de&gt;, 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>
+</blockquote>
 <h1 id="committing-security-fixes">Committing Security Fixes<a class="headerlink"
href="#committing-security-fixes" title="Permanent link">&para;</a></h1>
 <p>Open source projects, ASF or otherwise, have varying procedures for 
 commits of vulnerability fixes.  One important aspect of these procedures
@@ -448,7 +449,8 @@ taken.</p>
 bug is determined to be exploitable, the httpd security team will decide
 on a case by case basis when to document the security implications and
 tracking number.</p>
-<h1 id="patch">Patch Format<a class="headerlink" href="#patch" title="Permanent
link">&para;</a></h1>
+<h1 id="patch-format">Patch Format<a class="headerlink" href="#patch-format" title="Permanent
link">&para;</a></h1>
+<h4 id="patch">Patch<a class="headerlink" href="#patch" title="Permanent link">&para;</a></h4>
 <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
@@ -456,20 +458,22 @@ Subject beginning with <code>[PATCH]</co
 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
+<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 &gt;&gt; patchfile.txt</code>
</li>
+<li><code>svn diff http_main.c &gt;&gt; patchfile.txt</code> </li>
+</ul>
+<p>All patches necessary to address an action item should be concatenated
 within a single patch message. If later modification of the patch proves
 necessary, the entire new patch should be posted and not just the
 difference between two patches. The STATUS file entry should then be
 updated to point to the new patch message.</p>
 <p>The completed patchfile should produce no errors or prompts when the
-command,
-<code>patch -s &lt; patchfile</code> 
-is issued in the target repository.</p>
+following command is issued in the target repository:</p>
+<blockquote>
+<p><code>patch -s &lt; patchfile</code></p>
+</blockquote>
 <h1 id="addendum">Addendum<a class="headerlink" href="#addendum" title="Permanent
link">&para;</a></h1>
 <p>Outstanding issues with this document</p>
 <ul>



Mime
View raw message