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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
