From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: In-Reply-To: <20160906222058.GS3950@sirena.org.uk> References: <57C78BE9.30009@linaro.org> <20160905111105.GW3950@sirena.org.uk> <20160905140327.a6wgdl3lr42nlww4@thunk.org> <9895277.d39OTXtlqC@avalon> <20160906003532.GA3950@sirena.org.uk> <1473175831.17204.29.camel@HansenPartnership.com> <20160906194404.GA22363@kroah.com> <20160906222058.GS3950@sirena.org.uk> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: James Bottomley Date: Tue, 06 Sep 2016 18:34:00 -0400 To: Mark Brown , "gregkh@linuxfoundation.org" Message-ID: <10203253-0df5-4ff3-8cd4-9e6b38661d57@email.android.com> Cc: "ltsi-dev@lists.linuxfoundation.org" , ksummit-discuss@lists.linuxfoundation.org Subject: Re: [Ksummit-discuss] [Stable kernel] feature backporting collaboration List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On September 6, 2016 6:20:58 PM EDT, Mark Brown wrote: >On Tue, Sep 06, 2016 at 09:44:04PM +0200, gregkh@linuxfoundation.org >wrote: >> On Tue, Sep 06, 2016 at 11:30:31AM -0400, James Bottomley wrote: >> > 3. Increase the pain.  Not sure I like this, but in theory, we >could >> > churn the upstream API to increase the pain of upports, but >it would >> > also cause a lot of issues with backports. > >> I tried doing this in the past. It did cause pain for out-of-tree >> modules, but then they got really good and abstracted things away so >> that it made their future kernel porting efforts even easier than >> before, making their need to upstream code even less. And then when >> they did want to upstream stuff, it took more work unwinding the >> abstraction layer. > >> So watch out for unintended consequences here :) > >The other big unintended consequence I'd worry about here is that it >will present an obstacle to someone who wants to try to upstream >something while working in a downstream environment - if someone is >looking at some code but the changes for upstream are too great then it >might make it too much work for them to try if it's not their primary >job. > >I'd also worry about annoying people who are working upstream as well, >it's annoying having things break randomly due to API changes (both as >the submitter and as a maintainer or reviewer). Ok, so everyone went straight for the option I didn't like. I knew I shouldn't have included it. So what about options 1 or 2, or even something I hadn't thought of? James -- Sent from my Android device with K-9 Mail. Please excuse my brevity.