50万奖金+官方证书,深圳国际金融科技大赛正式启动,点击报名 了解详情
写点什么

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:005436
用户头像

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

关注

评论

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

即时通讯IM WorkPlus支持国产化信创环境

BeeWorks

消失与存续——应用交付行业的跌宕演进

通明湖

负载均衡 高可用 云原生 信创

可观测实践|如何使用阿里云 Prometheus 观测 ECS 应用

阿里巴巴云原生

阿里云 云原生

中台“不火”了,企业“底座”却火了

BeeWorks

SAP | 如何全局处理消息文本

暮春零贰

SAP 10月月更 动态消息

NFT质押挖矿分红dapp系统开发功能介绍

开发微hkkf5566

云科通明湖:金融业务可持续性能力建设,少不了这块“拼图”!

通明湖

负载均衡

颠覆性突破重构企业价值

通明湖

负载均衡 云原生

Sanitizers 系列之 address sanitizer 用法篇

网易云信

算法 语言 & 开发

关于软件系统的帮助文档页面,你该知道的那些事儿

Baklib

帮助文档

SAP | ABAP程序结构中的处理块

暮春零贰

SAP 模块化 10月月更

千企千面,WorkPlus面向政企提供个性化的数智办公平台解决方案

BeeWorks

软件测试面试真题 | 请介绍一下Python中的深拷贝和浅拷贝

测试人

Python 软件测试 面试题 测试开发

低代码又又又“出圈”了

优秀

低代码

英特尔财报彰显系统级代工渐成气候

科技之家

“程”风破浪的开发者|CTO浅谈数字化转型

CTO技术共享

学习方法 CTO 数字化转型 “程”风破浪的开发者

网络安全hw蓝队实战之溯源

网络安全学海

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

NFT质押挖矿分币系统开发模式定制

开发微hkkf5566

穿越周期性调整 英特尔多举措布局半导体产业

科技之家

阿里最新产,SpringCloud微服务核心技术全解手册Github星标50k

程序员小毕

Java 微服务 后端 SpringCloud springcloudAlibaba

云原生颠覆实践,可持续性应用创新引擎

通明湖

负载均衡 云原生

信息技术国产化浪潮中,云科通明湖如何助力企业转型蝶变?

通明湖

双活 高可用架构 自主可控

如何引发一场信创负载均衡领域的大变革?

通明湖

负载均衡 信创

ALL in ONE!博睿数据隆重举行ONE 2.0全面上线仪式

博睿数据

可观测性 智能运维 博睿数据 ONE平台

可观测可回溯 | Continuous Profiling 实践解析

阿里巴巴云原生

阿里云 云原生 可观测

“程”风破浪的开发者|CTO浅谈数字化转型失败原因

CTO技术共享

学习方法 数字化转型 “程”风破浪的开发者

API 动态更新 Upstream

通明湖

API upstream 动态更新

【网易云信】Sanitizers 系列之 address sanitizer 用法篇

网易智企

算法 开发语言

沉浸其境,共赴云栖数智硬核美学

阿里云CloudImagine

VR/AR 云栖大会 数智融合 超高清视频 云游戏

Flink 读写多套 Kerberos 认证的 Kafka 方案

移动云大数据

浅谈长连接负载均衡

捉虫大师

负载均衡 长连接 10月月更

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