On the need to move to a merge request workflow

[Daniel P. Berrangé]

On Tue, Mar 17, 2020 at 12:06:45PM +0100, Christophe de Dinechin wrote:
> +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.

NB, windows testing is covered by mingw64 cross compilers, at least for
build testing. If we wanted to run unit tests we can use wine, but it
hasn't been a priority. For real functional tests we'd need a real
windows install, but that's even further down the list of things we
care about.

macOS testing we get via Travis and that's the main gap we have with
GitLab, unless we get access some hardware we can setup as a GitLab
custom CI runner. 

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

Syncing issues & merge requests is tricky to do accurately, because you
need to parse the comments to identify references to usernames and
issues, etc. IMHO it just isn't worth the hassle to. Syncing everything
would also make google search results and split attention with people
not being sure which is the master vs mirror. We already have that
problem to some extent with the existing commit mirroring, so I'm
loathe to make it more confusing. 

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|