[cgl_discussion] KGDB and process issues

[John Cherry]

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

I agree with Khalid.  The tagging rules should still apply.

> 
> 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'"

Sounds like there are some process discussions happening on
developer at carrierlinux.org that might benefit cgl_discussion.

> <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:

Without commenting on the whole process description, I can say that it
seems insane to me to resolve integration conflicts in the main CVS
repository.  Submitters should generate two patches.  One that would
apply to a pristine 2.4.18 kernel and one that would apply to the CGLE
"head".  When the patch is actually submitted to the CGLE repository,
only conflicts which have recently been introduced need to be resolved. 
This puts most of the responsibility for conflict resolution on the
patch submitter and not on the integration team.

John

> 
> 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
> _______________________________________________
> cgl_discussion mailing list
> cgl_discussion at lists.osdl.org
> http://lists.osdl.org/mailman/listinfo/cgl_discussion