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*: Los proyectos en desarrollo pueden avanzar con nuevas características o cambios que requieran una adaptación significativa en Fedora. Es posible que Fedora deba implementar correcciones o soluciones temporales mientras se completa la adaptación posterior.

  • Necesidades Específicas de Distribución: Fedora, y sus distribuciones descendientes como EPEL, pueden tener requerimientos únicos o restricciones que necesiten modificaciones descendientes. Estas necesidades quizá relativas a mantenimiento de hardware específico, consideraciones de seguridad, o integración con otros componentes de Fedora.

  • Parafernalias No Libres: Fedora se compromete a promover software libre y de código abierto y a desarrollar todo desde el código fuente. A veces, los proyectos upstream incluyen bloques binarios no libres o precompilados que Fedora necesita parchear para cumplir con sus principios. Si bien Fedora puede discutir posibles soluciones con el desarrollador original, estos parches podrían no ser siempre aceptados si no hay alternativas adecuadas o si eliminan alguna funcionalidad.

En estas situaciones, Fedora se esfuerza para minimizar el ámbito y duración de parches en versiones anteriores, y continúa para trabajos para cambios posteriores en donde sea factible. Comprendiendo las razones para cambios por debajo es esencial para mantener transparencia y confiar en la comunidad.

Ejemplos en Acción

El principio de manifiestos «primero en desarrollo» en varias formas. Aquí hay una pareja de ejemplos:

  • Mejoras de Empaquetado: Un paquete de Fedora identifica un defecto o característica ausente en una cadena de herramientas de compilación. En vez de crear un parche específico de Fedora, envían un parche en el desarrollo a los mantenedores de la cadena de herramientas. Tras revisar y discutir, el parche es mezclado en el desarrollo, beneficiando a todos los usuarios del encadenado de herramientas y elimina la necesidad de parchear Fedora por debajo de la producción.

  • Guión de Comunidad: Un contribuidor de Fedora desarrolla un guión para analizar datos del paquete. Se comparte el guión públicamente. Otro contribuidor mejora el guión con características nuevas y envía una solicitud de agregar (pull). El contribuidor original une los cambios, mejorando el guión disponible a la comunidad completa.

  • Clasificaciones de Licencia: Un empaquetador de Fedora descubre problemas de licencia con un proyecto de código abierto, tales como licencias poco claras o no conformes para los activos incluidos. En lugar de simplemente excluir el proyecto desde Fedora, trabajan con los desarrolladores de upstream para clarificar o corregir las licencias. Esto asegura que el proyecto puede ser incluido en Fedora y beneficia a la comunidad de fuente abierta hermana promocionando cumplimiento de licencia.

  • Evitar Dependencias Manejadas: Un empaquetador de Fedora se da cuenta de que un proyecto upstream incluye una versión específica de una dependencia. En vez de utilizar dependencia de empaquetada, re-empaquetan el proyecto para utilizar la versión ancha del sistema de la dependencia. Esto asegura consistencia a través de paquetes de Fedora, activa desarrollo de parche de seguridad rápida, y mantene compatibilidad entre paquetes independientes.

  • Pruebas Tempranas e Informes de Errores: Fedora suele ser pionera en la integración de nuevas versiones de software y bibliotecas. Esta adopción temprana permite a los colaboradores de Fedora identificar y reportar errores de compilación o compatibilidad, particularmente en el ecosistema Python. Estas contribuciones benefician a toda la comunidad del código abierto al garantizar transiciones y actualizaciones más fluidas para todos.

Estos ejemplos ilustran el modo en que la fase previa fomenta la colaboración, la propiedad compartida y la mejora continua en el ecosistema del código abierto. Le animamos a que piense en cómo puede aplicar el principio de «primero lo primero» en sus contribuciones a Fedora. ¿Tienes una historia sobre una contribución río arriba? ¡Compártala con la comunidad!

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