这是系列文章的第四部分，基于 2 月份在捷克共和国 DevConf 的演讲。 本周，我打算介绍每个工作组联络员的所有报告，但结果证明那是一堵墙，所以我要一个接一个地做，从 Phil Knirsch 开始基础设计。
如果你还没有读过，你应该从第一部分开始，“为什么？”，如果你喜欢“逻辑进展”和“本末倒置”的一般概念，我建议从第二部分开始， “发生了什么？” 然后是第三部分，“治理、进步和更多想法”。
你可以观看 视频开 YouTube，但您可能会发现该文本更有帮助。 我已经总结和解释，而不仅仅是转录。 而且，由于已经两个半月了，我已经收到了每位演讲者的最新消息。
工作组报告视频
快速说明：这些人是谁？
该小组会议以来自每个工作组的 FESCo 联络员为特色。 FESCo 是 Fedora 工程指导委员会和工作组是该组的独立小组委员会。 每个小组的联络人（不一定）不是领导者，而是负责协调该级别的项目间沟通。 由于所有联络人都在 布尔诺 对于会议，我们聚在一起交谈。
基础设计：Phil Knirsch
菲尔从使命开始 基础设计：
的目标 Fedora Base 是为所有人提供一个具有通用技术、框架和 API 的标准平台 Fedora 产品
尽管他指出“所有”似乎相当强大，尤其是考虑到未来可能会有更多产品。
Phil 补充说，Base 本身作为一种设计本身不应该也不会作为产品发布，但工作组已经确定了从该任务中提取的一些具体目标：
- Base 的第一个定义包括：作为所有产品的标准机制的 Anaconda 安装程序、发布工程用于组装产品的 compose 工具、最小安装（尚未准确定义，但对 Cloud 并且可能用于嵌入式空间中的最终产品），以及大多数产品使用的一般功能。
- 根据其他工作组的反馈，Base 将为特定版本提供 API 和/或 ABI 稳定性，而不是简单地关注包版本/版本。 （API 稳定性意味着为一个版本编写的代码将继续编译；ABI 稳定性意味着二进制文件将继续运行。）
- Base 提供的功能的用户体验预计在不同的 Fedora 产品。
- 保持尽可能小的基础，同时仍然提供大多数产品将使用的功能。
这导致了一些正在进行的举措：
- 清理包构建依赖项。 计划是让 Base 成为自托管的，这样它就可以自己构建，并且是自包含和自持的。 如果你现在尝试这样做，你最终会得到大约 1,800 个包，这听起来相当疯狂——而且确实如此！ 因此，在 Harold Hoyer 和 Phil 进行的第一次审查之后，构建需求清理将使我们减少到可能只有几百个包。 如果没有自托管，我们已经减少到 127 个包。
- 清理包脚本。 每个包都可以有在安装系统时运行的“post”和“pre”脚本。 由于 RPM 的设计方式，这些可以是任意命令。 这很强大，但也很混乱——而且可能缓慢而脆弱。 该计划是为常见事物提供更多标准宏，并删除并非真正需要的脚本。
- 参与其他 WG 工作。 Base Design 将与其他公司合作 Fedora 工作组及其 PRD、技术规范和变更建议，以确保 Base 包含所有相关部分，并与发布工程和其他组合作以确保必要的工具到位。
Phil 指出，这些只是由此产生的举措的示例。 Base 本身将由产品的需求来定义——无论他们需要什么，有什么共同点，Base 都会提供，并且随着时间的推移，活动可能会增长。
他还邀请每个人参加小组的（通常）每周例会
#fedora 会议
在自由节点上 国税局 网络，周五 15:00 UTC。
下周观看更多第四部分
我保证，我并不是真的想永远把它拖出去。 有很多东西要讲。 即将发布来自 Environment & Stacks、Server、Workstation 和 Cloud. 由于这些内容比本系列的前几部分要短，因此我将尝试以比每周只做一个稍快的速度完成它们； 我们会看看情况如何。 无论如何，一旦完成摘要演示，就可以进行问答了。
和以前一样，让我们在评论和回复中继续这个对话，除了回复之外，我将把它提炼成本系列结尾的最后一篇问答文章（与会议问题的总结分开）。
