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 435B889C for ; Wed, 3 Aug 2016 17:20:19 +0000 (UTC) Received: from mail-pa0-f65.google.com (mail-pa0-f65.google.com [209.85.220.65]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id CCE30241 for ; Wed, 3 Aug 2016 17:20:18 +0000 (UTC) Received: by mail-pa0-f65.google.com with SMTP id cf3so14317539pad.2 for ; Wed, 03 Aug 2016 10:20:18 -0700 (PDT) Date: Wed, 3 Aug 2016 10:20:15 -0700 From: Dmitry Torokhov To: Guenter Roeck Message-ID: <20160803172015.GA36266@dtor-ws> References: <87oa5aqjmq.fsf@intel.com> <20160803110935.GA26270@kroah.com> <87a8guq9y8.fsf@intel.com> <20160803132607.GA31662@kroah.com> <20160803141937.GA9180@kroah.com> <57A21252.7000407@roeck-us.net> <20160803161234.GA32965@dtor-ws> <57A21F88.7000504@roeck-us.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <57A21F88.7000504@roeck-us.net> Cc: James Bottomley , ksummit-discuss@lists.linuxfoundation.org, Trond Myklebust Subject: Re: [Ksummit-discuss] [CORE TOPIC] stable workflow List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Wed, Aug 03, 2016 at 09:44:56AM -0700, Guenter Roeck wrote: > On 08/03/2016 09:12 AM, Dmitry Torokhov wrote: > >On Wed, Aug 03, 2016 at 08:48:34AM -0700, Guenter Roeck wrote: > >>On 08/03/2016 07:45 AM, Jiri Kosina wrote: > >>>On Wed, 3 Aug 2016, Greg KH wrote: > >>> > >>>>>Has anything changed in the process that'd just make patches like this one > >>>>>to be not merged these days? > >>>> > >>>>We have Guenter's test-bot that has helped out immensely here with this. > >>> > >>>That's very good to know, I admit that I have close to zero idea about how > >>>the stable -rcs are being tested. > >>> > >> > >>... and when it doesn't work because I messed it up, we get issues such as 3.18 > >>and 4.1 being broken for mips and sparc64 because a couple of patches which don't > >>apply to those kernels were tagged with an unqualified Cc: stable and applied. > >> > >>So, if anything, the one problem I see with the current stable process is > >>those unqualified stable tags. Maybe those should be deprecated; expecting > >>stable maintainers to figure out if a patch applies to a given stable branch > >>or not is a bit too much to ask for. With stable releases as far back as > >>3.2 (or 338,020 commits as of right now) it is almost guaranteed that a > >>patch tagged with an unqualified Cc: stable doesn't apply to all branches. > > > >When I put cc:stable it is simply a suggestion for stable maintainers to > >figure out if this commit is suitable for _their_ stable. I might have > >an idea about n-1.x stable series but I certainly do not have any desire > >nor time to research whether this patch applicable to 3.2 or 3.0 stable > >series. > > > >Stable maintaintership should be more than "swipe in everything marked > >as cc:stable, try compiling and hope it all good". > > > > I don't think I can agree to that. Personally I see it as my responsibility > to give stable maintainers as much information as possible. Dave for networking > goes even further, essentially providing stable maintainers with the patches > to apply (granted, I have no idea how he finds the time to do that). Me neither. There probably 100s of him, like Alans were in the days ;) > > How can one reasonable expect a stable maintainer to determine if a patch for > an oddball architecture applies, or one for a random subsystem ? Following > your argument, stable maintainers would have to be experts on all architectures > and subsystems in the kernel - because that is what they would have to be > in order to do more than "it compiles, therefore it works". Even compilation Well, yes, they would have. Or they would have to assemble a team who can cover this. As it is it is quite easy to start a stable tree - do you need anything except to announce it? I do not see subsystems maintainers being asked if they have time/resources/desire in maintaining said stable trees. > is difficult - I suspect I might run the only testbed which builds _all_ > supported architectures and runs qemu tests on 14 of them (not counting le/be > and 32/64 bit variants). > Thanks. -- Dmitry