[fdo] Migrating hosting to GitLab, and governance

[Daniel Stone]

Hi all,
I've finally published quite a long blog about fd.o migrating quite a
lot of our hosting to GitLab:
https://www.fooishbar.org/blog/gitlab-fdo-introduction/

The blog is quite long and involved, covering a lot of the history as
well for people who aren't familiar. Hopefully it covers all the
reasoning behind why we wanted to move: simply, with the time and
resources we have available, with the number and disparity of projects
we host (we're not the most tightly-integrated community), we were not
able to meet everyone's expectations from a hosted open-source
development platform.

Over the past several months, we've been trialling out GitLab, from
initial deployments, to taking a couple of early guinea-pig projects,
through to now ready to accept mass migrations, including large
projects.

We'd like to invite all projects to now to take part in migrating to
GitLab. You can do so by filing a new issue at
https://gitlab.freedesktop.org/freedesktop/freedesktop/issues/new/ and
selecting the migration-specific template, which has a bunch of
questions to fill out.

In migrating, you may change as little or as much as you like. If you
want to go all out, migrating your Bugzilla bugs to GitLab issues and
using merge requests for code review, go ahead. If you don't want to
change your workflow and would prefer to keep Bugzilla and
Mailman/Patchwork, that's great too. The only thing we are asking you
to do now is change your primary hosting point.

Why are you doing this?
--------------------------------
Simply put, our current infrastructure isn't sustainable in its
current form. Maintaining it consumes far too much admin time, and the
end result of that time is a service which isn't very good. We can't
provide CI for projects, we can't provide web-based code review to
those who want it, issue tracking isn't even integrated with
repositories (let alone external services), and so on. In addition,
our current fleet of machines is approaching life expiry, and rather
than attempt to renew those and face the same battles, we decided to
shift.

What does it mean for me?
------------------------------------
Repositories previously hosted at ssh://git.freedesktop.org will,
after migration, have a new additional https://gitlab.freedesktop.org
Git pull URL, and the push URL will change to
ssh://gitlab.freedesktop.org. Project leads will be able to completely
control their own repositories and users (including creating new
repositories and adding new users) with no admin intervention at all.

If you wish, you can also make use of GitLab features like its issue
tracking, merge requests, CI, Pages hosting, etc. If you don't want
to, you are certainly not being forced to.

At the moment we would like to invite everyone to consider when would
be the best time to migrate their repository hosting, discuss as a
project any issues which may come up as part of the migration, and
request migration at a time which makes sense for them. In a few
weeks' time, we will begin proactively contacting projects which have
not yet migrated and asking them to do so.

How is it hosted?
-----------------------
gitlab.freedesktop.org is a GitLab CE (fully open-source) instance run
on Google Cloud Platform hosting, with GCP VMs, storage, and IPs. One
shared runner is currently provided for CI, hosted and administered by
Collabora, though we are seeking more.

Who is implicated?
--------------------------
I am the primary administrator of the GitLab instance. Keith and
Tollef also have access to the GCP organisation, allowing them to gain
access to the instance. GitLab Inc. are currently reimbursing us for
our GCP hosting costs, though we are seeking a long-term sponsor to
follow on from GitLab's generous donation. (We reached out to GitLab
and requested this.)

What next?
---------------
As more people migrate to GitLab, we'll keep on looking at all our
services and seeing where it makes the most sense to put our limited
time into. This might mean, if everyone all stops using a particular
service, that we decide to no longer provide it. It might mean that we
focus our energy on particular services we find out people _do_ use a
lot.

One thing we're hoping to do, is to spend more time with our community
and with governance issues. Migrating a lot of our hosting, in
addition to hopefully being better for our hosted projects, is paying
down technical debt. The infrastructure we have consumes so much admin
time - mostly of 'oh god fix it now' urgency - that we never get to
spend any time talking to our projects and figuring out how to help
them in ways technical and non-technical.

Moving to GitLab doesn't instantly solve every problem we have here:
we still have very finite admin time and still a lot of projects and
users with their own needs. But we see the admin time required
lessening over time, and hopefully with the migration we can start a
conversation with the projects we host about how we host things. If
you have any issues you think we should address, if there are things
we're doing well or that you think we should do differently, if
there's something you're unclear about and would like to know more
about - please ask, either now or as part of the migration ticket.
We're happy to discuss.

Ongoing governance
----------------------------

One option we've floated is merging fd.o into the X.Org Foundation.
X.Org already has a surprisingly wide remit: covering kernel graphics
development, Mesa, Wayland, libinput, and more. Like us, they're a
project formed under SPI. And they have a strong governance structure:
membership with defined criteria, a rotating elected board with clear
accountability to the members, and a good administrative structure.

Last year after the code of conduct discussion, I discussed our
governance structure (currently none) with Keith and Tollef. One thing
we do want to do is to get more people involved, shine a much brighter
light on what we do, and in general act in a more open and transparent
way. Part of that definitely involves a more clear administrative
structure. We agreed that it didn't seem feasible to create our own,
particularly when much of it very closely parallels the X.Org
Foundation already.

We have suggested to the Foundation board that the Foundation could
widen its scope by taking on fd.o and its member projects, which they
are currently considering. This would require the Foundation to change
its bylaws, which would be subject to a vote by all its members, and
for the two organisations to come up with a good enough plan that
no-one feels disenfranchised.

Right now this is very early days, and we have no concrete proposal
yet. Again, any thoughts, concerns, encouragement or suggestions would
be more than welcome.

Cheers,
Daniel