patch naming policy

Fabio Massimo Di Nitto fabbione at
Thu Apr 7 05:50:17 UTC 2005

Hash: SHA1

Horms wrote:
> On Tue, Apr 05, 2005 at 07:29:09PM -0400, Andres Salomon wrote:

>>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).
> In the 2.4 debian tree patches are also incremented with a monotonically
> increasing serial number. Its a bit ad-hoc but generally the first
> patch is 001-blah, then 002-blah. If patches come toghether they
> can be grouped under the same serial number to make it slightly
> more obvous they came together. e.g. 123-fs-isofs-leak-1, 
> 123-fs-isofs-leak-2, 123-fs-isofs-leak-3. I find this very useful
> for quickly deterimining the relative age of patches in the tree,
> though I am not religious about it.

I think that we might have to do that, if we will move away from dpatch
and use any other packing system that does not use a list or patch dependency.
Otherwise patches will be applied randomically and most likely we will get
rejects for not respecting the order.

> I think the imporatnt thing here is to include a comment in the
> patch that describes where it came from, what can it fixes, etc.
> If the patch comes from bitkeeper this is pretty easy to do, 
> as they are usually commented (sans can number). Otherewise
> its not to hard to write something like.
> Fix for missing clock chips to allow blade servers to be detected
> Source: Dave Miller
> Upstream Status: Present
> Date: 25th March 2005
> At the very least this can be used to correlate it against changes
> that turn up in other trees. Though more information would be better.

I have only one issue with this. everytime you edit the patch you need
to readd the comments (according to how you stick them in) and it is
pretty annoying. I would be more happy to extend the changelog and make
it more anal.
It is more robust towards human errors in editing the patch in my experience.


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