同步操作将从 openEuler/community 强制同步,此操作会覆盖自 Fork 仓库以来所做的任何修改,且无法恢复!!!
确定后同步将在后台操作,完成时将刷新页面,请耐心等待。
该Charter内容遵循openEuler宪章 README中描述的约定,本文会根据需要进行更新,以满足openEuler SIG的需求。
为了使SIG的工作标准化,提高社区透明度,并将贡献者合理的到入到对应的SIG组内,SIG应该遵循以下准则:
本节中的“成员”是指
人数:1~3人 工作职责:SIG组的管理者,软件包的维护者。直接参与和技术委员会以及上游或周边的协调,但无汇报关系。初始由SIG创建时指定,后继人选从Committer中选出。如SIG组内暂无Committer或人数较少,Committer的职责可以由Maintainer兼任。
- 确定SIG的技术路线:包括规划和决策SIG技术方向、路标规划、架构演进。
- 制定SIG的项目发布计划:确定SIG的关键需求和发布计划;参与社区的PM活动,并协调SIG计划和社区版本的里程碑时间表匹配
- 参与社区协调活动:作为SIG的代表参与openEuler技术委员会或理事会组织的活动和特定会议等
- 召集SIG组会议:定期召集SIG组会议,决策SIG组内上升的争议
角色配置:openeuler.yaml内的developer标签
可选角色 人数:2~8人 工作职责:特性设计方案审核和批准,代码审核及主干代码合入。Committer由Maintainer/Committer提名并由当前的Contributor全体投票表决产生。
- 评审PR:对Contributor提交的PR完成评审,评审可以参考社区的编程建议和安全编程规范。
- 分发处理问题,请参考“问题处理流程“。
- 跟踪依赖性问题:在开发分支中,其他SIG组的软件包的更新可能会到导致破坏本SIG内软件包的依赖关系。此时Committer会受到告警公告,Committer应尽力重建软件包。依赖关系出错可能会使最终用户无法更新系统,打包团队也会介入并重建存在依赖性问题的软件包,但Maintainer 不应依赖这些重建。
- 如有接口变更,通知可能会影响到的SIG:其他SIG或团队会依赖本SIG,对软件包接口的变更可能会对他们造成影响。Maintainer应了解并评审&决策变更造成的依赖影响,并公告和发送API或ABI变更的告警邮件。这类公告应在变更发生至少一周前完成,并应通知到所有可能受影响的SIG。具体请参考接口变更通知流程。
- 更新和维护软件包版本:遵守社区的软件包更新质量控制策略完成软件包的更新。
- 和上游社区合作,包括:
- 将所有变更推送到上游社区
- 参与上游社区邮件列表
- 获取上游社区的bug跟踪器的账户,并跟踪上游社区的重要bug
- 将严重的错误转发给上游社区以寻求帮助 更多信息,请参考“上游社区软件包管理建议”
- 和测试团队合作,包括:
- 在提交软件包时,向质量检查人员提供如何调试/分类软件包的信息,以供问题的分类
- 提供基本功能的测试用例,用于测试回归
- 提交软件包更新时,提供有关更新中已经修复问题的测试用例,以供质量检查人员使用。
角色配置:openeuler.yaml内的developer标签
在committer中指定安全联络员 人数:1人 工作职责:
- 成为产品安全团队的对口SIG组联络人,对本SIG内的安全问题进行分类和处理。
- 参与安全团队的安全问题
- 维护SIG组内的安全规范和要求
子项目可以由SIG的Maintainer或Committer提案创建,子项目可以通过SIG组内的Maintainer和Committer通过“懒惰的共识”(沉默即同意)评审接受,结果应得到大多数SIG组成员的支持。
此处可能存在不合适展示的内容,页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容,可点击提交进行申诉,我们将尽快为您处理。