Skip to content

Latest commit

 

History

History
133 lines (99 loc) · 10.7 KB

24-5.GitHub-Labels-and-Milestones.md

File metadata and controls

133 lines (99 loc) · 10.7 KB

GitHub Labels and Milestones

SaltStack使用多个标签类别以及里程碑来分类传入的issues问题并在GitHub问题跟踪器中提取pull requests。 标签用于按类型、优先级、严重性、状态、功能区域、功能组和目标发布请求分类，并按状态、功能区域、功能组、变更类型和测试状态进行拉取请求。 里程碑用于指示问题是否已完全分流或计划由SaltStack在即将到来的sprint中修复。

Milestones

所有issues问题都分配给一个里程碑，而pull requests几乎从未分配给一个里程碑，因为pull requests的平均寿命很短，因此无需临时跟踪它们。

SaltStack使用里程碑来指示哪些问题在submitter 或upstream 操作中被阻止，已批准或计划在即将到来的sprint中修复或实施。 如果某个问题未附加到sprint里程碑，则欢迎您根据自己的意愿和便利进行工作。 如果它附加在sprint里程碑上，并且您已经开始研究它，或者已经有了解决方案，或者有其他与此问题相关的想法，建议您通过GitHub问题跟踪器与代理人进行协调，以创建最佳解决方案或实施。

  • Approved - 已批准，该问题已得到验证，并包含所有必要的信息。
  • Blocked - 已阻止，问题正在等待SaltStack外部各方的行动，例如从提交者那里接收更多信息或解决上游问题。 此里程碑通常与Info Needed, Question, Expected Behavior, Won't Fix For Now, 或 Upstream Bug标签结合使用。

Labels

标签用于排序和描述问题以及pull requests请求。 尽管大多数标签可能同时应用于这两个标签，但某些标签通常保留给另一个标签。

新问题将至少获得一个标签和一个里程碑，而新的pull request请求将至少获得一个标签。 除functional area和functional group标签类别外，每个类别通常最多只能收到一个标签。

Type

Issues问题分为几种类型之一。 Type标签几乎从未用于拉取请求。 GitHub在很多方面都将拉取请求视为问题，因此拉取请求可以视为应用了隐式“pul request”类型标签的issue。

  • Feature - 问题是对新功能的要求，包括更改，增强，重构等。
  • Bug - 问题记录了损坏，不正确或令人困惑的行为。 此标签始终带有严重性标签。
  • Duplicate - 问题是另一个功能请求或错误报告的重复。
  • Upstream Bug - 该问题是上游问题的结果。
  • Question - 问题不仅仅是请求新功能或报告损坏的功能，而是更多的问题，但有时可能导致进一步的讨论或更改令人困惑或不一致的行为或文档。
  • Expected Behavior - 问题是预期功能的错误报告。

Priority

问题的优先级相对于其功能范围。 例如，如果关于gitfs的错误报告表明gitfs的所有用户都将遇到此错误，将应用P1标签，即使不使用gitfs的用户也不会遇到该错误。 如果许多用户要求使用某个功能，则可以赋予该功能较高的优先级。

  • P1 - The issue will be seen by all users.
  • P2 - The issue will be seen by most users.
  • P3 - The issue will be seen by about half of users.
  • P4 - The issue will not be seen by most users. Usually the issue is a very specific use case or corner case.

Severity

严重性标签几乎始终只应用于标识有Bug的问题。

  • Blocker - 问题阻止了即将发布的版本。
  • Critical - 此问题导致数据丢失，崩溃或挂起salt处理程序，使系统无响应等。
  • High Serverity - 该问题报告功能不正确，功能损坏，用户体验混乱等。
  • Medium Serverity - 该问题报告 cosmetic items, formatting, spelling, colors等。

Functional Area

Salt的许多主要组件都有相应的GitHub标签。 这些标签将适用于所有问题以及pull requests。 它们在组织issues和pull requests中很有用，用于提供源代码与issues的相关性或者是根据pull requests更改的源代码等方面的参考。

  • Execution Module
  • File Servers
  • Grains
  • Multi-Master
  • Packaging ，与Salt的包装相关，而不是Salt对包装管理的支持。
  • Pillar
  • RAET
  • Returners
  • Runners
  • SPM
  • Salt-API
  • Salt-Cloud
  • Salt-SSH
  • Salt-Syndic
  • State Module
  • Tests
  • Transport
  • Windows
  • ZMQ

Functional Group

这些标签根据内部SaltStack工程团队对问题进行排序并提出请求。

  • Core - 与Salt本身关键或存在的代码有关的issue 或 pull request。
  • Platform - 与各种平台（如传统操作系统和容器），基于平台的实用程序（如文件系统，命令调度程序等）以及基于系统的应用程序（如Web服务器，数据库等）的支持和集成有关的issue 或 pull request。
  • RIoT - 与各种抽象系统（如云提供商，虚拟机管理程序，基于API的服务等）的支持和集成有关的issue 或 pull request。
  • Console - 与SaltStack企业控制台有关的issue 或 pull request。
  • Documentation - 与文档有关的issue 或 pull request。

