r61 - /web/deps/dep3.mdwn

[hertzog at users.alioth.debian.org]

Author: hertzog
Date: Sat Jun 13 19:04:15 2009
New Revision: 61

URL: http://svn.debian.org/wsvn/dep/?sc=1&rev=61
Log:
Fix title and add markdown formatting for the web page

Modified:
    web/deps/dep3.mdwn

Modified: web/deps/dep3.mdwn
URL: http://svn.debian.org/wsvn/dep/web/deps/dep3.mdwn?rev=61&op=diff
==============================================================================
--- web/deps/dep3.mdwn (original)
+++ web/deps/dep3.mdwn Sat Jun 13 19:04:15 2009
@@ -1,6 +1,6 @@
 [[meta title="DEP-3: Patch Tagging Guidelines"]]
 
-    Title: Introducing Debian Enhancement Proposals (DEPs)
+    Title: Patch Tagging Guidelines
     DEP: 3
     State: DRAFT
     Date: 2009-06-12
@@ -42,46 +42,46 @@
 
 For patch-systems like dpatch that require the patch to be a standalone
 script, the shebang line is ignored and it is possible to put those fields
-in comments. The line should then follow the format "# <field>". For
-multi-line fields, the subsequent lines should start with "#  " so that
-they start with a space once "# " has been stripped from the beginning.
+in comments. The line should then follow the format "`# <field>`". For
+multi-line fields, the subsequent lines should start with "`#  `" so that
+they start with a space once "`# `" has been stripped from the beginning.
 
 
 Standard fields
 ---------------
 
-In the following section, <Vendor> can be "Debian" or the name
+In the following section, `<Vendor>` can be "Debian" or the name
 of any other distribution that tracks the same problem/patch.
 
-  * Description (required)
+  * `Description` (required)
     This obligatory field contains at least a short description on the
     first line. Supplementary lines can be used to provide a longer
     explanation of the patch.
-  * Origin (required)
+  * `Origin` (required)
     This field should document the origin of the patch. It can have the
     following standard values: "upstream" (in the case of a patch cherry-picked
     from the upstream VCS), "backport" (in the case of an upstream patch
     that had to be modified to apply on the current version). Any other
     value is supposed to be free-form text describing the origin of the
     patch. It should typically be the name and email of the patch author
-    (ex: "John Bear <foo at bar.net>") or the project/company that she worked
+    (ex: "`John Bear <foo at bar.net>`") or the project/company that she worked
     for when she authored the patch.
-  * Bug-<Vendor> or Bug (optional)
+  * `Bug-<Vendor>` or `Bug` (optional)
     It contains one or more URLs (space separated) pointing to the related bugs
-    (possibly fixed by the patch). The "Bug" field is reserved
+    (possibly fixed by the patch). The `Bug` field is reserved
     for the bug URL(s) in the upstream bug tracker.
-  * Patch (optional)
+  * `Patch` (optional)
     URL pointing to the patch. It can be in a VCS web interface,
     a BTS attachment, etc. If the patch is available in the upstream VCS
     or BTS, those URLs take precedence.
-  * Commit (optional)
+  * `Commit` (optional)
     One or more commit identifiers. This should only be used when the
-    "Patch" field can't be used because the upstream project has no VCS web
+    `Patch` field can't be used because the upstream project has no VCS web
     interface or similar restrictions.
-  * Status (optional)
+  * `Status` (optional)
     This field is a textual explanation of its status concerning its
     inclusion in the upstream project. The first line should consist of a
-    single keyword among "<vendor>-specific" (the patch must not be
+    single keyword among "&lt;vendor&gt;-specific" (the patch must not be
     forwarded as it is specific to a vendor, ex: branding patches), 
     "must-be-forwarded" (nobody has taken the time to forward the patch
     yet), "forwarded" (the patch has been forwarded, the Bug or Patch