bmc-core SIG 入门指南

bmc_core SIG
1

1 bmc-core SIG 介绍

1.1 我们为什么存在

  • SIG（Special Interest Group，特别兴趣小组）是开源项目社区活力的最基本的体现组织，也是开源项目是否能否健康的持续发展的关键
  • bmc-core SIG 旨在维护 openUBMC 社区的BMC核心已有基础特性（BMC支撑的产品生态中都大部分可用的，并且被产品直接可见的特性），规划和孵化新的BMC基础特性/功能，参与社区生态建设的SIG

1.2 我们的职责和范围

bmc-core SIG 负责以下开源组件（见下表1），具体的职责如下：

  • 组件的日常代码维护以及方案评审（如issue的答复，PR的检视和合入，新功能方案的评审，重构&优化的规划）
  • 组件新功能的孵化，整体上以新的需求 issue 的方式进行跟踪落地
  • 组件的组织文档，包括但不限于以下形式：本组件的说明文档（如README或者docs自定义文档），社区文档中心 关于组件的说明文档（包括快速入门文档，开发指南文档，API文档）

表1：bmc-core 开源组件列表

组件名称（仓库链接） 组件说明
sensor 负责 IPMI 2.0 规范的传感器的管理，包括 Sensor，SDR，SEL，Entity 管理特性
frudata 负责 FRU 数据的管理，包括 电子标签，FRU器件，Component 部件管理特性
fructrl 负责 FRU 的上下电控制管理，包括 FRU 的通电开机策略，上下电锁，上下电延迟等 管理特性
hica 负责 BMC 的整体服务部署运行管理，包括 各个组件的服务运行组织 等管理特性
备注：当前组件归属SIG有争议，待决策后调整
active_standby_mgmt 负责 BMC 的多设备运行时主备管理，包括 多BMC运行时主备仲裁，多BMC主备心跳，BMC运行时主备切换等管理特性
bmc_datasync 负责 BMC 的多设备运行时数据同步管理，包括 多BMC设备之间的内存数据同步，多BMC设备之间的配置文件同步，多BMC之间不同的同步通道（over TCP/CAN/CAN-FD）支持等管理特性

1.3 SIG的成员管理

1.3.1 SIG 的成员角色说明

SIG 组的成员按照不同的角色进行运作，具体的角色有：

角色 角色说明 职责说明 成长路线
Maintainer 维护者 拥有SIG范围内所有代码合并权限，负责技术决策、代码审查和最终合并 通过不断贡献证明自己的能力之后由 Maintainer 提名，并且在 TC 进行答辩之后公示产生
Committer 提交者 拥有SIG范围内部分代码合并权限，负责核心代码的贡献以及审查 通过不断贡献证明自己的能力之后由 Maintainer 提名，SIG 内进行答辩之后现有 Maintainer 投票之后公示产生
Contributor 贡献者 拥有SIG范围内代码的查阅和提交PR的权限，负责积极参与贡献社区代码的输出和审查 通过不断贡献代码，文档，审查到社区，是成为 Committer 的预备阶段

1.3.2 SIG 的成员介绍

角色 姓名 gitcode id 负责SIG组件
Maintainer 黄晗 huanghan ALL
Maintainer 彭强 pengqiang-gs ALL
Committer 李晓宁 L_Ling ALL
Committer 王浩舟 duzhou13 ALL
Committer 孙培均 spjisgood sensor
frudata
active_standby_mgmt
bmc_datasync

1.4 有问题如何讨论&反馈

SIG组问题反馈通道：

2 bmc-core SIG 例会运作

组织例行会议的主要目的，就是使用公开的会议，建立一个 SIG 内成员的定期的沟通机制

2.1 会议组织

会议阶段 组织动作 阶段要求
通知 定期的会议由 Maintainer 进行定期组织和预定会议 1. 当前是月例行，每月的第一周的周二下午 16:30 - 17:30
2. 至少提前一周发出会议通知
订阅 对于openUBMC的社区全员均可以通过SIG组邮箱：请订阅 bmc-core SIG组消息
进行 会议由 Maintainer 轮流主持，按照议题进行依次进行 各个议题的责任人输出自己的议题纪要，纪要链接：Etherpad
结束 会议由 Maintainer 宣布结束 会议结束后一周之内由 Maintainer 汇总议题和纪要，并且通过邮件发送给订阅者（发送到 SIG 的公共邮箱，所有的订阅者均可以收到）

2.2 会议议题

SIG 运作的会议议题分为 两大类：

  • 固定议题：SIG上每次例会固定的议题，包括以下议题：SIG信息同步，SIG例会遗留问题，本月工作进展（特性同步，社区issue解决情况，论坛问题答复情况），社区活跃度统计
  • 临时议题：SIG上例会临时增加的议题，包括单不限于以下议题：社区组件的方案评审，问题缺陷，人员调整&竞聘等议题

2.3 如何申报临时议题

2.3.1 第一步，在会议通知中的议题中登记议题

在 bmc-core 的SIG会议公告板上对应会议的议题中找到临时议题申报点（如下图1）
议题登记：Etherpad

主要登记信息包括如下：

  • 议题： 申报的议题的主要信息，一句话说清楚当前要评审的主要内容
  • 主讲人： 当前议题的主讲人，至少是 姓名，尽量使用 姓名（gitcode id） 的方式
  • 议题时间： 当前议题预估的耗时，单位为 分钟（min）
  • 列席人： 可以空，当前议题关注的人，比如议题利益方或者诉求方，至少是 姓名，尽量使用 姓名（gitcode id） 的方式
  • 议题材料： 可以空，在评审之前进行补充，如果是简易问题则可以直接使用issue等处理
  • 议题纪要： 可以空，在评审之后由纪要人进行补充

图1：申报临时议题示例：

image
image679×270 14.3 KB

2.3.2 第三步，准备议题材料

议题材料尽量简约化，使用精简的语言描述清楚一件事情，可以借鉴使用 5W2H 的方式进行结构化描述。具体的方式和举例如下：

描述项 描述说明 示例
What 当前的评审点是什么 支持错峰上电，需要支持默认和页面修改两种方式
Why 当前评审点的背景是什么（为什么要评审） 新的多节点硬件机型需要支持
When 当前评审的特性在啥时候使用 机房整柜上下电时候使用，比如部署应用，计划上电等
Where 当前评审的特性在什么地方使用，可以不说明 客户数据中心
Who 当前评审的特性被谁使用（利益相关方），可以不说明 客户
How 当前评审的特性如何实现（特性方案） 采用独立配置的方式实现，需要fructrl组件支持CSR配置
How Much 当前评审的特性的约束（如性能，成本，人力，交付时间等约束） 错峰周期支持灵活配置，最大错峰120s，最小错峰15s；客户要求本月末要上线该特性

注意： 议题材料使用文本的方式记录，每个议题申报人可以单独开一片帖子，帖子关联对应的 issue，在议题申报时将该帖子的链接贴到会议议题下方

2.4 议题评审

对于议题评审会议，有如下两种方式：

2.4.1 方式1：SIG组例会评审

bmc-core SIG 组会周期性地举行例会，会议通知会提前根据SIG组的公共邮箱进行发送，订阅者可以收到会议通知。

2.4.2 方式2：SIG组临时组织评审

对于紧急（如紧急漏洞修复等）或者特殊情况（如客户临时需求等）下的场景，可以提前在SIG组的公共邮箱发送邮件约临时会议。bmc-core SIG Maintainer收到消息之后会组织临时会议。会议通知方式同上。

2.4.3 其他：评审意见处理

对于评审的意见（待解决问题），在评审会议结束之后，根据纪要中的 评审材料链接（帖子）进行更新，通过追加的方式进行更新，并且标注明确对应的意见所在的会议链接和议题。具体的处理方式根据意见类型的不同进行分别处理。

方式1：文档类意见

对于评审材料中的文档描述问题，直接在材料中标注明确并且更新即可。比如：


[文档正文省略...]

评审记录：
SIG会议：《会议链接》
评审意见：
（1）意见：当前方案描述流程不明确，需要更新文档方案描述
提出人：彭强（pengqiang-gs）
责任人：XXX（填写自己的姓名 + gitcode id）
闭环状态：已更新，请见材料 章节XXX

方式2：方案实施类意见

对于方案实施类的意见，如果在实施前进行评审，则直接同 方式1 进行。如果是实施后的追加评审，对于评审的意见处理，则需要 单独的 issue 进行跟踪处理，同时意见闭环状态中标注明确新的 issue 链接。比如：


[文档正文省略...]

评审记录：
SIG会议：《会议链接》
评审意见：
（1）意见：当前方案兼容性处理上需要考虑XX场景
提出人：彭强（pengqiang-gs）
责任人：XXX（填写自己的姓名 + gitcode id）
闭环状态：已更新，请见issue：《issue链接》
5 个赞