Re: On using Merge Requests on Salsa (Re: debian/watch version 5)
Hi!
On Sun, 17 Aug 2025 at 05:57, Theodore Ts'o <tytso@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
Reply to: