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

[Urs Liska]

Am 7. Februar 2020 09:48:30 MEZ schrieb Kevin Barry <address@hidden>:
>> (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).

To add: tests are also triggered when additional commits are pushed to an open 
MT.


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

I think this is an extremely good point. Being able to squash upon merge, with 
or without merge commit, in combination with being able to automate that as a 
staging branch with final test, seems a very good idea to me.

This integration of tools can be handled completely independently from any 
policies about the review process or countdown etc.

To recap at this point: the worry about gitlab.com is similar to that wrt 
guthub: their TOS won't give us a substantial amount of trust in continuity of 
service.

Urs
-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.