GitHub 上的 IPython#

注意

这完全复制自旧的 IPython wiki,目前正在开发中。本开发指南的许多信息已过时。

GitHub 工作注意事项

里程碑#

  • 所有已确认的问题都应有一个里程碑。

  • 问题在没有里程碑的情况下绝不应关闭。

  • 所有拉取请求都应有一个里程碑。

  • 所有已关闭的问题都应标记为下一个发布里程碑、下一个向后移植里程碑或无操作

  • 只有在以下情况下,未解决的问题才可能没有里程碑:

    • 需要更多澄清(标签:needs-info

  • 通常,将有四个里程碑包含未解决的问题

    • 下一个次要版本。此里程碑包含应为下一个次要版本向后移植的问题。有关向后移植的信息,请参见下文

    • 下一个主要版本。这应该是所有问题的默认里程碑。随着发布的临近,问题可以明确地推迟到下一个版本 + 1。

    • 下一个主要版本 + 1。只有我们确信不会包含在下一个版本中的问题才归入此里程碑。此里程碑在发布之前应基本为空。

    • 愿望清单。这是我们目前没有计划解决的问题的里程碑。

  • 其余的里程碑是针对不需要任何操作的已打开或已关闭问题的无操作

    • 并非实际问题(例如问题、讨论等)

    • 现有问题的副本

    • 已关闭,因为我们不会修复它

    • 当一个问题以无操作关闭时,这意味着该问题将不会被修复,或者它根本不是一个问题。

  • 关闭问题时,它应始终具有以下里程碑之一:

    • 下一个次要版本,因为问题已解决

    • 下一个主要版本,因为问题已解决

    • 无操作,因为问题将不会被解决,或者它是重复/非问题。

通常:如有疑问,请标记为下一个版本。当我们接近给定版本时,我们总是可以推迟。

标签和问题#

问题一旦被确认,就应始终贴上标签(对于仍在澄清或可能是重复或根本不是问题的问题,则不必要)。

一些重要的标签

  • needs-info:问题需要提交者提供更多信息才能取得进展

  • bug:引发错误或发生意外行为

  • enhancement:非错误性的改进

  • backport-X.Y.Z:此问题的任何修复都应向后移植到维护分支。向后移植以里程碑表示,从 2.1 开始。

  • prio-foo:用于对问题进行排名的优先级级别——非必要,但 prio-high/low 对于明确提升/降低问题很有用,尤其是在临近发布时。

  • ClosedPR:此问题是关于因过期而关闭的 PR 的提醒。

  • sprint-friendly:明显或简单的修复,其中

所有已确认的问题都应至少有一个bugenhancement标签,并标记有任何受影响的组件(例如parallelqtconsolehtmlnotebook),或特定的错误来源(例如py3kunicode),如果我们有适当的标签。

sprint-friendly标签可能是新贡献者开始的最佳位置。

拉取请求#

  • 所有工作都通过拉取请求提交。

  • 只要有值得讨论的代码,就可以提交拉取请求。拉取请求跟踪分支,因此您可以在提交 PR 后继续工作。审查和讨论可以在工作完成之前很久就开始,讨论越多越好。最坏的情况是 PR 被关闭。

  • 已停滞的拉取请求应关闭(请参阅[[我们关于关闭 PR 的政策|开发:关闭拉取请求]])

  • 拉取请求应始终针对主分支(向后移植 PR 在下面描述)。

  • 拉取请求应在可行的情况下进行测试

    • 错误修复应包括回归测试

    • 新行为至少应进行最少程度的演练

Travis在测试IPython和拉取请求方面做得相当好,但手动执行测试可能更有意义(可能使用我们的test_pr脚本),特别是对于影响IPython.parallel或Windows的PR。

打开问题#

打开新问题时,请采取以下步骤:

  1. 在GitHub和/或Google上搜索您的问题,以避免重复报告。对错误消息进行关键词搜索最有用。

  2. 如果可能,请尝试更新到主分支并重现您的问题,因为我们可能已经修复了它。

  3. 尝试包含一个最小可重现的测试用例

  4. 包含相关的系统信息。从以下输出开始:

    python -c "import IPython; print(IPython.sys_info())"
    

并根据问题包含任何相关的包版本,例如matplotlib、numpy、Qt、Qt绑定(PyQt/PySide)、tornado、网络浏览器等。

向后移植#

  • 我们应该保留一个A.x维护分支,用于从主分支向后移植修复。

  • 该分支应称为A.x,例如2.x,而不是2.1。这样,每个发布系列只有一个维护分支。

  • 当一个问题被确定适合向后移植时,应将其标记为A.B里程碑。

  • 任何解决向后移植问题的拉取请求也应获得相同的里程碑。

  • 补丁通过将拉取请求补丁应用于维护分支(目前使用backport_pr脚本)向后移植到维护分支。