From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Dave Airlie <airlied@gmail.com>,
ksummit <ksummit-discuss@lists.linuxfoundation.org>
Subject: Re: [Ksummit-discuss] vague topic for maintainers summit
Date: Mon, 09 Sep 2019 11:44:15 +0100 [thread overview]
Message-ID: <1568025855.6613.5.camel@HansenPartnership.com> (raw)
In-Reply-To: <CAPM=9tx7toB7Bsif6RDo51HNxcGbbHDPHD7DjmF9i+zs-J0HRQ@mail.gmail.com>
On Mon, 2019-09-09 at 20:17 +1000, Dave Airlie wrote:
> This topic occured to me on one of the planes I've spent time on this
> weekend, so it's kinda vague and handwavy.
>
> Methods for constructively saying No to large companies.
>
> I feel it would be best suited for something like maintainer summit
> as people can speak freely without causing employer issues.
>
> The idea would be to exchange ideas and discuss how to address large
> bodies of code or stacks that are misdesigned or have major issues
> that aren't suitable for stable inclusion, or are big additions to
> current drivers/layers, being submitted by large corporations with
> the expectations that we would land it because they designed it like
> that. I'm not sure if other maintainers face this sort of thing as
> regularly as I do, but just wondered if there was value in discussing
> it.
Having done this in SCSI for several drivers, there's definitely value
in discussing it, but the usual solution is to get trusted reviewers to
identify the design problem and recommend ways of fixing them. The
main difficulty we have is getting people to do the reviews ... the
larger the code size the more difficult this is. For most this all
goes amicably but, for a couple which were really important, I've
actually sometimes rewritten the code base myself (not that this should
ever be recommended or expected practice).
I haven't really found corporations attempting to apply pressure to get
their patches merged as is, although I've heard of others having this
problem. My usual problem is that the creator of the patch is deeply
wedded to their design and doesn't want to change so it's an individual
rather than a corporate issue.
James
next prev parent reply other threads:[~2019-09-09 10:44 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-09 10:17 Dave Airlie
2019-09-09 10:44 ` James Bottomley [this message]
2019-09-09 11:53 ` Mark Brown
2019-09-09 12:01 ` James Bottomley
2019-09-09 12:18 ` Mark Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1568025855.6613.5.camel@HansenPartnership.com \
--to=james.bottomley@hansenpartnership.com \
--cc=airlied@gmail.com \
--cc=ksummit-discuss@lists.linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox