[cgl_discussion] Kernel patches and tagging conventions - (formally KGDB and proce
Selbak, Rolla N
rolla.n.selbak at intel.com
Fri Sep 6 13:24:44 PDT 2002
> 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
> 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:
> 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:
> 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.
More information about the cgl_discussion