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@xxxxxxxxx> 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 :|
