• PatchReleaseChecklist

Patch Release Checklist

After being embarrassed a number of times, because of my own forgetfulness, I've created this checklist, of things to consider before sending a patch off to the LinuxKernelMailingList.

Creation

1. Use diff -urpN orig new where "orig" and "new" both contain the top level "linux" directory, so the resulting patch can be applied with patch -p1.

2. See http://developer.osdl.org/rddunlap/scripts/dontdiff-osdl for a list of files for use with -x incase you have already run a build in your tree.

Compilation

1. Does the kernel still compile for I386 (as well as IA64)?
2. Does the kernel work with CONFIG_SMP on uniprocessor and multiprocessor?
3. Does the kernel still compile and work with any new configuration options both Y and undefined (and M if applicable)?

4. Have you removed surplus printk()s or other debugging output (especially if you are benchmarking)

Style

1. Does the patch conform to Documentation/CodingStyle?
2. Does it apply cleanly to the kernel version you say it does, with patch -p1 ?

Stepping on People's Toes

1. Have you talked to the maintainer(s) of the code that's patched?

Documentation

1. Have you described what the patch actually does?
2. Have you said what kernel version the patch was generated against? Note that for development kernels, this is a tricky business as the head of Linus's BK tree is often not tagged.
3. Have you described side effects, incompatibilities with other patches (that you're aware of), and other impacts on the kernel?

Orthogonality

1. Is there only one thing in the patch?
   1. No superfluous whitespace changes?
   2. No piggybacked other changes?
   3. No introduced trailing whitespace

Mailing to lists

See Linux kernel patch submission format