Primera río arriba: Un Principio de Core Fedora

El concepto de «primero las principales» es un principio fundamental con el Proyecto Fedora. Da forma a nuestra historia, cultura y enfoque para contribuir al ecosistema de código abierto. Entendiendo este principio es crucial para cualquiera buscando como contribuir a Fedora y el ecosistema más amplio de distribución de Linux.

El Compromiso de Fedora para Primero Río Arriva

Fedora, como una distribución de Linux, representa un rol único como una integración de componentes software innumerables. Cuando Fedora desarrolla alguno de nuestros software, su función primaria es para entregar una experiencia de sistema operativo coherente compilada bajo el trabajo de numerosos proyectos realizados.

Desde su comienzo, Fedora ha defendido el principio de aguas arriba primero. Esto no es normativa o regla dura; es un valor fundamental entretejido en el tejido de la comunidad Fedora. Los colaboradores de Fedora creen que los cambios y mejoras en el software de código abierto deben, siempre que sea posible, ser compartidos con los proyectos anteriores. Esto asegura que todos los usuarios de ese software, no sólo los usuarios de Fedora, puedan beneficiarse. En última instancia, el objetivo final de Fedora es el beneficio del usuario, y los colaboradores de Fedora harán lo que crean que es mejor para el usuario, incluso si upstream no está de acuerdo.

El principio de la ingeniería pragmática también se aplica a las fases anteriores de la producción. Al contribuir con cambios en el flujo ascendente, Fedora reduce la carga de mantenimiento a largo plazo de llevar parches específicos del flujo descendente. Mantener conjuntos de parches externos puede resultar cada vez más difícil a medida que evolucionan los proyectos por arriba. Adoptar primero por arriba ayuda a asegurar la sostenibilidad de Fedora y sus contribuciones.

Este enfoque tiene un efecto dominó en todo el ecosistema del código abierto. Los cambios realizados en Fedora a menudo impactan en numerosos proyectos que utilizan a Fedora como base. Por lo tanto, contribuir a Fedora es una forma muy efectiva de influenciar y mejorar el panorama más amplio del código abierto, particularmente dentro del ecosistema RPM/Enterprise Linux.

Al priorizar las contribuciones upstream, Fedora se alinea con su visión de un mundo donde todos se benefician del software libre y de código abierto construido por comunidades inclusivas y acogedoras. Este compromiso se extiende a todo el software de código abierto, no sólo a Fedora.

Comprender las fases anteriores y posteriores

En el mundo del código abierto, los proyectos suelen tener relaciones interconectadas que se describen como "ascendentes" y "descendentes". El proyecto upstream es la fuente original del software, la base sobre la que se construyen otros proyectos. A su vez, los proyectos "aguas abajo" son los que utilizan y a menudo modifican el software "aguas arriba". Piense en ello como en un río: el río arriba es la fuente, y los proyectos río abajo están más adelante en la corriente, recibiendo y potencialmente alterando el agua.

Esta metáfora es esencial para entender cómo los proyectos de código abierto dependen e interactúan entre sí. Los diferentes modelos de desarrollo fomentan distintos tipos de relaciones ascendentes/descendentes.

Comunicación abierta con las instancias superiores

Fedora reconoce la importancia de una comunicación clara y abierta con los proyectos upstream. Creemos en el fomento de relaciones sólidas con los desarrolladores y comunidades upstream, y buscamos activamente sus aportaciones y comentarios.

Fedora siempre está abierta a escuchar de los proyectos upstream cómo podemos mejorar nuestros procesos de colaboración e integración. Entendemos que el uso descendente de Fedora puede a veces crear desafíos o fricciones para los proyectos ascendentes. Animamos a los desarrolladores a que se pongan en contacto con nosotros si encuentran algún problema o tienen sugerencias de mejora.

Nuestro objetivo es trabajar juntos de manera constructiva para encontrar soluciones que beneficien tanto a Fedora como a los proyectos upstream en los que confiamos. Si bien no siempre podemos satisfacer todas las solicitudes de los proyectos upstream, nos comprometemos a escuchar, aprender y adaptar nuestras prácticas para minimizar cualquier impacto negativo en las comunidades upstream.

