lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130821133713.GA16493@home.goodmis.org>
Date:	Wed, 21 Aug 2013 09:37:13 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Willy Tarreau <w@....eu>
Cc:	Greg KH <gregkh@...uxfoundation.org>,
	Josh Boyer <jwboyer@...oraproject.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	stable <stable@...r.kernel.org>, lwn@....net,
	Guenter Roeck <linux@...ck-us.net>,
	Hugh Dickins <hughd@...gle.com>,
	Johannes Berg <johannes@...solutions.net>,
	Borislav Petkov <bp@...en8.de>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Proposed stable release changes


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@...r.kernel.org> # after -rc5 is out
> > or
> > 	Cc: stable <stable@...r.kernel.org> # wait a -rc cycle
> > or
> > 	Cc: stable <stable@...r.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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