Hi Colin, Colin Watson <cjwat...@debian.org> writes:
> On Thu, Jan 23, 2025 at 10:57:56PM -0800, Xiyue Deng wrote: >> Actually there may be another reason to turn off MR feature: some >> packaging workflows don't preserve a linear Git history and hence may >> not work well with merging from MR on Salsa. For example, the "git-dpm" >> and "git-debrebase" workflows, which use a more complex >> merge/fast-forward strategy and merge requests don't integrate well. In >> such case it's better to turn off MR to avoid any confusions and let >> contributors post patches on BTS, and then the maintainer can apply >> those accordingly. > > I don't completely agree with the last part of this: I use git-dpm for > many packages and I leave MRs switched on anyway, even though it does > mean that sometimes I might need to do merges by hand. It's not ideal, > but it's OK. (I understand why people might feel differently, though.) > Thanks for sharing your experience. And yes, merging from MR does work for these workflow to some extents, though it does require understanding of how they work and handles the merge / fast-forward correctly. This would require people to be familiar with those workflows to deal with those, otherwise a directly merged MR would cause the repository layout becomes dpm/debrebase incompatible. I brought this up because personally I had done something similar before on a git-debrebase repository and made the repository a mess. I had to reach out to more knowledgeable team members to help fix it, and it was then decided disabling MR could help avoid this happening again. For those repositories the team and I have added debian/README.source describing the workflow and people need to consult git-dpm(1), git-debrebase(1), dgit-maint-debrebase(7), etc. to understand how to handle those cases properly. Again, this does not mean the developer is not accepting collaboration, and contributors are welcome to use BTS for the purpose. Lastly, I want to clarify I'm in support of keeping MRs open and promoting a standard workflow for most packages. Meanwhile I would also like to acknowledge that many other workflows exist because they handle different use cases well (e.g. carrying Debian-specific patches for a long time, complex custom packaging checks, etc.). Letting different workflows exist and work together, though not easy, is also beneficial for collaboration. > -- > Colin Watson (he/him) [cjwat...@debian.org] > -- Regards, Xiyue Deng
signature.asc
Description: PGP signature