La filosofía de trabajar primero aguas arriba no se limita al desarrollo. También abarca una relación productiva, positiva y respetuosa con nuestros proyectos upstream. Nuestras comunidades se superponen y queremos extender nuestros valores de Fedora a sus proyectos tanto como lo haríamos dentro de Fedora. Para ello, siempre queremos afrontar juntos los retos entre proyectos y tener líneas de comunicación claras.

Cuando se producen cambios aguas abajo

Si bien Fedora prioriza las contribuciones aguas arriba, existen situaciones en las que son necesarios cambios específicos aguas abajo. Estas excepciones no son contradicciones del principio aguas arriba-primero, sino más bien reconocimientos de las complejas realidades del desarrollo y distribución de software.

Entre los motivos de los parches posteriores figuran:

  • Rechazo de flujo ascendente: A veces, los mantenedores de las versiones anteriores pueden rechazar un parche por varias razones, incluso si es beneficioso para Fedora. Fedora aún puede necesitar llevar ese parche para abordar un problema o requisito específico.

  • * Progreso Río Arriba*: Upstream projects may move forward with new features or changes that require significant adaptation in Fedora. Fedora may need to backport fixes or implement temporary workarounds while the downstream adaptation is completed.

  • Distribution-Specific Needs: Fedora, and its downstream distributions like EPEL, may have unique requirements or constraints that necessitate downstream modifications. These needs might relate to specific hardware support, security considerations, or integration with other Fedora components.

  • Non-Free Blobs: Fedora is committed to promoting free and open source software and building everything from source. Sometimes, upstream projects include non-free or pre-built binary blobs that Fedora needs to patch out to adhere to its principles. While Fedora may discuss potential fixes with upstream, these patches might not always be accepted if there are no suitable alternatives or if they remove functionality.

In these situations, Fedora strives to minimize the scope and duration of downstream patches, and continues to work towards upstreaming changes whenever feasible. Understanding the reasons for downstream changes is essential for maintaining transparency and trust within the community.

Examples in Action

The principle of "upstream first" manifests in various ways. Here are a couple of examples:

  • Packaging Improvements: A Fedora packager identifies a bug or missing feature in a build toolchain. Instead of creating a Fedora-specific patch, they submit a patch upstream to the toolchain’s maintainers. After review and discussion, the patch is merged upstream, benefiting all users of the toolchain and eliminating the need for a downstream Fedora patch.

  • Community Script: A Fedora contributor develops a script for analyzing package data. They share the script publicly. Another contributor enhances the script with new features and submits a pull request. The original contributor merges the changes, making the improved script available to the entire community.

  • License Clarifications: A Fedora packager discovers licensing issues with an open source project, such as unclear or non-compliant licenses for included assets. Instead of simply excluding the project from Fedora, they work with the upstream developers to clarify or correct the licenses. This ensures that the project can be included in Fedora and benefits the broader open source community by promoting license compliance.

  • Avoiding Bundled Dependencies: A Fedora packager notices that an upstream project bundles a specific version of a dependency. Instead of using the bundled dependency, they repackage the project to use the system-wide version of the dependency. This ensures consistency across Fedora packages, enables rapid security patch deployment, and maintains compatibility between interdependent packages.

  • Early Testing and Bug Reporting: Fedora often pioneers the integration of new software versions and libraries. This early adoption allows Fedora contributors to identify and report build or compatibility bugs upstream, particularly in the Python ecosystem. These contributions benefit the entire open source community by ensuring smoother transitions and upgrades for everyone.

These examples illustrate how upstream first fosters collaboration, shared ownership, and continuous improvement within the open source ecosystem. We encourage you to think about how you can apply the "Upstream First" principle in your Fedora contributions. Have a story about an upstream contribution? Share it with the community!

Want to help? Learn how to contribute to Fedora Docs ›