Re: My preference to use Merge Requests and examples of them in practice for both package updates and new packages

[Otto Kekäläinen <otto@debian.org>]

Hi all,

I just wanted to remind that I have capacity to review more Go package
work, and I feel in particular efficient if I get stuff to review as
Merge Requests on Salsa as it is so easy to test, comment and later
re-review.

In the Go ecosystem pacakges typically have a lot of dependencies, and
in the Go team in Debian we often end up packaging a lot of libraries
for every actual program we want to get into Debian. Waiting for
packages to pass the NEW queue can take a long time and is
unpredictable, so my recommendation is to package and review all
related packages in parallel.

This leads to the question how to run CI if a package depends on
something that is not yet in Debian unstable? The solution is to use
the SALSA_CI_EXTRA_REPOSITORY variable in Salsa CI. I posted
https://salsa.debian.org/go-team/packages/dyff/-/merge_requests/1 as
an example of this. This package needs
golang-github-gonvenience-idem-dev to build, but it is not yet in
Debian unstable. As a temporary solution for the sake of testing I
built and uploaded this package to my PPA, and then in an extra WIP
commit (that needs to be removed before final merge) I added
https://salsa.debian.org/go-team/packages/dyff/-/merge_requests/1/diffs?commit_id=9fcc662c01b7d824769b2f3fdf0b1eb71bd893f3.

This example was in my original email (below), but pointing it now out
explicitly as many of you are likely needing this trick soon.


On Thu, 31 Jul 2025 at 14:55, Otto Kekäläinen <otto@debian.org> wrote:
>
> 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/