Re: On the need to move to a merge request workflow
+1 on the initial thread b
On 6 Mar 2020, at 15:54, Daniel Henrique Barboza
<danielhb413(a)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