KDE社区正在迁移到GitLab

KDE社区是#MovingToGitlab！在2019年11月宣布迁移到GitLab的最初决定后，KDE已经正式完成了迁移的第一阶段，贡献者已经开始在inv.kde.org上每天使用GitLab。请继续阅读，了解有关KDE迁移故事的更多信息。

KDE是一个为台式机和移动设备创建开源软件的国际社区。KDE软件兼容多种平台，包括GNU/Linux、FreeBSD、Windows、MacOS和Android。他们的产品被数以百万计的家庭和办公室员工使用，并正在世界各地的学校部署。

KDE社区拥有来自全球各地的2700多名艺术家、设计师、程序员、翻译员、作家和其他贡献者，KDE社区正在蓬勃发展。

这个社区总共为Qt开发人员创建和维护了200多个应用程序和数不清的附加组件、插件和类型库、1000多个存储库、80多个框架和2600多个项目。KDE软件被翻译成100多种语言，以实现广泛的全球覆盖。

自从机会出现以来，采用GitLab一直是自然而然的下一步。简化新贡献者的入职是我们在KDE社区的主要目标之一。KDE e.V.总裁Aleix Pol表示：能够让项目贡献者轻松参与他们维护的产品的测试和交付，这对我们的生态系统来说肯定是一个转折点。

KDE董事会成员、KDE入职团队核心成员Neofytos Kolokotronis补充说，通过使用一个提供大多数开源开发人员现在都熟悉的界面和工作流程的平台，我们相信我们正在降低新贡献者加入我们的门槛，并为我们的社区在未来几年的规模提供基础。Neofytos Kolokotronis是KDE的董事会成员，也是KDE入职团队的核心成员。他补充说，通过使用一个提供了大多数开源开发人员现在都熟悉的界面和工作流程的平台，我们相信我们正在降低新贡献者加入我们的门槛，并为我们的社区在接下来的几年里扩大规模提供基础。

对于像KDE这样的老牌社区来说，迁移到新工具是一项很大的工作。移民决策需要仔细的沟通和收集社区共识的复杂任务。

KDE团队在遵循了一系列精心设计的步骤后做出了迁移的决定。首先，他们与sysadmin团队进行了交谈，然后组建了一个迁移团队来评估这一举措。接下来，系统管理员团队完成了对GitLab功能的彻底研究，并将社区的需求与这些产品功能进行了比较。然后，他们创建了一个流程，允许KDE对一些项目运行较短的测试周期，记录流程，并向社区提供反馈。

迁移开始于一些更小、更敏捷的KDE团队，他们对测试和提供反馈非常感兴趣。在这个周期成功完成后，KDE开始迁移拥有更大代码库和更多贡献者的团队。一旦所有主要问题都解决了，他们就对计划搬迁的所有剩余项目进行了最后的切换。sysadmin团队记录了每个步骤之后的结果，并将其直接与KDE社区共享，以接收反馈并就如何继续进行收集共识。

由于转换到GitLab直接属于KDE精简新贡献者入职目标的范围，KDE入职团队也从一开始就参与其中，与领导这项工作的sysadmin团队密切合作。社区从一开始就参与决策，并对迁移的每个阶段保持最新状态，在此过程中所有问题和关注都得到了回答和解决。

这对我们来说是一个重大的变化，但我们对我们的社区如何在长时间的讨论中进行协作感到非常满意。Neofytos表示：我们相信，通过共同努力，我们在前进的过程中做出了最好的决定。

KDE面临的最大挑战是他们要处理的数据量太大，以及如何将其集成到众多正在使用的工具中(包括Phabricator)。拥有1,000多个存储库，这次迁移是一项艰巨的任务。

为了应对这一挑战，KDE决定分阶段进行迁移，而不是一次性完成。通过分阶段迁移，他们能够分别处理不同的数据类型，如存储库和任务。

