[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFC round 3: DEP-3: Patch Tagging Guidelines



Le Tue, Jun 30, 2009 at 08:49:21AM +0200, Raphael Hertzog a écrit :
> On Tue, 30 Jun 2009, Charles Plessy wrote:
> > * “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 ;) 
> 
> I prefer discussing a real patch here.

Maybe something like this?

Index: dep3.mdwn
===================================================================
--- dep3.mdwn	(revision 69)
+++ dep3.mdwn	(working copy)
@@ -47,10 +47,19 @@
 
 Structure
 ---------
-The meta-information would be stored in a set of RFC-2822 compliant
-fields. Those fields should start on the first non-empty line (after
-having stripped whitespace characters at the start and end of lines).
+The meta-information would be stored in a set of fields with a syntax
+similar to the RFC 2822 or Debian control files. More precisely:
 
+Fields are logical elements composed of a field name, followed by a colon (":"),
+followed by a field body, and terminated by a "line feed" character followed by
+any character except "space". A field name is composed of printable characters,
+except "colon". A field body is composed of any character except "line feed"
+unless when it is followed with a space, in which case the space is ignored. As
+a special exception, in the sequence of "line feed", "space", "dot" (.), "line
+feed", "space", the spaces are ignored and the dot is replaced by a space.
+Lines that do not belong to a field body and do not start a new field are plain
+comments.
+
 For patch-systems like dpatch that require the patch to be a standalone
 script, the shebang line is ignored and it is possible to put those fields
 in comments. The line should then follow the format "`# <field>`". For



Cheers,

-- 
Charles


Reply to: