Mantenerse Cerca de los Proyectos Upstream

Parches: Los parches son el más común y obvio tipo de cambio del upstream. Los parches pueden estar escritos por el mantenedor del paquete, seleccionados o respaldados desde el upstream o seleccionados de otras distribuciones.

Ejecutando sed o equivalente en un archivo de especificaciones: Aunque este cambio es menos obvio, debería ser considerado equivalente a un parche para los propósitos de esta guía. Un parche es también preferible porque al ejecutar sed puede cambiar, algunas veces, el software de forma no pretendida especialmente cuando el mantenedor del paquete está impulsando una nueva versión upstream como una actualización y dichos cambios pueden no ser obvios en comparación con un parche fallido.

Archivos de escritorio, archivos de unidad systemd, etc. se añaden algunas veces como fuentes adicionales: Si usted hace esto como mantenedor del paquete, necesita notificarlo upstream e idealmente incluirlos como parte de la fuente upstream. Mantenerlos por separado a menudo implica un mantenimiento adicional.

Opciones de configuración: Por ejemplo, si un software upstream concreto acepta tanto MySQL como Postgres como backend de base de datos, es posible que otras distribuciones hayan elegido Postgres y el paquete Fedora podría estar configurado para usar el backend MySQL de forma predeterminada en su lugar. Si upstream u otra distribución está favoreciendo una de las opciones sobre las otras, hable con ellos, descubra por qué y confíe en opciones consistentes y bien probadas tanto como sea posible.

Bibliotecas subyacentes y otros componentes de software: Incluso sin modificaciones intencionales, el software en Fedora puede ser todavía ser diferente del upstream u otras distribuciones, debido a versiones precisas de la librería u otros componentes de software de que depende el paquete. Por ejemplo, Firefox puede exponer un error sqlite y Fedora podría ser la única distribución que construye esa versión específica de Firefox contra esa versión específica de sqlite. Debería hablar al upstream y buscar si hay alguna cuestión conocida y buscar en los rastreadores de errores upstream u otros rastreadores de errores populares de la distribución para ver el problema.

Miscelanéos: La lista anterior no es exhaustiva. Incluso cambios aparentemente menores como el tema o las fuentes específicas del escritorio, pueden presentar errores en otro software, o puede exponer un error en el tema o fuente pero solo con algún software específico. Por ejemplo, LibreOffice puede tener un problema mostrando un lista cuando usa el tema Adwaita y la fuente Dejavu. Cuando se analizan cuestiones, compruebe considerar el impacto de cada cambio en Fedora o para los usuarios.

Beneficio Común y Carga de Mantenimiento Reducida: Cuando Fedora lleva parches que son específicos de Fedora o desviaciones de proyectos upstream, estos parches no son compartidos por cada distribución. Esto pone el coste del mantenimiento de esos parches en Fedora, que incluye el mantener esos parches en un estado funcional reescribiéndolos o reenviándolos para cada versión upstream. Este esfuerzo puede rápidamente resultar abrumador, sin tener el espíritu de compartir los beneficios (así como el esfuerzo en el mantenimiento) del software libre y de código abierto.

Documentación: Los proyectos upstream están documentados formalmente (en la forma de páginas de manual/informativas y en guías más largas) e informalmente en muchos foros de usuarios o listas de correos como respuestas a las preguntas de los usuarios. Las desviaciones de los proyectos upstream pueden de este modo confundir a los usuarios finales y a los desarrolladores upstream cuando esos parches pueden cambiar comportamientos que son específicos de Fedora y no documentados apropiadamente, aún donde la documentación formal (como las páginas de manual) también hayan sido parcheadas para describir los cambios.

Traducciones: El mantenimiento de las traducciones upstream tiene la ventaja de establecer comunidades de traductores, que probablemente tengan más experiencia con los términos del proyecto. Los proyectos downstream se benefician cuando utilizan esas traducciones. Además, elimina la carga de alojamiento y la necesidad de fusionarse a menudo desde el nivel upstream al downstream y viceversa. Para garantizar que el trabajo de traducción continúe en sentido upstream. Cualquier cambio en una cadena que se haya introducido por un parche debería ser mantenido por la comunidad downstream.

