FAQ/Colaboración entre SUSE y openSUSE Leap

P: ¿En qué consiste el anuncio?

Hace unos 8 años, SUSE ofreció los paquetes fuente de SUSE Linux Enterprise (SLE) para poder usarlos en Leap, para crear Leap, esos paquetes esenciales son recompilados junto con los paquetes específicos de Leap. Algunos de esos paquetes de Leap están directamente basados en openSUSE Tumbleweed la versión rolling release de openSUSE.

Hoy, SUSE está también ofreciendo los binarios precompilados de SLE además de las fuentes, para incrementar la compatibilidad y aprovechar las sinergias.

SUSE quiere llevar la experiencia y la calidad de openSUSE Leap y SUSE Linux Enterprise (SLE) a un nuevo nivel. A SUSE también le gustaría promover openSUSE Leap como una plataforma de desarrollo para comunidades y socios de negocios en el futuro.

Podemos conseguir esto juntos, colaborando de manera estrecha entre openSUSE y SLE.

P: ¿Qué proceso es el que sugiere SUSE?

Un primer paso en esta dirección es simplificar y limpiar los paquetes entre SUSE Linux Enterprise (SLE) y openSUSE Leap. SUSE está empleando recursos de ingeniería en realizar esto rápidamente.

En paralelo, los paquetes binarios de SLE serán ofrecidos en un proyecto compilado llamado Jump (el enlace será actualizado una vez que este disponible). Para asegurar una integración suave, los paquetes binarios no serán añadidos a Leap directamente, todavía.

Como próximo paso, SUSE está sugiriendo reemplazar los binarios actuales de openSUSE Leap con estos del proyecto Jump donde sea posible después de un tiempo de examinación y consolidación. Leap (también como Jump) todavía consistiría en unos paquetes esenciales que están en SLE y openSUSE Leap también como el conocido conjunto de paquetes de openSUSE Leap añade ya encima de esos.

Queremos contribuir a una buena experiencia para la comunidad, no perder las contribuciones de la comunidad o anular decisiones, así estamos revisando de manera activa y manual cada código base y reducir la desviación, así que sobre todo hay un resultado positivo para ambos flujos de código.

Esta limpieza y preparación es un trabajo de campo muy importante que preparará el escenario para una colaboración posterior y más unidad de SLE y openSUSE Leap para los próximos años. Para acomodar el trabajo de preparación para openSUSE Leap, SUSE ha decidido retrasar su propia publicación de SUSE Linux Enterprise 15 SP2 unas 4 semanas.

La comunidad de desarrolladores verán los siguientes beneficios para los paquetes básicos (aquellos que son idénticos en Leap y SLE):

• Paquetes bien probados. Los usuarios de Leap recibirán paquetes que han sido sometidos a un riguroso testeo.
• Actualizaciones bien probadas. SUSE hará disponibles las actualizaciones para los paquetes que provienen de SLE, y utilizará recursos en testear y arreglarlas.
• Un método de reporte de errores más sencillo. Los ingenieros de SUSE serán capaces de echar un vistazo a los errores más rápidamente, ya que se reducen los "errores de recompilado" debido a las diferentes configuraciones de compilación (Leap vs. SLE) para los paquetes.
• Utilizar código de alta calidad. En general se espera que haya mejoras en la calidad para ambos proyectos (Leap y SLE). Además, ambos se beneficiarán de la limpieza de los archivos spec que ocurrirá durante este proceso. Menos condicionante harán que haya una menor confusión.

P: ¿Qué significa esto para openSUSE Leap?

La propuesta es ofrecida a la comunidad para evaluarla y discutir la oferta de SUSE y la visión para un próximo lanzamiento. Los binarios estarán disponibles mediante un prototipo de distribución llamada Jump. Esto ofrece a openSUSE una oportunidad de discutir la propuesta y colectivamente formar una opinión sobre la visión para unir ambos flujos de código. Hay varios pasos o fases para que todo el proceso se logre.

