Re: [RFC] switch to GitLab / gitlab.com

[Kevin Barry]

> (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).