Re: Implementing feature requests for a package when a maintainer doesn't respond
On Fri, 13 Jun 2025 10:06:30 + Holger Levsen wrote: > On Thu, Jun 12, 2025 at 02:42:33PM -0700, Soren Stoutner wrote: > > I would recommend you first create a bug and an associated MR. > > Then, if you get no response (which is obviously different than a > > NACK), you can choose if you would like to salvage the package or > > if you would like to leave the MR there for someone else who to to > > come along and salvage the package. > > https://tracker.debian.org/pkg/raspi-firmware doesnt give any > indication to me that the package is ripe for salvaging it. Hijacking > it you could, but you should not. > > Please don´t give bad advice on -devel. > > (The bug in question is wishlist and merely asks for a new way to > boot raspis giving some hints how this could be implemented but does > not contain a patch, but rather explains how there are two unsolved > problems with that suggestion Not quite, it explains why it is my solution doesn't just work with the existing package and why a patch (which I offer to implement) is needed. > and finally the bug is from end of April 2025 when the freeze was > already quite far advanced, so no wonder there was no reply.) That's a good point, I hadn't thought about freeze timing in relation to maintainer responsiveness. Still, I would have hoped for something along the lines of "This looks good, let's wait until after the freeze to do this", "I'm concerned about XYZ but otherwise this seems like a good idea", or even "I hate everything about this, what on earth are you doing?! If you really need X so badly, do it this way", despite the freeze, simply since that's what I'm used to from other maintainers in Debian that I've worked with. Near-total silence when contacted in three different ways feels like inactivity or at least low availability to me. Maybe my experiences with those other maintainers are the exception and not the rule though. (I've been an unresponsive maintainer before sadly, but that was because the darn bug mail system wasn't telling me when people reported bugs to me.) > I forgot another important reason why suggesting to salvage was a > really bad advice here: there was only one single mail to the bug, > not even just two, but just one. So it´s really premature to suggest > anything except please mail the bug again, probably with more info. What more info do you believe the bug could use? If I left something out, I'd love to know what, but I think all of the info is there except for a patch, and as I've explained above I was hoping for some feedback of some sort before sending a patch. Sending a second email to the bug is a good idea in general, but do keep in mind I reached out in four different locations with some time between some of the messages, so while there may only be one bug email, I did try more than once to reach the maintainer about this. Best regards, Aaron pgpFw5QmioHmJ.pgp Description: OpenPGP digital signature
Re: Implementing feature requests for a package when a maintainer doesn't respond
On Fri, 13 Jun 2025 07:36:41 +0200 Marc Haber wrote: > On Thu, 12 Jun 2025 14:31:02 -0500, Aaron Rainbolt > wrote: > >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. > > If you had written that two weeks ago I would have saved myself a few > days of work. I spent some time with u-boot on the Raspberry Pi 4 and > am just in the middle of preparing a blog post. > > Did you publish your work? Would you mind linking that publication on > the Debian Wiki Raspberry Pi 4 page? I believe that page already has a > place that says that booting grub through u-boot is possible. That > would be the right place to publish your work. You don't need any team > to cooperate to write about your results there. I did publish the work, but it's in a development wiki for a Debian derivative I help develop, and it's kind of buried: https://www.kicksecure.com/wiki/Dev/boot#Booting_Debian_Trixie_with_GRUB_.2B_u-boot_on_Raspberry_Pi_4 I wouldn't be opposed to making a blog post though, I have a Substack I could use. (I wouldn't want to use the wiki link since we're changing that wiki all the time and things are liable to get deleted pretty much on a whim as development progresses.) > Does your solution mean that the regular Debian ARM64 installer just > works on the Raspi? It does not unfortunately, that would require the Debian ARM64 netinstaller image to have the necessary U-Boot and GRUB binaries on the right partition for the Raspberry Pi to find them. It's not like the EDK2 solution where you install the firmware first and then install Debian. > Does the resulting system enumerate the hardware via ACPI or is > there a Device Tree? It uses the same device trees provided by the raspi-firmware package already. > How about having accelerated Graphics? Accelerated graphics should work, since the appropriate device tree overlay is loaded so the kernel driver can find the GPU. > What did you do to keep the raspi-firmware package from messing > around with /boot/firmware? That's the part I haven't done yet, I'm definitely able to do it but was waiting for a maintainer response before digging in. After this email thread though, I'll probably be working on it soon. Thanks for the feedback! :) Aaron > Thanks for caring about Debian on the Raspberry Pi! > > Greetings > Marc pgpSt8hlDZRiH.pgp Description: OpenPGP digital signature
Re: Implementing feature requests for a package when a maintainer doesn't respond
Hi Aaron, Quoting Aaron Rainbolt (2025-06-13 15:51:50) > > 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 mean this in a mean way, but I wish you had spent the time to read > the initial email all the way through or read through any of the first three > links before suggesting this. I said no fewer than four times that I *want* > to send a patch quite badly, and was waiting for there to be any kind of > discussion, ACK, NACK, or sharing of concerns from the maintainer or anyone > else with authority in the Raspberry Pi area of things. It's generally a > universal rule in open-source that before implementing a large change in an > open-source project, you discuss it with maintainers first, otherwise you end > up with code that can't be used. I was unable to get that discussion started > on my first attempt, thus why I emailed here. you are right. I apologize, I should've paid more attention when reading your messages. I think you picked the correct approach and I would like to retract the part from my last mail where I implied that you would not be willing to do the work. I'm sorry for the noise. > > I suppose (but understand if you are not motivated enough to do this after > > being "ignored" like this) that you would get more of a reply if you > > actually can show a patch which implements your work on top of the Debian > > packaging. > I'm more than motivated enough, and really if the first patch had to be > discarded for whatever reasons and completely reworked, I'd be OK with that > too. What I don't want is to send a patch and have it go as ignored as my > attempts at reaching out to the maintainer, so if I'm going to implement it, > I want to make sure there's a way forward to actually get it reviewed and > merged (assuming of course the thing I'm trying to accomplish isn't > fundamentally unacceptable to the reviewer(s)). I think your approach is sound. Thank you for offering to contribute and thank you for sticking around instead of giving up. > > Incidentally, I just enabled EFI booting for the MNT Reform images I > > maintain using systemd-boot. The MNT Reform also uses u-boot by default but > > the RK3588 supports EDK2 and we are currently performing experiments with > > it. Maybe we switch away from u-boot to some efi-based solution in the > > future. > That's neat! I like U-Boot in particular personally, but EDK2 sounds useful > too. I haven't experimented with EDK2 since my workplace isn't interested in > it, they want U-Boot to be used. (It also happens to be already used by > Fedora and I *think* Ubuntu, so it's been tested and verified to work for > this sort of thing.) Thank you for your work and sorry again for my accusation in my earlier mail. cheers, josch signature.asc Description: signature
Re: Implementing feature requests for a package when a maintainer doesn't respond
On Fri, 13 Jun 2025 10:18:59 +0200 Johannes Schauer Marin Rodrigues wrote: > 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 mean this in a mean way, but I wish you had spent the time to read the initial email all the way through or read through any of the first three links before suggesting this. I said no fewer than four times that I *want* to send a patch quite badly, and was waiting for there to be any kind of discussion, ACK, NACK, or sharing of concerns from the maintainer or anyone else with authority in the Raspberry Pi area of things. It's generally a universal rule in open-source that before implementing a large change in an open-source project, you discuss it with maintainers first, otherwise you end up with code that can't be used. I was unable to get that discussion started on my first attempt, thus why I emailed here. > I suppose (but understand if you are not motivated enough to do this > after being "ignored" like this) that you would get more of a reply > if you actually can show a patch which implements your work on top of > the Debian packaging. I'm more than motivated enough, and really if the first patch had to be discarded for whatever reasons and completely reworked, I'd be OK with that too. What I don't want is to send a patch and have it go as ignored as my attempts at reaching out to the maintainer, so if I'm going to implement it, I want to make sure there's a way forward to actually get it reviewed and merged (assuming of course the thing I'm trying to accomplish isn't fundamentally unacceptable to the reviewer(s)). > Incidentally, I just enabled EFI booting for the MNT Reform images I > maintain using systemd-boot. The MNT Reform also uses u-boot by > default but the RK3588 supports EDK2 and we are currently performing > experiments with it. Maybe we switch away from u-boot to some > efi-based solution in the future. That's neat! I like U-Boot in particular personally, but EDK2 sounds useful too. I
Re: Implementing feature requests for a package when a maintainer doesn't respond
On Fri, 13 Jun 2025 16:43:45 +0200 Johannes Schauer Marin Rodrigues wrote: > Hi Aaron, > > Quoting Aaron Rainbolt (2025-06-13 15:51:50) > > > 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 mean this in a mean way, but I wish you had spent the time > > to read the initial email all the way through or read through any > > of the first three links before suggesting this. I said no fewer > > than four times that I *want* to send a patch quite badly, and was > > waiting for there to be any kind of discussion, ACK, NACK, or > > sharing of concerns from the maintainer or anyone else with > > authority in the Raspberry Pi area of things. It's generally a > > universal rule in open-source that before implementing a large > > change in an open-source project, you discuss it with maintainers > > first, otherwise you end up with code that can't be used. I was > > unable to get that discussion started on my first attempt, thus why > > I emailed here. > > you are right. I apologize, I should've paid more attention when > reading your messages. I think you picked the correct approach and I > would like to retract the part from my last mail where I implied that > you would not be willing to do the work. I'm sorry for the noise. No problem, and I'm sorry for getting upset there. > > > I suppose (but understand if you are not motivated enough to do > > > this after being "ignored" like this) that you would get more of > > > a reply if you actually can show a patch which implements your > > > work on top of the Debian packaging. > > I'm more than motivated enough, and really if the first patch had > > to be discarded for whatever reasons and completely reworked, I'd > > be OK with that too. What I don't want is to send a patch and have > > it go as ignored as my attempts at reaching out to the maintainer, > > so if I'm going to implement it, I want to make sure there's a way > > forward to actually get it reviewed and merged (assuming of course > > the thing I'm trying to accomplish isn't fundamentally unacceptable > > to the reviewer(s)). > > I think your approach is sound. Thank you for offering to contribute > and thank you for sticking around instead of giving up. > > > > Incidentally, I just enabled EFI booting for the MNT Reform > > > images I maintain using systemd-boot. The MNT Reform also uses > > > u-boot by default but the RK3588 supports EDK2 and we are > > > currently performing experiments with it. Maybe we switch away > > > from u-boot to some efi-based solution in the future. > > That's neat! I like U-Boot in particular personally, but EDK2 > > sounds useful too. I haven't experimented with EDK2 since my > > workplace isn't interested in it, they want U-Boot to be used. (It > > also happens to be already used by Fedora and I *think* Ubuntu, so > > it's been tested and verified to work for this sort of thing.) > > Thank you for your work and sorry again for my accusation in my > earlier mail. > > cheers, josch Thanks for the encouragement :) I'll try to send another bug email like Holger suggested, then probably start implementation work once the freeze is over (or sooner than that, but won't expect any further movement until the freeze is over). Best regards, Aaaron pgpUwmuXafS_2.pgp Description: OpenPGP digital signature
Re: New contributor experience
Am Donnerstag, dem 12.06.2025 um 18:15 +0200 schrieb IOhannes m zmölnig: > eg the multimedia team (which I'm a proud member of) is really not very much > of a "team" (with people working *together* on a bunch of packages), at least > in my impression (which might be totally off). > in practice, it is more of a "lowNMU" team, and that's it. > I don't really see how there would be enough bandwidth to do actual mentoring > and stuff. > > other people might have similar experiences with other teams. Confirmed. The expectations concerning the meaning of the word "team" when coming from paid work are misleading. Sincerely, Joachim -- Papier ist gebundenes CO2. Bitte drucken Sie diese EMail aus und archivieren Sie sie.
Re: Implementing feature requests for a package when a maintainer doesn't respond
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 suppose (but understand if you are not motivated enough to do this after being "ignored" like this) that you would get more of a reply if you actually can show a patch which implements your work on top of the Debian packaging. Incidentally, I just enabled EFI booting for the MNT Reform images I maintain using systemd-boot. The MNT Reform also uses u-boot by default but the RK3588 supports EDK2 and we are currently performing experiments with it. Maybe we switch away from u-boot to some efi-based solution in the future. Thanks! cheers, josch signature.asc Description: signature
Re: Implementing feature requests for a package when a maintainer doesn't respond
On Thu, Jun 12, 2025 at 02:42:33PM -0700, Soren Stoutner wrote: > I would recommend you first create a bug and an associated MR. Then, if you > get no response (which is obviously different than a NACK), you can choose if > you would like to salvage the package or if you would like to leave the MR > there for someone else who to to come along and salvage the package. https://tracker.debian.org/pkg/raspi-firmware doesnt give any indication to me that the package is ripe for salvaging it. Hijacking it you could, but you should not. Please don´t give bad advice on -devel. (The bug in question is wishlist and merely asks for a new way to boot raspis giving some hints how this could be implemented but does not contain a patch, but rather explains how there are two unsolved problems with that suggestion and finally the bug is from end of April 2025 when the freeze was already quite far advanced, so no wonder there was no reply.) -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Make lying wrong again. signature.asc Description: PGP signature
Re: Implementing feature requests for a package when a maintainer doesn't respond
Hi, > I would recommend you first create a bug and an associated MR. Then, if you > get no response (which is obviously different than a NACK), you can choose if > you would like to salvage the package or if you would like to leave the MR > there for someone else who to to come along and salvage the package. I think this is the best advice. It is easy for anyone else interested in the package to discover there is a Merge Request on Salsa, and even the fact that a fork has been made on Salsa. If the maintainer is in active the various contributors are likely to come across each other's work on Salsa, which can then lead to collaboration and perhaps several people jointly (e.g. you and Mark) salvaging the packages if the original maintainer remains unresponsive.
Re: Implementing feature requests for a package when a maintainer doesn't respond
On Fri, Jun 13, 2025 at 10:06:30AM +, Holger Levsen wrote: > https://tracker.debian.org/pkg/raspi-firmware doesnt give any indication > to me that the package is ripe for salvaging it. Hijacking it you could, > but you should not. > > Please don´t give bad advice on -devel. > > (The bug in question is wishlist and merely asks for a new way to boot > raspis giving some hints how this could be implemented but does not contain > a patch, but rather explains how there are two unsolved problems with that > suggestion and finally the bug is from end of April 2025 when the freeze > was already quite far advanced, so no wonder there was no reply.) I forgot another important reason why suggesting to salvage was a really bad advice here: there was only one single mail to the bug, not even just two, but just one. So it´s really premature to suggest anything except please mail the bug again, probably with more info. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ The apocalypse is here now, it’s just not equally distributed. signature.asc Description: PGP signature
Re: Implementing feature requests for a package when a maintainer doesn't respond
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