Primero, los archivos _spec_ de los paquetes afectado son revisado, las versiones son adaptadas y los paquetes que no han sido compilados antes serán compilados en uno u otro proyecto. Esto no debería tener un impacto en la funcionalidad ofrecida en openSUSE Leap, excepto donde por ejemplo una versión de un paquete pudiera ser actualizada. Mejor del código, los archivos _spec_ de números de tres dígitos cambiarán, se simplificarán y algunos errores internos serán solucionados.

En paralelo, el proyecto Jump estará lleno con los binarios pre compilados desde SUSE Linux Enterprise.

SUSE sugiere y está dispuesta a invertir, crear una publicación openSUSE Leap intermedia en octubre de 2020, para comprobar la integración de los paquetes binarios de SLE en Leap.

Los dos proyectos pueden coexistir durante un tiempo. Durante ese periodo, la comunidad de openSUSE Leap, usuarios y Equipo de Publicación pueden comparar las ofertas y decidir si es correcta la oferta de Jump para la nueva versión de Leap 15.3. Este periodo de tiempo permite realizar adaptaciones y correcciones donde sea necesario.

Solo cuando el contenido de Jump sea utilizado dentro de Leap 15.3 un cambio (visible) se realizará en openSUSE Leap. Esto es parcialmente debido a las diferentes firmas y en parte a los valores predeterminados.

P: ¿Hay una manera sencilla de actualizar un paquete de openSUSE Leap que provenga de SUSE Linux Enterprise?

¡Lo habrá! SUSE planea introducir un nuevo proceso para exactamente este propósito a finales de este año, hasta entonces, continuaremos con las "buenas prácticas" actuales:

La buena práctica actual es contactar con el responsable del paquete ya sea mediante bugzilla o mediante un correo electrónico. El responsable puede encontrar útil si tienes un paquete compilado con los cambios sugeridos en open build service y así lo puede importar directamente. Si no puedes contactar con el responsable envía una petición directamente a openSUSE Leap y el gestor del lanzamiento lo convertirá en una petición de una nuevas caracterísiticas de SLE por ti. Esto también se puede utilizar para una petición de documentación.

Otra opción es utilizar bugzilla.opensuse.org donde el gestor del lanzamiento procesa todos los errores de la distribución openSUSE con una nueva prioridad (P5) y convierte la petición de las funcionalidad con una razón suficientemente buena en una funcionalidad de SLE.

Sabemos que esta práctica existente no es conveniente y queremos mejorar durante los siguientes meses, permitiendo un impacto más directo en los paquetes y las peticiones.

P: ¿Cual es el plan de ruta para esto?

Las tareas requeridas para las propuestas serán realizadas en varias etapas. Una propuesta de plan de ruta es la siguiente:

Ahora mismo: Como parte de SUSE Linux Enterprise, SUSE ha escogido comenzar ya el trabajo en muchas de estas tareas ya que en la mayoría de los casos las diferencias no deberían haber tenido lugar. Esto incluye el trabajo en los paquetes, la limpieza de los archivos _spec_, solución de errores y algunas más. En algunos casos el efecto es solo visible en SLE, que ocurrirá como una actualización de versión o la habilitación del compilado de un subpaquete.

Seguido al anuncio y la aceptación general de la propuesta: La implementación de low proyectos requeridos y los procesos comenzarán. Esto incluye la configuración del proyecto en openSUSE Build Service (OBS), la creación de los scripts y mecanismos de sincronización de paquetes desde Internal BuildService (IBS) a la instancia de openSUSE (OBS).

Julio de 2020: SLE 15 SP2, openSUSE Leap 15.2 y Jump serán publicadas, con la mayoría del trabajo de limpieza y consolidación realizado. Los binarios en la intersección de SLE y Jump son idénticos. Los binarios de Leap serán diferentes, debido a las fuentes, que aunque son idénticas, todavía difieren en el compilado.

Octubre de 2020: La propuesta es realizar Jump la nueva Leap (con una número de versión todavía a discutir). La conferencia de openSUSE en octubre es una buena oportunidad para discutir la decisión mientras la propuesta debería seguir adelante, haciendo los cambios/modificaciones donde sea necesario o si la propuesto no debería ejecutarse.

Julio de 2021: Si la propuesta es aceptada, SLE 15 SP3 y Leap 15.3 se publicarán, mientras que Jump ya no será necesaria.

