Le ven. 22 août 2025 à 22:35, Otto Kekäläinen <o...@debian.org> a écrit :
> 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. > Another example of MR that is closed: https://salsa.debian.org/js-team/node-typescript/-/merge_requests/4 Despite all the noise, someone took the time to do this [image: image.png] and this is the nicest thing I can ask for now.
