On Thu, Aug 14, 2025 at 5:23 PM Antoine Le Gonidec <vv...@debian.org> wrote: > > Le Fri, Aug 15, 2025 at 03:08:20AM +0530, Nilesh Patra a écrit : > > Opening PRs/MRs are typically how most of the git forges are used for > > contributions. > > I have been using many of these forges for a decade and a half, I even > self-hosted a GitLab instance for far too many years, and have been part > of the Debian GitLab team bringing Debian stable users the ability to > install GitLab through FatsTrack. So I know quite well how the PR/MR > workflow works ;) > > > Having salsa and allowing to open MRs and then saying that you will accept > > a patch > > only if you file a bug report via BTS with proper tags is somewhat an > > anti-pattern. > > > > Opening an MR here *is* a way to communicate with you. Mailing you > > separately is adding > > another layer to that communication which I think I do not understand. > > Sending a mail/mentioning > > on MR makes sense if it does not come into notice or the maintainer forgets > > about it. > > Opening an MR without having contacted me *prior to the fact* is the > definition of a code dump. I do not care about code, I can very well > write it myself in the first place.
I don't think a lot of people realize this since MRs come with a text field for placing a description/rationale/whatever of the code itself. One might reasonably think "why would I waste this person's time making them read things in two different places, I'll just put all the rationale and whatever in the pull request and they'll see it". I've been guilty of that exact line of reasoning, and only really care to file a bug or send an email or whatever first if I know project policy expects that. I know Debian expects that and so I do it by default, but for other projects, I really might just send a patch and be done with it. Heck, at my workplace, we don't even bother with MRs most of the time, we just do "push to your fork and ping your boss so he can fetch the code", so unless the expectation is communicated, people can and will mess this up. (This isn't about "ease of entry", arguably contributing *should* be tricky so that only people who are dedicated enough to figure out the right buttons to press can submit contributions in order to avoid low-effort contributions, this is just about efficiency and properly communicating policy.) > What I care about is people, especially people who want to fix or > improve a package I am working on. But if they refuse to communicate and > only want to interact by silently sending patches, we can not work > together. > > If sending an e-mail is too much for them, well, too bad, they were not > all that interested in improving the package in the first place to stop > at such a trivial requirement. > > Maybe we need some debian/contributing file to make the contribution > rules explictit? Or maybe this could be a pertinent (ab)use of > debian/README.source? At least that way people who can’t stand the > effort of sending an e-mail (or an IRC ping, or even a message on XMPP, > I don’t care about the channel) prior to any kind of code contribution > would know there is no use wasting their time on packages I maintain. That sounds like a good idea at least to me. That would help people like myself know for sure that the maintainer really does want me to contact them via method 1 if I'm going to submit code via method 2. That also would allow maintainers that don't want to deal with Salsa for whatever reason to request patches to be sent by email only.
