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. Any current committer who has comitted in the last 12 months would get access to the new git repos. This would cleanup any inactive people who no longer contribute to libvirt. Gives us the ablity to have per-GIT repo commit privileges
On the other hand, giving people access to all of them was a nice gesture of trust. (Not really a point against, I just wanted to say it :))
Partially eliminates DanB / DanV as points of failure on libvirt.org, as the gitlab.com project admin privileges can be more flexibly granted, as compared to multiple people having root on DanV's personal server. Eliminates the libvirt.org physical server as a single point of failure for SCM, which has no disaster recovery plan in place. Improved reliability as libvirt.org anon-git breaks periodically libvirt.org SCM would remain as a read-only mirror, to serve as a disaster recovery option should we need it.
[...]
4. Use gitlab.com as the primary upstream issue tracker This is to replace the current usage of bugzilla "Virtualization Tools" product. For the work we do with the upstream bugzilla product the GitLab issue tracker is a good match, avoiding the complexity Bugzilla has grown for dealing with RHEL process bureaucracy.
The downside of sharing a bugzilla instance with RHEL was that it was easy to move low-priority downstream bugs there, effectively littering the tracker with bugs with no real demand. And vice-versa, some Red Hat people wanting to file downstream bugs against libvirt use the wrong product and they end up on the upstream tracker.
It is good for users, as they no longer need to register for an account on BZ.
Right, RH BZ only offers Fedora Account System as a login option, gitlab.com has Google, Twitter and GitHub.
It is easier & more inclusive for maintainers as changes to the issue tracker config are entirely self-service, instead of via a private Red Hat issue tracker only available to Red Hat employees, or knowing the right Red Hat admins personally.
Repo forks for major pieces of work can have their own issue tracker for free, providing a collborative way to track the problems before the code lands in upstream.
The forks get it for free regardless of point 1. and/or point 4. - all you need is a libvirt mirror on gitlab to fork from.
[...]
7. Use gitlab.com as the project wiki Replaces the current mediawiki install that is deployed via a Red Hat hosted OpenShift instance Would require a way to do an automated migration of the content from the current mediawiki deployment that I manage for wiki.libvirt.org Would requires a way to HTTP redirects from the old URLs DanB is eliminated as a single point of failure for the wiki and no longer has to waste time playing sysadmin for mediawiki / mysql.
Also one less account to sign up for. I've had commit access to libvirt for ~5 years before I got a wiki account. :)
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.
This is the major benefit of the git forge workflow.
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.
That would eliminate the current practice of patches being pushed into the language bindings without even being sent to the mailing list.
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.
/me saves his rants for a separate mail. Jano
Attachment:
signature.asc
Description: PGP signature
