XPost: linux.debian.bugs.dist
From: guillem@debian.org

Hi!

On Wed, 2024-07-10 at 22:45:01 -0700, Otto Kekäläinen wrote:

Please allow Merge Requests at https://salsa.debian.org/dpkg-team/dpkg
so that it is easier for others to contribute to the package.

These repos are just mirrors (I've updated the repo descriptions there now), like the ones on Codeberg, where stuff gets «git push --mirror»'ed into them. So enabling MR could cause accidental diverging history which would be messy, and given how --mirror works and how I think GitLab
tracks MRs, my assumption has been that those MR branches would be
deleted on mirror push anyway.

It would also spread where to look for changes, currently already
the BTS and the mailing list.

So, thanks for the request, but I think I'm going to decline it.

Git is a distributed version control system. You can perfectly fine
have multiple repositories and then sync between them.

Well dpkg already has multiple repos, and they are being kept in sync,
by having a main instance and then replicas! I think doing this
automatically without a merge-based workflow, for multiple pushers,
would either be racy, or not possible at all w/o making a mess of it.

Under no situation would a sync of the mirror overwrite the Merge
Requests. If I for example file a Merge Request at https://salsa.debian.org/dpkg-team/dpkg from a source branch in my own
fork, there is no way for you to overwrite that merge request branch.

Your own fork should indeed be safe from overwrites, but that was not
my point :), AFAIUI GitLab based forges store MRs against that project
as refs under the refs/nerge-requests hierarchy, that's why you can
fetch them remotely by adding something like this in your local tree
under .git/config:

[remote "some-name"]
url = git@gitlab-url:repo/repo.git
fetch = +refs/heads/*:refs/remotes/some-name/*
fetch = +refs/merge-requests/*/head:refs/remotes/some-name/mr/*

Then when you fetch, you'll see the MRs as those branches for that
remote. A «git push --mirror» will forcibly add, update or delete
remote branches to match the local (on the git server) bare repo, and
my assumption has always been that this would remove those refs, but
perhaps GitLab protects them someway and does not let you remove them
even by force, or when mirroring. TBH have never bother to test that,
but I think that's a bit besides the point as I mentioned.

It is true that if you accept Merge Requests, then you would have to
read email notifications from both patches submitted via
bugs.debian.org as well as via salsa.debian.org. However that is very
minor extra work. The benefit of accepting Merge Requests on
salsa.debian.org is that you can see that the CI you are using is
passing and the submission didn't regress anything testable.

One of the concerns is that this spreads this information for the
project, so that others will have a harder time seeing where things
are happening, and stores that information in a place where it will
be harder to extract (once, not if) Salsa goes away. With git being
distributed as you point out, people are in general not even checking
where most of my WIP work is happening, which to me seems to confirm
this being a problem already.

As mentioned, Salsa is one of the several mirrors for the project, and
its CI system is being used for some of the checks, but I also use the
CI from GitHub for Coverity, CodeQL and ports build checks. In the
same way there was a separate Jenkins instance doing package builds
up to recently (when it got decommissioned).

I think you were very quick to jump to the conclusion that accepting
Merge Requests is somehow a burden or extra work. I am confident that
if you give it a try, and more people contribute to improving dpkg,
the overall benefit far outweighs the minor inconvenience of getting
email notifications of patches from two systems.

I mange projects that live entirely in a GitLab instance as their
primary hosting site, and there that makes perfect sense. Although
GitLab or GitHub review capabilities are not very ideal compared to
either mail based workflows or even Gerrit. Salsa is also very slow,
which is quite frustrating.

Also most of the work and time consumption with dpkg IME, involves
change planning and design, analyzing what will break, how, preparing transitions, coordination with multiple involved parties, etc. I don't
think whether there are MRs enabled in a forge would help with any of
that.

But in any case, just to wrap up, this is not about not knowing how
these forges work, or their potential advantages, etc. I'm open to
reconsider this in general, and I've also been pondering for a while
whether to make dpkg a non-native project (for example to get
downstreams to use proper patch management instead of a mess of changes
over a native release of their own, and to get properly signed
tarballs that are usable by downstream). And as part of that perhaps
moving its entire development into some forge, either locally hosted
(but I don't really fancy having to do random user and spam management),
or into an existing one, but then my thinking has been that if this was
to happen the most likely candidate would be Codeberg, and not Salsa.
But then I'm also not very confident Codeberg (like Alioth, and I
expect Salsa) are long-term options, that will not disappear at some
point. :/ And if this happened the Debian BTS and mailing list would
still not go away, and migrating the data out from those is kind of
out of the question, so it looks like a massive mess in the making.

Thanks,
Guillem

--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)