How GNOME uses Git

The GNOME project's decision to centralize on GitLab is creating benefits across the community—even beyond the developers.
145 readers like this.
red panda

Mathias Appel via Flickr. Public Domain. Modified by Jen Wike Huger.

“What’s your GitLab?” is one of the first questions I was asked on my first day working for the GNOME Foundation—the nonprofit that supports GNOME projects, including the desktop environment, GTK, and GStreamer. The person was referring to my username on GNOME’s GitLab instance. In my time with GNOME, I’ve been asked for my GitLab a lot.

We use GitLab for basically everything. In a typical day, I get several issues and reference bug reports, and I occasionally need to modify a file. I don’t do this in the capacity of being a developer or a sysadmin. I’m involved with the Engagement and Inclusion & Diversity (I&D) teams. I write newsletters for Friends of GNOME and interview contributors to the project. I work on sponsorships for GNOME events. I don’t write code, and I use GitLab every day.

The GNOME project has been managed a lot of ways over the past two decades. Different parts of the project used different systems to track changes to code, collaborate, and share information both as a project and as a social space. However, the project made the decision that it needed to become more integrated and it took about a year from conception to completion.

There were a number of reasons GNOME wanted to switch to a single tool for use across the community. External projects touch GNOME, and providing them an easier way to interact with resources was important for the project, both to support the community and to grow the ecosystem. We also wanted to better track metrics for GNOME—the number of contributors, the type and number of contributions, and the developmental progress of different parts of the project.

When it came time to pick a collaboration tool, we considered what we needed. One of the most important requirements was that it must be hosted by the GNOME community; being hosted by a third party didn’t feel like an option, so that discounted services like GitHub and Atlassian. And, of course, it had to be free software. It quickly became obvious that the only real contender was GitLab. We wanted to make sure contribution would be easy. GitLab has features like single sign-on, which allows people to use GitHub, Google, GitLab.com, and GNOME accounts.

We agreed that GitLab was the way to go, and we began to migrate from many tools to a single tool. GNOME board member Carlos Soriano led the charge. With lots of support from GitLab and the GNOME community, we completed the process in May 2018.

There was a lot of hope that moving to GitLab would help grow the community and make contributing easier. Because GNOME previously used so many different tools, including Bugzilla and CGit, it’s hard to quantitatively measure how the switch has impacted the number of contributions. We can more clearly track some statistics though, such as the nearly 10,000 issues closed and 7,085 merge requests merged between June and November 2018. People feel that the community has grown and become more welcoming and that contribution is, in fact, easier.

People come to free software from all sorts of different starting points, and it’s important to try to even out the playing field by providing better resources and extra support for people who need them. Git, as a tool, is widely used, and more people are coming to participate in free software with those skills ready to go. Self-hosting GitLab provides the perfect opportunity to combine the familiarity of Git with the feature-rich, user-friendly environment provided by GitLab.

It’s been a little over a year, and the change is really noticeable. Continuous integration (CI) has been a huge benefit for development, and it has been completely integrated into nearly every part of GNOME. Teams that aren’t doing code development have also switched to using the GitLab ecosystem for their work. Whether it’s using issue tracking to manage assigned tasks or version control to share and manage assets, even teams like Engagement and I&D have taken up using GitLab.

It can be hard for a community, even one developing free software, to adapt to a new technology or tool. It is especially hard in a case like GNOME, a project that recently turned 22. After more than two decades of building a project like GNOME, with so many parts used by so many people and organizations, the migration was an endeavor that was only possible thanks to the hard work of the GNOME community and generous assistance from GitLab.

I find a lot of convenience in working for a project that uses Git for version control. It’s a system that feels comfortable and is familiar—it’s a tool that is consistent across workplaces and hobby projects. As a new member of the GNOME community, it was great to be able to jump in and just use GitLab. As a community builder, it’s inspiring to see the results: more associated projects coming on board and entering the ecosystem; new contributors and community members making their first contributions to the project; and increased ability to measure the work we’re doing to know it’s effective and successful.

It’s great that so many teams doing completely different things (such as what they’re working on and what skills they’re using) agree to centralize on any tool—especially one that is considered a standard across open source. As a contributor to GNOME, I really appreciate that we’re using GitLab.

What to read next
A slightly old photo of Molly de Blanc, in which she has blue highlights in her hair. She is wearing a black shirt and clear glasses.
I'm a free and open source software activist working out of beautiful New England (USA). I work at the GNOME Foundation, as the strategic initiatives manager, building partnerships with other organizations and engaging supporters of the GNOME Foundation. I serve as president on the Board of Directors of the Open Source Initiative.

4 Comments

Hi Molly,

thank you for the article! It was interesting to see, that Gnome can use Gitlab's project management outside of coding related stuff. I would like to know which plan do you use? Is the free, self hosted solution suffice all your needs?

I would also be really glad to read a more in-depth article of the workflow that you have, using Gitlab for non-coding projects (or maybe not-just coding). My main concern is with bigger projects that may also have some smaller subprojects. Is it easy and intuitive to handle them, or do you need some workarounds? Your opinion and mileage would be highly appreciated even in a short answer!

Thank you in advance!
Gergely

We use gitlab a lot.
We have problems with the search capabilities inside issues and wiki across all your projects. Does it work well for you?

I keep all of the GNOME GitLab notification mails for my projects around, because Thunderbird's search allows me to search only their subject (aka the issue's summary). I haven't found if GitLab allows for the same in its UI, but am pretty sure it doesn't.

Also, when comparing it to Bugzilla's search capabilities (with its whole dedicated page of a search form), I miss the date-and-time-based search capabilities the most.

In reply to by raisercostin (not verified)

Hi,

I am a bit confused as to your reasoning for discounting Github or Bitbucket. Both have a server offering for hosting yourself.

I am not arguing Gitlab was a bad choice.

Thanks.

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License.