/[dep]/web/deps/dep3.mdwn

Diff of /web/deps/dep3.mdwn

Parent Directory | Revision Log | View Patch Patch

-revision 62 by hertzog,
Sat Jun 13 19:04:32 2009 UTC
+revision 63 by hertzog,
Sat Jun 13 19:33:53 2009 UTC
 Line 30 
 achieve this task we must be able to bro
  information about them (their origin/author, if they have been forwarded
  upstream, if they are meant to be debian specific or not, etc.). Thus the
  first step is to include those information in the patches when they are
- available so that tools like http://patch-tracking.debian.net can display
+ available so that tools like the [Patch Tracking
- them.
+ System](http://patch-tracking.debian.net) can display them.
  Structure
 Line 43 
 having stripped whitespace characters at
  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
+ multi-line fields, the subsequent lines should start with
- they start with a space once "`# `" has been stripped from the beginning.
+ "`#`&nbsp;&nbsp;" (dash followed by two spaces) so that
+ they start with a space once "`#` " (dash followed by a space) has been
+ stripped from the beginning.
  Standard fields
-Line 54 
 In the following section, `<Vendor>` can
+Line 56 
 In the following section, `<Vendor>` can
  of any other distribution that tracks the same problem/patch.
    * `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)
      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
-Line 66 
 of any other distribution that tracks th
+Line 71 
 of any other distribution that tracks th
      patch. It should typically be the name and email of the patch author
      (ex: "`John Bear <foo@bar.net>`") or the project/company that she worked
      for when she authored the patch.
    * `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
      for the bug URL(s) in the upstream bug tracker.
    * `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)
      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
      interface or similar restrictions.
    * `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 "&lt;vendor&gt;-specific" (the patch must not be
-Line 90 
 of any other distribution that tracks th
+Line 103 
 of any other distribution that tracks th
      lines can be used to explain in more details the status of the patch.
      It should be used for example to explain why the patch has been
      rejected, or why this change is only meaningful for the vendor.
    * `Signed-off-by` (optional)
-      This field can be used to document the fact that the patch has been
-      reviewed by one or more persons. It should list their names and
+     This field can be used to document the fact that the patch has been
-      emails in the standard format (similar to the example given for
+     reviewed by one or more persons. It should list their names and
-      the `Origin` field), separated by commas if needed.
+     emails in the standard format (similar to the example given for
+     the `Origin` field), separated by commas if needed.
  Interpretation
-Line 105 
 facts can be deduced from the absence, p
+Line 120 
 facts can be deduced from the absence, p
  and their values.
    * Has the patch been forwarded upstream?
-     If there is a "Status" field, its value answers the question.
-     If there's an "Origin" field and it contains "upstream" or "backport",
+     If there is a `Status` field, its value answers the question.
+     If there's an `Origin` field and it contains "upstream" or "backport",
      the patch comes from upstream and it doesn't need to be forwarded.
-     The same is true if there's a "Commit" field.
+     The same is true if there's a `Commit` field.
-     In other cases, if there is a "Bug" field, then the patch has most
+     In other cases, if there is a `Bug` field, then the patch has most
      likely been referenced in the bug and upstream should know about it.
      Any package maintainer should ensure that the existence of the patch
      has been documented in the upstream bug log when he adds the
-Line 119 
 and their values.
+Line 135 
 and their values.
  Related links
  -------------
-   * https://wiki.ubuntu.com/UbuntuDevelopment/PatchTaggingGuidelines
+   * [Ubuntu's patch tagging guidelines](https://wiki.ubuntu.com/UbuntuDevelopment/PatchTaggingGuidelines)
  Changes
  -------

 Legend:



Removed from v.62
 


changed lines


 
Added in v.63
 Legend:



Removed from v.62
 


changed lines


 
Added in v.63
-Removed from v.62
+Added in v.63

	ViewVC Help
Powered by ViewVC 1.1.5