patch naming policy
Fabio Massimo Di Nitto
fabbione at ubuntu.com
Thu Apr 7 00:50:17 CDT 2005
-----BEGIN PGP SIGNED MESSAGE-----
> 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.
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