httpd-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From elu...@apache.org
Subject svn commit: r1772450 - /httpd/site/trunk/content/dev/guidelines.mdtext
Date Sat, 03 Dec 2016 10:46:37 GMT
Author: elukey
Date: Sat Dec  3 10:46:37 2016
New Revision: 1772450

URL: http://svn.apache.org/viewvc?rev=1772450&view=rev
Log:
Updated Markdown code to the dev guidelines page - part 2

Modified:
    httpd/site/trunk/content/dev/guidelines.mdtext

Modified: httpd/site/trunk/content/dev/guidelines.mdtext
URL: http://svn.apache.org/viewvc/httpd/site/trunk/content/dev/guidelines.mdtext?rev=1772450&r1=1772449&r2=1772450&view=diff
==============================================================================
--- httpd/site/trunk/content/dev/guidelines.mdtext (original)
+++ httpd/site/trunk/content/dev/guidelines.mdtext Sat Dec  3 10:46:37 2016
@@ -30,7 +30,8 @@ be resolved.
 
 # People, Places, and Things
 
-####Apache HTTP Server Project Management Committee
+###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
@@ -46,7 +47,8 @@ their earlier declaration or by once aga
 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 
+###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
@@ -61,27 +63,27 @@ project's work). Membership can be revok
 active PMC members (except the member in question if they are a PMC
 member).
 
-####Apache Developers 
+###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 
+###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
+###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
 Committee.
 
-####Subversion 
+###Subversion 
 All of the Apache products are maintained in shared information
 repositories using [Subversion on](devnotes.html). Only some of the
 Apache developers have write access to these repositories; everyone
@@ -155,7 +157,8 @@ to the STATUS file entry for that action
 
 # Types of Action Items #
 
-####Long Term Plans 
+###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
@@ -163,14 +166,16 @@ plan, or think an alternate plan would b
 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
+
 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
+###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
@@ -178,18 +183,21 @@ other trivia to keep us from tripping ov
 moments. Lazy majority (at least 3 x +1 and more +1 than -1) decides 
 each issue in the release plan.
 
-####Release Testing
+###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
+
 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 
+###Product Changes
+
 Changes to the Apache products, including code and documentation, will
 appear as action items under several categories corresponding to the change status:
 
@@ -261,14 +269,14 @@ change can be included in any public rel
 
 # CHANGES file and Subversion logs 
 
-#### Changelog
+### Changelog
 
 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
+### Subversion log
 
 The Subversion commit log message contains any information needed by
 
@@ -298,7 +306,7 @@ Example log message:
 Commit messages can be minimal when making routine updates to STATUS, for
 example to propose a backport or vote.
 
-#### CHANGES
+### CHANGES
 
 CHANGES is the subset of the information that end users need to see when
 they upgrade from one release to the next:
@@ -332,7 +340,7 @@ the change from the CHANGES file in trun
 
 The attribution for the change is anyone responsible for the code changes.
 
-#### Formatting
+### 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
@@ -397,7 +405,7 @@ tracking number.
 
 # Patch Format 
 
-#### Patch
+### Patch
 
 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
@@ -410,8 +418,8 @@ that message.
 The patch should be created by using the `diff -u` command from
 the original software file(s) to the modified software file(s). E.g. one of the following:
 
-* ` diff -u http_main.c.orig http_main.c >> patchfile.txt` 
-* `svn diff http_main.c >> patchfile.txt` 
+> ` diff -u http_main.c.orig http_main.c >> patchfile.txt` 
+> `svn diff http_main.c >> 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



Mime
View raw message