Re: Proposed stable release changes

[Steven Rostedt <rostedt@goodmis.org>]

First I want to say that I 100% support the idea of waiting at least one
-rc. Maybe even two.

On Wed, Aug 21, 2013 at 07:38:36AM +0200, Willy Tarreau wrote:
> > 	Cc: stable <stable@vger.kernel.org> # after -rc5 is out
> > or
> > 	Cc: stable <stable@vger.kernel.org> # wait a -rc cycle
> > or
> > 	Cc: stable <stable@vger.kernel.org> # wait a few weeks to bake
> 
> That's where I think that the default one (with no indication) should
> be the higher delay. If the author has no clue about the emergency of
> his patch, who else can guess for him ?
> 
> It's too optimistic to consider that some code authors will be
> realist about the impacts of their code. We all create bugs and
> regressions everywhere because we're sure about what we do, until
> someone says "hey dude you broke this". So if we expect authors to
> say "look, I managed to get this merged into mainline but I'm still
> not sure about the risks", I suspect only a small fraction of the
> patches will be tagged this way. But I may be wrong, after all it
> already works well with -net.

Really, most fixes are for regressions. If it isn't something that can
let non root crash the kernel, or have access that they shouldn't have,
then let it simmer in the kernel for a while. I don't see any reason to
rush out a regression fix if it just causes a device not to work
anymore. The user can go back to the old kernel for a week or two and
wait. Even with two weeks (or even a month) of waiting, we are still much
faster than Apple or Microsoft in getting regression fixes out.

If people are not rushing to update their kernel to stable every time a
new stable is released then why are we rushing to get them out?

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.

-- Steve