[libvirt] [RFC] Accepting PRs/MRs for libvirt on GitHub/GitLab

[Andrea Bolognani]

On Wed, 2019-10-16 at 17:03 +0100, Daniel P. Berrangé wrote:
> There's two tools being discussed here - both GitHub and GitLab.
> Splitting attention between email and a web based tool is bad,
> but splitting attention between email and two web based tools
> is even worse.
> 
> Finally I have general desire to *NOT* designate GitHub as an
> official part of the libvirt workflow on the basis that it is
> a closed source tool. Yes, we are already using it, but it is
> largely an ancillary service working as a passive backup service
> for our git repos, not a core part of our workflow. I don't want
> to elevate it to be a core part.

I understand why you feel this way and mostly share your opinion on
the matter, but from a pragmatic standpoint if our goal is to get
more people involved in libvirt's development then cutting off GitHub
is almost certainly the wrong way to go about it.

Just from the data we already have: GitHub, with the scary "don't
send PRs our way" warning at the top of the page, still got 13 PRs;
GitLab, which doesn't have the warning, got exactly zero so far.

> For example, currently we have a pratice of adding Reviewed-by tags
> on patches. This is possible, but inconvenient, when using the
> web tools. It is arguabley redundant, since the tools themselves
> record who commented, and who added approvals on the patch and
> who requested it merge. Dropping use of R-b assumes that we're
> 100% use the web tools and not email.

We should still record R-bs in git, because at the end of the day
the git history is the only thing that we can reasonably expect to
be able to migrate from provider to provider, or even from VCS to
VCS, in a lossless fashion.

> One of the things the web tools do well is fully integrating
> CI testing into the merge process. New submissions would typically
> get CI jobs run against them and only approved for merge once the
> CI has succeeded. This largely eliminates the problem of developers
> accidentally pushing changes to master that break the build. Again
> though this benefit is only seen if we discontinue use of email
> workflow. Much of our existing CI setup should be easy to integrate
> into GitLab. Our current VMs that are used with Jenkins just need
> to have the Jenkins agent replaced with the GitLab runner agent.
> We can then drop Jenkins entirely and do everything though GitLab
> for CI[1].

Looking at the repository containing the machine-executable
description of our CI setup, these days the part that actually
touches Jenkins is fairly small compared to the part dealing with
bringing up and maintaining runners. Of course we'd be able to reuse
pretty much all of it when moving to GitLab CI, but I just wanted to
highlight the fact that dropping support for Jenkins will not be that
much of a win in terms of maintenance.



Anyway, all of this talk about switching everything to a Web-based
workflow is entirely based on the assumption that, if we do that,
then we will start getting more contribution; however, we have *zero
evidence* that it would actually achieve that result.

That's why I'm suggesting is that we open up to contributions from
GitHub/GitLab while not giving up our current workflow, and after a
reasonable amount of time has passed look at the actual data and
base our decisions on what to do going forward on that.

-- 
Andrea Bolognani / Red Hat / Virtualization