On Feb 17 Mike Galbraith wrote: > On Wed, 2011-02-16 at 15:29 +0100, Stefan Richter wrote: > > Jiri, > > if the desire is to improve performance of existing features (and maybe > > add this and that little feature that looks attractive), while at the same > > time you want > > - experts to have looked at these improvements, > > - packagers to avoid duplicate work, > > - keep the number of local patches in check, > > then the solution is to /stay close enough to the mainline/.
[By which I meant updating, not backporting.] > That's the intent of pushing more than _purely_ critical bugfixes, get a > bit closer. Enterprise can't move as fast as mainline, not even close, > that's a given. Stable problem get griped about though, so there's no > choice but to take some risk. The tricky bit is how much, and how you > go about it. Granted. > People are fixing this and that in their enterprise kernels privately > every day. The only difference between that, and pushing baked fixes > back is that pushing to stable is visible. I strongly suspect that > there are just tons of mainline backports sitting in each and every > enterprise tree in existence. 'Visible' = the change which was an important performance improvement or outright fix at site A (and a nice-to-have improvement on sites B...X) eventually exhibits a regression at site Y. -- Stefan Richter -=====-==-== --=- =---= http://arcgraph.de/sr/ _______________________________________________ stable mailing list [email protected] http://linux.kernel.org/mailman/listinfo/stable
