PerfMa

IT系统稳定性保障专家

请至少选择一个您感兴趣的方案
发送验证码

感谢您的提交!

我们会在2工作日内与您联系

产品

全天候为您的IT系统稳定运行提供有力保障
即刻开启您的IT系统稳定性保障之旅

XSea 全链路压测平台

多地域高仿真流量模拟、端到端流量染色与数据隔离、全链路压测风险熔断

XWind 性能风险巡检与诊断平台

无人值守智能分析、风险处理能力闭环、可拓展性能风险知识库、丰富图表及报告、开放API助力DevOps

TestMa 质量效能平台

全流程的质量闭环,可度量的质量数据,无门槛的接口编排,高效率的精准测试

XChaos 混沌工程平台

应用架构智能感知、故障演练场景丰富、高级多流程编排、多维度演练观测、过程安全控制、第三方集成扩展

XSpider 监控平台

无侵入实时性能分析、低性能开销、动态采样、根因定位

解决方案

沉淀PerfMa多年的业务经验,提供金融、
证券、快消、交运等多个领域的解决方案

金融

依托全链路压测平台的能力,建立一套完整的性能保障体系

电商

基于平台的建设及专家咨询服务,进行统一平台管理,实现工具、框架的统一

连锁快消

实现多维自动化能力,协助构建标准化的性能测试及回归体系,提升测试效率

交通运输

以数据驱动,形成标准化测试能力,保障系统的正确性、性能容量及可靠性

公司动态

全方位汇集PerfMa大小资讯
寻找对您有帮助的事件

PerfMa新闻

PerfMa公司最新动态或消息,为您提供关于PerfMa公司的第一手资讯

PerfMa活动

为您提供PerfMa线上线下精彩活动回顾及预告

关于

和优秀的小伙伴一起共事
不负初心,用技术的力量创造梦想

关于PerfMa

强大的专业团队、企业资深专家,致力于为企业提供性能领域的全方位解决方案

加入我们

浓厚的工程师文化、靠谱的发展平台、舒适的办公环境,拥抱变化中快速成长

社区&开源

汇聚IT系统稳定性领域问题诊断调优精英
共建IT系统稳定性领域问题诊断调优标准和能力

专注性能领域垂直社区,几十万开发者在这里交流性能问题,分享技术干货,是开发者们学习和成长的乐园。


访问HeapDump社区 >

为终结性能问题而生的开源插件容器,将定位/解决各种性能问题的工具适配成插件,通过相互联动组合,一键解决您的性能问题。


访问XPocket官网 >
Python:Bug 官网不要了,全迁去 GitHub
2022-02-28

近几年,GitHub 开发者数量逐年上升,仅过去一年 GitHub 的新增用户便有 1600 万人,总用户数更是达到了 7300 万——在开源浪潮席卷全球中,GitHub 无疑成为了许多开发者迈入开源的一个重要途径。

 

Python 开发团队或许正是看中了这一点,才决定将 Python 开发基础设施逐步迁移至 GitHub。目前这项迁移工作已进行近 7 年,但最近卡在了“将 Python 的 Bug 迁移至 GitHub”这一步。

 

一、技术&法律,两面受阻


