patch naming policy

Fabio Massimo Di Nitto fabbione at
Thu Apr 7 05:43:13 UTC 2005

Hash: SHA1

Andres Salomon wrote:
> On Tue, 05 Apr 2005 18:13:43 +0200, Fabio Massimo Di Nitto wrote:
> [...]
>>I have rarely seen patches that were touching more than one kernel TOPDIR at the same time
>>(exception for include/) so i would say that the dirs in TOPDIR could easily define
>>the first set of delimiters..
> For debian, we tend to have patches based on the actual path to the files
> that are being touched; that works well.  So, for drivers,
> drivers-net-tg3-frobnicate.patch; for arch-specific stuff,
> arch-i386-corrupt_memory.patch.  Of course, it's a judgement call when a
> patch touches things in multiple top level directories, but it's usually
> fairly easy to determine what it should be (ie, the asfs patch adds stuff
> to Documentation, but it's clearly not a documentation-specific patch;
> it's a filesystem patch, so fs-asfs.patch is what we call it).  If it's a
> patch that touches a lot of directories, I'll use top-most common
> directory (ie, drivers-pci_update_something.patch, that updates something
> pci related on a number of net, char, and ide drivers).

yeah it matches more or less my idea. I think it would be good to give it a shot.

>>the second part should usually be a very short explanation of what the
>>patch does. Reserve all the comments for a detailed changelog entry.
> The main problem we've found w/ this has been related to patches that do
> the same thing.  For example, the various mm/ and fs/ files for elf and
> mmap related security things end up looking like
> 'fs-fix-int-overflow.patch'.  Then, another integer overflow is found, and
> you end up w/ 'fs-fix-int-overflow-2.patch'.  So, what I'll tend to do is,
> if it's a widespread change across multiple functions or files, I'll
> simply describe it ('drivers-dont-unregister-netdev-before-alloc.patch'). 
> If it's local to a function, I'll include the function name
> ('mm-do_mmap_pgoff-race-fix').  This helps a lot when multiple related
> fixes are made to the same file, but all w/ the same goal, and across
> different bk changesets.

Yes I had the same problem. I tend instead to short the bk commit short description.

[PATCH] ext3: fix memleak -> ext3-fix-memleak
[PATCH] ext3: fix memleak in deadlock -> ext3-fix-memleak-deadlock

or as close as possible to this.

> Also, since stolen-from-head is so common, you might consider shortening
> it to SFH or something, and having it be put at the end of the
> description.  So, drivers-media-video-saa7134-update-SFH.patch, or
> something like that; a quick 'ls *SFH.patch' allows you to see which
> patches are backports (same as you get now w/ the leading
> stolen-from-head*, but w/out making obscenely long filenames).

SFH is fine, but i like to have it at the begging. It is more intuitive than
at the end of very long name patches.


- --
Self-Service law:
The last available dish of the food you have decided to eat, will be
inevitably taken from the person in front of you.
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird -


More information about the kernel-team mailing list