Hi, On Sun, 17 Aug 2025 at 19:33, Theodore Ts'o <ty...@mit.edu> wrote: > On Sun, Aug 17, 2025 at 02:44:06PM -0700, Otto Kekäläinen wrote: > > In the web interface you can suggest changes that automatically become > > patches on the branch, which the original submitter can easily clean > > up / integrate next time they rebase/refresh the MR. > > My point was that it takes a lot more effort, and time, to tell the > submitter what to change, and then (a) wait for them to make the > change, and (b) hope they make the change correctly. If they don't > then you have to repeat, possily multiple times.
Yes, I know it takes more effort to write to a contributor and wait for them to finalize things compared to the receiver simply highjacking the idea and finalizing it straight away. But please consider the contributors' point of view too and how much effort something took them. Let me share a story about something that happened this week. A person I am mentoring had been planning to contribute to Debian for a long time. I suggested they start small by for example fixing a bug in an existing package (as doing a new upstream import or a completely new package is a lot more work and has steeper learning curve). My mentee found a bug in a package they use, the researched it well and found the correct solution and posted it as a MR on the package on August 7th. I reviewed it on August 8th and concluded that it looked correct to me, but since it was an actively maintained package I asked the maintainer to say the final word as pushing it directly without coordination is not that collaborative, even though technically I could have done it as this was a package in /debian/ namespace on Salsa. On August 19th the maintainer closed the MR. He thanked the submitter for it but decided that merging or was too much effort after he did other changes on the main branch, so he just went ahead and did the exact same change himself to save time/effort for himself. End result is that this new contributor did not get his name in the git commit log, his Salsa profile does not show that he has any successfully merged MRs (even thought he change was fully correct and identical to what the maintainer did), the contributor won't find his name in the changelog nor get anything accumulated at https://contributors.debian.org/contributor/<name>. So all the effort the submitter did - and also me as mentor - was in vain. This is not the end of the world, but I wanted to share it as an anecdote of the new contributor experience. > You could just make the change yourself, and then do a "git commit > --amend", but then the MR won't get closed automatically, becaue the > forge won't recognize the modified commit. And if you do a "git > commit" instead ofa "git commit --amend", then you break bisectibility > of the git tree. > > Yes, you could then close the commit manually, but now it's more work > than the e-mail based workflow. If think giving feedback and letting the submitter finalize the thing will help them feel more ownership, but if you do decide to just quickly do it yourself, you can actually edit the Merge Requests on Salsa (and Pull Requests on GitHub). The official documentation is at https://salsa.debian.org/help/topics/git/forks.md#push-to-a-fork-as-an-upstream-member but it is a bit hard to understand without an example. I will try to write a post about this with Debian examples in my blog soon. - Otto
