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.
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.
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.
- Does the kernel still compile for I386 (as well as IA64)?
- Does the kernel work with CONFIG_SMP on uniprocessor and multiprocessor?
- Does the kernel still compile and work with any new configuration options both Y and undefined (and M if applicable)?
Have you removed surplus printk()s or other debugging output (especially if you are benchmarking)
- Does the patch conform to Documentation/CodingStyle?
- Does it apply cleanly to the kernel version you say it does, with patch -p1 ?
Stepping on People's Toes
- Have you talked to the maintainer(s) of the code that's patched?
- Have you described what the patch actually does?
- 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.
- Have you described side effects, incompatibilities with other patches (that you're aware of), and other impacts on the kernel?
- Is there only one thing in the patch?
- No superfluous whitespace changes?
- No piggybacked other changes?
- No introduced trailing whitespace