Aceptación Upstream: Fedora está downstream de muchos miles de proyecto de software. Mucho de este software está empaquetado por mantenedores que no son programadores o carecen de experiencia en el lenguaje(s) en el que el software está escrito. En algunos casos el software tiene una gran y compleja base de código (como el kernel o Libreoffice) y los mantenedores del paquete pueden no tener el mismo nivel de conocimiento en todas las áreas en comparación con los mantenedores de los subsistemas o los desarrolladores upstream. Por esta y otras razones, Fedora necesita la aceptación de los desarrolladores de software upstream. Estos desarrolladores pueden ver cualquier parche importante como un desvío o negarse a recibir informes de errores de los usuarios de Fedora debido a las diferencias en el código base. Fedora como proyecto se esfuerza por ser acogedor y cooperativo con los desarrolladores upstream tanto como sea posible. Debemos evitar parches específicos de Fedora y cualquier parche que sea útil debe enviarse a los desarrolladores a través de listas de correo, rastreadores de errores o correo electrónico directo.

Control de Calidad: Los parches que son aceptados upstream son normalmente revisados o probados por mucha gente que incluye a desarrolladores y probadores. Esto incluye su prueba en otras distribuciones de GNU/Linux. Una desviación del código base común usado por muchos es una oportunidad potencial de introducir una regresión que es específica a Fedora.

Seguridad: Un caso especial de la cuestión de "Garantía de Calidad" son los cambios que tienen implicaciones de seguridad por sorpresa tienen más posibilidades de ser detectados upstream (quien, con frecuencia, tiene un conocimiento más profundo del programa).

Mejoras incrementales rápidas: Mantenerse cerca de las versiones upstream es útil cuando se realiza cambio de versión para actualizaciones que incorporan nuevas funciones. Esto evita vueltas atrás tediosas únicamente de seguridad y correcciones de errores. Las desviaciones upstream pueden obstaculizar significativamente la velocidad de entrada de mejoras de las nuevas versiones a los usuarios finales. Sin embargo, se deben evitar las regresiones y se deben evaluar cuidadosamente las posibles mejoras y nuevas funciones frente al riesgo de dañar la experiencia de los usuarios. Vea más detalles en ref:fesco::Updates_Policy.adoc[Política de Actualizaciones].

Desviaciones ABI o API: Los parches que introducen una nueva interfaz binaria de aplicación (ABI) o una interfaz de programa de aplicación (API) deben evitarse especialmente, incluso si se plantea que los cambios ABI/API lleguen upstream. Cuando estos paquetes lleguen upstream (sí alguna vez lo hacen), los desarrolladores upstream pueden introducir cambios en la ABI/API urante el proceso de revisión del código antes de fusionarlo. Esto podría romper otro software en el repositorio que hace uso de los ABI/API de Fedora parcheados.

Comentarios Directos del Usuario Final: Cuando los usuarios tienen problemas con cualquier software que esté en Fedora, pueden informar de los problemas directamente upstream. Al no desviarse del upstream, mantiene una ubicación central para todos los informes de error en ese software, lo que permite a los mantenedores de paquetes de Fedora concentrarse en un buen empaquetamiento en lugar de actuar entre los usuarios y los problemas upstream.

Hablar upstream. Mantener un flujo regular de comunicación con el proyecto upstream es útil para comprender bien a los desarrolladores upstream y los alienta a ser más receptivos en sus solicitudes. También ayuda en el entendimiento de cuestiones técnicas como, por ejemplo, como prefieren que se envíen los parches.

Hacer los parches lo bastante genéricos para ser mantenidos por los desarrolladores upstream. Explicar la necesidad de sus parches, esto es, que errores corrigen o que nuevas características añaden. Cualquier referencia a los informes bugzilla o las peticiones de los usuarios pueden ser bastante útiles para los desarrolladores que reciben sus parches.

No considere que cualquier cambio sea demasiado pequeño para enviarlo upstream. Incluso los cambios menores como la corrección de un permiso en un archivo o la exclusión de un archivo vacío puede y debería ser reportado upstream incluso en el caso que upstream no se actúe necesariamente sobre todos ellos rápidamente.

Divida los parches en partes pequeñas e independientes que sigan siendo funcionales, de este modo ellos los pueden entender, revisar y aceptar o rechazar individualmente.

Si el parche introduce nuevas cadenas o cambia las existentes, haga los cambios tan genéricos como sea posible.

Corrija su estilo de escritura para que coincida con las directrices del proyecto upstream. Esto puede parecer trivial pero muchos proyectos upstream insisten en que se sigan sus directrices de modo que su código base parezca internamente consistente y sea más fácil de mantener.

Siempre que sea posible, fomente las versiones puntuales upstream que corrigen errores y cuestiones de seguridad solo, para evitar la posibilidad de regresiones.

Pruebe sus cambios lo más detalladamente posible antes de enviarlos upstream. Los parches rotos dejan una mala impresión duradera.

Sea paciente y cooperador. Si se ofrecen comentarios, analice los cambios, responda a las preguntas y proporcione revisiones que solucionen cualquier problema. No llame ni discuta innecesariamente con los desarrolladores upstream. El objetivo general es persuadir a los desarrolladores upstream para que envíen sus parches upstream y no demostrar "quien es mejor." No olvide el elemento humano en estas conversaciones. Si es necesario, tendremos que implementar algunos parches en sentido downstream para hacer cumplir nuestras políticas incluso si el nivel upsream no está de acuerdo con nosotros en ese momento.

Cuestiones Graves de Seguridad O Correcciones de Errores Importantes: Para cualquier cuestión importante como agujeros de seguridad o problemas de pérdida de datos, esperar un nuevo lanzamiento upstream puede ser demasiado retraso. En estas circunstancias, puede ser mejor respaldar esas correcciones upstream o solucionar el problema escribiendo su propio parche y realizar una actualización de Fedora. Si está escribiendo un nuevo parche, envíelo upstream de manera que Fedora comparta los beneficios y evite desviaciones en los nuevos lanzamientos que siguen. Sin embargo, tenga cuidado al acelerar la aplicación de parches. Un parche de seguridad que no esté completo puede dejar agujeros de seguridad inesperados todavía abiertos o un parche que corrige un problema importante puede empeorar el problema. Haga que sus parches sean revisados por pares tanto como sea posible. Debido a las diferencias de planificación de lanzamientos entre los proyectos upstream y los lanzamientos Fedora, los encargados del mantenimiento tendrían que tener en cuenta los bloqueos de funciones y desarrollo en Fedora y solucionar los problemas en consecuencia.

Software no libre o sujeto a patentes: Si los proyectos upstream incluyen software que no sea libre o que tenga problemas de patentes conocidos, dicho software no cumple las Directrices de Licenciamiento y Fedora no lo incluirá. En muchos casos, dicho código es opcional en forma de complementos que Fedora simplemente no necesita incluir en su repositorio de software. En otros casos, podría ser posible trabajar con upstream para hacerlo opcional o parchear partes específicas.

Proyectos Upstream Sin Mantenimiento o que no Responden: En los casos donde los proyectos upstream no tienen mantenimiento o no responden, podría ser aceptable parchear el software. Si el upstream no está mantenido, es posible que desee considerar compartir parches con otras distribuciones o hacerse cargo del mantenimiento si tiene tiempo, habilidades e interés. Tenga cuidado con el mantenimiento del software sin upstream ya que toda la carga de mantener el código base y las tareas de empaquetado recaen sobre usted. ISi el upstream no responde y muchas distribuciones se desvían significativamente podría ser una oportunidad para una bifurcación de distribución cruzada. (Similar a XFree86 y Xorg).

Parches que Van Upstream: Cualquier parche que se sepa que está en desarrollo puede_ ser parcheado temporalmente en Fedora si los parches proporcionan correcciones de errores importantes o, en casos excepcionales, características para los usuarios. Sí se hace esto, el esfuerzo de mantenimiento debería tener un impacto bajo durante el corto período de tiempo hasta que el upstream fusione los parches y realice una nueva versión.

Integración de Distribución: Hay características que son críticas o muy buenas para Fedora como distribución, pero que no han sido suficientemente significativas para que los proyectos upstream acepten las mejoras relacionadas. Utilice su criterio con cuidado al elegir integrar dichos parches, ya que existe una compensación entre la aceptación ascendente y la integración de Fedora y los costes/beneficios asociados.

Agrupación de Librerías: Vea la sección Agrupamiento y Duplicado de Librerías del Sistema de las Packaging Guidelines (Directrices de Empaquetamiento) para más detalles. Por supuesto las correcciones relacionadas con la agrupación deben enviarse upstream si es posible.

Iniciativas Actuales

Todos los parches deberían tener un enlace al error upstream o comentario

https://fedoraproject.org/wiki/PackageMaintainers/TrackingUpstream

https://fedoraproject.org/wiki/PackageMaintainers/TrackingDownstream