On Wed, 21 Aug 2013 19:23:27 +0200 Jochen Striepe <jochen@xxxxxxxxxxxxxxx> wrote: > ... people are very different. Many just update here and then, but > there are those who do update on most stable releases. Those are the > ones you get feedback and testing from, and I think you should encourage > them to update as soon as a new -stable kernel is released. Getting > regression fixes fast sounds like a good encouragement especially for > people interested in the -stable series. Keeping the number of > regressions low is the whole point of -stable, right? Yes, but its even worse when we add a new regression to fix the old one. Note, this will still encourage people to upgrade to stable, and the delay should be even more encouragement. The point of the delay is to catch regressions caused by fixes in mainline. We don't want that added regression to trickle into stable like it has a few times. As you say "Keeping the number of regressions low is the whole point of -stable". Yes it is. By the delay, it should help stable from getting as many regressions as it is today. > > > Maybe people are rushing, but I don't update my main machines every > > stable release because I can't always afford the down time it causes me > > to do so. > > On my server/router and on my desktop machine it's the same, those are > for daily work. But I have a netbook for playing around. :) Right, and after upgrading your server/router to a new stable, it will suck that it hits a new regression and you have to update again. A delay should help limit those occurrences even more. For netbook that you can play with the -rc candidates and if you hit a regression, report it, and go back to a more stable kernel. The point I'm making, we should be more reluctant in pulling patches into stable as quick as we are. A patch ideally should simmer in linux-next for a bit, then go into mainline. It should also simmer there for a bit before it goes into stable. Except for those very rare patches that can cause the system to easily crash, let an exploit happen, or corrupt data. Those do need to go into stable ASAP. But luckily, those are also rare and far between. -- Steve -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html