Eclipse OpenJ9 提交者操作指南：规范与最佳实践

Eclipse OpenJ9 提交者操作指南：规范与最佳实践

openj9 项目地址: https://gitcode.com/gh_mirrors/ope/openj9

前言

作为 Eclipse OpenJ9 项目的提交者（Committer），您肩负着代码质量把控的重要职责。本文将系统性地介绍在代码审查和合并过程中需要遵循的规范与最佳实践，帮助您高效、规范地完成代码管理工作。

核心原则

1. 避免自我合并

提交者不应自行合并自己发起的合并请求（Pull Request），这是保证代码审查独立性的基本原则。

2. 变更影响评估

当合并请求涉及项目贡献指南修改时，必须要求作者在合并后向开发邮件列表发送详细的变更摘要，确保社区成员了解变更内容。

3. 责任归属明确

• 只有被列为合并请求指定人（Assignee）的提交者才能执行合并操作
• 作为主要提交者，您需要：
  • 主动将自己添加为指定人
  • 必要时可邀请特定领域专家进行深度技术评审（通过@提及）
  • 即使委托他人评审，仍需亲自过目变更内容

合并前检查清单

1. 基础验证

• 确认合并请求标题不含"WIP:"前缀（表示工作尚未完成）
• 确保所有被@提及要求评审的开发者都已提供反馈
• 所有自动化验证和持续集成构建必须通过
  • 特殊情况需在合并请求中明确记录跳过验证的合理理由

2. 提交规范

• 检查每个提交（commit）的标题和描述是否准确反映变更内容
• 合理压缩提交记录：
  • 确保每个提交包含逻辑上独立的变更集
  • 消除无明确理由的冗余提交

3. 测试覆盖

• 必须触发足够的构建测试覆盖所有受影响架构和语言级别
• 可针对特定平台限制测试范围（如仅修改x86相关文件时），但需：
  • 在评论中明确说明理由
  • 确保新增提交后重新触发测试
  • 基础设施问题导致的失败必须重新执行

4. 文档同步

• 代码变更如需配套文档更新：
  • 为合并请求添加depends:doc标签
  • 确认关联文档仓库的合并请求已准备就绪
  • 两者需同时批准才能合并

特殊场景处理

1. 代码回滚

当合并请求涉及撤销之前的提交时：

• 必须包含清晰的回滚原因说明
• 需创建问题单（Issue）关联回滚提交与原始合并请求
• 必须@通知原始作者确保问题得到跟进

2. 与OMR项目的协同合并

当变更需要同时在OpenJ9和OMR项目提交时：

操作流程（仅限双项目提交者执行）：

1. 预验证：在OpenJ9合并请求上执行包含OMR变更的完整测试

   Jenkins test sanity.functional,sanity.openjdk all jdk8,jdk11,jdk17,jdk21 depends eclipse/omr#{OMR PR号}
   

2. 通知：在公共Slack频道声明协同合并意向

3. OMR操作：

   • 合并OMR项目的合并请求
   • 执行镜像构建将OMR变更同步到OpenJ9-OMR仓库

4. OpenJ9操作：

   • 取消自动触发的验收构建（因已预验证）
   • 执行OMR变更提升操作
   • 最终合并OpenJ9变更

5. 完成通知：在Slack频道确认协同合并完成

最佳实践建议

1. 明确批准：无论变更简单与否，都应明确表达批准意见

2. 元数据完善：为问题和合并请求添加描述性标签，提高可追溯性

3. 工具使用：

   • 利用JIT linter自动检查（在PR打开/同步时自动触发）
   • 必要时可从PR的Checks标签手动重新运行

4. 变更记录：确保所有操作步骤和决策理由都有清晰的文档记录

通过遵循这些规范和实践，您将能够有效地维护Eclipse OpenJ9项目的代码质量，同时促进开发团队的高效协作。记住，作为提交者，您的每个决策都直接影响着项目的健康发展。

openj9 项目地址: https://gitcode.com/gh_mirrors/ope/openj9