patch naming policy

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


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

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

iQIVAwUBQlTKBFA6oBJjVJ+OAQL3+A//c0XU8nCFL/bGR3KytKbPUv2WKuQEwEaO
h5G2qrZbiTzo3Qpypvg+EC+jJ5jW1BT5TOMooWzv+s1NtIuwq0rhOfJIOCBa6xvy
Vjskclh1TX6ZgA3Vlvrb5z9iulXUg3XyesJdApXGW2DfsTyT6MWh1tiKCIV5ke8a
o4SI8NLmXQbxT9PfNtoTmUERyBYAsfAZYvcwXBblar7PZGk+7/+2xae2nKkFCgOc
OE7eytuOd0AlEP4s+YOb/knnNuYxtHhJ6lG//MTA1aYzh/rimuOIq9bOpLwI3ASX
xyy2rRjAozup7lHN18y1PD4ZSkP/nR5e1GnB5DrQERHe1dDFcYEFshcoeERfZSJH
xVQPJ7lnUAQrwl05iLrmFMFtSl0UJKnC/53+QAd0VRIwO6nmpe3g42jVNGFBm7Za
KVKQ89rhAjhvmtk8C0LqqXHVdoxmZ5kTNIDw5SXVDBwVHKv/gAxHnO8u/Po63xft
dOxyUE//iOFxaXra1m0uPA8KvqC00EXC9Fxfqg4mmoxq9+Wz4KBSjSDk+5v4/sgs
VFp8cThasKMDwoQiZ79k8tUVIZ1su2BHH4ncVt1e7InDqOr3O6amnLqwyDsFVKvt
sVaC3bavtLgbdw57ESYFuHocm4I4GCKEJEo5L01ZmsHVp+eHjIa6eQflJ7RRz7km
x8Uwr346TwY=
=TxPA
-----END PGP SIGNATURE-----




More information about the kernel-team mailing list