headers
Fabio Massimo Di Nitto | 5 Apr 2005 18:13
Favicon

patch naming policy


Hi everybody,

as i was talking with some guys on IRC, it would be a very good idea to enforce a strict
naming policy for our patches. This is my proposal..

Right now we are using only a single delimiter that is:

stolen-from-head_*.dpatch

I think we can organize our patches a lot better than how it is now,
if for example we can start adding other prefixes like:

driver - to apply extra patches to kernel drivers that are not upstream yet or stolen from other
~         upstreams.
edriver- to cover an external 3rd part driver that must be documented in debian/external-drivers
fs-     for extra filesystems
and so on..

Note the prefix 'e' to underline the 'external'.

The applying patch order will always be the same:

stolen-from-head-
all patches that are not ^e-external.
all the external drivers/patches.

The apply order will respect the actual one with stolen-from-head that must always
be applied before the others and the others to be rediffed on top.
(Continue reading)

Permalink | Reply | 6 comments |
headers
Andres Salomon | 6 Apr 2005 01:29
Picon
Favicon

Re: patch naming policy

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

> 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
(Continue reading)

Permalink | Reply | 4 comments |
headers
Horms | 6 Apr 2005 05:31
Picon
Favicon

Re: patch naming policy

On Tue, Apr 05, 2005 at 07:29:09PM -0400, 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).

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.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Fabio Massimo Di Nitto | 7 Apr 2005 07:43
Favicon

Re: patch naming policy


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.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Fabio Massimo Di Nitto | 7 Apr 2005 07:50
Favicon

Re: patch naming policy


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
(Continue reading)

Permalink | Reply | 1 comment |
headers
Andile.Mampofu | 7 Apr 2005 08:33
Picon

RE: kernel-team Digest, Vol 3, Issue 2

Hi 
guys

My name is Andile can some please give me information of what if happening
and I have just joined the team.

Andile  M. Mampofu

LAN Support Technician: SITA

Tel:   (012) 336 0659

Fax:  (012) 336 0691

Cell:  076 1520 926

Andile.mampofu <at> sita.co.za

-----Original Message-----
From: kernel-team-bounces <at> lists.ubuntu.com
[mailto:kernel-team-bounces <at> lists.ubuntu.com]On Behalf Of
kernel-team-request <at> lists.ubuntu.com
Sent: None
To: kernel-team <at> lists.ubuntu.com
Subject: kernel-team Digest, Vol 3, Issue 2

Send kernel-team mailing list submissions to
	kernel-team <at> lists.ubuntu.com

To subscribe or unsubscribe via the World Wide Web, visit
(Continue reading)

Permalink | Reply | 0 comments |
headers
Horms | 8 Apr 2005 06:32
Picon
Gravatar

Re: patch naming policy

On Thu, Apr 07, 2005 at 07:50:17AM +0200, Fabio Massimo Di Nitto wrote:
> -----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.
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
J Nelson | 6 Apr 2005 22:45
Picon

quick question

Hi, 
WHere do you keep the kernel source tree in Ubuntu -Hoary Hedgehog?
ie. /usr/src/linux-kernel.v.e.r
--

-- 
--Xenon--
Permalink | Reply | 1 comment |
headers
Fabio Massimo Di Nitto | 10 Apr 2005 08:47
Favicon

Re: quick question


J Nelson wrote:
> Hi, 
> WHere do you keep the kernel source tree in Ubuntu -Hoary Hedgehog?
> ie. /usr/src/linux-kernel.v.e.r

The kernel source and the headers are not installed by default.

You can use synaptic or apt-get to get them.

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.
Permalink | Reply | 0 comments |
headers
Fabio Massimo Di Nitto | 11 Apr 2005 06:00
Favicon

Re: patch naming policy


Fabio Massimo Di Nitto wrote:
> 
> Hi everybody,
> 

It's time to get to a conclusion, since we need to start breezy kernel asap.

I liked the idea suggested by both Andres and Horms and, if everybody agrees,
I would like to give a shot to the format suggested by Andres in which the name
of the patch is based on the top most common path that the patch touches, and
use a 3 letter identifier at the beginning to recognize the origin of the patch
(3 for STH, may be more for other sources to avoid clashing). Renaming patches
is still a cheap operation to do, so I don't think we should wait ages to switch.
Since we are still using dpatch, as best practise, once the patch is ready and
tested, add the comment inside it.
I still wish, generally, to write more detailed changelog entries about patches,
but this is really up to every committer.

Fabio

PS I will start the transition today in our 2.6.12 playground branch.

--
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.
Permalink | Reply | 0 comments |

Gmane