KDE开发了定制工具，以便在整个迁移过程中更轻松地进行批量更新。这些工具帮助设置项目的名称、描述和头像，以及一些设置，例如受保护的分支和合并方法。通过使用这些用于批量更新的自定义工具，KDE还能够避免向单个贡献者授予维护人员访问权限。根据系统管理员的访问和权限策略，KDE仅允许维护人员访问。

KDE移植了定制的Git钩子，以确保某些检查和操作在迁移到GitLab之后继续进行。其中包括检查以确保文件编码符合KDE要求，并根据需要关闭Bugzilla安装上的bug。

为了支持他们的翻译社区(他们的工作流程中仍然使用Subversion)，KDE还构建了从GitLab导出SSH密钥的工具，以避免在两个地方更新这些密钥。

KDE还调整了用于构建和开发KDE软件的工具，使其与GitLab中的新存储库结构兼容。

在这一点上，KDE克服了他们的大部分迁移障碍。准备工作完成后，清理了一些系统，以便更好地与GitLab配合工作，实际迁移大约需要一天时间。

但是，在KDE将持续集成(CI)和任务管理过渡到GitLab之前，还有更多的挑战。为了跟踪KDE迁移，您可以查看KDE正在跟踪的问题列表。

迁移到GitLab的组织面临的一个共同挑战是决定如何构建他们的小组，以便最好地支持他们的社区工作流程，并允许他们遵守他们的政策。

KDE决定通过在GitLab的顶层建立一系列小组作为类别来应对这一挑战。然后，KDE的1200个存储库被分类到这些类别中的每一个。

KDE形成了这一架构策略，以帮助使项目更容易被发现。KDE希望避免人们需要无休止地滚动存储库的不切实际。设置顶级类别还允许开发人员更容易地了解他们最感兴趣的类别的合并请求。

关于权限，KDE使用单一的KDE Developers主组来管理成员资格和权限级别。那里的每个人都有权访问开发人员。然后，除了包含KDE网站和基础设施存储库的组之外，该组被邀请到所有包含存储库的组。这种处理权限的方法允许KDE维护单一的真理来源。

KDE之所以使用GitLab的社区版，是因为他们致力于开源。他们是我们GitLab for Open Source项目的成员，在整个迁移过程中一直积极与GitLab团队成员合作。使用GitLab for Open Source计划进行大规模迁移的好处之一是，社区经常在评估期及以后提供一些额外的帮助。

例如，GitLab for Open Source计划有一个用于KDE迁移的公共跟踪器，用于交流和更好地一目了然地了解特别重要的问题。这使得KDE、GitLab和更大的开放源码社区可以一起协作应对挑战。

Neofytos表示，GitLab的协作和透明价值观确实大放异彩。我们赞赏他们对接受社区成员的合并请求和考虑新功能的建议持开放态度。到目前为止，我们与GitLab社区的成员和GitLab团队的成员-从开发人员到项目经理再到产品所有者-都有很好的合作经历。

现在KDE迁移的第一阶段已经完成，我们期待着在迁移的其余阶段继续与KDE协作。

KDE有一个令人惊叹的社区，他们欢迎新成员！现有会员很乐意就新成员的贡献提供反馈，目的是帮助他们学习。每天都有越来越多的人加入不断增长的KDE大家庭--而且总是有更多的空间！

KDE拥有丰富的基础设施，包括Web资源、论坛、邮件列表、IRC(聊天)和许多其他联系方式。要了解更多关于加入KDE社区的信息，请访问他们的“参与进来”页面，该页面为来自各种背景的所有贡献者提供指导。

正在考虑为您的开源项目或组织进行迁移吗？了解更多有关GitLab for Open Source项目的信息，请不要犹豫，请通过[email protected]与我们联系。关注我们的社交媒体标签#MovingToGitlab，了解更多迁移故事、提示和诀窍。

非常感谢KDE&39；的Aniqa Khokhar，Ben Cooksley，Bhushan Shah，Neofytos Kolokotronis和Paul Brown在这篇博客文章中合作。