From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Mon, 11 Jul 2016 13:20:41 -0400 From: Theodore Ts'o To: Dmitry Torokhov Message-ID: <20160711172040.GB21285@thunk.org> 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> <20160711171506.GC26822@dtor-ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160711171506.GC26822@dtor-ws> 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 10:15:06AM -0700, Dmitry Torokhov wrote: > > 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. The reason why I'm wondering whether or not quilt based might be better is because if it turns out that a patch introduces a regression, with a quilt based system the patch can be *dropped*, or revised in place. When you do a cherry-pick, you depend on the BSP kernel maintainer figuring out that a commit was later reverted, or fixed by a later commit that might have a different name, and which doesn't make it obvious that if you take commit 'A', you REALLY want to take commits 'B' and 'C' as well.... - Ted