一文了解龙蜥社区&芯片厂商研发合作模式 原创

截至目前，龙蜥社区已经有越来越多的研发伙伴参与共建，其中主流芯片厂商贡献成为一大特色。那么针对芯片厂商的研发和适配工作，社区需要保证高效的合作研发模式，以满足大量适配需求。在​​龙蜥社区「走进系列」走进兆芯 MeetUp ​​上，龙蜥社区 Cloud Kernel SIG Contributor、阿里云高级研发工程师易兴睿根据以往社区与芯片厂商合作的经验与成果，从合作内容、研发交流、问题需求同步、交付验收 4 方面详细介绍社区的研发合作模式。未来，社区研发合作也将围绕这 4 点来分阶段逐步推进开展，根据具体情况做出相应调整。

(图/龙蜥社区 Cloud Kernel SIG Contributor、阿里云高级研发工程师易兴睿)

​

龙蜥社区秉承“平等、开放、协作、创新”的原则，社区合作以兴趣小组 SIG（Special Interest Group） 为媒介开展。SIG 成员主导 SIG 的治理、推动成果输出，并争取让交付成果成为社区发行的一部分。针对南北向适配的问题，龙蜥社区已创立了 60 个 SIG 工作组，这样各个芯片厂商的适配，就可以单独创建对应 SIG 进行研发合作。龙蜥社合区 SIG 工作组是公开开放的，社区成员均可自愿申请建立、参与 SIG 工作组进行贡献。

SIG 建立之后，对于一个新平台的适配，首先社区需要与合作伙伴明确合作方向，其次确立各个合作方向研发负责人及具体的合作内容，最后将合作内容形成 SOW 合作备忘录文件并签署，以合作备忘录的形式来指导后续的研发工作。

合作内容

明确合作内容的各个方面对于项目成功至关重要。双方在确定了合作关系后，需要明确以下 6 大重要事项，包括任务分类、里程碑、交付成果、交付时间节点、责任方以及验收标准，这里重点阐述 6 大类中的任务分类。

目前任务分类主要有 3 类：预研类、需求类以及文档演示类。首先预研类为技术推动，暂时没有明确需求，因此它需要明确阶段性交付的内容以及时间节点，根据后续需要随时可以转变为需求类，按照需求类进行要求。其次需求类包括了已知问题修复以及需求，重点是需要在交付时间节点中明确交付版本（内核、Base OS）以及对应的时间节点。最后是文档/演示类，比如 E2E 优化、技术 demo、教学指导等，这些交付内容需要在 SIG 进行透出，并按照 SIG 内部制定的标准进行验收。

研发与交流

为了更加高效的管理社区的研发合作，龙蜥研发交流建设重心将围绕以下两点展开：首先是建立合作知识库，实时同步各项合作内容以及研发信息，保证项目研发同学查看最新进展，更好地掌握研发进度。其次是建立基于 AIops 的数字化管理平台。在日益增长的研发需求背景下，研发任务、研发人员逐渐趋于复杂化，因此，简单的社区交流模式已经很难满足快速响应企业的需求。龙蜥社区通过升级为数字化平台的管理，并借助大语言模型，极大地提高合作效率。

• 合作知识库：首先是最基础的版本信息同步，包括内核、base os 版本的路标及规划，让研发同学明确其任务的截止时间和版本规划的变动。其次是合作内容，基于 SOW 以及最新任务更新与进展。接着是研发人员信息，能够通过研发人员信息，方便统计并跟踪平台相关的代码提交和审查。最后为平台特性内容介绍、平台问题跟踪及总结，总结汇总研发交流过程中所有平台相关的特性与问题，帮助我们对平台的适配有更深刻的理解

• AIops 的数字化管理平台。借助强有力的工具，我们可以构建智能化的管理平台。通过为大模型提供脱敏后的合作知识库的内容，加上各类 API 工具的辅助，智能助手就可以实现去辅助代码提交、统计、review 等工作，以及各项信息的跟踪，并且可以拿更新后的信息去更新知识库。另外，智能助手也可以通过其大语言模型的生成能力，帮助我们进行智能答疑、月报生成等工作。

问题和需求同步

在日常研发中，我们需要面对源源不断的需求和问题，那么就需要一个合理的机制来进行同步。

​

问题和需求同步分为快路径和慢路径进行管理。问题同步机制属于快路径，其着重于快速修复已知问题并及时响应。我们问题的来源包括已知的平台问题、测试发现问题、社区反馈问题和研发中遇到的问题等，这些问题通常以 Bugzilla 汇总，统一由社区及合作伙伴研发同学定位问题，并分发给相应领域处理，再评估解决方法与周期。如果研发难度较高、周期长，考虑转需求，如果可以快速响应，则继续流程。

慢路径则是针对需求。需求评审更加着重于对新增特性的需要，需要一定的开发周期和难度，严密的测试覆盖。此类需求的来源包括社区需求、业务需求等。需求的提交首先除了需求背景、需求内容外，还需要明确工作量、周期、交付版本等信息。需求要经过 SIG 和龙蜥社区技术委员会的评审，判断其合理性。经过评审需求通过，则按照正常的研发流程进行研发交付和验收。此周期相较问题评估更长，需要对需求有一个宏观的判断的反复的讨论。

交付验收

针对不同的任务类别，制定了不同阶段的结果验收标准。首先是日常研发流程测试，该测试针对预研类和需求类，流程由开发者自行保障，代码提交者将测试截图放在 PR 中、reviewer 可根据具体情况进行复现。其次是龙蜥的版本发布测试，该测试针对预研类和需求类，需要双方共建测试用例以及自动化测试平台，版本发布流程由龙蜥+厂商联合进行。龙蜥社区会联合各个芯片厂商针对平台特性共建自动化测试平台，基于龙蜥 ​​T-One 测试平台​​、硬件环境共建测试用例。最后是文档演示类的验收，各 SIG 负责进行，按照 SIG 指定的标准验收。

—— 完 ——