Python 将迁移到 GitHub
Python 目前的维护者，Brett Cannon，日前在 Python 的核心工作流邮件列表中 宣布 了 Python 将迁移到 Github 中，在与 InfoQ 的对话中，Cannon 解释了决定此次迁移花了超过一年的时间，当初主要的考虑有如下三个备选方案：
最后到决定是选择了 GitHub，主要归结为以下三个方面的原因：
- GitHub 和 GitLab 在功能方面基本差不多；但是，Cannon 这里特别提到，GitLab 的开源与否根本就不是决定性的因素。
- 活跃的开发者均熟悉 Github，无论是核心开发者还是外围的贡献者。另外就是，虽然有一些开发者明确的反对迁移到 GitHub，但是没有一个说如果社区就这么决定了就没有人使用 Github 了。
- Guido van Rossum 偏爱 Github，Cannon 考虑到尽管现在 Rossum 只是偶尔贡献一下，但他的影响力仍在，为了避免潜在的冲突，应当考虑 Rossum 的感受。
Cannon 向 InfoQ 谈到他是如何做这个决定的：
基本上我这次的所作的决策过程和原来做过的两次没有太大的不同，过程都是这样的：我向 PEP 请求关于问题的可能的解决办法，基于所提出的议题来进行讨论（尽管讨论通常都是流于形式的，但是 PEP 会自始自终都保留详细记录，有最新的建议一般都会通知到），制订各种期限，比如测试实例这样的，到那时，当我要做出决策的时候，我所基于的素材就非常的丰富了。
这里值得一题的是 Python 使用 GitHub，仅用于其代码托管和代码审核的支持，这也就意味着 Python 的缺陷跟踪和维基百科不会迁移到 GitHub 上。
Cannon 还讲过 Python 的核心开发者们彼此之间也是争论的不可开交。 Stefan Krah 所表达的观点其实是代表了开发者当中倾向于使用 GitLab 的人们，为此，Cannon 专门进行了 回复 ，并收到了很多未抄送给邮件列表的私聊回复，均回答了假定GitHub 是首选的话大家是否会停止提交代码？他还补充到，在他看来无论是迁移到GitHub 或者是其它的仓库都会有一小部分人的不适应，但必须要妥善处理。
InfoQ 借机采访了 Brett Cannon，希望更加深入的了解到此次决定所能带来的好处，在整个流程中目前处于何种地步。等等。
你能解释下 Python 和 Python 社区迁移到 Github 有何好处吗？
我目前正在写的一个 PEP 的 草稿 可以解答一部分，但是我们所期望的好处是可以做到更快速的补丁审核以及人们能够更加容易的参与到社区（真正的关键还是前者，但后者属于锦上添花）。希望是所有的工具都是或可以是围绕着 GitHub 所构建，能够做到为 Python 开发团队过去需要手动去做的大量的工作均替代为自动化，减少花时间去审核补丁的时间，从而提高生产效率。（目前我们最大的问题就是在缺陷跟踪上对于外来贡献者特别的不好，甚至让他们非常的不爽）。更何况不论是开发团队还是更为广泛的开源社区均对 GitHub 熟悉有加，而且我希望的是让所有人参与其中能够更加的快速和方便。
目前的状态是什么？下一步将会做什么？
说到状态，我是在 2016 年 1 月 1 日对 Python 的开发迁移到 GitHub 上这个决定的，现在的话我正在撰写关于我们各个代码仓库迁移所需要的所有步骤的 PEP（在上一个问题的回答中我给出的链接）。一旦在我们的 核心工作流邮件列表 中达成共识，且 PEP 会更加的完善、突出一些细节。在那之后，我们就会开始我们的工作。
至于具体的接下来的工作，他们要做的就是解决掉那些个会妨碍代码仓库迁移的“拦路虎”。因为我们迁移仓库所花费的困难是取决于他们所需要的工具，我希望是首先解决掉所有仓库的通用问题，然后再根据具体的仓库问题具体的解决。
你在公告中提到邮件列表中仍然有一些争论存在，你希望以何种方式来结束这场讨论？
你指的是在我发表过决定之后在核心工作流邮件列表中的讨论吧！我对此结果非常的满意。虽然有一些人因为 GitLab 拥有一个开源的版本就愿意去选择它，但是所有人都理解我为何做出如此的决定，而且支持我的坚持。大家还是对此次迁移持积极态度的，而且利用此机会让我们的开发平台尽可能的保持平台无关性，在未来能够不懈的追求更加的简单（这一定能够实现，自从我成为核心开发者之后，这算是第三次改动了，而且 Python 到今天已经走过了第 25 个年头，依然保持强劲的势头，当然，在接下来的几年，我们是不会再做平台的变换的了）。
开源项目近期往 Github 上迁移似乎渐渐的增多，你是否有过担心，如 其它人 那样认为如此依托给一个商业公司是不靠谱的？你认为这会给 Python 带来困扰吗？
对于未来的平台发生改变的情况还是非常担心的（将来某个时候一定会发生）。但是我们将仅使用 GitHub 来托管代码以及用来做代码审核，前者是很容易找到替代产品，而后者的话，一旦关闭某个 pull request 历史，其临近的也就没有什么价值了。也就是说，我们会对代码审核的历史做备份，那么我们一旦找到替代者，我们可以得到有效的代码审核，因为审核历史是有价值的，哪怕是直有一条接受的提交。如果 GitHub 不能提供开放的 API 给我们访问数据以及提高壁垒的话，我们当初就不会考虑它。另外，诸如 GitLab 之类的平台会提供一些工具让你来替代 GitHub，包括 pull request 都可以导入到他们的平台，我们知道我们并不会失去什么，但是 GitHub 可以给我们最快的时间。还有就是我们的缺陷跟踪系统不会迁移到 GitHub 上去，这就让那些担心失去控制的稍稍放松一些，缩小了一些改动的范围。