• Type:

The KDE community is moving to GitLab

The KDE community is #MovingToGitlab! After announcing the original decision to migrate to GitLab in November 2019, KDE has officially completed phase one of their migration, and contributors have begun to use GitLab on a daily basis at invent.kde.org. Read on to learn more about KDE’s migration story.

About KDE

KDE is an international community that creates open source software for desktops and mobile devices. KDE software is compatible with multiple platforms, including GNU/Linux, FreeBSD, Windows, macOS, and Android. Their products are used by millions of home and office workers and are being deployed in schools around the world.

With more than 2,700 artists, designers, programmers, translators, writers, and other contributors from across the globe, the KDE community is thriving.

Together, this community creates and maintains more than 200 applications and countless add-ons, plugins, and Plasmoids, 1000+ repositories, 80+ frameworks for Qt developers, and more than 2,600 projects. KDE software is translated into more than 100 languages to enable vast global reach.

Why KDE moved to GitLab

“Adopting GitLab has been as a natural next step since the opportunity was presented. Simplifying the onboarding of new contributors is one of our main goals in the KDE community. Being able to allow project contributors to easily participate in how the products they maintain are tested and delivered will certainly be a turning point for our ecosystem,” says Aleix Pol, President of KDE e.V.

“By using a platform offering an interface and workflow that most open source developers are nowadays familiar with, we are confident that we are lowering the bar for new contributors to join us, and are providing the foundation for our community to scale in the following years,” added Neofytos Kolokotronis, member of KDE e.V.’s Board of Directors and a core member of KDE’s Onboarding team.

Moving to new tools is a lot of work for established communities like KDE. Migration decisions require careful communication and the complex task of gathering community consensus.

The KDE team made the decision to migrate after following a series of carefully designed steps. First, they talked to the sysadmin team and then formed a migration team to evaluate the move. Next, the sysadmin team completed a thorough study of GitLab’s features and did an intake and comparison of the community’s needs against those product features. Then, they created a process that allows KDE to run short test cycles with some projects, document the process, and provide feedback to the community.

The migration started by moving some smaller and more agile KDE teams that were very interested in testing and providing feedback. After this cycle was completed successfully, KDE started migrating teams with a larger codebase and more contributors. Once all of the major issues were resolved, they made the final switch for all remaining projects they planned to move. The sysadmin team documented the results after each step and shared them directly with the KDE community to receive feedback and gather consensus on how to proceed.

As the switch to GitLab fell directly under the scope of KDE’s “Streamlined Onboarding of New Contributors” goal, the KDE Onboarding team was also involved from the start, working very closely with the sysadmin team, who were leading the effort. The community was involved in the decision-making from the beginning, and stayed up-to-date on each phase of the migration, and all questions and concerns were answered and addressed along the way.

“This was a major change for us, but we are very satisfied with how our community collaborated over long discussion threads. We believe that by working together we made the best decisions as we moved forward,” says Neofytos.

Migration challenges and solutions

The biggest challenge for KDE was the sheer volume of data they were dealing with and how it was integrated into the numerous tools in use (including Phabricator). With more than 1,000 repositories, this migration was a big undertaking.

To address this challenge, KDE decided to approach the migration in phases rather than do it all at once. By phasing the migration, they were able to deal with different data types, such as repositories and tasks, separately.

KDE developed custom tools to make bulk updates easier throughout the migration process. These tools help set the name, description, and avatar of the projects alongside a number of settings, for example, protected branches, and merge methods. By using these custom tools for bulk updates, KDE was also able to avoid granting maintainer access to individual contributors. KDE only allows maintainer access for sysadmins per their access and permissions policy.

KDE ported custom Git hooks to ensure that certain checks and actions continued after the move to Gitlab. These include checks to ensure file encodings match KDE requirements and that bugs on their Bugzilla installation were closed as needed.

In order to support their translation community, which still uses Subversion in their workflow, KDE also built tooling to export SSH keys from GitLab to avoid the need to update these in two places.

KDE also adjusted the tools used to build and develop KDE software to make them compatible with the new repository structure in GitLab.

At this point, KDE overcame most of their migration hurdles. Once the preparation work was finished to clean up a number of systems to work more natively with GitLab, the actual migration took about one day.

But there are a few more challenges left before KDE can transition continuous integration (CI) and task management over to GitLab. To follow along with the KDE migration, you can take a look at the list of issues that KDE is tracking.

Architectural decisions

A common challenge for organizations moving to GitLab is deciding how to structure their groups to best enable their community’s workflows and allow them to abide by their policies.

KDE decided to tackle this challenge by setting up a series of groups at the top level of GitLab to act as categories. KDE’s 1,200 repositories were then sorted into each of these categories.

KDE formed this architectural strategy to help make projects more discoverable. KDE wanted to avoid the impracticality of people needing to scroll endlessly through repositories. Setting up top-level categories also allows developers to get an easier overview of merge requests for the categories they are most interested in.

With regards to permissions, KDE uses a single master “KDE Developers” group to manage membership and permission levels. Everyone there is given “Developer” access. This group is then invited to all of the groups containing repositories except for the ones containing the KDE website and infrastructure repos. This method of dealing with permissions allows KDE to maintain a single source of truth.

GitLab + KDE = ❤️

KDE is using the Community Edition of GitLab because of their commitment to open source. They are a member of our GitLab for Open Source program, and have been actively collaborating with GitLab team members throughout the migration. One of benefits of using the GitLab for Open Source program for large migration efforts is that the community often offers some extra assistance through the evaluation period and beyond.

For example, the GitLab for Open Source program has a public tracker for KDE’s migration, which is used to communicate and better understand at a glance the issues that are especially important. This allows KDE, GitLab, and the larger open source community to collaborate on challenges together.

“GitLab’s values of collaboration and transparency really shine through,” says Neofytos. We appreciate their openness to accepting merge requests from community members and considering proposals for new features. We have had a great experience so far collaborating with members of the GitLab community and members of the GitLab team – from developers to program managers to product owners alike.”

Now that phase one of the KDE migration is complete, we look forward to continuing to collaborate with KDE through the remaining phases of the migration.

Summary of the KDE migration

  • Phase 1: Code hosting & review ✅
  • Phase 2: CI
  • Phase 3: Task management for developers

How to contribute to KDE

KDE has an amazing community and they welcome new members! Existing members are happy to provide feedback on newcomers’ contributions with the goal of helping them learn. Every day more and more people join the ever-growing KDE family – and there’s always room for more!

KDE has a rich infrastructure of web resources, forums, mailing-lists, IRC (chat), and many other ways to get in touch. To learn more about joining the KDE community, visit their “Get Involved” page, which offers guidance to all contributors from all backgrounds.


Considering a migration for your open source project or organization? Learn more about our GitLab for Open Source program and don’t hesitate to contact us at opensource@gitlab.com. Follow our social media hashtag #MovingToGitlab for more migration stories, tips, and tricks.

A big thank you to KDE’s Aniqa Khokhar, Ben Cooksley, Bhushan Shah, Neofytos Kolokotronis, and Paul Brown for collaborating on this blog post.

Cover image by DICSON on Unsplash

Read More

Previous Post

Make educated wireless router/AP upgrade decisions

Next Post

The U.S. can now set its own rates for mail from China and other countries

Leave a Reply

Your email address will not be published. Required fields are marked *

Scroll to top