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

Package: dpkg
Severity: wishlist

Hi!

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

Thanks!

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

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

Hi!

Thanks for a quick reply!

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.

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.

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.

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.

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

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

Hi!

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.

Git fully supports accepting Merge Requests / Pull Requests from
multiple places. You just apply the commit on the main place like you
usually do and push and you are all good.

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.

You have a very elaborate explanation of something that nobody does,
never has happened, and which is not even technically possible. What
you are indirectly expressing here is just that you don't like
Salsa/GitLab and don't want to learn or think how it works or what
benefits it brings, but rather focus on coming up with reasons not to
use it, even imaginary ones.

...

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

Everything relevant about the code change is in the git commit message
itself. I don't think allowing Merge Requests on Salsa would mean that
you need to store the metadata about MRs forever. They are useful to
facilitate making the change, such as tracking if the code passes CI
and what is the state of the MR. Once it is merged or closed it is
fine to forget about the MR.

...

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.

GitLab and GitHub track things like CI and submission status, which is completely missing from email. And both on GitLab and GitHub you can
actually also review by email if you don't want to be assisted by the
UI.

I do agree on the slowness, and have filed https://salsa.debian.org/salsa/support/-/issues/395

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

The fact that your first response to this bug report was to
immediately close it paints a clear picture that you have a strong gut
feeling is against the proposal, and your half-arguments reflect that
you really want to come up with reasons to not support MRs.

I just wish you would have replied simply that you don't like using
Salsa MRs but left the bug report open for more people to potentially
voice their opinion (assuming there is dpkg-team, perhaps there
isn't).

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