Status

状态标签用于定义和跟踪issues和pull requests的状态。 并非所有潜在状态都与标签相对应，但是某些状态很常见，因此已经为其创建了标签。 如果问题未移至“Blocked”里程碑之外，则很有可能只会带有状态标签。

  • Bugfix - back-port pull request需要反向移植到较早的发行分支。 这是通过针对该分支重新创建pull request来完成的。 back-port完成后，此标签将替换为Bugfix - [Done] back-ported标签。 通常，应在开发中加入新功能，并在最早的受支持发行版分支中进行错误修复，请参见 此处。

  • Bugfix - [Done] back-ported - pull request已经反向移植到较早的发行分支。

  • Cannot Reproduce - 该问题是一个错误，已由SaltStack工程师进行了审查，但无法使用所提供的信息和上下文进行复制。 与该错误相关的人员将需要研究其他想法，直到可以隔离和验证该错误为止。

  • Confirmed - 该问题是一个已被SaltStack工程师确认的错误，他们会经常记录一个最小的可重现该错误的工作示例。

  • Fixed Pending Verification - 该问题是一个错误，已通过一个或多个pull requests解决，该请求应链接到该问题。 该问题的完成取决于提交者确认的解决方案。 如果提交者报告否定确认，则该标签将被删除。 如果几周后未给出任何答复，则将认为问题已解决并已解决。

  • Info Needed - 该问题需要更多信息，然后才能进行验证和解决。 对于 feature request ，这可能包括用例的描述。 几乎所有的错误报告都至少需要包含salt的版本及其依赖项，系统类型和版本，使用的命令，调试日志，错误消息以及相关的配置。

  • Pending Changes - pull request需要进行其他更改才能合并。

  • Pending Discussion - 在关闭或合并问题或请求之前，需要进行更多讨论。 issue 或 pull request的状态不清楚或不够明显，无法采取确定的措施，或者已请求SaltStack，提交者或另一方的其他输入。

    如果问题不是紧急请求，则一旦讨论得出有力的结论，该标签将被删除并接受问题。 如果是 pull request请求，则讨论结果可能需要进行其他更改，并因此需要“Pending Changes”标签。

  • Won't Fix for Now - 该问题是合法的，但SaltStack团队目前尚无能力或愿意解决或实施。 将来可能会重新考虑带有此标签的问题。

Type of Change

每个pull request都应收到一个更改标签。 这些标签可衡量变更的数量以及变更的重要性。 考虑到更改的数量和更改的代码区域的重要性，通常需要进行二次代码审核的深度以及更改的潜在影响也可能会建议准确选择标签。

核心代码区域包括：状态编译器、加密引擎、master、minion和syndic守护程序、传输、pillar渲染、加载器、传输层、事件系统、salt.utils、客户端、cli、日志记录、netapi、runner引擎、模板引擎、topfile 文件编译、file client、file server、mine、salt-ssh以及test runner等。

非核心代码通常构成Salt的几个插件层中的每一层的特定插件集：执行模块、状态、运行器、返回器、云等。

  • Minor Change
    • 少于 64 行代码变更，或者
    • 少于 8 行核心代码变更
  • Medium Change
    • 少于 256 行代码变更，或者
    • 少于 64 行核心代码变更
  • Master Change
    • 多于 256 行代码变更，或者
    • 多于 64 行核心代码变更
  • Expert Change
    • 需要专业的、深入的评审

Test Status

这些标签与对pull requests运行的自动测试的状态有关。 如果对pull requests的测试失败并且没有被这些标签之一覆盖，则pull requests提交者需要更新代码和/或测试，以便测试通过并且可以合并pull requests。

  • Lint - 除代码lint checker检查器外，该pull request已通过所有测试。
  • Tests Passed - 即使某些测试结果是否定的，pull request也通过了所有测试。 有时，自动化测试基础结构会遇到与pull request中的代码更改无关的内部错误，这些错误会导致测试运行失败。 这些错误可能是由云主机和网络问题以及Jenkins问题引起的，例如错误累积工作空间工件，资源耗尽以及长期运行的Jenkins进程引起的错误。

Other

这些标签表示其他问题类型或状态，这些问题或状态很常见或很重要，可以使用标签进行跟踪和排序。

  • Awesome - pull request实现了精心设计的解决方案，或者非常困难但必要的更改。
  • Help Wanted - 这个问题似乎有一个简单的解决方案。 对于新来的贡献者来说，带有此标签的问题应该是一个很好的起点。
  • Needs Testcase - issue 或 pull request 与需要测试覆盖的功能有关。 包含测试的pull request 应参考具有该标签的问题或请求，然后应删除该标签。
  • Regression - 问题是一个错误，该错误会破坏以前版本中已知的功能。
  • Story - SaltStack工程师使用该问题在一个地方跟踪多个相关问题的进度。
  • Stretch - 该问题是当前sprint的可选目标，但可能无法实现。
  • ZD - 该问题与Zendesk客户支持票证有关。
  • - 该问题计划由<Release>实施。 有关Salt发行版本代号的讨论，请参见 此处。