ICU票据生命周期

（请参见提交ICU错误和功能请求有关ICU JIRA问题跟踪程序的一般信息。）

ICU票据在其生命周期中遵循一条明确的路径，从最初的开放到实施或修复，再到关闭和发布ICU更新版本中的更改。

票证类型

    1. Bugs（错误）：打开这些报告是为了报告ICU库代码的一些问题。

      • 一份好的错误报告应该包含足够的信息，以便重现问题，包括（视情况而定）

        • ICU版本

        • 操作系统类型和版本

        • 编译器版本

        • 对于Java代码，JDK版本

        • 展示问题的代码片段，最好是小而独立的

      • 一些旧票据具有Type=Bug，但是关于API文档、工具问题等的错误报告。这些早于更具体的票据类型。

  1. 增强功能：这些是开放的，用于报告ICU可以改进但不一定存在缺陷的领域。示例：绩效改进；消毒剂贴片；构建系统更改。

  2. 新功能：开放这些功能以请求向ICU添加新功能或功能。

      • 注意：一些旧票据有一个“RFE:”摘要前缀（Request for Enhancement），但由于我们切换到了带有Type字段的更好的问题跟踪器，所以我们不再使用这样的前缀。

      • 大多数此类票据都需要API提案。

  3. 任务：这些表示为支持ICU项目而要完成的工作项，库用户无法直接看到这些工作项。

  4. 测试：测试代码中不影响库代码的错误或增强。

  5. API文档,用户指南, ...: 对于非代码问题。

票据组件

我们为ICU中有缺陷或可以改进的部分设置了一个组件。我们将其用于筛选/优先排序/调度。请参阅 Jira上的ICU组件页面.

提交

任何人都可以随时提交门票。在提交错误报告之前，最好检查问题是否已被报告。

入场券

ICU团队大约每周审核一次新机票。（有时新门票的推出速度超过了我们的处理能力。）

我们讨论每个问题，并将其分配给团队成员，或将其作为重复、超出范围等关闭。

即使是团队成员也应该在我们的团队会议上讨论后分配/接受门票。如果有紧急情况，请向团队邮件列表发送一封电子邮件，其中包含门票链接和简要说明，并注意您正在抢购门票。

我们通常会为即将到来的ICU版本安排门票，但我们更急于接受和安排门票，这超出了我们的处理能力。不幸的是，无论是即将发布的“修复版本”还是高度优先级，都不能保证届时问题会得到解决。唯一的保证是事后状态=完成。

优先级主要基于为项目提供开发人员的公司的要求，和/或基于团队成员的优先级。

为了将票据移出Status=New，需要设置以下字段：

    • 成分

    • 修复版本（可以是“未来”以使其不计划）

    • 受让人

    • 优先级≠评估

设置好后，在团队协议或电子邮件通知后，团队成员可以单击“接受”。

设计

如果我们不确定什么是正确的方法，我们将问题放入Status=Design。所有人应该提出一个团队同意的计划，然后再接受，或者可能因为不可行而关闭罚单，等等。

开发和审查

在实际工作开始时，开发人员应该接受票据，并将“修复版本”字段设置为即将发布的ICU版本（如果尚未设置）。

有关代码更改：请参阅 ICU开发人员的git第页。批准并合并一个或多个请求后，ICU团队成员（如果是票据所有者，则为票据所有者）将票据关闭为“完成/已修复”。

对于非代码更改：更新用户指南文本、执行任务等，然后添加注释，设置票证审阅者，并将票证置于状态=审阅中。审阅者可能会通过Status=ReviewFeedback要求您执行更多操作，或者如果他们满意，可以将其关闭为Fixed。

过时：svn分支开发

对于非平凡的提交（如果有疑问，这是非平凡的），最好在分支。请参阅“合并和分支”获取有关分支工作的一些提示。下面是一些示例，说明为什么要在分支上工作：

    • 你期望争论：在一段时间内，这是一个涉及面很大的更改，其他开发人员可能会提交与您冲突的代码。

    • 你在找回顾和/或测试在开发过程中：其他人可以拿起分支并尝试它，或者查看提交。

    • 你期望试验破损在开发过程中。提交到主干不应破坏测试。在树枝上工作，直到测试干净。

