Re: RFC round 3: DEP-3: Patch Tagging Guidelines
Raphael Hertzog wrote:
> Hello,
>
> it looks like we quickly converged on something relatively well accepted.
> Current version: http://dep.debian.net/deps/dep3/
Thanks for working on this Raphael, I am glad to see it moving.
I have a few comments, but overall I like the current proposal. It is
also fine to replace the current Ubuntu guidelines for this in my
opinion (there's no issues with "deriving from" the information that I
can see).
> Structure
This certainly makes it easier to implement parsers, but I'm wary of it
being too strict.
To my reading it is not clear whether this is valid:
#!/usr/bin/dpatch-run
#
# Description: ...
and I think it should be.
Also, can you use "#" comments if it isn't a dpatch file? I can
imagine that some would write it like that for other patch formats.
> 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
> and its history.
Is it worth advising that lines be < 80 characters (including
"Description: ")?
> one should simply indicate the URL where the patch got grabbed
"one should simply indicate the URL where the patch was taken from" is
less colloquial English.
> Bug-<Vendor> or Bug (optional)
I think your reasoning behind this is good, however, without a list of
vendors is there going to be a problem with consistency in the Vendors?
Is it Bug-Debian or Bug-debian? Should we just specify that parsers
should compare the vendors in a case-insensitive manner when they do so,
and assume that there aren't two names for a distribution?
> Author (optional)
Can be given multiple times I assume? That should be explicit as the way
to handle multiple authors.
> This field can be used mutiple times if several persons reviewed the patch.
"several people" is more usual English, and the correct spelling is
"multiple".
> This field can be used to record the date when the meta-information
> have been last updated.
"was last updated" is more usual English.
What do you see as the use for this? Is it just informational?
> Josselin Mouette wanted to allow bug numbers instead of URLs in the Bug-*/Bug
> fields. Several people expressed their preference for a simple URL field.
> Sub-thread: http://lists.debian.org/debian-devel/2009/06/msg00543.html
I don't like this suggestion at all. Copying and pasting a URL in is
generally convenient, and while many of us will have quick ways of going
from a bug number to the bug page, new contributors and those outside
the project won't, and so it will be harder for them to get the
information.
Yes, typing the bugs.debian.org part when you have the bug number is
tedious, but it's easy, and it's possibly a case of write-one read-many.
> Guido Günther suggested to reuse field names used by git-format-patch and/or
> allow them together with existing fields.
> Message: http://lists.debian.org/debian-devel/2009/06/msg00551.html
I can see the attraction here, but I see potential for difficulty around
the extra fields that aren't in git-format-patch output.
> After this round, if we don't have any important changes, I'll probably
> announce the format to debian-devel-announce. Should I use this opportunity to
> ask for more review or simply suggest people to start using the format?
I think the suggestion of an implementation of a parser is a good one,
though I'm not sure you should block on it. I would be interested in
helping to write a tool to parse the fields and do something useful with
them, if we had some idea of what would work well for lintian and other
tools that would want to consume the output.
Thanks,
James
Reply to: