RFC round 4: DEP-3: Patch Tagging Guidelines
Hello,
one more turn for this DEP, after all. Recent changes are not numerous
but there are some.
Current version: http://dep.debian.net/deps/dep3/
=== Changes since last round ===
- Clarified that vendor names are case-insensitive
- Made the categorization in Origin optional. Made the field optional if Author
field is present. he whole paragraph has been rewritten due to this:
+ * `Origin` (required except if `Author` is present)
+
+ This field should document 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 was taken from (mailing list
+ archives, distribution bugtrackers, etc.) when possible.
+
+ The field can be optionaly prefixed with a single keyword followed by
+ a comma and a space to categorize the origin. The allowed keywords are
+ "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.
+
+ In general, a user-created patch grabbed in a BTS should be
+ categorized as "other". When copying a patch from another vendor, the
meta-information (and hence this field) should be kept if present, or
created if necessary with a "vendor" origin.
+ If the `Author` field is present, the `Origin` field can be omitted
+ and it's assumed that the patch comes from its author.
+
- Recommend to keep description lines shorter than 80 chars
- Allow multiple Author fields.
- Added the rationale for encoding vendor name in Bug-<Vendor>
--- a/web/deps/dep3.mdwn
+++ b/web/deps/dep3.mdwn
@@ -115,6 +115,12 @@ of any other distribution that tracks the same problem/patch.
bug tracker. Those fields can be used multiple times if several
bugs are concerned.
+ The vendor name is explicitely encoded in the field name so that
+ vendors can share patches among them without having to update the
+ meta-information in most cases. The upstream bug URL is special
+ cased because it's the central point of cooperation and it must
+ be easily distinguishable among all the bug URLs.
+
* `Forwarded` (optional)
=== Remaining concerns/ideas ===
* Charles Plessy wanted to specify more precisely the format instead
of saying "RFC-2822 compliant fields". The discussion went nowhere
and nobody else expressed support for such a change.
* I wonder if I shall add some samples to the document to make it clearer
in everybody's mind. What do you think? If you think it's a good idea,
feel free to provide some interesting (real-life) sample.
Cheers,
--
Raphaël Hertzog
Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny :
http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: