Python 迁移到 GitHub 的幕后故事
(点击上方蓝字，快速关注我们)
译文：伯乐在线专栏作者 - PJing
英文：Brett Cannon
如需转载，发送「转载」二字查看说明
【伯乐在线导读】：本文写于 2016 年 1月。作者 Brett Cannon 是 Python 软件基金会的主管（Director）。Python 社区早在 2014 年就开始讨论是否迁移到 GitHub 以改进开发流程，当时 Python 使用的版本控制系统是 Mercurial，而 GitHub 只支持 Git 版本控制系统。
2016 年 1 月，Python 项目宣布将迁移到 GitHub，从 Mercurial 切换到 Git 。2017 年 2 月 7 日终于有结果了，Brett Cannon 在 Python 官方邮件组发消息（截图），确定迁移到 GitHub 的日期了。
以下是正文
考虑到未来 Python 的开发流程，我决定将其迁移到 GitHub。我在 Twitter 上询问是否有人希望看到我把此事的幕后故事写出来。大家回答说“是”（字面上意思），因此这篇博文得以问世。
背景
我频繁地参与 python-dev 开始于我编写 《Python-Dev Summaries》，第一版由我于 2002 年 9 月 1 日出版。在攻读学士和硕士学位期间我休学了一年编写这些摘要，使我真正地融入到 Python 的开发流程（我最终总共编写了两年多的摘要）。不仅让我知道了 Python 中的一切事情，而且帮助我能立刻注意到有事情需要做。这些都是有益的，因为意味着我能不断地接越来越复杂的任务，让我变得越来越自在地做出贡献。
有两件事对我很关键。一是，我深深地感谢开源项目，特别是 Python 能提供给像我这样没有大量的编程经验，但是有驱动力、热情、愿意贡献代码和能从贡献中学习的人机会。二是，让我注意到 Python 开发流程是如何工作的，不仅让第一次作出贡献的人们，在第一个开源贡献中获得喜悦与经验变得容易，而且尽可能使核心开发人员方便地与他们合作，并最终认可他们的贡献。
这所有的一切使我最后可以在 2006 年 12 月负责迁移 Python 的 SVN 代码库和关闭 SourceForge 上的问题跟踪器并移到 svn.python.org，使用 Roundup 管理 bugs.python.org（“有趣的”是， 原先问题跟踪器用的是由 Atlassian 托管的 JIRA，但是来自社区的压力包括Richard Stallman 和 FSF（Free Software Foundation）让我们使用 Roundup 代替）。这次迁移影响了我两个方面。一是建立了关于基础设施问题上如何在相互竞争的解决方案中，选择处理的决定。基本上我会呼吁大家提出如何解决问题的意见，这样可以消除个人偏见，而且我不会允许我自己提出建议（在这种情况下，提出的建议可以采用建议问题跟踪器测试用例的形式）。我对一小群人的建议很放心，他们可以直接反馈给我，同时还允许他们任何人在合适的邮件列表上畅所欲言，然后我根据包括所有的反馈、我的测试用例经验和我的总体思路做出结论。用同样的方法我把 Python 从 svn.python.org 迁移到 hg.python.org（在 2009 年做出这项决定，2011 年发生变化）。
我学到的第二课是关于志愿者的奉献。当做出决定选用 JIRA 时，一个主要的吸引力是 Atlassian 将托管我们的实例，而且直接提供支持（他们都参与在他们自己的提议之中）。但是当社区开始抗议 Java 应用封闭源码想法的时候，我公开说过，如果我们有足够多的志愿者来管理属于我们自己的 Roundup，我可以对使用 Roundup 松口。事实上有相当多数量的人站了出来，因此我们也改变了（FSF 提出帮助召集志愿者，但最终我没有采纳他们的建议，因为我感觉我自己好像就可以召集到足够多的志愿者）。但最后发生的是几乎没有留下一个志愿者。这时候很感谢我们的两位核心开发者 Ezio Melotti 和 R.David Murray，他们这些年维持着问题跟踪器的运行和用 Upfront Systems 来托管它。这次经历教会我，你真正可以指望的人是那些把精力都放在建议本身和有良好记录的人。尽管人们都有着凭空而来的良好意愿，可这并不能保证他们将真正地跟进（老实说，根据从 PyCon US 大会上 Python 核心冲刺中得到的经验，我已经知道人们习惯常常解决大问题时，先拿出部分解决方案，接着他们发誓当他们到家就完成剩下的，然后再也听不到他们的声音）。
一切的开始
虽然我的博士专业在计算机科学技术上没有一个研究点附属于它，非正式地称之为软件工程。但作为 不列颠哥伦比亚大学 软件实践实验室 的一员，我周围的人们总是试图找出改善软件开发的方法。这让我一直对软件开发实践抱有兴趣，也同时让我非常清楚地认识到，开始追赶当前 Python 自身开发流程的最佳实施，或许会变得举步维艰。
在 2014 年对与我们一些人来说，Python 的开发流程实际上变成了一种负担。提交补丁的速度远远大于它们被评审的速度。这让外部贡献者感到沮丧，因为他们努力编写的补丁，有时会发生最后等待几年的时间才被核心开发人员评审。因为 Python 社区非常友善，大家只是很有礼貌地坐在那里等待有人注意到他们的补丁，而不是追问是否有人可以查看它（随后我们告诉大家，如果他们的补丁在问题跟踪器上停留太久，可以发送有邮件到 python-dev）。对于开源项目来说，这是一个非常糟糕的情况。因为如果外部贡献者停止参与，那么这个项目就会跟随着核心开发者慢慢终结。外部贡献者不能被代替，因为他们无法取代。
尽管我们当中有几个人对这个问题公开地表示过遗憾。在 2014 年 7 月 Nick Coghlan 决定创建 PEP 474 公开承认这一问题。在该文档中 Nick 提议把我们的Mercurial 代码迁移到 Kallithea 上来托管，而且可以给我们提供代码评审集成（后者是所期望的，因为bugs.python.org 使用了一个 Rietveld 自定义没有主动维护的分支）。可是，这个 PEP 并没有得以实施，因为 Nick 还有很多其他项目的工作要做，而且他也没有现成的方法可以用来改变当前的开发流程
快进到 2014 年 11 月，Nick 决定尝试再次迁移一些东西，问我们是否应该把辅助代码仓库迁移到 BitBucket（在Python 中辅助代码仓库类似于 PEPs，基准等；基本上所有代码库，都不是由一个人贡献而成的，除了 cpython 代码库）。在接下来的讨论中，Guido 反对 Nick 迁移到 GitHub 的想法，更早之前在类似的讨论中 Dnoald Stufft 也提出过。为了帮助推动做出决定，Guido 指示正被讨论的 3 个代码库中的 2 个由我来管理。因此我应该打电话去联系，而他只是想轻松地等我完成这件事（在 LWN 上有报道过整个讨论）。
做出决定的重担直接落在了我的肩上（我本可以不答应，但是当跟 Python 有关时我不会那样做，我的妻子可以证明）。我要抓住这次机会，用我的方式来尝试现代化 Python 的开发流程。在 2014 年 12 月的时候我写过一份愿景文档，详细地阐述了我理想中的 Python 开发流程应该是怎么样的，我担心每个人真正关心的只是辅助代码库和关键代码库，而忽略了手边实际的问题。我说过我想要一个尽可能简单的开发流程，方便核心开发人员评审外部贡献者的代码。就像是自动化测试的补丁、代码覆盖率和通过游览器来合并补丁等等。简单总结我想要的就是，当你身处在海滩时，可以通过平板电脑连接 WIFI 对外部贡献者提交的代码进行评审(这不是一个愚蠢的请求，就像实际上我人在温哥华)。我的想法还包括如果能使这个过程简化，核心开发人员便可以在工作中的午餐时间完成一次评审，或者当他们在家遇到停机时，不需要在一些特殊的机器上安装 SSH 密钥。大体上我就是希望开发过程能如此合理化，能让外部贡献者的代码评审轻松一些 (绝不像现在的情形；在那时是一个麻烦，我至少没有完成的乐趣，更多的是出于一种义务的感觉)。
过程
决策过程开始于 2015 年 2 月我要求起草 PEPs 的时候。PEPs 最初充当一种让我知道谁在提议、谁愿意努力付出帮助的方式。在截止日期前，Nick 的 PEP 474 和 Donald Stufft 提议 GitHub 的 PEP 481（ 还有 Phabricator 可以选择，不过最后被遗弃了）。然后我想要在 4月份的 PyCon US 2015 大会上得到最终的 PEPs。我希望 5 月 1 日前能做出决定。
可是到了 5 月 1 日还是没有做出决定。发生了什么呢？在 PyCon US 大会后我结束了求职，离开 Google 横跨加拿大又回到温哥华生活，在那里我加入了 Microsoft 的 Python 团队。然后我需要一段时间去适应——搬到新的地方，重建自己“新的”小镇（在温哥华我完成了博士学位。现在只是和土生土长在温哥华的妻子重新适应回到这里），并开始新的工作。一直到 9 月我都没有努力去做出决定。这里要感谢我的新工作，让我能够在这上面开始投入一些工作时间。在 2015 年 10月 31 日，北美正是万圣节的时候，我要求为提议的两个平台测试cpython 代码库的实例，同时目标 2016 年 1 月 1 日做出决定。然而很快发生了，Barry Warsaw 问是否可以考虑 GitLab , Nick Coghlan 随后也说他宁愿用 GitLab 也不用 Kallithea (由于项目成熟度问题)。Donald 对这次改变没有提出异议，Nick 也仅仅只是在技术上扭转了他之前的提议，Barry 坚持到底要有跟踪记录，我容许以 Nick 的提议为中心。
2015 年 11 月，像好几个私底下或者在核心工作流邮件列表里向我反馈的人一样，我整月都在处理测试用例。12 月的前三个星期用来回答大家关于这两种途径的问题。紧接着到了 2016 年 1 月 1日。
决定
在元旦那天，我宣布选择 GitHub 而不是 GitLab。之所以做出这个决定是有很多原因的。一是 GitHub 基本上打造了一个开源贡献者们的社交网络，这让不同的核心开发者告诉我，他们已经对 GitHub 感到称心如意，希望我能选它。还意味着在 GitHub 上已经有许多以开发流程自动化为目标的工具，可以用来缩减 Python 团队维护的基础架构。
二是 GitLab 没有杀手锏。现在有人会说开源就是 GitLab 的杀手锏，但对于我，开发流程远比担心一个云服务是否公布其源代码更为重要。如果有人担心，例如在开发开源项目时使用了 Gmail 地址。这些尤其不用担心，因为 GitHub 不是一个封闭的花园，它有大量 SDK 允许随意下载，而且可以上传所有数据到平台上。由于 GitHub 可以用来托管代码仓库和代码评审，意味着仅仅只需要备份代码评审的数据。再加上 Git 是一个分布式版本控制系统，因此在每个(完整)克隆中包含了整个操作历史。
最后，我们的 BDFL (仁慈的独裁者)也倾向于 GitHub。从整个决策过程的开始，Guido 就已经让人们知道他认为 GitHub 是最好的选择。对我来说我想要确保 Guido 感到称心，而不是沮丧地贡献出他自己的编程语言。现在，Guido 将会是第一个告诉你他的贡献率是多么低，他的意见不应该凌驾于其他任何珍贵的核心开发者之上。但是对于我，我想确保 Guido 保持尽可能高的参与度，所以 Guido 的偏好对我很重要。
下一步
在做出决定的同时，我们已经开始在核心工作流的邮件列表里讨论拟定如何管理此次迁移。我目前正在写一个 PEP，其中概述了我们希望移动的每个存储库，对其迁移的必要步骤。随后就开始处理每一个步骤，慢慢地把各种存储库迁移到 GitHub。我希望能今年完成迁移，但是可能会推迟到 2017 年（这些工作主要是由志愿者们推动，可他们中许多人有不同的意见，因此不会轻而易举的完成）。
无论何时能完成，我都很乐观地认为最终会得到回报。我有一些想法，比如说怎样尝试利用从 GitHub 获得的收益来使驱使开发流程顺利进行。我们可以有一个类似于 Python 社区的 SLA(Service-Level Agreement)，协定愿意花多久来处理外部贡献。如果我们的项目可以再次设法变得能快速响应外部贡献，那么所有这一切都将是值得的。
看完本文有收获？请转发分享给更多人
关注「程序员的那些事」，提升编程技能