Re: Please check open Merge Requests before your next upload
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
Reply to: