Re: using bug reports on vendor kernels

[Ville Herva <vherva@mail.niksula.cs.hut.fi>]

On Thu, Aug 09, 2001 at 10:46:35PM +0100, you [Arjan van de Ven] claimed:
> On Thu, Aug 09, 2001 at 05:34:59PM -0400, Bill Rugolsky Jr. wrote:
> 
> > The real question is why not include the documentation with the patch?
> > As Linus will probably tell you, patch is pretty smart about stripping out stray
> > commentary, e.g.,
> > 
> > 	patch -p1 < ~/mail/apply
> > 
> 
> Doesn't help the people who don't want to look at all the patches but just
> want an overview.... and the spec file where the patches are applied does
> have (mostly 1 liners) documentation.

I proposed this before, but what about having one standard PATCHES file in
the kernel source tree, with all the applied pathes would touch\x7f

After having built a kernel, I could come back after months and see at one
glance what patches I (or somebody else) had applied and in what order.

Something like

cat PATCHES
+++++++++++++++++
patch: ac5
summary: Alan Cox kernel patch collection
url: ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.2
date: 05.04.2001
email: laughing@shared-source.org
+++++++++++++++++
patch: ide-04052001
summary: Hedrick IDE patch
url: ftp://ftp.kernel.org/pub/linux/kernel/people/hedrick/2.2
date: 05.04.2001
email: andre@linux-ide.org
+++++++++++++++++
patch: proconfig
summary: /proc .config support
url:  http://www.it.uc3m.es/~ptb/proconfig/
date: 06.08.2000
email: ptb@it.uc3m.es

etc etc. Every applied patch would append its info to that file. I'm not
sure, though, how that could be accomplished with patch, but if anything
else fails, PATCHES/-directory might do the job. Although then you lose the
apply order information.

And the compiled kernel could automagically have 
2.2.18-ac5+ide-04052001+proconfig suffix (if that's feasible - it could
become quite long.)


-- v --

v@iki.fi