P: ¿Dónde se discutirá esta propuesta?

La propuesta fue enviada las listas de correo de opensuse-project y opensuse-factory. Estas dos listas de correo son los cauces lógicos para discutir la propuesta y las implicaciones técnicas respectivamente.

P: ¿Convivirán los dos proyectos Leap y Jump coexistir para siempre?

No. La intención es tener a Leap y Jump existir en paralelo durante unos meses. Cuando openSUSE Leap 15.3 / SLE 15 SP3 sean publicadas, solo uno de los dos proyectos continuará. Ya sea "Jump" o "Leap" (como lo es ahora mismo) y como se llame será escogido por la comunidad para decidir antes de la publicación (Ver también "¿Cual es el plan de ruta para esto?").

Renombrar la distribución no es recomendable. Es una posible decisión, sin embargo, renombrar una distribución plantea unos retos como descubrimos cuando migramos de openSUSE 13.2 a openSUSE Leap 42.1.

P: ¿Por qué al prototipo se le llama "Jump"?

El prototipo de una nueva Leap necesita un nombre, para distinguirlo entre el antiguo y el nuevo formato de una manera adecuado. El nombre debería ser algo similar a "Leap", pero que también refleje que este es un gran salto para los paquetes de ser compilados en un sistema interno a ser compilados por el sistema de openSUSE. Y el nombre "Leap" ya estaba cogido (guiño).

P: ¿Seré capaz de poder añadir mis propios paquetes a la nueva publicación?

Sí, la publicación permitirá a los usuarios/desarrolladores añadir sus propios paquetes. Ver más adelante "cómo". Como hasta ahora openSUSE Tumbleweed continuará siento la manera de enviar paquetes para Leap y SLE.

P: ¿Cómo actualizo o añado un nuevo paquete al nuevo openSUSE Leap?

La respuesta es muy simple: Creas una petición para cualquiera de las próximas versiones de openSUSE Leap. El equipo de publicación comprobará si el paquete es completamente nuevo o si ya está disponible en SLE, y gestionará la petición de manera coordenada. Todavía se aplica el lema "Factory primero".

P: Tanto openSUSE Leap y SUSE Linux Enterprise soportarán un conjunto diferente de plataformas ¿Qué significa esto para openSUSE Leap?

SUSE Linux Enterprise 15 se ofrece para cuatro arquitecturas: aarch64, x86-64, ppc64le, s390x. Estas también estarán disponibles para openSUSE Leap and Jump.

openSUSE Leap mantendrá RISC-V y ARMv7. Estas deberán ser compiladas juntas con los paquetes restantes en un proyecto separado.

Actualmente no hay planes de compilar SLe para RISC-V y ARMv7.

P: ¿Qué consigo con un aplazamiento de 8 semanas del lanzamiento? ¿Por qué no postponer todos los cambios para el próximo lanzamiento?

Nos gustaría tener una prueba de trabajo y un mecanismo de nuevas actualizaciones antes de entrar en la fase Beta para openSUSE Leap 15.3. Y estos cambios son muy grandes para un único lanzamiento.

El tiempo extrar será utilizado en reducir el número de "forks" de los paquetes de SLE en Leap. Esto también reduciría el trabajo para los responsables de openSUSE Leap y los ingenieros de lanzamiento.

Tanto la versión Beta y las fases de "Release Candidate" (RC) serán extendidas y esto nos dará más tiempo para finalizar el refresco de paquetes desde Factory.

P: ¿Podré aumentar las solicitudes de funciones para Leap en el futuro?

Sí. No será posible en los próximos días, pero está planeado para openSUSE Leap 15.3 /SLE 15 SP3 como muy tarde.

P: ¿Cómo podré reportar "bugs" después de que el cambio a "Jump" se haya realizado?

No hay cambios en el proceso en el proceso para "bugs". Puedes reportar errores sobre producto openSUSE en https://bugzilla.opensuse.org/

La petición de funcionalidades se gestionará de manera separada, ver: "¿Hay una forma sencilla de actualizar un paquete de openSUSE Leap que provenga de SUSE Linux Enterprise?"

