[cgl_discussion] Kernel patches and tagging conventions - (formally KGDB and proce ss issues)

[Selbak, Rolla N]

Hey everyone,

maybe I can clear up a few things hopefully, we'll see how I do:

1. Tagging Rules for the Kernel

Alrighty, so in terms of tagging, the "patching rules" document says it all.
http://www.developer.osdl.org/projects/docs/CGLE-patching-rules.pdf  

Basically the idea is to tag the kernel source 'before' you apply your
patch, and then 'after' you apply and commit the patch.  So the steps would
be somethin' like: (a) tag the kernel source with a 'before' tag before you
commit your patch  (b) apply your patch to the kernel source and checkin the
changes and add files as needed (c) tag the kernel source with an 'after'
tag.  NOTE: If you want to go ahead and add tags that might be helpful to
your development, you can do that as well.  There is no real rule that says
you can't add your own personal tags that can help you develop, so feel
free.

2. No universal 'v1_0__build' tag for Kernel

When Tariq wrote: "You don't need to tag kernel patches or kernel source
after
patching with anything." he meant that no 'universal' tag is needed for the
kernel source because the build process pulls on the tip of the kernel
source, you still need to follow the standard 'before' and 'after' tagging
conventions.  i.e. no tag such as the v1_0__build used for components is
needed, but we still need to tag before and after a patch is applied.

3. New 'Tagging Conventions' document posted

I added a new document called "CGLE Tagging Conventions" located in the
Documentation section of developer.osdl. The link is right ova here:
http://www.developer.osdl.org/projects/docs/CGLE_tagging_conventions.php

4. Current "patches" directory in CVS

Now for the "patches" directory in CVS.  What this directory was supposed to
contain were patch files diffed against the pristine kernel, i.e.
open-source ready patches.  These patches were also supposed to be
'collective' rather than 'serial/delta)'. For example let's take LVM.  What
we might see in the patches directory under LVM are a few patch files such
as:

lvm-1.1.1-kernel-2.4.18-rev001.patch
lvm-1.1.1-kernel-2.4.18-rev002.patch
lvm-1.1.1-kernel-2.4.18-rev003.patch

This means that there have been 2 other updates to LVM after the original
check-in of the patch (updates are rev002 & rev003 patches).  What rev003
would include is rev001 + rev002 + any updated changes = rev003, so that
applying the rev003 patch of LVM would collectively include all previous
changes as well.  So now in order to get the most recent LVM changes, all
one would have to do is apply the rev003 patch to a pristine kernel, rather
than having to apply rev001, rev002 and rev003.

5. Suggestions for keeping track of CGLE changes

Any changes made to the CGLE kernel have to be in the form of a .diff or
.patch (I hope this was clear in the documenation.  If not, please let me
know).  Now an issue was brought up that yes, though we do have the
prstine-diffed patch in the patches directory, how do we keep track of the
.diff or .patch file we applied to the CGLE kernel source (which most of the
time is at least slightly different than the pristine-diffed one). 

The documenation says that it is the developers' responsibility to keep
track of those patches on their own developer machines.  But since this
issues was brought up, it does seem only logical that these be tracked in
CVS as well, I totally agree with this actually. 

So what I suggest is that developers maybe create a sub-dir in the
patches/[patch-name] in CVS and put any .patch files they used to patch the
CGLE tree.  Or even just rename the .patch file differently than the
pristine-diffed one.  Remember, the build process does not even touch the
patches directory, it is used for back-tracking and history purposes, as
well as containing the open-source version of the patches. 

6. Help?

-Documenation section on developer.osdl.
-Email: cvs-admin at developer.osdl.org anytime you have a question or comment
or need clarification on something.  
-Also, if something in the documenation is unclear, please email us so we
can change that as soon as possible.


THANKS!

rs