[cgl_discussion] process issues, review of conflict resolution

george anzinger george at mvista.com
Thu Sep 5 16:41:04 PDT 2002


John Cherry wrote:
> 
> >
> > 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.

Yes, sorry I missed this.  Actually the new rules look
better.
> 
> >
> > 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.  

I think you must think I suggested a commit between steps 1
and 4.  I did not.

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

I don't think I am suggesting otherwise.  The patch comes
into the CGLE head and conflicts with other patches.  The
DEVELOPER resolves the problem and commits.  THE PROBLEM IS
THAT THIS ASSUMES THAT HE KNOWS THE OTHER PATCH.  My
suggestion (actually Louis's suggestion) is that the changes
made to resolve the conflict be reviewed (or, at least, be
presented for review) by the developer of the "other code". 
I submit that presenting the whole patch is much more than
is needed and just hides the issue, which is the impact on
other developers.  By extracting just the conflict
resolution we come up with much less code to review.

I further submit that NOT presenting this information has
and will continue to cause problems further along in the
process.  By recording the changes concisely (i.e. the
conflict resolution patch) in the CVS tree, anyone can go
back and review just those things that were changed because
of conflicts.

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

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



More information about the cgl_discussion mailing list