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.