Patch format documentation may need some clarification
tim.gardner at canonical.com
Thu Dec 1 14:23:19 UTC 2011
On 12/01/2011 02:45 AM, Stefan Bader wrote:
> This came up today on irc. Basically  and  talk about the format patches
> should be submitted for sru and cves.  is much older and maybe needs to be
> updated or hidden better.
> But generally I can see one issue. But I am not sure whether this is just my
> opinion, so I wanted to put it up for discussion.
> When talking about the subject line of a patch, this can mean two places:
> 1. The subject line of the email containing the patch (or the cover letter)
> 2. The subject line of the actual patch
> IMO, there are some things that make sense for 1. but not for 2., like
> the target release, tags for sru / cve, or even the cve number (which is
> in the body of the patch already). This seems to be even more confusing when the
> patch is inlined as the email then has two subject lines (sort of):
> Subject: [<releases>] (reason):<summary>
> --- patch ---
> Subject: [PATCH] [UBUNTU: [SAUCE] ...]<patch summary>
> That is at least how I think is better because then one just can save the patch
> and apply it. While if the patch itself contains the other tags, I would
> manually remove them before applying.
> In that light  sometimes would be confusing to me as it only speaks of patch
> and subject. So, is the intention as I wrote it down? Then I would try to update
> the wiki page accordingly... Should the older page be removed/updated?
>  https://wiki.ubuntu.com/KernelTeam/KernelUpdates
>  https://wiki.ubuntu.com/Kernel/Dev/StablePatchFormat
I personally prefer the 'git send-mail' form where you send a cover
letter with the SRU justification and a separate email in the same
thread with the actual patch(es). The cover letter should contain (in
the subject) an indication that this is an SRU, pre-stable, or whatnot
and the release(s) for which it is applicable.
If you're going to send a single email. then I prefer the patch as an
attachement. Otherwise you have to save the email as a file, 'git am'
it, then 'git commit --amend' to clean up the cruft that git has
included from the first subject line to the second.
Tim Gardner tim.gardner at canonical.com
More information about the kernel-team