Re: Moving project infrastructure / services to GitLab
On Mon, Mar 02, 2020 at 11:01:55AM +0000, 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 supporting tools (libvirt-jenkins-ci, etc)
All these projects would now benefit from pre-merge CI testing which
will catch build problems before they hit master. There is less
disruption to downstream consumers & no need for "build breaker fix"
rule to push changes without review.
The patch traffic for these repos is fairly low compared to libvirt.git
and the patches themselves tend to be simpler and thus easier to review.
Moving the non-core projects thus makes a smooth onramp for the libvirt
contributors to become more familiar with the merge request workflow,
and identify any likely places we might need to invest in tooling
Refer to separate mail to follow later for full consideration.
10. Use gitlab.com merge requests for core project
This is the final piece, removing the mailing list workflow for the main
libvirt.git repo.
Same points as for merger requests with non-core projects
Refer to separate mail for full consideration.
+1 from me as I share the same view on all the points. Reducing the
number of different services that we use for testing is a plus.
We might add another service to this list as I'm in process of setting
it up, but there were some issues and I'm solving it via email with
admins of that service. It's <https://scan.coverity.com/> where we
could run coverity tests for all relevant projects. To make the builds
that needs to be uploaded to have the processed we can use gitlab CI
infrastructure as well.
About moving the whole process to GitLab I was also planning to propose
to move all the libvirt related projects there to figure out the process
and to see what can be improved and what we need to do to make it
usable. If it doesn't work we can still move back to mail workflow but
I would rather try to make it work. As some of us already discussed we
can try to contribute to GitLab to improve mail notifications and
actually implement mail workflow in addition to the browser workflow
and the bichon tool that you are working on.
So the conclusion is that I agree with the suggestions.
Pavel
Attachments:
- signature.asc (application/pgp-signature — 833 bytes)