Hi Otto, On 14/08/25 at 10:07 -0700, Otto Kekäläinen wrote: > Hi! > > I encouraged DDs and DMs to review open Merge Requests on Salsa back in > January: > https://lists.debian.org/debian-devel/2025/01/msg00267.html. Hopefully > folks can continue with doing reviews! > > > ## Priority: Check MRs for your own packages > > Please remember to check if your package has open MRs *at least once* > before the next upload! > > I have now witnessed several cases where a maintainer blatantly > ignored the MRs their package received. It is demotivating to new > aspiring Debian contributors to put in significant effort to learn the > complexities of Debian packaging and submit an improvement, only to > see that the maintainer two months later didn't look at the MR at all, > and instead implemented the same change themselves, and the > submitter's work essentially got wasted. > > You can check open MRs from the command line with `salsa > merge_requests` > (https://manpages.debian.org/unstable/devscripts/salsa.1.en.html) if > you don't like checking the Salsa project page.
What I'm really missing here is the global picture of how this (= uses of Salsa beyond just using a Git repository) fits in Debian workflow_s_. Just saying "you can check open MRs from the command line with `salsa merge_requests` if you don't like checking the Salsa project page." is not very useful. There are developers who maintain a small number of large packages, and developers who maintain a large number of small packages. There are developers who prefer push-based notifications using email (and then use their mailbox as a To-Do list), and developers who prefer dashboard services[1] to get a new overview of what they need to look at. [1] Mostly https://qa.debian.org/developer.php, https://udd.debian.org/dmd/ (both per-maintainer/team) and https://tracker.debian.org/ (mainly per-package) those days. All this is reasonable and meets real needs. As you care about better integration of Salsa in Debian workflows, I think that you should review what is the current integration level, and how it can be improved. Some random ideas of things that could be worked on: Data about MRs and Issues is currently collected to all dashboard using a service called vcswatch (https://qa.debian.org/cgi-bin/vcswatch). UDD also has its own importer for stuff that isn't covered by vcswatch (https://salsa.debian.org/qa/udd/-/blob/master/rimporters/salsa.rb?ref_type=heads ; https://udd.debian.org/salsa/). Could this be improved? vcswatch only checks packages every few days, and UDD does it once per day. Could they refresh more frequently? real-time updates? Email notification from Salsa sucks. Maybe Salsa could be configured on the admin side to send all notifications to some email address, and then we could have a small re-dispatcher service that would forward those notifications to interested maintainers? tracker.d.o already has an email subscription/notification service that could maybe be leveraged. The important thing to remember is the difficult use case of teams that have thousands of low-activity packages. This was mentioned in the thread, but tracker.d.o doesn't know of Salsa MRs. I've been working (on the UDD side) on providing a way to check and uniformize Salsa configurations across packages maintained by a team (see https://udd.debian.org/salsa/?email1=pkg-ruby-extras-maintainers%40lists.alioth.debian.org&email2=&email3=&packages=&ignpackages=&format=html&branches=on&gitlabci=on&gbpconf=on&pipeline=on , which is still a bit experimental/WIP at the moment). I understand the salsa CLI tool also helps with that. It would be useful to survey current practices by teams, and share good ideas, tooling, etc. What is the recommended way of using Salsa MRs for changes that involve several branches (such as packaging a new upstream version)? Lucas
