patch naming policy
Fabio Massimo Di Nitto
fabbione at ubuntu.com
Thu Apr 7 05:43:13 UTC 2005
-----BEGIN PGP SIGNED MESSAGE-----
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.
The last available dish of the food you have decided to eat, will be
inevitably taken from the person in front of you.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the kernel-team