写点什么

Python 将迁移到 GitHub

  • 2016-01-24
  • 本文字数:2177 字

    阅读完需:约 7 分钟

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 上去,这就让那些担心失去控制的稍稍放松一些,缩小了一些改动的范围。

查看英文原文: Python will be Moving to GitHub

2016-01-24 18:004985
用户头像

发布了 30 篇内容, 共 11.0 次阅读, 收获喜欢 0 次。

关注

评论

发布
暂无评论
发现更多内容

五大模型揭秘深度学习用于时序预测的最新进展

云智慧AIOps社区

人工智能 机器学习 深度学习 算法 模型

无线标准802.11ac 和 802.11ax到底有什么区别?哪个更快?

wljslmz

网络技术 无线技术 802.11ac 802.11AX 11月月更

费劲拿到的阿里P8架构师私藏(java岗的)JCF和JUC源码分析与实现笔记

程序知音

Java 高并发 源码刨析 java架构 后端技术

Eureka框架的原理

阿泽🧸

Eureka 11月月更

三分钟带你了解一站式大数据平台运维管家 ChengYing 产品包制作

袋鼠云数栈

Docker 镜像使用

我是一个茶壶

Docker 镜像 11月月更

金融服务的超级App

FN0

生态 超级app 组装式应用

袋鼠云产品功能更新报告 02 期丨有亿点点走心!

袋鼠云数栈

Docker容器的使用

我是一个茶壶

容器 11月月更 docker、

大数据生态中的 RocketMQ 5.0

阿里巴巴云原生

阿里云 RocketMQ 云原生

AI生命周期 | 聊聊数据准备阶段的偏见问题

澳鹏Appen

人工智能 机器学习 数据标注 数据训练 数据偏见

非行稳无以致远:华为如何写好数字金融的大文章?

脑极体

数据中台选型必读(四):要想中台建的好,数据模型得做好

雨果

数据中台

重磅发布!星汉未来全国开发者悬赏计划

星汉未来

云计算 开发者 运维 云原生 星汉未来

2022-11微软漏洞通告

火绒安全

安全漏洞

阿里云 Landing Zone 上好云伙伴联盟正式起航

云布道师

阿里云 2022云栖大会

【kafka运维】 kafka-consumer-groups.sh消费者组管理

石臻臻的杂货铺

kafka kafka运维 11月月更

报名|企业数字化转型有何“利器”?一起来揭秘

元年技术洞察

数字化转型

实战指南 | Serverless 架构下的应用开发

阿里巴巴云原生

阿里云 Serverless 云原生

官宣!Taier1.3 新版本正式发布,新鲜功能抢先体验

袋鼠云数栈

2022 vivo开发者大会人工智能专场:打造「1001个便利」

Geek_2d6073

获奖作品《重力》超详细制作过程!建议码住!

Renderbus瑞云渲染农场

Blender制作教程

Knative架构解析

穿过生命散发芬芳

Knative 11月月更

【线上分享会回顾】九科信息董事&产品VP傅恺分享流程挖掘实践案例

九科Ninetech

极客时间运维进阶训练营第三周作业

好吃不贵

解决APP抓包问题【网络安全】

网络安全学海

网络安全 安全 信息安全 渗透测试 漏洞挖掘

SQL编写规范

默默的成长

前端 sql 11月月更

颠覆传统BOM检查!用这个方法既​简单、快速又准确

华秋PCB

工具 PCB BOM PCB设计

持续优化,欣欣向云 | RocketMQ Operator 0.3.0 正式发布

阿里巴巴云原生

阿里云 RocketMQ 云原生

得物极光蓝纸箱尺寸设计实践

得物技术

算法 遗传算法 供应链 建模 运筹

Redis的一些概念

饱饱巴士

redis 11月月更 redis梳理

Python将迁移到GitHub_开源_Sergio De Simone_InfoQ精选文章