From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Mark Brown <broonie@kernel.org>
Cc: ksummit <ksummit-discuss@lists.linuxfoundation.org>
Subject: Re: [Ksummit-discuss] vague topic for maintainers summit
Date: Mon, 09 Sep 2019 13:01:07 +0100 [thread overview]
Message-ID: <1568030467.6613.19.camel@HansenPartnership.com> (raw)
In-Reply-To: <20190909115338.GD2036@sirena.org.uk>
[-- Attachment #1: Type: text/plain, Size: 1991 bytes --]
On Mon, 2019-09-09 at 12:53 +0100, Mark Brown wrote:
> 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.
Actually, I find the inherited code part easier because usually the
person pushing it isn't wedded to someone else's design and is happier
to do a rework because it makes it more their code. My biggest problem
has been with the original author trying to push their design as the
only possible way and then trying to bring corporate pressure to bear
when it became clear this wouldn't be accepted.
> 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.
Trying to explain that it's a maintenance and consistency issue more
than anything else does seem to help.
James
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
next prev parent reply other threads:[~2019-09-09 12:01 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
2019-09-09 12:01 ` James Bottomley [this message]
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=1568030467.6613.19.camel@HansenPartnership.com \
--to=james.bottomley@hansenpartnership.com \
--cc=broonie@kernel.org \
--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