Re: Moving project infrastructure / services to GitLab
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 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 :))
Yes, good point. Both approaches have their pros & cons. The right answer
will probably come down to how well we know the people we're granting
privileges for. Fine grained perms might encourage us to grant privs to
more people, especially around the language bindings.
> 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. :)
Oh, and we no longer have to manually have someone (me) create accounts for
users to deal with anti-spam.
> 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.
We have flexibility in how we configure things wrt merge requests and
acceptance rules.
The default is essentially unrestricted. You can push directly to git
master, or create a merge request & self-approve it (assuming you're a
project member). This matches what we do with many language bindings
today.
You can turn on a requirement to have passing CI tests. This would
prevent direct push to master, and require a merge request to trigger
the CI. You can still self-approve it. So this is fairly similar to
what we do now, just with added pre-merge CI.
You can turn on a requirement to have an explicit non-author person
approve the merge request preventing self-push. This is a slightly
stronger variant of our normal rules requiring an ack from someone
for core libvirt.git
The CI requirement is separate from the approvals requirement.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|