Hi Andrew,

I don't know, the maintainers may in fact be in perfect agreement (I certainly do not know) - but certainly at odds with actual developers. So, there appears to be a problem with the way edk2-platforms is run. Or at the very least, I don't understand why it's run the way it's run.

The RPi3/4 support is developed by a group of folks (https://rpi4-uefi.dev, https://github.com/pftf). These folks (from Arm, from VMware, or unaffiliated) all follow their own goals, with some alignment, but there's overall consensus that working upstream is A Good Thing and is worth the effort. We loosely  coordinate with each other (Discord, have a bug tracker, etc). However, it seems that every patch we propose, to a code base that we largely wrote and chose to upstream into edk2-platforms, gets put under the microscope. That would be fair and square when we're talking about changes to shared components, or code that for technical reasons (quality or design) does not fit the implementation/design goals of Tiano. However, what ends up happening is _maintainers_ taking arbitrary decisions, contrary to the community of developers behind the port. As a final say. I don't mean an abstract mute community of developers. I mean the folks that specifically do all development today for Tiano on Pi platforms. We have no control. We have no say. Maintainers are certainly developers, and may have a stake and interest in the code being reviewed, but at the end of the day they are maintainers - they need to abstract away and agree to disagree on matters that are subjective and opinion-based.

Why are maintainers making these calls? We brought these platforms into your garden because we were sold on the idea. Let us water them and take care of them together. Instead, everything we do gets frisked with a strip search. We have to spend our time constantly proving the value of our work instead of using that very little valuable time we have to actually move the Pi support forward.

The outcomes are pretty serious. If you ask folks in the Arm community, they'll tell you "upstream first", and specifically cite lack of firmware being upstreamed as being a serious problem. However, the way edk2-platforms is structured, that goal is literally unobtainable because edk2-platforms development doesn't scale, as all code gets funneled through the few maintainers. I mean, why would anyone choose to upstream to edk2-platforms? For the lack of positive reinforcement? For the tedious process with no light at the end of the tunnel? It turns developers away. It makes folks feel unvalued and disenfranchised. You get to burn the midnight oil - pro bono - into something only to have others tell you that you should have done something else or just get your proposals ignored. It's not really a community - our choices, our code and our desire to CONTRIBUTE and BE RESPONSIBLE for a proper polished UEFI experience on the Raspberry Pi are worth absolutely nothing here.

Why does a maintainer have any say over platform-specific code, where there is developer consensus on the trajectory and there are no over-arching technical concerns? Why can't individual platforms have their own maintainers?

A

From: Andrew Fish <afish@apple.com>
Sent: Sunday, April 19, 2020 8:03 PM
To: devel@edk2.groups.io <devel@edk2.groups.io>; Andrei Warkentin <awarkentin@vmware.com>
Cc: Pete Batard <pete@akeo.ie>; Ard Biesheuvel <ard.biesheuvel@arm.com>; Samer El-Haj-Mahmoud <samer@elhajmahmoud.com>; Leif Lindholm <leif@nuviainc.com>
Subject: Re: [edk2-devel] [edk2-platform][PATCH v1 0/4] Platform/RaspberryPi : Enable TFTP shell command