Makes perfect sense to move over to pvops (in mainline) directly :
- Many of us have already used pvops-git and it works
- Other branches (2.6.27/29/30 or whatever) would be a single-chunk
forward port, with more scope for latent bugs (and no long-term benefits).
- We anyway need to make pvops happen. The more we wait, greater will be
the feature parity.
... and many more reasons.
One of the reasons cited for sticking on 2.6.18 was that it would hopefully encourage folk to use pv_ops if they wanted anything more modern. I'm not sure that worked out too well...
One argument for using 2.6.27 is that I believe it's the kernel used by SLES11, so there should be good availability of drivers backported to it. It strikes me it's not a bad plan to have two trees, one based off the latest stable enterprise distro (in this case SLES11), and the pvops tree based off the latest kernel.org release.