Hi! On Sun, 17 Aug 2025 at 05:57, Theodore Ts'o <ty...@mit.edu> wrote: > 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?
Yes, one can always blame that the submitter didn't communicate enough, but then again it was an orphaned package and the person uploading did push to git before uploading so they did know a repository exists. They just missed checking that a MR was pending. Most people who are new to Debian do have some experience with other open source projects, and on GitHub it is common that posting a PR is itself enough communication, and people don't send separate emails to the upstream maintainers announcing that a PR has been posted. I would argue that in Debian the fact that a MR was posted is already a form of communicating, it is just not that widely respected/noted, as the Debian culture for using MRs for collaboration is still new. > 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. Maybe we can have more of this, but note that we already have at least 7 avenues for the information about an open MR can reach the maintainer: https://wiki2025.debian.org/wiki/Salsa. I think this ultimately boils down to people who dislike Salsa vs others. Seeing that you host none of your packages on Salsa I am not surprised you are not keen on the topic of looking at MRs, and I respect that, but for the rest of the crowd, I still want to remind checking for potential open MRs. > > 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 Just to clarify, you don't think it is good to have a culture in Debian that maintainers tend to check for open Merge Requests? The rest of the paragraph was about something else. > 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 This might again be a language/culture difference, but I don't view myself as forcing anything by just sending a reminder/request on the mailing list. In my view to be able to force something one needs to have the ability to assert power on something. I am not a member in any of the Debian delegations that control the Debian archive, releases or policies, and I don't hold any power to decide on anything else than my own packages. I am just championing Merge Requests as a nice way to collaborate with mailing list emails. > 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. Actually I like reading those problems. It helps me understand what the experience of others is, and in some cases being aware of the problem leads to changes that solves the problems. This thread also inspired me to write https://optimizedbyotto.com/post/debian-salsa-merge-request-best-practices/ > 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 This is a famous example and I followed it myself 15 years ago when I did my only kernel contributions. Nowadays the "industry standard" is to have a CONTRIBUTING.md in the git project root. This works well for independent and large projects. For Debian packages I think it would be problematic if every ~40k package had its own debian/CONTRIBUTING.md or debian/README.source(.md) with custom workflows, as it would increase the cost for a new contributor to increase the number of packages they contribute to. But perhaps these mailing list discussions lead to identifying 5-10 workflows and then packages can be explicit about which one of them they follow. > 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. In my experience, the number of MRs received per package is quite low, so turning it off completely and signaling you don't want to have any MRs seems a bit harsh towards new contributors. > 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. Other distros have been able to agree on workflow changes and more unified workflows than Debian. An even Debian does have examples of its own, like moving to Debhelper 15 years ago. I don't think being a volunteer organization necessarily puts us in an inferior situation. It's just that the decision making process is different, and we need to arrive on them by multi-year mailing list discussions and parallel work on tooling and documentation that makes the workflows better and compatible with all use cases. Thanks, Otto
