求助:关于 openUBMC 大版本管理策略及不同 SIG 组维护方式的困惑

各位好,

目前 openUBMC 正在推进第一个大版本的发布阶段,各 SIG 组在维护和管理上采取了不同的策略。在这个过程中,我们注意到一些差异化做法在一定程度上对版本的可持续演进产生了挑战,因此想就相关问题寻求一些指导和建议。

当前观察到的情况:

  • 第一个大版本仍在持续演进中,但目前已出现一些问题;
  • 不同 SIG 组的维护方式存在差异,例如:
    • 有 Maintainer 通过 push -f 或清理历史的方式对仓库进行维护,导致部分 commit 历史不可追溯;
    • 有的组将当前仓库作为备份,另起一个新仓库继续开发;
    • 但最近部分原有的备份仓库也已被清理或删除。

面临的思考与疑问:

随着后续更多大版本(如 330 → 630 → 930 → 1230)的规划推进,可能会涉及到版本迁移和兼容性演进的问题:

  • 如果各 SIG 组维持各自独立的策略,而未形成统一的迁移和版本管理规范,是否可能影响未来版本的整体一致性、可追溯性和协同开发效率?
  • 当前一些版本间的变动缺乏连续性,是否会对后续的演进、问题排查或代码审计工作造成一定困难?
  • 一些历史记录丢失的情况,是否会影响到版本差异分析或回溯问题时的判断依据?

想请教的建议:

  • 社区是否有计划就大版本管理和版本迁移流程,制定一个统一的策略或参考建议?
  • 如果某个 SIG 计划采用新仓库或新分支进行演进开发,是否有推荐的规范或需要与 TC 做同步的流程?
  • 针对版本历史完整性和迁移可控性,是否建议社区层面进行一定的约定或指导?

以上问题仅是出于未来版本维护便利性和整体社区协同的角度提出,欢迎大家讨论和补充,如有理解偏差,也请指出。

感谢各位!

330版本作为社区首个正式发布版本,后续会持续演进,也不会出现切仓、清commit的事务
SIG组的策略是一致的,如果有不一致的,可以反馈至TC

社区整体会以 开发分支 - 稳定分支的方式进行演进,开发分支用于合入当前版本中的需求开发,稳定分支会基于上一个大版本后进行bug修复等合入。具体的版本定义和发布节奏RM SIG近期会发布。

1 个赞