Objetivo de Fedora Minimization

Miles de individuos y contribuidores corporativos en la comunidad Fedora para explorar los nuevos problemas y construir un moderno y de rápido movimiento sistema operativo con un rico ecosistema que les permita experimentar y modernizar su infraestructura.

Ayudar a los desarrolladores de código abierto, administradores de sistemas y mantenedores de la distribución Linux a centrarse en lo que es relevante para ellos.

Fedora es una plataforma popular porque su ecosistema es de vanguardia y está bien optimizado para implementaciones modernas como IoT y contenedores. Esto hace que mucha gente use Fedora en lugar de compilar y ensamblar sus propios artefactos desde proyectos upstream. Y eso alivia la presión sobre los desarrolladores de código abierto causada por los usuarios, que de otro modo, pedirían que sus problemas específicos de seguridad y otras cuestiones se resolvieran rápidamente.

Así:

Los casos de uso específicos están definidos en Fedora. Luego, la comunidad se centra en esos casos de uso con desarrollo y mantenimiento, optimización (como minimización) y pruebas (como CI y gating). Estos casos de uso pueden ser priorizados transparentemente por los recursos de infraestructura en base a los intereses de la comunidad.

Feedback Pipeline monitoriza activamente cada caso de uso y registra el tamaño y las dependencias necesarias para su ejecución. Se mantiene y muestra un histórico de datos para ver los cambios en el tiempo. Y para mantener las cosas pequeñas con el tiempo, Feedback Pipeline también detecta automáticamente incrementos de tamaño y potencialmente abre errores de Bugzilla para rastrear/corregir/justificar dichos incrementos transparentemente.

Un enfoque activo en la minimización significa que nuestros mantenedores producen contenido de tamaño optimizado con el mismo o menor esfuerzo. Las herramientas, los servicios y los datos les ayudan a tomar la decisión correcta sobre las dependencias fácilmente y mantener las cosas lo más pequeñas con el tiempo.

Identificar casos de uso relevantes y permitir a la comunidad (lo que significa no solo el Minimization Team (Equipo de Minimización) definir lo suyo. Pensamos en un caso de uso como un conjunto de paquetes instalados en un contexto específico, que tiene un propósito específico — como Apache HTTP Server Container. Define casos de uso para al menos:

También, considere mirar casos de uso nativos de contenedores, como:

Recoja casos de uso específicos hablando con gente en eventos tecnológicos, foros de internet y cualquier otro lugar viable.

Servicios extendidos de monitorización (Feedback Pipeline) que:

Además de las funciones, también necesitamos:

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 mininal 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.