| 71 |
--------------- |
--------------- |
| 72 |
|
|
| 73 |
In the following section, `<Vendor>` can be "Debian" or the name |
In the following section, `<Vendor>` can be "Debian" or the name |
| 74 |
of any other distribution that tracks the same problem/patch. |
of any other distribution that tracks the same problem/patch. Vendor |
| 75 |
|
names are case-insensitive ("Fedora" and "fedora" refer to the same |
| 76 |
|
vendor). |
| 77 |
|
|
| 78 |
* `Description` (required) |
* `Description` (required) |
| 79 |
|
|
| 86 |
upstream but has been rejected, the description should also document |
upstream but has been rejected, the description should also document |
| 87 |
why it's kept and what were the reasons for the reject. |
why it's kept and what were the reasons for the reject. |
| 88 |
|
|
| 89 |
* `Origin` (required) |
It's recommended to keep each line shorter than 80 characters. |
| 90 |
|
|
| 91 |
This field should document the origin of the patch. It starts with a |
* `Origin` (required except if `Author` is present) |
|
single keyword that 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), "vendor" for a patch created |
|
|
by Debian or another distribution vendor, or "other" for all other |
|
|
kind of patches. It can be optionally followed by a colon with |
|
|
leading/trailing spaces before/after it. In that case, all the content |
|
|
after the colon contains supplementary information defining in more |
|
|
details the origin of the patch. In most cases, it should be a simple |
|
|
URL. For patches backported/taken from upstream, it should point into |
|
|
the upstream VCS web interface when possible, otherwise it can simply |
|
|
list the relevant commit identifier (it should be prefixed with |
|
|
"commit:" in that case). For other cases, one should simply indicate |
|
|
the URL where the patch got grabbed (mailing list archives, |
|
|
distribution bugtrackers, etc.) when possible. |
|
| 92 |
|
|
| 93 |
In general, a user-created patch grabbed in a BTS should be tagged |
This field should document the origin of the patch. In most cases, it |
| 94 |
as "other". When copying a patch from another vendor, the |
should be a simple URL. For patches backported/taken from upstream, it |
| 95 |
|
should point into the upstream VCS web interface when possible, |
| 96 |
|
otherwise it can simply list the relevant commit identifier (it should |
| 97 |
|
be prefixed with "commit:" in that case). For other cases, one should |
| 98 |
|
simply indicate the URL where the patch was taken from (mailing list |
| 99 |
|
archives, distribution bugtrackers, etc.) when possible. |
| 100 |
|
|
| 101 |
|
The field can be optionaly prefixed with a single keyword followed by |
| 102 |
|
a comma and a space to categorize the origin. The allowed keywords are |
| 103 |
|
"upstream" (in the case of a patch cherry-picked from the upstream |
| 104 |
|
VCS), "backport" (in the case of an upstream patch that had to be |
| 105 |
|
modified to apply on the current version), "vendor" for a patch |
| 106 |
|
created by Debian or another distribution vendor, or "other" for all |
| 107 |
|
other kind of patches. |
| 108 |
|
|
| 109 |
|
In general, a user-created patch grabbed in a BTS should be |
| 110 |
|
categorized as "other". When copying a patch from another vendor, the |
| 111 |
meta-information (and hence this field) should be kept if present, or |
meta-information (and hence this field) should be kept if present, or |
| 112 |
created if necessary with a "vendor" origin. |
created if necessary with a "vendor" origin. |
| 113 |
|
|
| 114 |
|
If the `Author` field is present, the `Origin` field can be omitted |
| 115 |
|
and it's assumed that the patch comes from its author. |
| 116 |
|
|
| 117 |
* `Bug-<Vendor>` or `Bug` (optional) |
* `Bug-<Vendor>` or `Bug` (optional) |
| 118 |
|
|
| 119 |
It contains one URL pointing to the related bug (possibly fixed by the |
It contains one URL pointing to the related bug (possibly fixed by the |
| 147 |
patch author did not add copyright notices for his work in the patch |
patch author did not add copyright notices for his work in the patch |
| 148 |
itself. It's also a good idea to add this contact information when |
itself. It's also a good idea to add this contact information when |
| 149 |
the patch needs to be maintained over time because it has very little |
the patch needs to be maintained over time because it has very little |
| 150 |
chance of being integrated upstream. |
chance of being integrated upstream. This field can be used multiple |
| 151 |
|
times if several people authored the patch. |
| 152 |
|
|
| 153 |
* `Reviewed-by` (optional) |
* `Reviewed-by` (optional) |
| 154 |
|
|
| 155 |
This field can be used to document the fact that the patch has been |
This field can be used to document the fact that the patch has been |
| 156 |
reviewed by someone. It should list her name and email in the standard |
reviewed by someone. It should list her name and email in the standard |
| 157 |
format (similar to the example given for the `Author` field). This |
format (similar to the example given for the `Author` field). This |
| 158 |
field can be used mutiple times if several persons reviewed the |
field can be used multiple times if several people reviewed the |
| 159 |
patch. |
patch. |
| 160 |
|
|
| 161 |
* `Last-Update` (optional) |
* `Last-Update` (optional) |
| 162 |
|
|
| 163 |
This field can be used to record the date when the meta-information |
This field can be used to record the date when the meta-information |
| 164 |
have been last updated. It should use the ISO date format |
was last updated. It should use the ISO date format `YYYY-MM-DD`. |
| 165 |
`YYYY-MM-DD`. |
|
| 166 |
|
Sample DEP-3 compliant headers |
| 167 |
|
------------------------------ |
| 168 |
|
|
| 169 |
|
A patch cherry-picked from upstream: |
| 170 |
|
|
| 171 |
|
Description: Fix regex problems with some multi-bytes characters |
| 172 |
|
Origin: upstream: http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=bdb56bac |
| 173 |
|
Bug: http://sourceware.org/bugzilla/show_bug.cgi?id=9697 |
| 174 |
|
Bug-Debian: http://bugs.debian.org/510219 |
| 175 |
|
|
| 176 |
|
A patch created by the the Debian maintainer John Doe, which got forwarded |
| 177 |
|
and rejected: |
| 178 |
|
|
| 179 |
|
Description: Use FHS compliant paths by default |
| 180 |
|
Upstream is not interested in switching to those paths. |
| 181 |
|
. |
| 182 |
|
But we will continue using them in Debian nevertheless to comply with |
| 183 |
|
our policy. |
| 184 |
|
Forwarded: http://lists.example.com/oct-2006/1234.html |
| 185 |
|
Author: John Doe <john@foobar.com> |
| 186 |
|
Last-Update: 2006-12-21 |
| 187 |
|
|
| 188 |
|
A vendor specific patch not meant for upstream submitted on |
| 189 |
|
the BTS by a Debian developer: |
| 190 |
|
|
| 191 |
|
Description: Workaround for broken symbol resolving on mips/mipsel |
| 192 |
|
The correct fix will be done in etch and it will require toolchain |
| 193 |
|
fixes. |
| 194 |
|
Forwarded: not-needed |
| 195 |
|
Origin: vendor: http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=80;bug=265678 |
| 196 |
|
Bug-Debian: http://bugs.debian.org/265678 |
| 197 |
|
Author: Thiemo Seufer <ths@debian.org> |
| 198 |
|
|
| 199 |
Related links |
Related links |
| 200 |
------------- |
------------- |
| 208 |
* 2009-06-19: Replace Origin/Status/Patch with Origin/Forwarded. Add new |
* 2009-06-19: Replace Origin/Status/Patch with Origin/Forwarded. Add new |
| 209 |
fields Author and Last-Update. Rename Signed-off-by in Reviewed-by. |
fields Author and Last-Update. Rename Signed-off-by in Reviewed-by. |
| 210 |
Add a paragraph about the scope of the proposal. |
Add a paragraph about the scope of the proposal. |
| 211 |
|
* 2009-07-15: Make categorization in Origin optional. Make Origin optional |
| 212 |
|
if Author is present. |
| 213 |
|
* 2009-08-24: Add samples. |
Parent Directory
| 
Revision Log
| 
Patch