7:17 a.m.
On a Monday in 2020, Daniel P. Berrangé wrote:
[...]
>
> 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.
> 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
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.
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.