Re: [libvirt] [RFC] Accepting PRs/MRs for libvirt on GitHub/GitLab
On Thu, Oct 17, 2019 at 09:40:08AM +0200, Andrea Bolognani wrote:
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.
Attracting more contributors is not an absolute goal in isolation.
It is one of many factors that need to be balanced. One of the
factors is basing our development workflow on open source tools
not closed source tools.
> 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.
I'm not really suggesting its a win for maint of the CI systems,
I doubt it will be better or worse, just different.
The point of integrating with GitLab is to get the pre-merge
checking of patches, instead of post-merge that we have now.
IOW, it is a win for maint of the code being developed.
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.
I don't think that will offer meaningful data, because it is setting
it up as a second class citizen to the email workflow, and not taking
advantage of the different features that GitLab offers. So we'll
see the downsides of the new tool without experiancing the upsides.
Growing contributors in any meaningful amount is something that will
likely take a long time to have an effect too - I can easily imagine
12 to 24 months, not something we can measure after a 3-6 months IMHO.
Even if it doesn't grow contributors I think it'll still the be right
move to make long term, because it normalizes the libvirt development
model with what's widely expected for open source projects these days,
and other factors such as unreliability of our mailing list software
impacting us significantly.
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 :|