[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC] switch to GitLab / gitlab.com
From: |
Urs Liska |
Subject: |
Re: [RFC] switch to GitLab / gitlab.com |
Date: |
Fri, 07 Feb 2020 10:36:44 +0100 |
User-agent: |
K-9 Mail for Android |
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.
- Re: [RFC] switch to GitLab / gitlab.com, (continued)
- Re: [RFC] switch to GitLab / gitlab.com, Federico Bruni, 2020/02/11
- Re: [RFC] switch to GitLab / gitlab.com, Jonas Hahnfeld, 2020/02/11
- Re: [RFC] switch to GitLab / gitlab.com, David Kastrup, 2020/02/11
- Re: [RFC] switch to GitLab / gitlab.com, Jonas Hahnfeld, 2020/02/11
- Re: [RFC] switch to GitLab / gitlab.com, David Kastrup, 2020/02/11
- Re: [RFC] switch to GitLab / gitlab.com, Jonas Hahnfeld, 2020/02/11
- Re: [RFC] switch to GitLab / gitlab.com, David Kastrup, 2020/02/11
- Re: [RFC] switch to GitLab / gitlab.com, Jonas Hahnfeld, 2020/02/11
- Re: [RFC] switch to GitLab / gitlab.com, David Kastrup, 2020/02/11
Re: [RFC] switch to GitLab / gitlab.com, Kevin Barry, 2020/02/07
Fw: Re[2]: [RFC] switch to GitLab / gitlab.com, Trevor, 2020/02/07