Patch format documentation may need some clarification

[Tim Gardner]

On 12/01/2011 02:45 AM, Stefan Bader wrote:
> This came up today on irc. Basically [1] and [2] talk about the format patches
> should be submitted for sru and cves. [1] 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 [2] 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?
>
> -Stefan
>
>
> [1] https://wiki.ubuntu.com/KernelTeam/KernelUpdates
> [2] 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.

rtg
-- 
Tim Gardner tim.gardner at canonical.com