Johannes Schauer Marin Rodrigues, 2025-06-13 10:18 +02:00: > Hi Aaron, > > Quoting Aaron Rainbolt (2025-06-12 21:31:02) >> Some time ago, I did a lot of work on getting a U-Boot + grub-efi-arm64 >> boot flow to work on the Raspberry Pi 4 with Debian. I was able to get >> a proof-of-concept implementation to work correctly, and was interested >> in upstreaming my work to Debian if it was welcome. To that end, I >> attempted to reach the team taking care of Raspberry Pi support >> maintenance in Debian in a few different ways. [1] [2] [3] [4] So far I >> haven't gotten much of a response on any platform. >> >> Obviously, I would like to see this feature in upstream Debian at some >> point, which is why I did the work to see if it could be done. I'd like >> to send patches to implement the feature. However, since I haven't >> gotten any response (no explicit "this would be good, send a patch and >> let's see what you have", no criticism or discussion, etc.), I don't >> know how to proceed. I don't want to submit a patch and have it ignored >> similar to the research and feature requests up to now. I also don't >> want to just wait indefinitely before implementing patches. >> >> I know that for bugfixes, the NMU process can be used to work around an >> unresponsive maintainer, while still giving the maintainer time to take >> a look and fix things if they'd like to. But for this kind of a feature >> addition, I don't know if this is the right approach. As the Debian >> Developer's Reference [5] says, "Using NMUs to make changes that are >> likely to be non-consensual is discouraged." >> >> What's a good way forward here? Am I trying to do something that >> fundamentally shouldn't be done, or is there a good way for me to >> contribute this feature? >> >> [1] https://lists.debian.org/debian-arm/2025/04/msg00012.html >> [2] https://salsa.debian.org/raspi-team/image-specs/-/issues/78 >> [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1102607 >> [4] Also reached out via IRC, didn't get much of a response except one >> person let me know about the existence of another UEFI >> implementation for Raspberry Pi devices. >> [5] >> https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#when-and-how-to-do-an-nmu > > thank you for your work! I see that the mails, the issue and the bug report > you > opened did not get much of a reply and I agree that that's not ideal. On the > other hand, you also did not send a patch. I realize that you linked > instructions you created to implement what you propose but you actually didn't > implement it, no? So maybe (and i can only guess) your bugs and issues did not > result in much of a reply because even though you showed a proof-of-concept, > it > still requires somebody to actually do the work. And if that's the case, your > issues are just asking others to carry out that work. I realize that this is > frustrating for you but the maintainers are volunteers just as you, so maybe > they have not yet found time to look into your instructions, implement and > test > your work?
I don't understand how Aaron messages created the impression that he is "just asking others to carry out that work". From [1]: > With all of the above in mind, how likely would it be that U-Boot + > GRUB support for the Raspberry Pi could be upstreamed into Debian, > perhaps even as the default boot flow for the Raspberry Pi 4? We'd be > interested in helping out in this regard if this is something others > here would be interested in having. [3]: > I would like to suggest (and if acceptable, contribute) the following > two features: [...] [2]: > Is this a feature for which you would welcome a merge request here, > either as an option or even as the default? To me this sounds very much the oposite. Many projects explicitly request to discuss non-trivial changes upfront. And even if not explictly requested that sounds like a good idea in general.
OpenPGP_signature.asc
Description: OpenPGP digital signature
