linux-kernel - Re: Proposed stable release changes

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: <20130821135816.41127e6f@gandalf.local.home>
Date:	Wed, 21 Aug 2013 13:58:16 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Jochen Striepe <jochen@...ot.escape.de>
Cc:	Willy Tarreau <w@....eu>, 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

On Wed, 21 Aug 2013 19:23:27 +0200
Jochen Striepe <jochen@...ot.escape.de> 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 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/