[Ksummit-discuss] vague topic for maintainers summit

[Ksummit-discuss] vague topic for maintainers summit

[Dave Airlie]

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.

Dave.

Re: [Ksummit-discuss] vague topic for maintainers summit

[James Bottomley]

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

Re: [Ksummit-discuss] vague topic for maintainers summit

[Mark Brown]

[-- 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 --]

Re: [Ksummit-discuss] vague topic for maintainers summit

[James Bottomley]

[-- 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 --]

Re: [Ksummit-discuss] vague topic for maintainers summit

[Mark Brown]

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

On Mon, Sep 09, 2019 at 01:01:07PM +0100, James Bottomley wrote:
> On Mon, 2019-09-09 at 12:53 +0100, Mark Brown wrote:

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

Yeah, both are issues - the corporate one is usually basically a
"we've decided we need to get this done in X timeframe" or a "we
have a massive investment in testing that we couldn't possibly
repeat without which any other solution much worse" so it goes
beyond the individual developer.  The developers might be happy
to do the reworks (they sometimes thank me offline for saying
what they've been saying internally already) but are being told
to push the existing code.

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

Those problems do tend to be a bit easier to get over to the
management people.

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