Nota previa:
stable: es el canal estable
rc: es el canal de la versión candidata
devel: es el canal de desarrollo
edge: es el canal de la vanguardia. También un campo de minas
A esta pregunta de @3arn0wl sobre cuándo se trasladará el trabajo que se ha hecho en el canal edge al canal devel, @UniSuperBox responde lo siguiente (texto original aquí).
Realmente no tenía ningún plan sobre dónde expresar mejor esta información, así que este es un lugar tan bueno como cualquier otro.
En RESUMEN: Aún no está listo.
Primero, algunas definiciones para asegurarnos de que estamos en la misma página:
A grandes rasgos, todo lo que se fusiona en una rama de xenial, empaquetado al estilo de Debian en la organización de https://github.com/ubports, se construye y se publica en devel. Esto es lo que queremos decir cuando hablamos de "fusión en edge" o algo similar.
Tenemos la expectativa de publicar una versión de Ubuntu Touch cada 6-8 semanas, incluyendo 2 semanas para pruebas. Esto nos da entre 4-6 semanas de tiempo de "fusión abierta", en un ciclo en el que se pueden fusionar cambios de prioridad baja a crítica. Durante el período de pruebas de 2 semanas solo se realizan fusiones de cambios de prioridad crítica.
Las versiones de Ubuntu Touch se mueven secuencialmente de devel, a rc y a stable. Es decir, «Stable OTA-10» es exactamente el mismo conjunto de bits que rc 2019-W33/2, que es exactamente el mismo conjunto de bits que devel 2019-08-16.
Esta es la única forma en que podemos publicar software. Los cambios que fusionamos en un paquete van a devel, que deberán ir a rc y que deberán ir a stable. No podemos, por ejemplo, sustituir de forma fácil y limpia una versión antigua de un paquete. Si fusionamos cambios rotos, nuestras opciones son o revertir esos cambios o arreglarlos para que no estén rotos. Esa fue la causa del retraso de OTA-10: fusionamos algunos cambios probados inadecuadamente y creímos que podíamos arreglarlos más rápido de lo que podíamos revertirlos. Esto se demostró que no es así.
Para que quede claro, si algo está roto en devel, estará roto en la próxima stable.
Estoy bastante seguro de que llevará más de una semana fusionar todos los cambios de xenial_-_edge a xenial, construir los paquetes correctamente y conseguir que los canales de publicación estén contentos de nuevo. Esto se toma entre 1/4 y 1/3 del tiempo de nuestro ciclo estimado, reduciendo el número de errores que podemos esperar arreglar antes de que podamos publicar de nuevo.
Creo firmemente que "si añades un poco a un poco, tienes un gran montón" (frase atribuida a Hesíodo). Echa un vistazo a https://github.com/orgs/ubports/projects/10. Parece un pequeño montón de cosas. Sin embargo sabemos que, como somos los primeros en adoptar el software de vanguardia, somos por ello probadores imperfectos. No vamos a pillar todas las regresiones de devel a edge. Es por esto por lo que pasamos el software a devel. Mucha gente haciendo pruebas significa más informes de errores y software de mayor calidad. En este caso, eso añadiría un poco más a nuestro pequeño montón. De repente, ya no parece más un montoncito de errores.
No queremos terminar con esa prisa o ese apuro. Significa software de menor calidad. Nuestro objetivo es tener el número de errores conocidos en edge en un punto mínimo en el inicio de un ciclo para que nos podamos tomar nuestras 1-2 semanas para la fusión de xenial_-_edge a xenial. Entonces podemos arreglar la infinidad de errores que la gente encontrará, porque son mejores probadores que nosotros.
Si quieres ayudarnos, prueba el canal edge e informa de cualquier cosa extraña que encuentres. Esto podría retrasar aún más la fusión pero asegurará una transición suave y una publicación más rápida cuando la fusión se lleve a cabo.