P: ¿Cual sería el beneficio de incluir más paquetes de SUSE Linux Enterprise (SLE)?

SLE y Leap comparten más recursos si los repositorios de Package Hub son incluidos. Las compilaciones de terceras partes serán compatibles con ambas, tanto con Leap como con SLE.

P: ¿Por qué no tener simplemente una distribución FreeSLE?

SUSE consideró esto como una opción, pero sintió que traería competencia de intereses con las publicaciones de openSUSE. SUSE cree que la propuesta actual es la mejor opción tanto para openSUSE como para SUSE, y ve la propuesta como una unificación de esfuerzos y de las comunidades de desarrollo de contribuir con Leap. Acercando Leap y SLE se consigue un verdadero código común de base y fomenta un mensaje y una plataforma consistente para desarrolladores.

P: ¿Por qué no es SLE simplemente desarrollada completamente en el servicio de compilado de Build Service de la comunidad openSUSE?

Actualmente, esto no es posible debido a diferentes factores externos, incluyendo requisitos de certificaciones y gestión de socios tecnológicos. Sin embargo se considera como opción para próximos flujos de código importantes.

P: ¿Donde consigo más información sobre los prototipos de binarios basados en SLE para el próximo openSUSE Leap?

Los enlaces al proyecto Jump serán añadidos aquí después de que acaben los ajustes del proyecto.

P: ¿Cómo sería el modelo de fin de vida de soporte para cada versión?

El modelo de fin de vida (End Of Life EOL) seguirá siendo el mismo. Los usuarios tendrán un plazo de 6 meses para actualizar a la nueva versión desde su publicación.

P: ¿Se verá afectado el mantenimiento y la seguridad para Leap 15.1 o 15.2?

Leap 15.1 tendrá un EOL más largo que el originalmente planeado. Leap 15.2 tendría un EOL similar a las versiones previas de Leap. El lanzamiento propuesto con los binarios de SLE recibiría el mismo mantenimiento y actualizaciones de seguridad de SLE, así que hay una posibilidad de beneficiarse de mover el código a una posición común.

P: ¿Seguirá openSUSE Leap publicándose bajo una licencia GPL?

Sí, el acuerdo de licencia de usuario final para openSUSE no cambiará.

P: ¿Los usuarios de openSUSE necesitarán registrarse para acceder a los binarios de Leap?

No, No se requerirá ningún registro para descargar, actualizar o utilizar openSUSE Leap.

P: ¿Será más complicado contribuir con Leap?

No, El proceso para contribuir con los paquetes esenciales seguirá siendo el mismo. Todos los paquetes compartidos seguirán estando disponibles en Open buil Service para la comunidad para hacer un "fork" y modificar cuando se necesite.

P: ¿Cuales serían los riesgos de unir los dos flujos de código?

Si no se prepara correctamente, el cambio podría acarrear problemas de desarrollos para los colaboradores a los paquetes esenciales. Las opciones han sido discutidas en cómo reducir cualquier impacto negativo en los colaboradores, ver más arriba "¿Podré aumentar las solicitudes de funciones para Leap en el futuro?"

P: ¿Habrá algunos problemas de funcionalidades?

Las funcionalidades que no están disponibles en SLE se espera que estén disponibles mediante "forks" o sub-paquetes en Leap. Podría hacer pequeñas diferencias funcionales como más soluciones de errores en Leap, pero la cantidad de estos es considerada baja y podría no afectar a los usuarios directamente.

P: ¿Cómo se tratarán las diferencias entre SLE y openSUSE?

Hay múltiples formas de abordar esto:

• Implementar las funciones openSUSE Leap o un subconjunto de las mismas en SUSE Linux Enterprise 15 *. Esto requiere aprobación como parte del proceso de requisitos de SUSE Linux Enterprise. El equipo de gestión de productos de SUSE ha expresado su voluntad de abrir y mejorar este proceso, por lo que los miembros de la comunidad puedan interactuar directamente.
• Dividir la funcionalidad en un paquete separado específico de Leap (similar a la marca)
• Siempre que sea posible, modificar las diferencias para que sea independiente del sistema (leer las cadenas de /etc/os-release durante la instalación).