The effort is really much better spent trying to get to 2.6 first before
worrying about things like 2.7. I hope 2.6 doesn't turn into the
"heres my 2.4+preempt+rmap patchset" monster that we saw six months ago.
> We want code that will add new drivers / devices and general
> improvements to the kernel.
non-core changes (ie, new drivers) still get added during code freeze,
and during 2.6.x, there's no need for a specific tree just for this.
Adding a new driver doesn't (or at least shouldn't) impact any existing
users if done right.
> The goal is once these are stabilized they can be
> submitted to Linus and friends for blessings and inclusion into 2.7 dev
> *early* so we won't have a mad rush for features before the next feature
> freeze.
Nice try. It'll still happen regardless. Bombing Linus with ten zillion
patches when he opens up 2.7.x with "has been tested in 2.6-xyz" isn't
the way to do it. Everything has to happen incrementally, or you end
up with a mess.
Dave
-- | Dave Jones. http://www.codemonkey.org.uk | SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/