Hi Andrew, This particular issue revolves around enabling a feature by default in the DSC for Pi 3/4 platforms - the TFTP Shell command. Clearly, enabling this for Pi bears no effect on other Tiano platforms. So far I've heard something about the TFTP code being somehow bad, but what does that have to do with the Pi platform using it? If it's bad, delete it from Tiano. Or rewrite it. .../last/ time we got into a spat about the value of revving the Pi ACPI to 6.3 (the ACPI support we contributed in the first place). So that patch just got ignored. Not even sure what to do about that one... 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 Sent: Sunday, April 19, 2020 8:03 PM To: devel@edk2.groups.io ; Andrei Warkentin Cc: Pete Batard ; Ard Biesheuvel ; Samer El-Haj-Mahmoud ; Leif Lindholm Subject: Re: [edk2-devel] [edk2-platform][PATCH v1 0/4] Platform/RaspberryPi : Enable TFTP shell command -100 since we don't use a points system :). The process is if the maintainers can not agree we let the Stewards decide. The next Stewards meeting is May 5th, so in the mean time we can try to reach consensus as that is our preference for a process. Maybe it would be useful to summarize the issue and state the pro and cons? Thanks, Andrew Fish