From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Mon, 11 Jul 2016 10:15:06 -0700 From: Dmitry Torokhov To: Theodore Ts'o Message-ID: <20160711171506.GC26822@dtor-ws> References: <20160709000631.GB8989@io.lakedaemon.net> <1468024946.2390.21.camel@HansenPartnership.com> <20160709093626.GA6247@sirena.org.uk> <5781148F.1010102@roeck-us.net> <20160709212130.GC26097@thunk.org> <20160711151300.GB3701@sirena.org.uk> <20160711170333.GE3890@thunk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160711170333.GE3890@thunk.org> Cc: James Bottomley , ksummit-discuss@lists.linux-foundation.org, Jason Cooper Subject: Re: [Ksummit-discuss] [CORE TOPIC] stable workflow List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Mon, Jul 11, 2016 at 01:03:33PM -0400, Theodore Ts'o wrote: > On Mon, Jul 11, 2016 at 04:13:00PM +0100, Mark Brown wrote: > > On Sat, Jul 09, 2016 at 05:21:30PM -0400, Theodore Ts'o wrote: > > > > > the latest stable kernel. (But even if they do, apparently many > > > device vendors aren't bothering to merge in changes from the SOC's BSP > > > kernel, even if the BSP kernel is getting -stable updates.) > > > > It would be pretty irresponsible for device vendors to be merging BSP > > trees, they're generally development things with ongoing feature updates > > that might interact badly with things the system integrator has done > > rather than something stable enough to just merge constantly. > > So the question is who actually uses -stable kernels, Community-based distros definitely use stable, but that might be the latest stable, not the older stables that are out there. > and does it make > sense for it even to be managed in a git tree? > > Very few people will actually be merging them, and in fact maybe > having a patch queue which is checked into git might actually work > better, since it sounds like most people are just cherry-picking > specific patches. Cherry picking a commit from a branch/remote is much nicer than fetching a part of [quilt based?] patch queue from git, unless I misunderstand what you are proposing. Thanks. -- Dmitry