My preference to use Merge Requests and examples of them in practice for both package updates and new packages
- To: Jianfeng Liu <liujianfeng1994@gmail.com>, Giacomo Paviano <pavianogiacomo@gmail.com>, Leonardo Arias Fonseca <agami@riseup.net>, Vincent Blut <vincent.debian@free.fr>, Debian-Go Mailing List <debian-go@lists.debian.org>
- Cc: Aayush Raj <meet44yu5h@gmail.com>, Nilesh Patra <nilesh@iki.fi>, aquilamacedo@riseup.net, Maytham Alsudany <maytham@debian.org>, Andrea Pappacoda <andrea@pappacoda.it>, "Loren M. Lang" <lorenl@north-winds.org>, Nicolas Peugnet <nicolas@club1.fr>
- Subject: My preference to use Merge Requests and examples of them in practice for both package updates and new packages
- From: Otto Kekäläinen <otto@debian.org>
- Date: Thu, 31 Jul 2025 14:55:57 -0700
- Message-id: <[🔎] CAOU6tAC80kDNf=KsuMcM+ecWWkRY5Gzpkn3wYXBnKNZH==vvyg@mail.gmail.com>
Hi all whom I have been mentoring or otherwise discussing this topic with,
While mentoring multiple people in 2025 I have noticed that reviewing
Debian packaging, both for updates of existing packages and creation
of new packages, is by far most convenient if there is a Merge Request
on Salsa.
It is very easy for me to look at a MR, write my feedback, wait a
couple of days, check new changes, respond and rinse and repeat until
everything is ready. Open MRs stay on my "TODO list" and I don't
forget anything. If there *is no MR* and I am forced to send feedback
by email or by adding comments to the main git HEAD branch commits, it
quickly becomes confusing to re-check and re-review things, in
particular when trying to mentor multiple people working on dozens of
pacakges.
Thus my request to everyone I mentor or who otherwise on the Go team
wants to have my reviews: please have a workflow that leads to a Merge
Request on Salsa.
This should be fairly easy. For example Vincent submitted a package
update as MR in
https://salsa.debian.org/go-team/packages/fzf/-/merge_requests/6.
Jianfeng submitted a new package in
https://salsa.debian.org/go-team/packages/apt-transport-oci/-/merge_requests/4
and Leonardo likewise in
https://salsa.debian.org/go-team/packages/golang-github-offchainlabs-go-bitfield/-/merge_requests/2.
I am sharing this as examples you can look at.
Even better, to make repeating this super easy, I filed "mock MRs"
with every single step and command documented:
* https://salsa.debian.org/go-team/packages/golang-github-holiman-uint256/-/merge_requests/1
* https://salsa.debian.org/go-team/packages/golang-github-gonvenience-idem/-/merge_requests/1
* https://salsa.debian.org/go-team/packages/dyff/-/merge_requests/1
If you follow this pattern and file a MR in the Go team, feel free to
add me as the reviewer!
I can also review non-MR work, but I am just saying that if it is an
MR, it is much easier for me personally.
I am checking my dashboard at
https://salsa.debian.org/dashboard/merge_requests?scope=all&state=merged&reviewer_username=otto
on daily basis and promise to review and re-review all MRs quickly.
- Otto
PS. In particular with new Go packages we often discover upstream
bugs. I also encourage people to submit fixes to them upstream as soon
as possible, and you can ping me 'ottok' on GitHub/GitLab on those
upstream submissions to help champion them. Easy upstream submissions
is also why I advocate use of the git-buildpackage 'upstreamvcs' and
'gbp pq' features. More at
https://optimizedbyotto.com/post/debian-packaging-from-git/
Reply to: