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
signature.asc
Description: PGP signature
