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 Fedora Board nel marzo 2010 ed è citata nell’attuale politica di aggiornamento del Fedora Engineering Steering Committee [https://docs.fedoraproject.org/en-US/fesco/Updates\_Policy/](https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/). Sebbene alcuni fattori di contesto siano cambiati da allora, i principi fondamentali che hanno informato la politica di FESCo sono ancora rilevanti. |
Contesto
Le discussioni di marzo 2010 in varie mailing list di Fedora hanno mostrato che attualmente esistono molte posizioni diverse su come dovrebbe essere la strategia di aggiornamento di Fedora. Queste variano da una soluzione di aggiornamento rolling a una soluzione bloccata e limitata solo a aggiornamenti di sicurezza. La mancanza di chiarezza su questo tema contribuisce a creare confusione sia tra i manutentori dei pacchetti sia tra gli utenti finali.
La maggior parte delle persone concorda sul fatto che aggiornamenti difettosi siano dannosi per la distribuzione Fedora e dovrebbero essere evitati.
Meno persone sono d’accordo su:
-
Quanti aggiornamenti sono accettabili per una versione stabile e come misurarli.
-
Cosa costituisce un aggiornamento accettabile per una versione stabile.
-
A quale costo si dovrebbero evitare aggiornamenti difettosi, bilanciando aggiornamenti occasionalmente problematici con la velocità di distribuzione del nuovo software e la semplicità del flusso di lavoro dei manutentori.
Per questi motivi, il Fedora Board sta emettendo una dichiarazione di intenti per l’aggiornamento delle versioni stabili, al fine di guidare la creazione e l’implementazione di una politica sugli aggiornamenti di Fedora. Questa politica non è destinata a governare l’introduzione di nuovi pacchetti.
Creando questa dichiarazione, il Board ritiene che:
-
La soddisfazione dell’utente finale per la nostra distribuzione aumenterà
-
Sviluppatori e utenti finali avranno un’esperienza di versione stabile più solida
-
Gli utenti finali e gli sviluppatori avranno più tempo per concentrarsi su altri ambiti di Fedora
Fattori
Quando si crea una panoramica degli aggiornamenti, è necessario tenere conto di alcuni fattori. Il primo e più importante è tenere a mente i criteri generali che il Board ha definito per il pubblico di riferimento dell’intera distribuzione Fedora, che descrivono qualcuno che:
-
sta passando volontariamente a Linux
-
ha familiarità con i computer ma non è necessariamente un hacker o uno sviluppatore
-
è probabile che collabori in qualche modo quando qualcosa non va con Fedora, e
-
vuole utilizzare Fedora per la produttività generale, sia tramite applicazioni desktop che tramite un browser Web.
Una piattaforma in continua evoluzione e cambiamenti comportamentali visibili influenzeranno la produttività dell’utente, poiché quest’ultimo dovrà sottrarre tempo alle attività desiderate per scoprire cosa è cambiato, adattare il modo in cui esegue le attività di supporto e riconcentrarsi sui propri obiettivi originali. Poiché la produttività è considerata importante per questo utente, questo risultato è indesiderabile. Allo stesso modo, gestire regolarmente un gran numero di aggiornamenti distrae l’utente dalle attività di produttività desiderate.
Gli aggiornamenti offerti dai nostri strumenti integrati sotto l’egida del Progetto Fedora sono considerati autorevoli dagli utenti. Sebbene un utente che soddisfa questi criteri sia propenso a segnalare un bug in caso di problemi, non si aspetta automaticamente che emergano nuovi problemi in una versione stabile a seguito dell’utilizzo di tali aggiornamenti. Quando tali problemi emergono, la fiducia dell’utente nella piattaforma viene compromessa.
Un altro fattore da tenere presente è il rapido ciclo di sviluppo di Fedora. Un ciclo di sviluppo di sei mesi per una release consente a Fedora di integrare le release più recenti e migliori dei progetti upstream nella distribuzione "rawhide" e di rendere disponibile tale corpus di lavoro alla base utenti in un lasso di tempo relativamente breve. Idealmente, questo rapido ciclo di release consente sia agli sviluppatori che agli utenti di concentrarsi su un insieme coerente, consistente e ben funzionante di contenuti software per ogni release.
Dichiarazione di intenti
Considerando il contesto e i vari fattori sopra menzionati, il Consiglio ritiene che i flussi di aggiornamento debbano essere gestiti tenendo presenti i seguenti scopi:
-
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 garantire un’esperienza utente coerente durante tutto il ciclo di vita e correggere solo bug e problemi di sicurezza.
-
Le versioni stabili non dovrebbero essere utilizzate per monitorare da vicino la versione upstream quando è probabile che questa modifichi l’esperienza utente oltre a correggere bug e problemi di sicurezza.
-
Ove possibile, dovremmo monitorare attentamente l’upstream nel repository Rawhide e dovremmo impegnarci a spostare le nostre patch upstream.
-
Si incoraggiano gli utenti più esperti e/o intrepidi a utilizzare Rawhide e a partecipare ai test delle branche stabili durante il periodo di sviluppo e pre-rilascio.
-
Le release stabili, i branch di pre-release e Rawhide hanno un approccio graduale ai tipi di aggiornamenti previsti. Ad esempio, un branch di pre-release dovrebbe accettare alcuni aggiornamenti che una release stabile non accetterebbe, mentre Rawhide accetterebbe aggiornamenti non appropriati né per una release stabile né per una pre-release.
-
I membri del progetto dovrebbero essere in grado di misurare o monitorare in modo trasparente un nuovo processo di aggiornamento per misurarne oggettivamente l’efficacia e determinare se il processo di aggiornamento sta realizzando le dichiarazioni visionarie di cui sopra.
Attuazione
In seguito alla dichiarazione di visione del Consiglio di amministrazione di Fedora, è stata approvata la seguente politica, entrata in vigore a partire da ottobre 2010:
Want to help? Learn how to contribute to Fedora Docs ›