ORSP004.md

ORSP004 openEuler RISC-V 定时快照构建规范

Meta info

提议者：周嘉诚、罗云翔、席静、吴伟

时间：2022-05-09

背景 / Background

openEuler RISC-V 自动构建基础设施初步建立，而定时快照的构建方式未有成文规范。测试团队要求新的快照与附带的软件源在测试周期内不会变动以便于追溯和复现。

问题 / Issues

1. openEuler RISC-V 目前测试工作反馈周期较长，现行版本和软件源管理方式难以满足测试要求的一致性与可复现性，出现的问题难以排查。

提议 / Proposal

1. 本提议希望在先前的 ORSP003 基础上确立 openEuler RISC-V 定时快照的构建规范。
2. 定时快照单次构建的产物至少应当包括快照镜像与其附属软件仓库。软件仓库与镜像一一对应，在制作之后当保持静止不作删改。遇有特殊情况，应另设附加仓库存放对应此版本镜像的更新或修复软件包，以保证可复现性。
3. 开发团队至少应为 QEMU、Allwinner Nezha/D1、HiFive Unmatched 和 VisionFive V1 四个对象提供定时快照，无法全部提供时至少应保证 QEMU 快照的成功构建；开发快照每日构建一次或以上，以供开发流程验证；测试快照每周构建一次或以上，以供测试使用；稳定快照每月构建一次或以上，以供测试或发版使用。
4. 构建产物应在保证目录结构向后兼容的同时按开发、测试、稳定快照与正式大版本的分类方式存放于软件源中以供公开下载，所有构建产物应具有全局唯一的构建日期或版本号以相互区分避免歧义。暂定以 $VERSION_FLAG/$VERSION_DATE/$VERSION 方式进行版本的命名，其中 VERSION_FLAG 为构建用途，VERSION_DATE 为构建时间，VERSION 为当日版本号。
5. 测试版、稳定版的快照应当保留 90 天或在条件允许时保留到对应大版本发布为止。某版本超过保留期限，但仍有测试等需求时，维护者可协商延长保留期限。开发版对保留时间不做要求。
6. 相关资料与权责信息在 gitee:openEuler/RISC-V 仓库中进行维护。

时间线 / Timeline

2022-05-10: 基础设施开始构建，产物对外开放同步到至少一个下游（周嘉诚）

2022-05-25: 构建产出可满足测试团队双周测试要求（周嘉诚）

资源 / Resources

• openEuler RISC-V SIG 负责方向及路线规划、与 openEuler 各 SIG 进行沟通协调。
• 中国科学院软件研究所 Tarsier 团队周嘉诚负责担任发布方面的协调者。