# printf("Hello, srcmgr\n"); * 原文：[printf(“Hello, srcmgr\n”);](https://freebsdfoundation.org/our-work/journal/browser-based-edition/freebsd-15-0/freebsd-and-google-summer-of-code-2025/) * 作者：Mark Johnston FreeBSD 的开发者以及 DevSummit（开发者峰会）的与会者可能对新成立不久的 srcmgr（“源代码管理”）团队有所耳闻。不过，由于自 srcmgr 开始定期召开会议已有约一年时间，现在似乎是向更加广大的社区，正式介绍我们的好时机。 srcmgr 是由 FreeBSD 源代码开发者组成的团队，其目标是帮助组织和协调 FreeBSD 的 src 开发。作为背景，FreeBSD 的开发模式在开源项目中相对独特：它并非由单个开发者或小团队主导项目和做重大决策，而是由一群 src 开发者组成一个相对扁平的层级结构，当然仍需遵循维护者规则和惯例。开发者们共同承担推动 src 开发的责任，包括发现或修复 bug、撰写文档、代码审查、增加功能和测试等工作。 这种开发模式运作得相当不错——例如，FreeBSD 项目本身的历史比部分开发者的资历还要久——但这种开发模式也存在不足。单个开发者的正式责任较少；他们被期望贡献代码并相互协作，但缺乏严格的正式监督。这种模式在开发者人数较少、彼此熟悉且互相信任的小团队中表现良好，并能相互激励；这也是 FreeBSD 早期开发的特点。然而，随着时间推移，问题开始出现：资深开发者逐渐远去，系统变得更复杂、维护难度增加，同时新开发者数量上升，这给经验丰富的导师带来压力，而这些导师通常自由时间有限。 在以往 FreeBSD 核心团队（Core Team）提供了后备支持：每当出现争议或树结构中被忽视的部分出现问题时，他们会介入。这种方式在历史上行之有效，因为核心团队长期主要由 src 开发者组成，尽管它代表的是整个 FreeBSD 项目。但在最近几个任期中，Ports 团队在核心团队中的代表性有所增加。因此，近期的核心团队在处理 src 相关问题上的资源相对有限，同时核心团队的注意力应更多集中于项目的长期战略方向，而非日常事务。 这就是 srcmgr 的由来。srcmgr 于 2024 年 10 月 8 日在 FreeBSD 内部开发者邮件列表上正式公布，目前成员包括我（Mark Johnston）、Ed Maste、Warner Losh 和 John Baldwin。我们还有五名“潜水员”，即参加 srcmgr 会议并参与讨论但尚未正式成为成员的开发者；他们通过这种方式试水，以决定是否愿意正式加入。简而言之，srcmgr 在 src 树中的角色类似于 portmgr 和 doceng 团队在 ports 树和 doc 树中的作用：我们提供监督，并帮助解决该领域特有的挑战。 尽管早些时候已有组建 srcmgr 团队的想法，但我最初的接触是在 2023 年 BSDCan 与 John Baldwin 和 Ed Maste 的交流中。大家认识到核心团队（Core）往往负担过重，无法主动引导 src 的开发。同时，我对我们处理 bug 报告、新贡献者以及代码评审的整体方式感到沮丧。作为个人开发者，要在完成常规有偿工作之余，还兼顾这些事务，实在是太耗费精力。 那么，srcmgr 在实际工作中做什么呢？我们的[章程](https://www.freebsd.org/srcmgr/charter/)概述了主要职责。我们每两周开一次会，约两小时；前一小时用于审查议程事项、讨论并提供状态更新，后一小时通常用于处理最近的[src bug 报告](https://bugs.freebsd.org/bugzilla/)和/或[GitHub pull requests](https://github.com/freebsd/freebsd-src/pulls)。 该团队的核心职责是对 src commit bit 进行投票：当一名 src committer 与贡献者合作，并认为该贡献者能够合理使用 src commit 权限时，可以向 srcmgr 提出申请，由团队投票决定是否授予 commit 权限。这个流程通常比较直接、无争议，实际上消耗的时间很少。 此外，我们还会处理一些“维护”任务，例如禁用不活跃开发者的 commit 权限、推进废弃占用项目资源的过时或无人维护的功能、更新开发者政策，以及在 FreeBSD 集群管理员团队的大力协助下，维护一些基础设施，比如 git commit hooks。 我们的大部分时间都花在推动各项计划上，主要目标是：1）提高有经验开发者的生产力，2）让新来者更容易参与贡献。针对第一个目标，我们一直在推动创建各种工具，以降低 FreeBSD 的开发难度。当前，对新的 FreeBSD 开发者（有兴趣的贡献者、谷歌编程之夏学生、使用 FreeBSD 的公司员工等）而言，搭建一个能够快速且可靠地测试 src 树修改的环境仍然过于困难。我们拥有一套规模庞大的回归测试套件，但真正运行它需要相当多的前期配置，并且难以实现自动化。建立一个高效、交互式的“编译－编辑－测试”循环同样不容易。许多开发者都有各自的定制脚本和工作流来实现这一点，但这意味着很多人实际上是在重复造轮子；此外，我们也缺乏一套可供新来者快速采用并加以定制的成熟“现成”方案。从总体上解决这一问题本身就是一项挑战，因为 FreeBSD 是一个规模庞大、包含众多组件的代码库，而这些组件往往需要专门化的开发方式。即便如此，仍然存在大量改进空间。 围绕工具这一主题，我们还在开发脚本，以简化 MFC 操作，并以程序化方式捕捉某些类型的问题，例如 stable 分支中缺失回溯提交的情况，尤其是在提交 B 修复了提交 A 中的缺陷，但在合并提交 A 时却遗漏了提交 B 的场景。另一个重点方向是为项目成员分流和甄别进入的工作：Bug 报告、代码评审请求以及贡献者补丁。尽管单个 FreeBSD 开发者在处理这类日常请求上投入了大量时间，但目前缺乏一种有效的整体监督机制，来确保高优先级问题不会被遗漏。srcmgr 由熟悉 src 树的开发者组成，能够迅速判断在某个具体问题上应当“标记”谁来参与协助，从而推动问题向前解决。 最后，一项正在持续推进的计划是举办“ bug 分拣”活动，通常通过 Zoom 或 meet.freebsd.org 进行。我们会提前在开发者邮件列表上公布这些活动，并邀请大家参与大约 3 小时的分流处理和缺陷修复工作。我通常会通过逐条审阅具体的 Bug 报告来主持这些活动，并寻找能够快速取得进展的机会：将问题指派给相关领域的专家，向提交者提出后续问题，以及与通话中的其他人讨论问题。参与方式完全自由；有些人会在后台默默地处理特定 Bug，同时留意讨论内容，另一些人则会跟随整体流程，或并行地对 Bug 进行分流处理。 这些活动（以及 srcmgr 的整体参与）在很大程度上保持了我的动力：与其他开发者的实时互动有助于维持我们这些远程工作的人的投入感，而能够在 Bug 和拉取请求（PR）上迅速取得具体、可见的进展，也让积压问题不至于显得难以承受。当我们能够及时处理不断进入的问题和工作请求时，就更容易对项目产生自豪感，而这种协作也有助于维系我们共同的责任感。 srcmgr 还有很多希望为项目提供帮助的工作内容，我们也有许多计划将在来年持续推进，尤其是在 FreeBSD 15.0 发布日期日益临近、并且我们能在假期中获得一些休整时间的情况下。 如果你有任何反馈或想法，欢迎随时通过电子邮件与我们联系：。 *** Mark Johnston 是一名居住在加拿大安大略省多伦多的 FreeBSD 开发者。当不坐在电脑前的时候，他喜欢和朋友一起参加城市躲避球联赛。 --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://freebsd-journal-cn.bsdcn.org/2025-101112-freebsd-15.0/printfhello-srcmgrn.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.