From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 446927AA for ; Wed, 3 Aug 2016 13:57:42 +0000 (UTC) Received: from bedivere.hansenpartnership.com (bedivere.hansenpartnership.com [66.63.167.143]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id C665F14D for ; Wed, 3 Aug 2016 13:57:41 +0000 (UTC) Message-ID: <1470232658.2482.42.camel@HansenPartnership.com> From: James Bottomley To: Jiri Kosina , Greg KH Date: Wed, 03 Aug 2016 09:57:38 -0400 In-Reply-To: References: <871t27s1i8.fsf@intel.com> <20160802153400.GD10376@sirena.org.uk> <3268954.rXb0BJAX6c@vostro.rjw.lan> <87oa5aqjmq.fsf@intel.com> <20160803110935.GA26270@kroah.com> <87a8guq9y8.fsf@intel.com> <20160803132607.GA31662@kroah.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Cc: Trond Myklebust , ksummit-discuss@lists.linuxfoundation.org Subject: Re: [Ksummit-discuss] [CORE TOPIC] stable workflow List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Wed, 2016-08-03 at 15:48 +0200, Jiri Kosina wrote: > On Wed, 3 Aug 2016, Greg KH wrote: > > > Real examples from now on please, if there are problems in the > > stable workflow that we have today, everyone needs to show it with > > examples, I'm tired of seeing mental gymnastics around stable > > kernels just because it is "fun". > > Let me pick an example I personally had a lot of issues quite some > time ago: > > https://lkml.org/lkml/2013/4/22/259 > > This was a patch that got added to -stable to fix a problem that > didn't exist there. It caused system bustage almost immediately, > which indicates that very limited testing has been done prior to > releasing the patch. > > I believe that patches like this should really be caught during > -stable review; anyone familiar with the VFS code and actually > looking at the patch would notice immediately that it's fixing a bug > that doesn't exist in the code at all in the first place; that seems > to indicate that noone has actually explicitly reviewed it for > -stable, and therefore it's questionable whether it should have been > applied. This isn't a viable approach. Firstly stable review is less thorough than upstream review because the review mostly goes "yes, I already reviewed this in upstream". Secondly, if the upstream review didn't catch the problems why would we suddenly catch them in a stable review? The fact that possibly no-one reviewed the upstream patch indicates the need for a better upstream process (so something like we now have in SCSI which is no patches applied without one review tag), but expecting stable to fix our upstream process isn't going to work. James