Il semble que dans Canonical a pris en compte de nombreux commentaires fait non seulement par la communauté, mais aussi par les développeurs car il y a quelques jours, via des listes de diffusion fait savoir que ont pris la décision de modifier le processus de préparation des versions LTS intermédiaires d'Ubuntu (par exemple, 20.04.1, 20.04.2, 20.04.3, etc.), dans le but d'améliorer la qualité des versions au détriment du respect des délais exacts.
Si les versions intermédiaires précédentes ont été formées en stricte conformité avec le plan prévu, la qualité et l'intégrité des tests de tous les correctifs seront désormais priorisées.
Les changements ont été adoptés en tenant compte de l'expérience de plusieurs incidents passés, à la suite de quoi, en raison de l'ajout d'un correctif à la dernière minute et du manque de temps pour la vérification, des modifications régressives ou des solutions incomplètes du problème sont apparues dans la version.
Dans le but d'améliorer nos processus et la qualité de Spot release images LTS, à partir du 20.04.3 (en août), nous serons essayer une approche légèrement plus sûre. Fondamentalement, le principal changement notable est-ce que maintenant nous suivrons les procédures SRU même pour tout bloqueurs de publication que nous avons trouvés au cours de la semaine de publication unique. Ce signifie qu'en plus de quelques cas très exceptionnels, chaque correction (même pour un bloqueur) devra suivre la même vérification, régression processus d'analyse et période de vieillissement, auquel cas, si une erreur est détectée dans les images post-candidats, nous retarderons simplement le point relâcher jusqu'à ce que la correction soit vérifiée, vieillie et seulement ensuite postée sur mises à jour.
Retarder la libération d'un point est malheureux, mais c'est mieux que de réduire notre
Normes de qualité.
Avec lui, ils mentionnent essentiellement que à partir de la mise à jour d'Ubuntu 20.04.3 août, toute correction de bogue classée comme crash de lancement effectué dans la semaine avant le lancement prévu Cela changera l'heure de lancement, ce qui permettra de ne pas appuyer sur la correction à la hâte, mais de tout tester et vérifier en profondeur.
En d'autres termes, si une erreur est trouvée sur les builds qui ont le statut de release candidate, la publication sera désormais retardée jusqu'à ce que toutes les révisions du correctif soient terminées.
Nous avons déjà eu des cas où nos corrections de dernière minute se sont accélérées sous la pression du temps, ils n'ont pas été suffisamment testés et ont été introduits régressions (ou, tout aussi ennuyeux, semblaient n'être que partielles arrangements). La qualité étant l'aspect le plus important de toute version d'Ubuntu, nous voulons nous assurer que les utilisateurs bénéficient de la meilleure expérience de notre images de sortie de spot.
Pour s'adapter à ce changement et s'assurer que le plus grand nombre de bloqueurs de version sont trouvés dans les plus brefs délais, nous modifierons également la proposition de l'image quotidienne de la série est compilée 2 semaines avant la sortie (donc semaine avant que les images des candidats ne soient prévues pour la première version).
Auparavant, nous gardions les images quotidiennes activées pour les propositions jusqu'à une semaine avant le lancement (ne les désactivant que pour le lancement des candidats sont construits), principalement comme un héritage de l'ancien temps lorsqu'il est proposé comme tout a été mis à jour dans le cadre du processus. Cela n'a pas a déjà été fait pendant des années (car ce n'est plus sûr), alors partez proposition dans les journaux a moins de sens que par le passé.
Pour la détection précoce des problèmes bloquant la publication, il a également été décidé d'augmenter le temps de gel des builds quotidiens d'une semaine à deux semaines avant la sortie, c'est-à -dire qu'avant la sortie de la première version candidate, il y aura une semaine supplémentaire pour tester le quotidien gelé. construire.
Enfin, Il convient également de noter qu'il a été annoncé que la base Ubuntu 21.04 était gelée de l'introduction de nouvelles fonctions (Feature Freeze) et l'objectif a été changé pour finaliser les innovations déjà intégrées, identifier et éliminer les erreurs.
Si vous voulez en savoir plus, vous pouvez consulter le lien suivant.