On the need to move to a merge request workflow

[Daniel P. Berrangé]

On Fri, Mar 06, 2020 at 11:54:57AM -0300, Daniel Henrique Barboza 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.

So we have a mixture of code submissions, design discussions (on libvir-list)
and user discussions (on libvirt-users). The design discussions make up a
fairly low volume of the mail.

Based on what I see with other projects, they generally encourage design
discussions to happen in the issue tracker. The designs may lead to many
distinct pieces of work, each of which get turned into todo items and
associated with separate merge requests. So the issue tracker is basically
used to discuss / plan / coordinate all the non-coding work.  With this
approach there's not really much compelling reason to keep using the
libvir-list. If you look at systemd, after they moved to merge requests,
their mailing list still exists, but it mostly just has end user questions.
For libvirt this role is filled by the libvirt-users mailing list.
I wouldn't shut down libvir-list, but I wouldn't expect significant
traffic in the long term.

> 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.

The open source platform aspect is the overriding factor. I believe in the
core value / message of open source software, so I can't credibly say that
in order to develop open source software, you must use a closed source
platform. It is a contradictory message IMHO.  I would prefer if GitLab
didn't follow the open-core model of split offerings, but it is at least
still an open source project.

At a technical level, I find the native CI integration more compelling in
GitLab, vs GitHub where CI is traditionally outsourced to further 3rd
party closed source services (though IIUC they have native Azure support
now too as an option). This is fairly minor though.

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