Fedora 最小化的目标

虽然 Fedora 可以很好的运行在传统的实体或虚拟工作站和服务器上，但对那些传统安装环境之外的使用环境就显得缺乏竞争力了。

像物联网还有容器等当下的一些部署方式对系统大小要求较高。比如物联网环境下，数据连接量通常比较低（针对更新或管理），但在云服务或者容器环境下，却有着大数量级的数据交换。

举个实际的例子，像 Systemd 这样很有用而且在实体系统中经常出现的程序，却很少在容器中使用。问题并不在于软件包只是需要 Systemd 的 systemd-sysusers 来创建用户。只是在容器中，这意味着系统尺寸的明显增加。

此外，基本上所有部署情形都可受益于尺寸的减小。因为安装所用的空间大小和攻击范围以及相关关键漏洞都有直接关系。

Thousands of individual and corporate contributors collaborate in the Fedora community to explore new problems and to build a fast-moving modern OS with a rich ecosystem allowing them to experiment on modernising their infrastructure.

协助开源开发人员、系统管理员和 Linux 分发维护人员关注与他们相关的事项。

Fedora is a popular platform because its ecosystem is both cutting-edge and well optimized for modern deployments such as IoT and containers. That makes many people use Fedora rather than to build and assemble their own artifacts directly from upstream projects. And that relieves the pressure on open source developers caused by users who would otherwise ask for their specific security and other issues to be fixed quickly.

因此：

Specific use cases are defined in Fedora. The community then focuses on those use cases with development and maintenance, optimisation (like minimisation), and testing (like CI and gating). These use cases can be transparently prioritized for infrastructure resources based on community interests.

Feedback Pipeline actively monitors each use case and records the size and the dependencies required for it to run. Data history is kept and shown to see changes over time. And to keep things small over time, Feedback Pipeline also automatically detects size increases and potentially automatically opens Bugzilla bugs to track/fix/justify such increases transparently.

An active focus on minimization means that our maintainers produce size-optimised content with the same or lower amount of effort. Tooling, services, and data help them to make the right decision about dependencies easily, and to keep things smaller over time.

Identify relevant use cases and allow the community (meaning not just the Minimization Team) to define their own. We think of a use case as a set of packages installed in a specific context, having a specific purpouse — such as Apache HTTP Server Container. Define use cases at least for:

Also, consider looking at container-native use cases, such as:

Collect specific use cases by talking to people at tech events, internet forums, and any other viable venues.

Extend monitoring services (Feedback Pipeline) that:

除了新功能，我们还需要

Being able to see what’s going on is a prerequisite of implementing any changes. Seeing all the relevant opportunities helps us to focus on the ones having the most impact, and a transparent tracking helps us prove the usefulnes of our work, and to further focus on the most impactful activities.

Minimize the installation size of the use cases by optimizing RPM dependencies, features, software architecture, and other factors. Specifically, look for:

Engage with upstream developers regarding bigger changes in packaging and architecture. An example is Systemd and splitting the systemd-sysuser package.

Implement process and policy changes reflecting bigger, more general changes. Again, a good example is using Systemd in containers, or the general issue of creating users in containers.

Provide guidance for the Fedora community in form of blog posts, videos, and conference talks. Even though we might have guidelines and policies in place, spreading the word is always important.

Cloud resources to prototype services. We are not going to change the existing Fedora infrastructure in any way before whatever we develop proves useful and worth the hustle of stabilization and changing production.

No existing Fedora Infra or Release Engineering resources are needed at the moment. However, we might need help with setting up (or getting access to) the cloud resources.

Active support from our maintainers, the FPC, and other community members is definitely needed. This is obviously not something we can "request", but it’s still a necessary input.

Usefulness over size: There is a balance between the usefulness and size. We take that in mind and will not implement drastic changes that would prevent our users from using Fedora. However, nothing prevents us from producing additional very specific and minimal artifacts.

Using RPM: We’re doing this with RPM. We’re not achieving minimization by deleting files after installation. This might be obvious, but still worth mentioning.