On Sun, Aug 17, 2025 at 12:54:14AM -0700, Otto Kekäläinen wrote: > > I am in fact mentoring two out of the nine GSoC students we have, plus > a dozen other new contributors as part of regular mentoring under the > Debian mentoring umbrella. One of my GSoC students posted a MR to > update a package to the latest version on June 6th, which I reviewed > on June 7th and commented on again that my plan is to upload it once > Trixie is released. On August 10th another DD pushed updates to the > Salsa repository and uploaded it.
It sounds like this is more of an issue of communication between the packages's maintainers/uploaders, no? I can see ways that this could be automated; for example, a MR could be tagged that it has already been reviewed, and one could imagine systems that would autoamtically file a bug in BTS when some trigger condition is met, so once Trixie is released, a bug could be filed indicating that the following MR's should be processed. > As a very senior engineer, it would be helpful if you expressed > support that checking MRs is good general advice in Debian, and others > should do it, even if you personally don't do it. This could help > improve the overall culture in Debian that checking MRs is valued, and > new contributors publishing their work as branches on Salsa that are > visible in MRs in the projects they target is a good thing. But I don't agree that this is a cultural change which is a good thing. I have served in leadership roles for a variety of volunteer organizations for decades, and one of the things that my mentor taught me at the very beginning of my career is that as a volunteer leader, all you can do is stop something from happening. Hopefully, you're only stopping bad things from happening, as quality control; but you can not *command* that something happen. Being a leader of a volunteer organization is very different from being an executive at a company. Debian, as a volunteer organization, has a large number of volunteers that have their own workflow. You can't force people to adopt your favored workflow (e.g., using MR's for everything). In the worst case, this will inspire a backlash where people explain all of the problems with a particular workflow. So trying to force something to happen not only won't work, it can end up being counter-productive. What I would suggest instead is that we allow packages to document what their advised contribution policy should be. For example, for the Linux kernel there is a very detailed documentation of how to contribute (and note that the words "pull request" or "merge request" appear nowhere in said document): https://docs.kernel.org/process/submitting-patches.html Suggestions that people simply disable Salsa MR's is a form of documentation. It's a bit of a blunt way of doing things and doesn't encourage other variants (e.g., submit a MR and then also file a bug in the BTS), but at least it is documenting that submitting a MR isn't the way to go, at least for a particular package. A counterargument to this might be that it would be better if there was one standardized way that anybody can contribute to any Debian package. This might be nice, and it might work inside a company. But in a volunteer organization that's tantamount to trying to force all volunteers to adopt a specific workflow, and in my opinion, that is not likely to be a path to success. - Ted
