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

Re: Patch Tagging Guidelines (aka DEP3)

On Mon, Sep 07, 2009 at 11:03:37PM +0200, Raphael Hertzog wrote:
> Hello,
> after several rounds of discussion on -devel, we now have a
> new standard defining meta-information to integrate on patches that we
> distribute/apply in our packages:
> http://dep.debian.net/deps/dep3/

Sorry I haven't answered to the DEP before, but I've been pretty busy so

FWIW I don't like it completely because it's not compatible with the
de-facto standard used by kernel-like project (that would count linux,
or git, and many other).

In git (and the idea is trivially used in any VCS that can format-patch
to mail) you use either rfc822 headers or pseudo-headers for many fields
you have re-defined.

My point is that there are _lots_ of patches that follow the kernel
conventions out there, and it should not require anything more than
grabbing the patch, possibly add an URL in it pointing to where you
grabbed it from, and be done with it. Your proposal requires an
extensive rewrite of such patches, and it kind of sucks.

Also I would like to be able to extract my patches from my git
repository just doing a git format-patch upstream..upstream+patches
e.g., and not having to touch them (hence the need for pseudo-headers).

Here are my remarks wrt individual fields:

  * Description/Subject:
    Description should just be any bit of rfc822 text that isn't a
    header nor a patch nor a pseudo header. What you propose for
    Description is just a major hassle for any people using git/hg/...
    And you should have a short description, as "Subject:". The
    description should not be mandatory, the Subject should be.

    Also, if the patch contains a line with exactly "---\n", then all
    that follows, up to the diff is data that is _not_ part of the
    Description, and should be dropped (it's where git puts its
    diffstat, and this format has also become a standard nowadays too).

  * From should be an allowed synonym for Author (git uses both, with a
    preference for From).

  * Reviewed-by is usually rather Acked-by.

  * Forwarded as a boolean (no/not-needed/...) field is IMHO useless,
    but whatever.  Also, when the argument is an email address, Cc: is
    usually preferred.

  * Instead of Last-Update, simply Date: is usually preferred. Plus the
    proposed format is all but an "iso" standard. rfc822 dates are a
    better idea.

Your proposal doesn't explicit what repetition of fields means. Debian
usually uses:

    Foo: value1, value2,
     value3, ...

But git people usually use:

    Foo: value1
    Foo: value2

Both should be accepted and understood in the same way.

Finally, I would suggest that Author or From should be mandatory for
conforming patches, rather than Origin. And I would suggest a License:
field for people wishing to license their patch with a specific license.

FWIW, I don't believe any packager with an upstream using git will
consider adopting DEP3 without those "fixes". With those fixes though,
it's just a tiny bit of effort for them, so you'll instead probably see
quite a fast adopting rate for DEP3...

·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org

Attachment: signature.asc
Description: Digital signature

Reply to: