Re: [PATCH 19/19] ArmPlatformPkg: New DP500/DP550/DP650 GOP driver.

[Evan Lloyd <Evan.Lloyd@arm.com>]

Hi Ard.

> -----Original Message-----
> From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org]
> Sent: 05 December 2017 21:28
> To: Evan Lloyd <Evan.Lloyd@arm.com>
> Cc: edk2-devel@lists.01.org; Matteo Carlini <Matteo.Carlini@arm.com>;
> Leif Lindholm <leif.lindholm@linaro.org>; Girish Pathak
> <Girish.Pathak@arm.com>
> Subject: Re: [PATCH 19/19] ArmPlatformPkg: New DP500/DP550/DP650
> GOP driver.
>
> On 5 December 2017 at 20:03, Evan Lloyd <Evan.Lloyd@arm.com> wrote:
> >
> >
> >> -----Original Message-----
> >> From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org]
> >> Sent: 01 December 2017 17:19
> >> To: Evan Lloyd <Evan.Lloyd@arm.com>
> >> Cc: edk2-devel@lists.01.org; Matteo Carlini <Matteo.Carlini@arm.com>;
> >> Leif Lindholm <leif.lindholm@linaro.org>; Girish Pathak
> >> <Girish.Pathak@arm.com>
> >> Subject: Re: [PATCH 19/19] ArmPlatformPkg: New DP500/DP550/DP650
> GOP
> >> driver.
> >>
...
> >> >
> >> >> whatsoever. If you introduce any library classes that abstract
> >> >> away the differences between platforms, you can include a Null
> >> >> version of such a library that simply does ASSERT (FALSE) in every
> function:
> >> >> this
> >> >
> >> >  [[Evan Lloyd]] One could, indeed, do that.  We, however, would be
> >> > very
> >> reluctant to incur the overhead of rework in response to spurious
> >> cavils from a maintainer when it is of no direct relevance to us.
> >> >
> >>
> >> I don't think the suggestion that we evil maintainers are nothing but
> >> an impediment to the likes of you and your team members doing the
> >> actual work is justified.
> >>
> >> We are all on the same team here, and the goal is to make UEFI code
> >> reusable for the customers of /your/ employer. Throwing stuff over
> >> the fence != upstreaming, and it is my job as a maintainer to ensure
> >> that code is still maintainable long after the original authors have
> >> moved on to something else.
> >>
> >> ArmPlatformPkg is a perfect example where code reuse is much more
> >> difficult than it needs to be, and we as maintainers need to deal
> >> with contributors from other companies that have used it as
> >> 'guidance' for how to architect their UEFI firmware, which is usually
> >> filled with vexpress-isms that date back to before anyone currently
> involved with UEFI can remember.
> >>
> >> This is why I have taken the time to sit down, go through all the
> >> crap code, clean it up, refactor it and propose it on the list as
> >> improvements. I even went so far as taking the preparatory Mali work
> >> of your team and rebase it so that we can keep the bits that we may
> >> share, and move the bits out that should not be kept in main EDK2
> >> because they are being taken as gospel by engineers that are new to
> >> ARM+UEFI.
> >>
> >> If this is too much to deal with for you, then fine, don't upstream your
> code.
> >> But if you do, you are going to have to play nice with the others,
> >> including the maintainers.
> >>
> > [[Evan Lloyd]] Hi Ard.  Firstly, I apologize, I assumed from your name that
> you were Dutch and would therefore probably have a lively sense of
> humour.  Of course, if I have touched a nerve, that is unfortunate and I'm
> sorry.
>
> No, the apparently blatantly obvious tongue-in-cheek nature of your
> response was completely lost on me. But I know a person who does have a
> lively sense of humour, so next time I will ask him for help.

 [[Evan Lloyd]] I would like to extend my apology.  From comments others have made it is apparent that my wording was too easily interpreted as just offensive.  I shall try and resist the temptation to make such points with dubious attempts at humour in the future, at least on fora like this where they are out of place.  Het spijt me.

>
> > I agree that cleaning up the code is important, worthwhile, and an
> objective for us all.  What can be a difficulty is our very different
> conceptions of what clean means.
> >
>
> Fair enough. But as maintainers, we take ownership of your code, with the
> implied promise to keep it in a working state. I don't think it is
> unreasonable that we get to dictate some of the terms under which that
> occurs.
>
> > You should be aware though that a certain amount of whingeing is to be
> > expected when dealing with Brits. (Ask Leif - he knows! Or any Australian.)
> I do not disagree with your intent - but I do sometimes feel that the criteria
> applied do not take into account the cost/benefit aspects, and seek to air
> that point.  I shall endeavour to make such points in a less bantering way in
> future.
> >
>
> Thanks.
>
> I think one of the misconceptions may be that upstreaming is something
> one does once the code is completely finished. Instead, please involve us
> much sooner if you intend to upstream your code (or just Leif for
> confidential stuff). That way, any effort invested in the code benefits your
> product as well as the open source, rather than shipping one version, and
> having to go back and change stuff for the version that ends up upstream.
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.