On the need to move to a merge request workflow

[Christophe de Dinechin]

+1 on the initial thread b

> On 6 Mar 2020, at 15:54, Daniel Henrique Barboza <danielhb413 at gmail.com> wrote:
> 
> 
> 
> On 3/6/20 8:44 AM, Daniel P. Berrangé wrote:
> 
> 
> [...]
> 
> 
> What happens with this mailing list when the migration to the new workflow is
> completed with all the repos? Is it still going to be used for discussions,
> questions, RFCs and etcetera? I'd rather be in Gitlab watching opened issues
> and merge requests all the time, without the need to check the Libvirt ML
> ever again.
> 
> And apparently we're leaning towards Gitlab. I'll not be standing here
> defending closed-source, Microsoft based Github, but I'm curious: aside from
> that (and that reason alone is enough, no need to grab the pitchforks),
> is there any other technical advantage for going Gitlab? I suppose most
> existing "coding support tools" are Github friendly already. Also, due to
> Microsoft deep pockets, Github will probably experience less downtime and have a
> better support overall in case something goes wrong.

GitHub and GitLab have different approaches to CI, with pros and cons on
both sides. Obviously, it is easier to get stuff tested on Windows with GitHub,
for example.

You can use both, with automatic mirroring of the commits. For some of
my own projects, I have dual push targets in git (triple, actually, SourceForge),
and then I get two sets of (different) CI tests on a push. For example,
GitLab will test a number of Linux targets like Ubuntu, etc, while
GitHub will test macOS and someday Windows.

I am not aware of a good way to sync issues, though, only commits.
Anybody knows differently?

> 
> 
> Thanks,
> 
> 
> DHB
> 
>