Le Thu, Aug 14, 2025 at 11:00:53PM -0600, Antonio Russo a écrit : > (…) > When I run in to a problem in Debian, I try to follow a rough pattern: > > 1. I identify a suspect package, and diagnose a cause. > 2. I identify a solution. > 3. I implement the solution, recompile, and confirm it solves the problem. > 4. I submit the solution (either upstream or to Debian). > > Part of step (4) involves writing prose that documents the investigation > and describes the patch. > > If I am understanding this email correctly, it sounds to me like you > are saying that this is a "code dump" because I didn't email you first. > > Am I understanding you correctly? Yes, that’s correct. I should be contacted even before step 2., as a simple matter of respect actually. If not, how is the potential contributor knowing I am not going to waste time on something they too are planning to fix? I think coordination is very important for both software development and packages maintenance, and it can not happen if communication is skipped or only happens after the fact. Of course I can make exceptions on a case-by-case basis, like an e-mail coming with a trivial, consensual patch. But even in such cases I’m going to ask the contributor to do things better next time, and respect that simple rule if they want to work with me: communication first, code only second. > This is very important to me because I have several open bug report > with patches that perhaps are being disregarded for this very reason, > and I'd like to understand how I can get people to look at them. > > Would I need to close them and restart the whole process to get your > attention? No, that would be silly. What I want is communication, not bureaucracy. I don’t care that contributors do not get the process right immediately, I’m going to explain it to them if required. And I am *not* going to ask them to start a contribution from scratch just for fun.
Attachment:
signature.asc
Description: PGP signature