httpd-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From build...@apache.org
Subject svn commit: r1002092 - in /websites/staging/httpd/trunk/content: ./ dev/guidelines.html
Date Sat, 03 Dec 2016 10:46:43 GMT
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">&para;</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">&para;</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">&para;</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">&para;</a></h4>
+<h3 id="apache-http-server-committers">Apache HTTP Server Committers<a class="headerlink"
href="#apache-http-server-committers" title="Permanent link">&para;</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">&para;</a></h4>
+<h3 id="apache-developers">Apache Developers<a class="headerlink" href="#apache-developers"
title="Permanent link">&para;</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">&para;</a></h4>
+<h3 id="mailing-list">Mailing list<a class="headerlink" href="#mailing-list" title="Permanent
link">&para;</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">&para;</a></h4>
+<h3 id="private-list">Private list<a class="headerlink" href="#private-list" title="Permanent
link">&para;</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">&para;</a></h4>
+<h3 id="subversion">Subversion<a class="headerlink" href="#subversion" title="Permanent
link">&para;</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">&para;</a></h1>
-<h4 id="long-term-plans">Long Term Plans<a class="headerlink" href="#long-term-plans"
title="Permanent link">&para;</a></h4>
+<h3 id="long-term-plans">Long Term Plans<a class="headerlink" href="#long-term-plans"
title="Permanent link">&para;</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">&para;</a></h4>
+<h3 id="short-term-plans">Short Term Plans<a class="headerlink" href="#short-term-plans"
title="Permanent link">&para;</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">&para;</a></h4>
+<h3 id="release-plan">Release Plan<a class="headerlink" href="#release-plan" title="Permanent
link">&para;</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">&para;</a></h4>
+<h3 id="release-testing">Release Testing<a class="headerlink" href="#release-testing"
title="Permanent link">&para;</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">&para;</a></h4>
+<h3 id="showstoppers">Showstoppers<a class="headerlink" href="#showstoppers" title="Permanent
link">&para;</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">&para;</a></h4>
+<h3 id="product-changes">Product Changes<a class="headerlink" href="#product-changes"
title="Permanent link">&para;</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">&para;</a></h1>
-<h4 id="changelog">Changelog<a class="headerlink" href="#changelog" title="Permanent
link">&para;</a></h4>
+<h3 id="changelog">Changelog<a class="headerlink" href="#changelog" title="Permanent
link">&para;</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">&para;</a></h4>
+<h3 id="subversion-log">Subversion log<a class="headerlink" href="#subversion-log"
title="Permanent link">&para;</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">&para;</a></h4>
+<h3 id="changes">CHANGES<a class="headerlink" href="#changes" title="Permanent link">&para;</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">&para;</a></h4>
+<h3 id="formatting">Formatting<a class="headerlink" href="#formatting" title="Permanent
link">&para;</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
 "&lt;" and "&gt;" 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">&para;</a></h1>
-<h4 id="patch">Patch<a class="headerlink" href="#patch" title="Permanent link">&para;</a></h4>
+<h3 id="patch">Patch<a class="headerlink" href="#patch" title="Permanent link">&para;</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 &gt;&gt; patchfile.txt</code>
</li>
-<li><code>svn diff http_main.c &gt;&gt; patchfile.txt</code> </li>
-</ul>
+<blockquote>
+<p><code>diff -u http_main.c.orig http_main.c &gt;&gt; patchfile.txt</code>

+<code>svn diff http_main.c &gt;&gt; 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



Mime
View raw message