patch naming policy

Andres Salomon dilinger at
Tue Apr 5 23:29:09 UTC 2005

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).

> 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.

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).

More information about the kernel-team mailing list