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.
>
> 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.
In debian we have a per-release "series" file. The series files
themselves are ordered by the release to which they are attached -
actually, they live in debian/patches/series, and the name
of the file matches the name of the release that they belong to.
Inside the file is an ordered list of patches to apply and unapply
(and files to remove, but that isn't relevant here). This system
works pretty well as we can arbitarily patch to any release.
It also means that the numbering scheme I list above actually
doesn't effec the order patches are applied in. Is just a convenience
when the patches are listed using ls or something that shows
our svn repository via http.
> > 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.
I guess it depends how you edit your patches. Personally I don't find
the updating bit to be bothersome. I just open the patch, delete
everything after the comment and read in the new patch. But I can
understand that this process might not be so easy for others.
In the long run as long as the information is there, and there
is a clear link between what change was caused effected by
which patch - in debian we list the patch names in the change log
along with a super-breif summary - then I think all is well.
--
Horms
--
kernel-team mailing list
kernel-team@xxxxxxxxxxxxxxxx
http://lists.ubuntu.com/mailman/listinfo/kernel-team
|
