Re: [libvirt] [RFC] Accepting PRs/MRs for libvirt on GitHub/GitLab
On Thu, 2019-10-17 at 09:48 +0100, Daniel P. Berrangé wrote:
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:
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.
Personally I see pre-merge CI as a mere nice-to-have: as long as we
keep enforcing the pre-release freeze period, fixing things before
merging them or immediately afterwards with follow-up patches
doesn't really make a lot of difference in my eyes.
For testing stuff or reproducing CI issues locally we already have
our 'make ci-*' targets, which thanks to their interactivity are
IMHO much nicer to use than the GitLab CI / Travis CI workflow of
push → wait for the build to finish → scroll through the logs and
try to figure out what went wrong → change some code → go back to
the beginning and repeat multiple times until you finally manage
to get it right.
> 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.
If mailing list reliability was the problem, we could "simply" start
running a mailman instance on libvirt.org and take ownership of our
own mailing lists, no need to change workflows.
Anyway, we're clearly seeing different goals in the potential move
to Web-based tools, so it's not surprising that we'd approach it in
fairly different ways :)
To me the Web-based workflow is inferior to the mail-based one, this
opinion being informed by using GitHub regularly for the past two
months or so. I'm willing to take hit if it can be proven that the
drawbacks are compensated with an increased number of contributors,
but otherwise I'd much rather keep things the way they are.
Once Bichon is usable perhaps I'll change my mind, but until then
I don't think there's much of a chance of us agreeing.
--
Andrea Bolognani / Red Hat / Virtualization