相信大多 Python 程序员应该有所了解:此前,如需进行 Bug 提交、跟踪、修复等操作,一般可前往 Python 官方 Bug 网站(https://bugs.python.org/,可简称为 BPO),而 BPO 所用的 Bug 跟踪器为开源工具 Roundup,即由 Roundup 存储 Bug 相关数据。

 

为了顺利将 Python 的 Bug 迁移至 GitHub,上周 Python 核心开发者 Łukasz Langa 在 Python Discourse 论坛上宣布:

 

Roundup 中的 Bug 数据将全部迁移至 GitHub 的 Python 存储库中,此后用户和核心开发者发现的新 Bug 统一在 GitHub Issue 中处理;同时为避免 BPO 中 URL 失效引发混乱,此后 BPO 将以只读模式继续存在,而当前 BPO 中存在的每个 Bug 都将链接其 Github 地址。

 

“我们希望这将降低新贡献者的门槛,并提供更流畅的用户体验。”Łukasz Langa 解释道。

 

理想很丰满,但现实却很难如意。Łukasz Langa 感慨:“不论在技术还是法律层面上,这都不是一件容易的事。”为此,他自一月份起,就一直与同为 Python 开发者的 Ezio Melotti 共同讨论如何推动本次迁移任务。

 

二、复杂的迁移过程


Łukasz Langa 将整个 Bug 迁移工作分为测试反馈阶段及正式迁移阶段:

 

(1)以下为测试反馈阶段时间表:

 

  • 2022 年 2 月 18 日开始为期两周的公众反馈收集期。在此期间,开发者可前往 https://github.com/psf/gh-migration/issues/ 查看 Bug 迁移、测试执行等详细步骤并报告具体问题,还可前往 https://github.com/psf/gh-migration/issues 查看一些迁移 Bug 的示例。
  • 2022 年 3 月 4 日,在 Github 的帮助下,使用 10% 的 Bug 执行最终的端到端测试迁移,以此估算迁移所需时间及过程中可能会出现的问题。

 

(2)如果反馈收集过程中没有发现任何问题,最终测试也成功实现,就开启正式迁移阶段:

 

  • 2022 年 3 月 10 日开始迁移。BPO 在欧洲中部时间晚上 9 点(太平洋标准时间下午 12 点)进入只读模式,BPO 中的数据将被导入 Github 上的临时存储库中(此过程预计需要 22 个小时)。
  • 2022 年 3 月 11 日,Github 开始将临时存储库中的 Bug 全部转移至 Python 库中。

 

据 Łukasz Langa 预计,正式迁移大概需要花费 3-7 天的时间(具体取决于 Github 的负载),而 Bug 迁移期间,Python 程序员需要注意以下几点:

 

  • 不可在 Github 或 BPO 上创建新 Bug;
  • 可以在 Github 上创建新 PR 并与现有 PR 交互,这点不会被影响;
  • 可以与 Github 上已迁移的 Bug 进行交互,但尽量不要有破坏性操作(如修改 Bug 标题、编辑评论内容、删除评论、删除标签等),因为数据更改会使迁移团队无法确定迁移是否完全成功。

 

Bug 数据迁移完成后,Python 官方会进行相关通知;但如果迁移无法在 7 天内完成,这项工作将中止并重新启用 BPO。

 

除了以上技术方面的问题,本次迁移任务还牵扯到了部分法律纠纷,主要集中在“Python 软件基金会(PSF)是否可以在不征求用户同意下,将用户生成的内容及其潜在的个人身份信息(PII)从 BPO 移动到 GitHub”。

 

关于这个问题,指导委员会和 PSF 律师确定,此次迁移不需要用户同意:

 

“BPO 和 Github 都是面向公众的系统,用户主动将他们的信息(包括 PII)放在 BPO 系统中,BPO 将根据主动同意存储、公开访问等权限,按需分发这些信息。而我们将后端更改为 Github 并不会修改这些权限,迁移过程中也不会显示之前在 BPO 系统中不允许公开访问的任何新用户信息。”

 

三、放弃 BPO 的理由


在看过以上迁移流程后,或许会有人疑惑:既然迁移这样麻烦,继续用 BPO 不“香”吗?针对这类问题,Python 官方早在 2018 年创建的 PEP 581 提案中就明确回应了。

 


该提案中,罗列出了一串 Roundup/BPO 中已知存在的问题:包括核心开发者在内,维护人员不到 5 人;没有可用的 CI(持续集成),现有维护人员的负担太大(需要审查、测试和应用补丁);隔绝了来自外界开发者的大量贡献;UI 需重新设计;易暴露用户的电子邮箱,还经常发垃圾邮件给用户;注册新账户过程繁琐…

 

但这一切问题,可能在部分已习惯 BPO 的开发者眼中,“罪”还不至于被放弃的地步,甚至希望 BPO 维护人员可以就这些问题加以改进。不过,Python 官方坚持认为:“GitHub 中有很多我们喜欢的功能,并且我们相信,创建和维护 GitHub 集成及相关工作量,要远低于加速并维护 Roundup 所需的工作量。”

 

最后,正如上文所提到的迁移流程,按计划自 3 月 10 日起 Bug 迁移将正式开始,届时相关开发者需注意迁移期间可能会带来的影响。

 

文章来源:CSDN
链接:https://blog.csdn.net/m0_50065287/article/details/123126314

请至少选择一个您感兴趣的方案
发送验证码

感谢您的提交!

我们会在2工作日内与您联系

业务咨询电话:4008-717-107

公司联系电话:0571-8500-1801