Patch format documentation may need some clarification
stefan.bader at canonical.com
Thu Dec 1 14:41:47 UTC 2011
On 01.12.2011 15:23, Tim Gardner wrote:
> 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
> 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.
Sounds quite similar and also I learned today that git am (despite not exactly
saying so in documentation) will remove any blocks in  at the beginning of the
subject. So one can actually place as much as one wants there and it goes away
In fact for CVEs we tend to use the cover letter email and then the patches with
the target release hint in the patch/email subject. So the newer document may
completely replace the older one perhaps...
More information about the kernel-team