Sembra che in Canonical ha tenuto conto di molti dei commenti realizzato non solo dalla community, ma anche dagli sviluppatori perché pochi giorni fa, tramite mailing list fatto sapere che hanno preso la decisione di apportare una modifica al processo per preparare le versioni intermedie di LTS di Ubuntu (ad esempio, 20.04.1, 20.04.2, 20.04.3, ecc.), con l'obiettivo di migliorare la qualità delle versioni a scapito del rispetto delle scadenze esatte.
Se le precedenti versioni provvisorie sono state formate in stretta conformità con il piano pianificato, la qualità e l'integrità del test di tutte le correzioni avranno ora la priorità.
Le modifiche sono state adottate tenendo conto dell'esperienza di diversi incidenti passati, in conseguenza di ciò, a causa dell'aggiunta di una correzione all'ultimo minuto e della mancanza di tempo per la verifica, nella versione sono sorte modifiche regressive o soluzioni incomplete del problema.
Nel tentativo di migliorare i nostri processi e la qualità di Immagini LTS rilascio spot, a partire dal 20.04.3 (ad agosto) saremo cercando un approccio leggermente più sicuro. Fondamentalmente il principale cambiamento evidente è che ora seguiremo le procedure SRU anche per qualsiasi blocchi di rilascio che abbiamo trovato durante la settimana di rilascio spot. Questo significa che, oltre ad alcuni casi del tutto eccezionali, ogni correzione (anche per a blocker) dovrà seguire la stessa verifica, regressione processo di analisi e periodo di invecchiamento, nel qual caso, se viene riscontrato un errore nelle immagini post candidate ritarderemo semplicemente il punto rilasciare fino a quando la correzione non sarà verificata, invecchiata e solo successivamente pubblicata aggiornamenti.
Ritardare il rilascio di un punto è sfortunato, ma è meglio che ridurre il nostro
Standard di qualità.
Con questo, fondamentalmente lo menzionano a partire dall'aggiornamento di agosto di Ubuntu 20.04.3, eventuali correzioni di bug classificate come crash di avvio realizzato entro una settimana prima del lancio programmato cambierà il tempo di lancio, che consentirà di non premere la correzione in fretta, ma di testare e verificare a fondo il tutto.
In altre parole, se viene rilevato un errore sulle build che hanno lo stato di release candidate, il rilascio verrà ora ritardato fino al completamento di tutte le revisioni per la correzione.
Abbiamo già avuto alcuni casi in cui le nostre correzioni dell'ultimo minuto sono accelerate sotto la pressione del tempo, non sono stati testati abbastanza a fondo e introdotti regressioni (o, altrettanto fastidiose, sembravano essere solo parziali arrangiamenti). Poiché la qualità è l'aspetto più importante di qualsiasi versione di Ubuntu, vogliamo assicurarci che gli utenti ottengano la migliore esperienza dal nostro immagini di rilascio spot.
Per adattarsi a questa modifica e garantire che il maggior numero di blocchi di rilascio si trovano appena possibile, cambieremo anche la proposta dell'immagine quotidiana della serie viene compilata 2 settimane prima del rilascio (quindi settimana prima che le immagini candidate siano pianificate per il primo rilascio).
In precedenza, mantenevamo abilitate le immagini giornaliere per le proposte fino a una settimana prima del lancio (disabilitandoli solo per quando lanciano i candidati sono costruiti), principalmente come eredità dei vecchi tempi quando proposti come file tutto è stato aggiornato come parte del processo. Questo non ha è già stato fatto per anni (dato che non è più sicuro), quindi vattene la proposta sui giornali ha meno senso che in passato.
Per il rilevamento precoce dei problemi che bloccano il rilascio, è stato anche deciso di aumentare il tempo di congelamento per le build giornaliere da una settimana a due settimane prima del rilascio, ovvero prima che venga rilasciato il primo candidato alla versione, ci sarà una settimana aggiuntiva per testare il quotidiano congelato costruire.
Infine, degno di nota anche il fatto che è stato annunciato che il dock di Ubuntu 21.04 si è bloccato dall'introduzione di nuove funzionalità (Feature Freeze) e l'attenzione si è spostata per finalizzare le innovazioni già integrate, individuando ed eliminando gli errori.
Se vuoi saperne di più, puoi consultare il seguente collegamento.