[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

Attachment: signature.asc
Description: signature


Reply to: