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

Mark Brown broonie at kernel.org
Tue Sep 6 22:20:58 UTC 2016


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).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/ksummit-discuss/attachments/20160906/bf3f3318/attachment.sig>


More information about the Ksummit-discuss mailing list