Re: RFC round 3: DEP-3: Patch Tagging Guidelines
Hello Raphaël,
A few more comments:
* “The meta-information would be stored in a set of RFC-2822 compliant fields.”
RFC-2822 distinguishes between “unstructured” and “structured” fields. The
‘Description’ field you propose is not unstructured, since the first line has a
special role, but is not structured in the RFC-2822 way, since that would mean
for instance that things between parenthesis are comments. Moreover, having a
special role for the first CRLF sign is not consistant with the folding rules
of the RFC. Given that in addition RFC-2822 is non-free and therefore can not
be distributed in the Debian operating system, I think that it would be safer
to write “in the spirit of the RFC-2822” of even “in the spirit of the Debian
control files”, and write black on white what parsers should expect. Then we
can point to DEP3 in DEP5 ;)
* “In the following section, <Vendor> can be ‘Debian’ or the name of any other
distribution that tracks the same problem/patch.”
When I packaged my first Perl library, I really had a hard time to understand
what “Vendor” was meaning and that Debian is a vendor since we do not sell our
packages. If native English speakers confirm that a vendor is a seller, then I
would like to suggest to use another keyword, like “Organisation”.
* “Origin (required): This field should document the origin of the patch. It
starts with a single keyword that can have the following standard values”
I think that the rules are too hard to follow strictly. What if the patch is
not from upstream but for backporting, for instance? I think that an URL, an
organisation name or an author name (in a decreasing order of interest) are
probably enough.
* “The Bug field is reserved for the bug URL in the upstream bug tracker.”
I think that parsers can be educated to be smart with URLs (like for
bts-link?). I would prefer to just cut-and-paste any URL to the Bug field.
* “If the [Forwarded] field is missing, its implicit value is ‘yes’ if the ‘Bug’
field is present, otherwise it’s ‘no’”
I am affraid it will create false positives and recommend an implicit value of
‘no’ in all cases.
* “Reviewed-by (optional): This field can be used to document the fact that the
patch has been reviewed by someone. It should list her name and email in the
standard format”
How about relaxing the format so that the field can also point at the review
in the case it makes sense reading it?
* “Last-Update (optional): This field can be used to record the date when the
meta-information have been last updated. It should use the ISO date format
YYYY-MM-DD.”
I think I will not use this field: it has too much chances to be inconsistent
by accident, and most of the time this information is available in the VCS
where the source package is stored.
Have a nice day,
--
Charles Plessy
Tsurumi, Kanagawa, Japan
Reply to: