[Ksummit-discuss] [Stable kernel] feature backporting collaboration

James Bottomley James.Bottomley at Hansenpartnership.com
Tue Sep 6 22:34:00 UTC 2016


On September 6, 2016 6:20:58 PM EDT, Mark Brown <broonie at kernel.org> wrote:
>On Tue, Sep 06, 2016 at 09:44:04PM +0200, gregkh at 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.


More information about the Ksummit-discuss mailing list