@ThinkRob: Not to disregard the effort made to create such patchset, but I would say it's rather too specific. Most people either use default distro-provided kernel or make their own "patchset" that suits their needs, because kernel configuration is now (2.6) a lot easier. Full patchsets are much more useful as individual series of patches that anyone can browse in and pick any favorites. Of course, that doesn't mean there won't be anyone interested in a full patchset.
In this my post, I'd like to give you at least some feedback / points to think about. Please take no offense.
- alternate/experimental/special-purpose I/O schedulers
I have tested both Con's BFS CPU scheduler and the BFQ I/O scheduler with pretty much zero gain. The BFS scheduler needs non-NO_HZ kernel with at least HZ_1000 to work as expected. BFQ have failed (on my testing machine) to schedule out a big write() syscall of a heavy-disk-I/O process and prefer other processes. It might as well be related to NO_HZ. If not, then I'd say BFS/BFQ is nothing but a placebo effect
- any i915 fixes that can be backported without breakage
I'd be careful with those. I don't know how often you plan to release your patchset, but "bleeding edge" people can simply get those fixes from the next upstream version and "long-term" people will get those from 2.6.32 maintainers. I see little gain in backporting them any sooner and some danger in doing so (I already made one kernel unbootable by backporting an "innocent" radeon typo fix).
- the latest version of thinkpad-acpi
If you are able to safely backport bleeding-edge thinkpad-acpi onto 2.6.32, then it would be nice.
- misc. patches (minor fixes, precautionary security patches, etc.)
In my "patchset", those fixes often include things that only I want, since they are really specific and not useful to most people. Things like "do not ever lock cdrom drive", "colored printk", some custom netfilter modules I wrote and so on. The kind of patches you don't want in a generic patchset. If your "misc. patches" include backported upstream fixes instead, then please ignore this paragraph.
The .config idea is, in my opinion, a lot more useful one, since there are tons of kernel-configuration newbies and those often include many things they don't need and/or forget thinkpad-specific / important things. So I can't argue with a sane "defconfig for thinkpads".
Other than that:
- enables either voluntary or real-time preemption with CONFIG_HZ_300
- aims to maximize power savings
You can either run NO_HZ kernel and have maximum power savings, or run HZ_NNNN kernel with regular ticks (without NO_HZ) and get decent response time, .. or use the RT patchset. The CONFIG_HZ_NNNN has very little meaning when NO_HZ is enabled.
So, use NO_HZ to gain better battery life, CONFIG_HZ_1000 (optionally with Con's "low latency" patches) to get better system responsiveness at the cost of battery life .. and the RT patchset to get realtime scheduling (if you really need it) at the cost of lower battery life.
There are quite a lot of patches one would like to set-up on it's own, like the PHC (undervolt) one, which REALLY makes a difference (68°C before, 56°C after - under heavy load). I myself maintain my own tp_smapi git tree outside the kernel, since making upstream hdaps.c compatible would need a lot more effort.
Using all the power-saving I can get, I'm able to last for about ~10 hours with lowest brightness and firefox-browsing via ethernet (T500, i915, 9-cell battery). The power saving includes, amongst others, things like software-ejecting the ultrabay drive, turning off wake-on-lan, using 100Mbit ethernet mode, always-spinning HDD (turns out that it's more power/latency-efficient than spinning it up each 4-5 minutes, except for only-firefox-browsing
I hope you'll find some of my points useful.