社区所有版块导航
Python
python开源   Django   Python   DjangoApp   pycharm  
DATA
docker   Elasticsearch  
aigc
aigc   chatgpt  
WEB开发
linux   MongoDB   Redis   DATABASE   NGINX   其他Web框架   web工具   zookeeper   tornado   NoSql   Bootstrap   js   peewee   Git   bottle   IE   MQ   Jquery  
机器学习
机器学习算法  
Python88.com
反馈   公告   社区推广  
产品
短视频  
印度
印度  
Py学习  »  Python

Python:Bug 官网不要了,全迁去 GitHub!

玩转VSCode • 3 年前 • 402 次点击  


整理 | 郑丽媛
出品 | CSDN(ID:CSDNnews)

近几年,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 迁移将正式开始,届时相关开发者需注意迁移期间可能会带来的影响。

参考链接:

  • https://discuss.python.org/t/github-issues-migration-is-coming-soon/13791

  • https://lwn.net/SubscriberLink/885854/bb107c53bdebc248/

  • https://www.python.org/dev/peps/pep-0581/

END


推荐阅读:


玩转VS Code

VS Code · 编程开发 · 业界资讯

Python社区是高质量的Python/Django开发社区
本文地址:http://www.python88.com/topic/127848
 
402 次点击