[CarrierLinux Developer] Re: [cgl_discussion] KGDB and proces
mauri.whalen at intel.com
Thu Sep 5 15:58:22 PDT 2002
Actually - this is a good example of what we don't want to do.
All CGLE 1.0 discussions should happen exclusively on
cgl_discussion at osdl.org. This is no different than development moving to
Using both mailing lists is not acceptable - please just switch to
TSP Build & Integration
mauri.whalen at intel.com
From: John Cherry [mailto:cherry at osdl.org]
Sent: Thursday, September 05, 2002 3:49 PM
To: george anzinger
Cc: Andy Pfiffer; Tim Anderson; Zhuang, Louis; cgl_discussion at osdl.org;
developer at carrierlinux.org
Subject: [CarrierLinux Developer] Re: [cgl_discussion] KGDB and process
> 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.
> 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"
> 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
> Preemption patch:
> cgl_discussion mailing list
> cgl_discussion at lists.osdl.org
Developer mailing list
Developer at carrierlinux.org
More information about the cgl_discussion