Visione aggiornamenti stabili
|
Questa pagina conserva un documento del passato di Fedora. Potrebbe non riflettere (e probabilmente non riflette) le politiche attuali o le pratiche del progetto Fedora. |
|
La "Visione degli aggiornamenti stabili" è stata adottata dal Consiglio di amministrazione di Fedora nel marzo 2010 ed è citata nell’attuale Comitato direttivo di Fedora Engineering policy degli aggiornamenti. Sebbene alcuni fattori di base siano cambiati da allora, i principi fondamentali che hanno ispirato la politica FESCo sono ancora rilevanti. |
Sfondo
Le discussioni del marzo 2010 in varie mailing list di Fedora hanno dimostrato che attualmente disponiamo di un’ampia varietà di posizioni su come dovrebbe essere la strategia di aggiornamento di Fedora. Queste spaziano da una release rolling a una soluzione di aggiornamenti bloccati per la sola sicurezza. La mancanza di chiarezza su questo tema contribuisce a generare confusione sia tra i manutentori dei pacchetti che tra gli utenti finali.
La maggior parte delle persone concorda sul fatto che gli aggiornamenti difettosi siano dannosi per la distribuzione Fedora e debbano essere evitati.
Meno persone sono d’accordo su:
-
Quanti aggiornamenti sono accettabili per una release stabile e come misurarli.
-
Cosa costituisce un aggiornamento accettabile per una release stabile.
-
A quale costo dovrebbero essere evitati gli aggiornamenti difettosi, bilanciando l’occasionale presenza di bug con la velocità di distribuzione del nuovo software e la semplicità del flusso di lavoro dei manutentori.
Per queste ragioni, il Consiglio di Fedora sta rilasciando una dichiarazione di visione sugli aggiornamenti per le release stabili, al fine di guidare la creazione e l’implementazione di una politica degli aggiornamenti di Fedora. Questa politica non è destinata a regolare l’introduzione di nuovi pacchetti.
Creando questa dichiarazione, il Consiglio ritiene che:
-
La soddisfazione dell’utente finale nei confronti della nostra distribuzione aumenterà
-
Gli sviluppatori e gli utenti finali avranno un’esperienza di release stabile più solida
-
Gli utenti finali e gli sviluppatori avranno più tempo per concentrarsi su altre aree di Fedora
Fattori
Nel creare una panoramica degli aggiornamenti, è necessario tenere conto di alcuni fattori. Il primo, e più importante, è tenere a mente i criteri generali stabiliti dal Consiglio per il pubblico di riferimento dell’intera distribuzione Fedora, che descrivono qualcuno che:
-
passa volontariamente a Linux
-
ha familiarità con i computer ma non è necessariamente un hacker o uno sviluppatore
-
è propenso a collaborare in qualche modo quando qualcosa non va in Fedora, e
-
vuole utilizzare Fedora per la produttività generale, sia usando applicazioni desktop che un browser Web.
Una piattaforma in continua evoluzione e cambiamenti comportamentali visibili influiranno sulla produttività dell’utente, poiché quest’ultimo dovrà sottrarre tempo alle attività desiderate per scoprire cosa sia cambiato, adattare il modo in cui svolge le attività di supporto e rifocalizzarsi sui propri obiettivi originali. Poiché si presuppone che la produttività sia importante per questo tipo di utente, tale risultato è indesiderabile. Allo stesso modo, dover gestire regolarmente un gran numero di aggiornamenti distoglie l’attenzione dalle attività produttive che l’utente intende portare a termine.
Gli aggiornamenti offerti dai nostri strumenti integrati sotto l’egida del Progetto Fedora sono considerati autorevoli dagli utenti. Sebbene sia probabile che un utente che risponda a questi criteri segnali un bug quando qualcosa non va, ciò non significa che si aspetti automaticamente l’emergere di nuovi problemi in una versione stabile come conseguenza dell’installazione di tali aggiornamenti. Quando questi problemi si presentano, la fiducia dell’utente nella piattaforma viene minata.
Un altro fattore da tenere a mente è il rapido ciclo di sviluppo di Fedora. Un ciclo di sviluppo semestrale per ogni rilascio consente a Fedora di integrare le ultime e migliori versioni dei progetti upstream nella distribuzione "rawhide", rendendo tale lavoro disponibile alla base di utenti in un lasso di tempo relativamente breve. Idealmente, questo ritmo serrato permette sia agli sviluppatori che agli utenti di concentrarsi su un insieme di contenuti software coerente, costante e ben funzionante per ogni singolo rilascio.
Dichiarazione di intenti
Tenendo conto del contesto e dei vari fattori sopra citati, il Consiglio ritiene che i flussi di aggiornamento debbano essere gestiti con i seguenti obiettivi:
-
I repository di aggiornamento per le versioni stabili della distribuzione Fedora dovrebbero fornire ai nostri utenti un flusso di aggiornamenti coerente e di alta qualità.
-
Le versioni stabili dovrebbero fornire un’esperienza utente coerente durante tutto il loro ciclo di vita, limitandosi a correggere bug e problemi di sicurezza.
-
Le versioni stabili non dovrebbero essere utilizzate per seguire da vicino le versioni upstream quando ciò rischia di modificare l’esperienza utente al di là della correzione di bug e problemi di sicurezza.
-
Il monitoraggio ravvicinato dell’upstream dovrebbe essere effettuato nel repository Rawhide, laddove possibile, e dovremmo sforzarci di integrare le nostre patch direttamente nell’upstream.
-
Gli utenti più esperti e/o intraprendenti sono incoraggiati a utilizzare Rawhide e a partecipare ai test dei rami stabili durante il periodo di sviluppo e di pre-rilascio.
-
Le versioni stabili, i rami di pre-rilascio e Rawhide adottano un approccio graduale rispetto ai tipi di aggiornamenti previsti. Ad esempio, un ramo di pre-rilascio dovrebbe accettare alcuni aggiornamenti che una versione stabile non accetterebbe, mentre Rawhide accetterebbe aggiornamenti non appropriati né per una versione stabile né per una di pre-rilascio.
-
I membri del progetto dovrebbero essere in grado di misurare o monitorare in modo trasparente un nuovo processo di aggiornamento per valutarne oggettivamente l’efficacia e determinare se tale processo stia realizzando le dichiarazioni di intenti precedentemente menzionate.
Implementazione
In conformità con la dichiarazione d’intenti del Fedora Board, la seguente politica è stata approvata ed è in vigore da ottobre 2010:
Want to help? Learn how to contribute to Fedora Docs ›