所有返回到subversion的代码提交都必须包含与提交消息相关联的票证号。审核人员将使用此信息来确定与特定票据相关的完整更改列表。

svn提交消息具有以下形式

票证：1234：一条描述签入更改的短消息

由其他更改修复

如果记录单-缺陷或功能-由与不同记录单相关的更改处理，则应在涉及的每个记录单中添加情况的简要说明，除实际工作发生的记录单外，所有记录单都应转至Status=Review；如果连接明显，则直接转到完成/修复。

我们不想忘记这样一个事实，即一个报告的问题之所以得到了解决，仅仅是因为它是一组相关问题中的一个，而这些问题是通过一组代码更改修复的。

测试

对于缺陷，在对实现代码进行任何修复之前，应该编写一个由于问题而失败的测试。然后应该修复问题，并通过刚写的测试检查修复情况。

C和Java

大多数ICU服务同时存在于C和Java中。应检查（测试端口）报告给另一方的任何缺陷，如果存在，也必须检查。必须这样做之前转到审查步骤。

维护版本

某些高影响力票据可能会添加到维护分支机构。要建议将提交添加到维护分支，请选中提交到维护分支并针对维护分支创建拉请求。有关更多详细信息，请参阅 gitdev公司.

大多已过时：

要将Unicode主服务器更改合并到Unicode维护分支，请使用维护票据，例如 国际癌症研究所20049并将pull请求与Unicode主机的cherry-pick提交一起使用。对于票证修复版本，使用下一个维护编号（62.1之后的62.2），无论我们是否实际计划发布。

TODO公司：添加有关如何进行樱桃点击提交的说明。

TODO:回顾一下GitHub时代的这一部分。这似乎是这个内容的错误页面。合并到 BRS/发布#标记相关的svn文件和/或源代码访问和/或 ICU开发人员的git?

对于每个版本，我们都会创建一个维护分支，通常是在发布候选版本之前。例子： http://bugs.icu-project.org/trac/log/branches/maint/maint-60

主干和维护分支可能会在初始发布之前出现一些分歧。发布经理会将为候选发布版本同意的更改挑选到维护分支中。

当我们发布候选版本时，我们从维护分支创建一个标记。例子：http://bugs.icu-project.org/trac/log/tags/release-60-rc

发布管理器可能会从主干向维护分支提交更多的樱桃点状变更集。

初始版本是维护分支的另一个标签。示例：ICU 60.1http://bugs.icu-project.org/trac/log/tags/release-60-1

当我们有错误应该进入维护分支或版本时，我们设置下一个里程碑（例如61m1）并添加关键字“maint”。错误修复变更集使用错误修复票证编号提交到中继。

当我们决定对维护分支应用错误修复时：

    • 对于维护分支或最新ICU版本的版本，例如60.2：

      • 如果还没有60.2里程碑，那么将其添加到路线图中，并创建60.2发布票证。

      • 60.2版本管理器将错误修复cherry-pick变更集提交给维护分支。

      • 然后将错误标签更改为里程碑60.2。

      • 注：因此，ICU 61的门票显示了自上次ICU 60.x维护版本以来发生的变化，与用户看到的最新官方版本保持一致。

    • 对于早期ICU版本的维护分支或版本，例如58.3：

      • 如果还没有58.3里程碑，那么将其添加到路线图中，并创建58.3发布票据。

        • 即使我们不打算实际发布58.3版本，也要使用58.3。

        • 不要将里程碑称为“58.x”。使用下一个可用的维护版本次要版本号。

      • 58.3版本管理器将错误修复cherry-pick变更集提交给维护分支。

      • 然后将关键字“maint58.3”添加到错误记录单。

      • 一张票据可能会收集多个此类关键字。

当我们发布维护版本时，我们从维护分支创建一个标记。例子：http://bugs.icu-project.org/trac/log/tags/release-60-2

注：其中一些是2017-12-13年12月以来的新情况。在此之前，我们像对待早期版本一样对待最新ICU版本的维护分支和发布，并且我们没有使用特定于发布的maint58.3等关键字。