Date: Thu, 21 Apr 2016 16:12:09 +0200
From: Willy Tarreau <w@1wt.eu>
To: Sasha Levin <sasha.levin@oracle.com>
Cc: Greg KH <greg@kroah.com>, Jiri Slaby <jslaby@suse.cz>,
        LKML <linux-kernel@vger.kernel.org>, stable <stable@vger.kernel.org>,
        lwn@lwn.net
Subject: Re: stable-security kernel updates
Message-ID: <20160421141209.GA9930@1wt.eu>
References: <5717DD8A.4000707@oracle.com>
 <571876AB.2060106@suse.cz>
 <20160421071157.GC9359@1wt.eu>
 <5718B92B.3080105@oracle.com>
 <20160421123631.GA19248@kroah.com>
 <5718DD39.40808@oracle.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5718DD39.40808@oracle.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 940
Lines: 23

On Thu, Apr 21, 2016 at 10:01:29AM -0400, Sasha Levin wrote:
> > What are you "stop-gapping" then?  The 7-10 days between stable
> > releases?
> 
> In a perfect world where everyone has a team of kernel hackers on hand
> reviewing stable commits, verifying the resulting kernel doesn't regress
> their product, and fixes existing regressions for their product it might
> be 7-10 days.
> 
> In the real world, this process takes much longer.
> 
> Doing a full rebase of the kernel tree is a much more costly process than
> cherry picking a handful of security commits.

Usually what is being done is mostly to check the intersection areas
between local patches and the updated parts from the next kernel. I'm
not saying it doesn't take some time, I mean for most products, only
certain areas are being considered since you usually have lots of
"CONFIG_* is not set" in a product. It's totally different for a distro
however.

Regards,
Willy