Wikimedia正在迁移到GitLab
跳转到导航跳转到搜索2020-10-23：工作组决定将我们的代码库从Gernt迁移到GitLab是正确的决定。GitLab是获取更多详细信息的门户。
在过去的两年中，我们的开发人员满意度调查显示，人们对我们的代码审查系统Gernt存在一定程度的不满。这种不满对我们的志愿者社区尤为明显。对代码审查的明显不满，加上对我们的CI工具和实践的内部审查，使得现在是重新审视我们的代码审查选择的好时机。
虽然Gerrit的工作流程在很多方面都是同类中最好的，但它的界面存在可用性缺陷，而且它的工作流程不同于主流的行业实践。这为社区设置了进入障碍，并减缓了WMF技术人员的入职速度。此外，越来越多的个人和团队(包括员工和非员工)选择放弃使用Gernt，转而使用第三方托管选项(如GitHub)。选择使用第三方托管的原因各不相同，但根据非正式交流，主要分为3组：
所有这些解释都指向我们现有的代码审查系统中的摩擦，它不仅没有促进开发，反而减缓了开发。选择使用第三方代码托管损害了我们的协作(内部和外部)，增加了入职的混乱，并使跨存储库维护代码标准变得更加困难。同时，还要求部署到Wikimedia Production的所有软件都是从Gernt托管和部署的。
如果我们不能解决用户在Gernt上遇到的真正的可用性问题，人们将继续在他们喜欢的任何系统上启动和构建项目--维基媒体的GitHub已经包含152个项目，研究团队有127个项目。
这就提出了一个问题：如果格瑞特有可识别的问题，为什么我们不能用格瑞特解决这些问题呢？GERRIT是开放源码(Apache许可)软件；修改很简单，只需编程即可。
我们在GERRIT用户社区中是独一无二的，其中包括SAP、爱立信、高通和谷歌等大公司。特别是谷歌，他们在Android和Chromium等项目中使用Gernt是独一无二的。要支持这些大型开放项目，需要多站点功能；然而，这些工作中的大部分要么是闭源的，要么不支持多站点写入。
Upstream在最近的版本中改进了UI，并且版本变得更加频繁；但是，通常缺少升级路径文档。例如，从Gerrit2到Gerrit3的迁移需要几个上游补丁程序集来避免建议的几天停机时间。这是维持现状所需的努力。即使是很小的改进也需要努力和时间，因为我们的用例通常与Gernt社区的其余部分非常不同。
GitLab是一个用Ruby编写的功能强大且可伸缩的代码审查系统。GitLab可用于自托管，以与我们的其他开发工具基础设施平起平坐，并缓解对数据隐私或第三方托管的使用限制的担忧。由于GitLab提供麻省理工学院许可的社区版(CE)，因此它遵循基金会的自由和开源指导原则。
最后，GitLab作为发布工程团队持续集成工作组的一部分进行了评估。虽然GitLab的持续集成系统被发现足以满足我们的需求，但代码审查超出了该工作组章程的范围。因此，将GitLab的能力与引入社会摩擦和增加复杂性的可能性进行了权衡-将GitLab的CI与Gerrit相集成。用GitLab取代Gernt将显著改变我们的CI工具的方程式-允许我们使用GitLab中内置的行业标准工作流和自助式CI工具。出于这些原因，我们希望将本讨论的范围限制为评估从GitLab迁移到GitLab进行代码审查是否可行和可取。范围内的内容包括：代码审查工作流和流程；代码审查过程中涉及的工具和机器人；合并、分支和部署策略；为避免产生疑问，持续集成(CI)和任务/项目跟踪不在此评估范围之内。
以下是一些用于比较GitLab和GERRIT代码审查的有用术语和定义：
格瑞特语言中的积分方法。正在审查的单一提交。在代码评审过程中修改提交是非常常见的。[3]。
GitLab中的集成方法。将一个分支合并到另一个分支的请求。[4]。
将一个功能的所有工作放在它自己的分支上，当功能完成时集成到主线中。[5]这些分支通常是短暂的。[6]。
开发人员一旦拥有了可以共享的健康承诺，就会立即进行主线集成。[7]。
更广泛的维基媒体运动(通过咨询的讨论页面、给wikitech-l@和wikitech-amesadors@的邮件列表信息，以及Technews时事通讯)
工作小组负责参与讨论、整理和权衡各谘询小组的意见、提供建议，以及直接告知谘询结果。工作小组成员如下：
参与这次协商的各团体之间的沟通对于实现这一进程的公平结果非常重要。
公告将在Wiki上、通过邮件列表和通过Technews时事通讯发布。以下概述的进程的每个阶段开始和结束时将宣布。此外，在整个咨询过程结束时，将合并反馈意见的摘要。
反馈将在维基上、通过邮件列表和通过技术新闻征求。在咨询期内将通过维基讨论页面收集反馈。工作组成员将努力参与咨询期内在维基上进行的讨论。在整个过程结束时，将分享在咨询期间收集的反馈摘要。
由于这一决定对我们的持续集成系统有次要影响，该系统也计划在不久的将来更换，我们希望遵循以下时间表：
托管在维基媒体云服务基础设施上的GitLab的测试实例可在以下网址获得：https://gitlab-test.wmcloud.org/。
注意：这只是一个测试实例。任何数据都应该预料到会丢失。注册时不要重复使用任何密码。对于使用测试实例时的bug或配置/功能请求，请使用GitLab-Test项目在Phabricator中归档任务。
Wikimedia技术社区有来自世界各地的许多工作流程和参与者，他们拥有不同水平的技术知识和专业知识。为了就采用GitLab做出公平的决定，有必要权衡合理的担忧与社区管理的技术项目的持久性，同时也要考虑所有贡献者的需求。这些都是评估中将使用的考虑因素。评估工作将由工作小组成员初步完成，并在谘询期内分享。讨论的议题包括：
我们会使用GitLab企业版还是社区版？社区版(CE)。它是GitLab的免费软件专用版本。这类似于其他使用GitLab的自由软件/文化团体，例如：Debian、GNOME和KDE。
为什么持续集成(CI)超出范围？CI超出了范围，因为该基础设施是代码审查的次要部分。换句话说，理想情况下，CI如何设置和维护的细节对于开发人员日常来说并不重要。
为什么不考虑GitHub？GitHub将是加入维基媒体技术社区所需的第一个工具，该社区将是非自由软件和非自托管的。
GitHub也不能满足我们所有的需求；例如，GitHub对元数据几乎没有控制，对隐私策略/数据保留、制裁和禁止几乎没有影响，对备份和数据完整性检查几乎没有控制，并且没有对底层存储库设置和配置的长期保证访问权限。
如果我们迁移到GitLab，在GitHub上开发的存储库会发生什么情况？鉴于GitLab提供了非常相似的工作流程和功能集，我们强烈建议所有开发人员使用GitLab而不是GitHub进行所有开发。出于可见性的目的，存储库仍将镜像到GitHub。
如果我们决定使用GitLab进行代码审查，那么使用GitLab内置的其他功能(如问题、Wiki、页面等)会怎么样？这次咨询只关注代码审查，而不是问题跟踪或替换已经提供给Wikimedia开发人员的其他功能。为了在问题跟踪中先发制人，我们可以在GitLab上关闭问题跟踪。此外，我们将关闭存储库wiki、GitLab页面和其他与当前提供的工具重叠的功能。
