ksummit.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: ksummit <ksummit-discuss@lists.linuxfoundation.org>
Subject: Re: [Ksummit-discuss] vague topic for maintainers summit
Date: Mon, 9 Sep 2019 12:53:38 +0100	[thread overview]
Message-ID: <20190909115338.GD2036@sirena.org.uk> (raw)
In-Reply-To: <1568025855.6613.5.camel@HansenPartnership.com>

[-- Attachment #1: Type: text/plain, Size: 1327 bytes --]

On Mon, Sep 09, 2019 at 11:44:15AM +0100, James Bottomley wrote:

> 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

I've definitely faced this in various forms, mostly coming from
companies in the embedded space.  It feels like it's got better
over time as companies have become less prone to going on
substantial out of tree adventures but it's still there.

> 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.

That's often a corporate problem as well, if the company has a
big investment in whatever approach or codebase they have they
may not want to spend the time on substantial rework.  Often it
seems fairly clear that the people doing the upstreaming have
inherited something from other engineers rather than having done
the design and original implementation themselves.  In my more
embedded experience I'd say that the corporate investment is a
more common issue than developers.

I'm not sure I have any particularly bright ideas other than
being clear with people about what the issues are and asking for
clearer explanations of what's being done and why it's different
to everything else.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2019-09-09 11:53 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
2019-09-09 11:53   ` Mark Brown [this message]
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=20190909115338.GD2036@sirena.org.uk \
    --to=broonie@kernel.org \
    --cc=James.Bottomley@HansenPartnership.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