Traducción de ¿Cuándo se pasará el trabajo de «edge» a «devel»?
-
Nota previa:
stable: es el canal establerc: es el canal de la versión candidatadevel: es el canal de desarrolloedge: 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
edgeal canaldevel, @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 endevel. Esto es lo que queremos decir cuando hablamos de "fusión enedge" 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, arcy astable. Es decir, «Stable OTA-10» es exactamente el mismo conjunto de bits querc 2019-W33/2, que es exactamente el mismo conjunto de bits quedevel 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 arcy que deberán ir astable. 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óximastable.Estoy bastante seguro de que llevará más de una semana fusionar todos los cambios de
xenial_-_edgeaxenial, 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
develaedge. Es por esto por lo que pasamos el software adevel. 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
edgeen un punto mínimo en el inicio de un ciclo para que nos podamos tomar nuestras 1-2 semanas para la fusión dexenial_-_edgeaxenial. Entonces podemos arreglar la infinidad de errores que la gente encontrará, porque son mejores probadores que nosotros.Si quieres ayudarnos, prueba el canal
edgee 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.
