2 项目测试与发布流程
2 日常开发
本节介绍项目如何通过 Autobuilder 自动化测试与 QA 团队协作， 验证变更并最终发布版本。
项目希望在变更合入 master 分支之前，先通过测试矩阵验证。
因此，变更会分批排入主仓库的 master-next 分支，
或 poky-contrib 中的 ross/mut 等个人测试分支。
Ross Burton 参与补丁审查与测试，ross/mut 就是他的测试分支。
测试构建主要分为“完整”（full）与“快速”（quick）两类。 Autobuilder 界面中分别显示为 “a-full” 和 “a-quick”，前缀只是为了便于排序。 大多数测试相关工作可在 Autobuilder 的 控制台视图 中查看。
测试分支准备好后，由人工触发构建，并由 SWAT 团队监控。
详情见 https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team。
测试成功后，通常将变更合入 master；如果失败，
会有人在邮件列表中回复相关变更，说明测试失败的情况。
选择快速测试还是完整测试，取决于变更类型以及需要多快获得结果。
Autobuilder 每天会构建一次 master，首先是确保当前主干仍能构建，
同时也更新 yocto-testresults、
buildhistory 和共享状态缓存。
周末改为构建 master-next，以更新那些平时较少运行的目标的测试结果。
性能构建在控制台中以 buildperf-* 为目标名，每六小时单独触发一次，
结果会自动推送到 buildstats 仓库。
快速测试选择最容易发现问题或能提供最有价值数据的目标。
例如，它会运行耗时较短的 ptest，而不会运行耗时很长的测试。
快速目标不包含所有架构的 *-lsb 构建、部分 world 构建，
也不触发性能测试或 ltp 测试。完整构建包含这些内容，因此更慢但覆盖更全面。
2 版本发布构建
项目通常每年发布两个主要版本，间隔六个月，分别在四月和十月发布。 两个主要版本之间会有若干里程碑版本（通常四个），最后一个里程碑仅用于稳定性工作； 稳定分支还会发布维护版本。
发布构建与 日常开发 中的流程相似， 同样使用 Autobuilder 的 a-full 目标，但还要在表单中启用构建产物的生成和发布， 并填写里程碑编号、版本、候选发布编号等信息，同时勾选 “generate an email to QA”。
构建完成后，yocto-autobuilder-helper
仓库中的 send-qa-email 脚本会向该版本配置的联系人发送邮件。
发布构建产物放在 Autobuilder 的 https://valkyrie.yocto.io/pub/releases 下，
邮件中会给出目录地址。此后的流程更依赖人工操作，主要交由发布工程团队负责：
QA 团队回复邮件，说明计划执行哪些测试，以及何时提供结果。
QA 团队执行测试，将结果和发现的问题摘要放入 yocto-testresults-contrib 仓库。
发布工程团队按其流程准备发布。
QA 团队的测试结果以独立目录纳入发布产物， 并上传到 yocto-testresults， 与该修订版本的其他测试结果放在一起。
使用 resulttool 重新生成最终发布的 QA 报告，纳入新的测试结果， 并将各团队的测试摘要放在生成报告的开头。
按发布检查清单与发布就绪标准进行核对。
最终由负责监督发布就绪情况的 YP TSC 决定是否发布。