GitHub 上的 IPython#

注意

这是从旧的 IPython wiki 原封不动复制过来的，目前正在开发中。本开发指南中此部分的大量信息已过时。

使用 GitHub 的说明

里程碑#

100% 的已确认问题应具有里程碑。
问题绝不应在没有里程碑的情况下关闭。
所有拉取请求都应具有里程碑。
所有已关闭的问题都应标记为下一个版本里程碑、下一个反向移植里程碑或无操作。
只有在以下情况下，开放的问题才不应具有里程碑
- 需要进一步澄清（标签：needs-info）
通常，将有四个具有开放问题的里程碑
- 下一个次要版本。此里程碑包含应为下一个次要版本反向移植的问题。有关反向移植的信息，请参见下方。
- 下一个主要版本。这应是所有问题的默认里程碑。随着版本的临近，问题可以明确提升到下一个版本 + 1。
- 下一个主要版本 + 1。只有我们确信不会包含在下一个版本中的问题才会出现在这里。此里程碑在接近发布之前应基本为空。
- 愿望清单。这是我们没有立即计划解决的问题的里程碑。
剩余的里程碑是无操作，适用于不需要操作的开放或已关闭问题
- 实际上不是问题（例如问题、讨论等）
- 现有问题的重复
- 关闭，因为我们不会修复它
- 当问题以无操作关闭时，这意味着该问题不会得到修复，或者它根本不是问题。
关闭问题时，它始终应具有以下里程碑之一
- 下一个次要版本，因为该问题已得到解决
- 下一个主要版本，因为该问题已得到解决
- 无操作，因为该问题不会得到解决，或者它是一个重复/非问题。

一般来说：如有疑问，请标记为下一个版本。当我们接近给定版本时，我们始终可以推迟。

标签和问题#

一旦问题得到确认，就应始终对其进行标记（对于仍在澄清中、可能是重复或根本不是问题的问题，没有必要）。

一些重要的标签

needs-info：在取得进展之前，问题需要提交者提供更多信息
bug：引发错误或发生意外行为
enhancement：不是 bug 的改进
~~backport-X.Y.Z：对该问题的任何修复都应反向移植到维护分支。反向移植用里程碑表示，从 2.1 开始。~~
prio-foo：用于对问题进行排名的优先级 - 非必要的，但 prio-high/low 对于明确提升/降低问题的优先级非常有用，尤其是在接近发布时。
ClosedPR：此问题是提醒一个因过时而关闭的 PR。
sprint-friendly：明显或简单的修复，其中

所有已确认的问题至少应具有bug或enhancement标签，并标记为任何受影响的组件（例如parallel、qtconsole、htmlnotebook），或特定错误来源（例如py3k或unicode），如果我们有适当的标签。

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

拉取请求#

所有工作都通过拉取请求提交。
一旦有值得讨论的代码，就可以提交拉取请求。拉取请求会跟踪分支，因此可以在提交 PR 后继续工作。在工作完成之前就可以开始审查和讨论，讨论得越多越好。最坏的情况是 PR 被关闭。
已暂停的拉取请求应被关闭（参见[[我们关于关闭 PR 的政策|Dev: 关闭拉取请求]])
拉取请求应始终针对 master（PR 的反向移植将在下面描述）。
如果可行，应测试拉取请求
- 错误修复应包括回归测试
- 新行为至少应获得最小的练习

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

打开问题#

打开新问题时，请执行以下步骤

在 GitHub 和/或 Google 中搜索你的问题，以避免重复报告。对错误消息进行关键字搜索最有用。
如果可能，请尝试更新到 master 并重现你的问题，因为我们可能已经修复了它。
尝试包含一个最小的可重现测试用例
包括相关的系统信息。从以下内容的输出开始
```
python -c "import IPython; print(IPython.sys_info())"
```

并根据问题包括任何相关的软件包版本，例如 matplotlib、numpy、Qt、Qt 绑定（PyQt/PySide）、tornado、网络浏览器等。

反向移植#

我们应该保留一个 A.x 维护分支，用于反向移植 master 中的修复。
该分支应称为 A.x，例如 2.x，而不是 2.1。这样，每个发布系列只有一个维护分支。
当确定某个问题适合反向移植时，应将其标记为 A.B 里程碑。
解决反向移植问题的任何拉取请求也应收到相同的里程碑。
通过将拉取请求补丁应用到维护分支（当前使用 backport_pr 脚本），将补丁反向移植到维护分支。