On Mon, Mar 02, 2020 at 05:09:28PM +0100, Erik Skultety wrote:
> Apart from the WebUI-based review process which is rather painful (but I guess
> anything is better than gerrit for that matter) and non-existent threading
> within discussion topics, I agree to all the points, as having a nice SaaS
>
On Mon, Mar 02, 2020 at 11:01:55 +, Daniel Berrange wrote:
> We've discussed the idea of moving to a GitForge before, with the debate
> circling around the pros/cons of mailing list vs merge request workflows.
>
> This mail is NOT focused on that particular debate, rather it is tackling the
>
Apart from the WebUI-based review process which is rather painful (but I guess
anything is better than gerrit for that matter) and non-existent threading
within discussion topics, I agree to all the points, as having a nice SaaS
platform alleviating us from much of the maintenance burden is the way
On Mon, Mar 02, 2020 at 02:17:02PM +0100, Ján Tomko wrote:
> On a Monday in 2020, Daniel P. Berrangé wrote:
> > 1. Use gitlab.com as the location of the "master" git repositories
> >
> >Current committers to libvirt.org would have create accounts on
> > gitlab.com
> >and upload their SSH
On Mon, Mar 02, 2020 at 11:01:55AM +, Daniel P. Berrangé wrote:
[...]
> 9. Use gitlab.com merge requests for non-core projects
>
> This means every git repo that is not the core libvirt.org. All the
> language bindings, the other object mappings (libvirt-dbus/snmp/etc)
> and sup
On a Monday in 2020, Daniel P. Berrangé wrote:
1. Use gitlab.com as the location of the "master" git repositories
Current committers to libvirt.org would have create accounts on gitlab.com
and upload their SSH key.
No change in development workflow, merely update the "origin" URI.
We've discussed the idea of moving to a GitForge before, with the debate
circling around the pros/cons of mailing list vs merge request workflows.
This mail is NOT focused on that particular debate, rather it is tackling the
much broader issue of libvirt project infrastructure consolidation, such
