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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
