[cgl_discussion] KGDB and process issues

[george anzinger]

Andy,

Tim sent me a message from you with the following in it:

 1. The rules of integration on this project indicate that
we need
    two sets of diffs.  One against a pure 2.4.18 that will
be preserved
    in a patch directory, and another set that would be
applied to the
    current CVS tree and committed.  I can't make a good
case for
    getting kgdb into the tree very soon without the diffs
in-hand.

Now what this usually means is the the "pure" patch gets put
in the patch directory.  It is then applied and fixups are
done and committed.  I.e. the second diff is preserved ONLY
in the CVS logs.  In the TLT tree, we were to tag the tree
after the commit with a well defined tag, but the pre commit
tag was private and not controlled.  Of course having both
would allow one to actually get cvs to produce a diff of the
committed code.

This, WAS the way.  As I understand the new rules we are not
tagging the tree at all.

Also, in the old way (and the new) there is something of a
black hole around what is changed to make the patch apply.  

Yesterday on the  "'developer at carrierlinux.org'"
<developer at carrierlinux.org> mail list "Zhuang, Louis"
<louis.zhuang at intel.com> proposed an extension to this way
of doing things that I think has a lot of merit.  After
thinking about it for a bit here is what I think he would
like the process to be:

1.) Apply the patch (the one that is to be put in the patch
directory and is against a "pure" kernel).

So far this is just what we do, but now:

2.) Put a stake in the ground.  I.e. capture the post patch
kernel BEFORE any conflict resolution.  A simple way would
be to hard link the kernel tree to a new kernel tree.

3.) Make the changes needed to "fix" the conflicts.

4.) Take a diff of the new kernel against the kernel prior
to step 3.

5.) Put this diff in the patch directory AND mail it to the
development list.

Why the mail?  Well, the reason the patch did not apply is
that someone else (possibly several someone else's) has been
messing in the same sand box.  Putting the patch on the
mailing list gives everyone an opportunity to see what was
done to his code by the new patch and to catch any problems
early on (well, we can dream...).

By only doing a diff of the problem areas we keep the diff
small and, with luck, easy to read.

Subsequent fixes to the kernel for the same feature should,
I think, also have two patches checked in, the same as the
first one.  Of course, it is possible that there may be no
need for the second patch of the pair as the patch may apply
cleanly.  It is also possible that a subsequent fix will
only change code in our tree and not in a "pure" kernel, so
only the second patch would get checked in.

I think we should also have a naming convention for these
patches so we can easily separate the "pure" from the "fix"
patches.

Having said all this, I realize that you may not be the one
I should be sending this to.  Please help me in this regard.
-- 
George Anzinger   george at mvista.com
High-res-timers: 
http://sourceforge.net/projects/high-res-timers/
Preemption patch:
http://www.kernel.org/pub/linux/kernel/people/rml