Re: [PATCH] [RFC] adding support for .patches and /proc/patches.gz

["Cef (LKML)" <cef-lkml@optusnet.com.au>]

On Wed, 12 May 2004 14:59, Jon Oberheide wrote:
> Any patches applied against the current vanilla kernel.org kernel would
> be listed in .patches.  This would include vendor, third-party, and even
> pre/bk/mm patches.
>
> Keep in mind, .patches would not contain the entire patch, as that would
> be WAY to large, but just a short entry such as the name, date last
> modified, and date applied of the patch file.

A URI would always be nice. That way the originator of the patch can be 
contacted and/or the patch can be fetched easily, all without the original 
kernel source.

In fact, it seems to me that BK (or in fact any patch management system) could 
prove useful here. Not only could it list merged changesets in .patches, it 
could also provide a URI for the author or the repo/patch. And as the kernel 
tree moves and the patches get pushed into releases, the .patches file gets 
cleared of everything that exists in the base tree. Really, something like a 
translated output of the BK changelog for a tree would probably do the job. 
Much like lk-changelog.pl, but more compact information wise. Providing a 
tool at least would get it out in the open and used.

Of course, then you have to define what the base is, and really this should be 
the first thing in .patches - You need to state what the baseline is you're 
comparing against. It'd be good if it wasn't in a separate place. That 
increases it's versatility greatly.

For something like this to happen with BK (ie: as a BitMover provided app), 
you may want to talk to Larry McVoy - it's his baby after all. Of course, you 
could just hack on lk-changelog.pl yourself.

-- 
 Stuart Young (aka Cef)
 cef-lkml@optusnet.com.au is for LKML and related email only