> Except when those updates qualify as stable updates. Which I believe they should.
-stable could be redefined to allow this, but since this is adding functionality, not fixing a bug, it wouldn't fit the current definition.
> Or when everyone get's their act together and when a new kernel releases it already has the "right" set of definitions.
I don't see how that is possible.
month M kernel.org releases 3.4, starts development on 3.5
Month M+1 distro A decides their next release (version 10, to be released in 3 months) will be based on 3.4 starts defining minimum requirements for the next release
Month ~M+3 kernel.org releases 3.5 starts work on 3.6
Month M+4 distro A finalizes the version 10 release (based on 3.4) and now has the final definition for the minimum requirements. Distro A submits these upstream, Linus allows the patches past the merge window.
Month ~M+6 kernel.org releases 3.6 (with distro A version 10 minimum config embedded) and starts working on 3.7
multiply this out by hundreds of different distros.....
Remember that the kernel.org schedule is not fixed, it's working out to about 2.5-3 months (two week merge window plus 6-9 -rc releases before the final release) while the distros are on a fairly strict 6 month schedule. the distros aren't going to be trying to release the kernel that kernel.org is currently working on (if we are lucky, they are working on the release only one back, but it may very well be older than that)