patch naming policy

[Fabio Massimo Di Nitto]

-----BEGIN PGP SIGNED MESSAGE-----
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.

Fabio

- --
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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQIVAwUBQlTIblA6oBJjVJ+OAQJ5Tg/+LLh115crXulkHmVT86eRlDN1hir86KD6
fmzIzPIbJ180n8UgaGRFVQptB328jhmnOspaY01VCKERCKyxciAQfKvWnaBOmAZB
XS6L+xU9QTqfmG23G7xX6OwRD9COWMv5taUlmqnmWeMeUYCEFvqLo1g75RtGwz12
4zp03r9RYi09lNPJtpsEmrupeStGSQSiOWMaC8Kr4uPvCUVYv2CJDg4J5LuNg8ri
xaCO2Ea0q3qG22bM/HKkOBEal5UT9683Y9IMetSmqBiPb8quRpuFECTk+uZxQ6Mr
2DzG03lp1yJkjasFx9EWOUIl41rNCgsp3bjao7kbionfXQGxmRYZr7EZ0LDGUMHs
E9zqR1JsHmKhjlPpIg2WNpNPun972qvbwDjHxmqn9bP9HG/kv9aWqR0QPsyQUuw4
3ZVZS/j3/+7ZUjHO4srKWQjxBg6hvKfR/FVtN787Zu+J3q0ffbNs/u411c1O2oO8
V7A7YsG2LwSibviUrlApoOU+OP+xCjq8eM5BTOWa4WhBC50LDWUE8kKGIMtFYogY
h7ENbWkkr5CPczWSaILUkQu8q7N7T+pfFOyhow/nsOy78FCFQF51l3bl3EkaQYQt
qkNiVUr3ayc0eec9X+jyZ98A2ic96m2310pmoiCq7HFgshoiWqpJBxOzhU0oiOQg
pb1SEhMJKWU=
=I3/V
-----END PGP SIGNATURE-----