> (CC to Kevin Barry, who mentioned GitLab experience in a separate > thread. My info here is more based on research than experience, so > please call out any misunderstandings I have.)
Thank you for the CC. I have read through the messages, and the previous discussion from 2018. My two cents are: - I think if we want to integrate issue tracking, code review, and source code hosting in one place, then Gitlab is the best option - I do not have the experience of working with SF/Allura, Rietveld, and Savannah to get code into LilyPond, but, judging from appearances, the flow for contributions will be smoother for existing developers and less off-putting for new or occasional developers (I think, outside projects like the Linux kernel, drive-by pull/merge requests are more common than drive- by patches) - I agree that using gitlab.com is better than self-hosting, but depending on the technical challenges involved it may be necessary to host a dedicated Gitlab runner (i.e. a server for doing CI/CD builds/tests). - I think it's possible James Lowe's workflow might be be different under Gitlab. Re the concerns he raised in the old thread, I believe he would be able to mostly replicate what he does now with labels (and sorting by priority label). (I can see that this flow, including the "countdown" is under discussion elsewhere.) - I don't know who tests that every patch successfully builds and passes basic tests, but in my experience, having Gitlab do that for me every time someone opens a merge request (on one of my own projects at work) has been a godsend (before that, I had to do it myself every time). > Additionally I'm not (yet) proposing to use MRs to actually > merge the change, that still happens via staging -> master. I only > propose that we use the UI to review the patches, instead of Rietveld. I think this is a good approach. Gitlab allows, for example, to have a number of protected branches (master + staging), and to default merge requests to any one. You can also set it to do different CI/CD on a branch by branch basis (for example you may want to run more stringent or longer tests on the staging branch than on others).
