本系列将介绍构建和发布红帽企业 Linux 10 所涉及的人员和规划。从最早的概念阶段到 2025 年红帽全球峰会上的发布，我们将听到有关 RHEL 10 诞生的第一手资料。
在第一篇博文中，我们探讨了红帽企业 Linux（RHEL）10 的诞生历程，介绍了在 2022 年红帽全球峰会暨 RHEL 9 发布之后立即启动的早期阶段，这包括组建团队、设定期望，以及与上游社区协作来收集想法。在第二部分中，RHEL 10 背后的团队将分享全新的平台构建思路是如何逐步清晰并最终实施的。
2023 年（距离 RHEL 10 发布还有两年）
Brian Stinson，首席软件工程师
我们首先从 Fedora 入手。通过这个社区，我们获得了内容集以及要研究的问题领域。然后，我们便持续推进各项相关工作。
Stef Walter，工程高级总监
我们采取的一项措施是将 CentOS Stream 作为 RHEL 的开发平台。RHEL 的很多内容来自 Fedora，但后续的大量迭代（每天多次、持续构建完整 RHEL）都是在 CentOS Stream 中完成的。
Stinson
我们通过 [CentOS Stream] 获得的主要优势在于，我们基本上是在公开进行构建，这实际上对我们维持参与度有很大帮助。
Walter
尽管我们对 RHEL 的内容拥有绝对的掌控权，但我们也欢迎其他人提出更改建议或贡献代码。
Stinson
能够向公司外部传递这类信号，是件很有价值的事。我们希望在主要版本中做的 [一件事] 是进行真正的重大更改。但与此同时，我们也不希望在每次发布新版本时，都让用户感到意外。这不应该是他们第一次有机会了解即将推出的内容。
Mike McGrath，核心平台工程副总裁
对于像 RHEL 团队这样规模庞大的企业组织而言，团队内部拥有明确的方向和极具魄力的领导者至关重要。因为如果每项决策、每个技术问题都必须由我来定夺，或者必须得到我的指示才能向前推进，那么 RHEL 项目将会陷入停滞。
Shelley Dunne，高级首席项目经理
这与 RHEL 项目的变革方向大致一致。团队致力于实现更敏捷的协同配合，这也推动决策权进一步下放给那些真正需要做出决策的人。
McGrath
团队每周都会聚在一起，讨论哪些工作有效、哪些无效。问责制是红帽的核心价值观之一。如果我们工程团队承诺会按时完成某项工作，但却未能如期完成，那么在项目例会上，我们就必须对此负责。这种问责文化对于如此庞大的团队至关重要，因为有了问责制，重大错误就能得到控制。如果没有建立问责制，后果将不堪设想
Stinson
这有点像马戏团，当然我这里是褒义。每个人都有自己负责的领域，每个人都在整体协作中贡献自己的力量。
现在，距离发布还有两年时间，工作流已制定并启动，各项迭代也开始通过 CentOS Stream 公开进行。随着发布日期日益临近，团队现在必须能够稳住这一整套同时运转、环环相扣的体系，打造出全球领先的企业级 Linux 平台。
