Politica sugli aggiornamenti

La fondazione “First” di Fedora

Fedora Linux is a fast-moving distribution by design. This is expressed in our First foundation: we provide the latest in stable and robust, useful, and powerful free software.

La nostra comunità si aspetta che Fedora integri rapidamente nei propri repository le nuove versioni dei software provenienti da vari progetti a monte, ma con il minimo disagio e in modo che si integrino perfettamente con gli altri pacchetti. Questo equilibrio è alla base del ruolo di manutentore di pacchetti, e il presente documento descrive le nostre linee guida per collaborare al fine di garantire la migliore esperienza possibile a tutti.

Riponiamo grande fiducia nei singoli manutentori dei pacchetti per quanto riguarda la gestione e l’aggiornamento dei loro pacchetti, nel rispetto delle Linee guida per il packaging di Fedora e delle politiche qui riportate. Tuttavia, vi preghiamo di ricordare che si tratta di uno sforzo collettivo. Rispettiamo, apprezziamo e celebriamo il lavoro che ogni singolo manutentore dedica ai propri pacchetti, e inoltre incoraggiamo la co-manutenzione e la collaborazione per migliorare il packaging nell’intera collezione Fedora.

Informazioni sulla presente informativa

Fedora has differing policies for each of its branches. This document describes for maintainers what sort of updates should be created in packages for each of the various branches of existing Fedora. In the event of questions or clarifications, please file a FESCo ticket or discuss on the devel list. In general, releases should go from less conservative (Rawhide) to more so (the oldest supported stable release). This document attempts to describe when and what kinds of updates maintainers should push to Fedora users of its various branches. The Stable release updates vision from the Fedora Board includes more high level discussion and philosophy, while this document is more a practical guide. Refer to Package Update Guide for the technical steps on pushing the updates. The Fedora Release Life Cycle provides a more detailed overview of the development process.

Requisiti di aggiornamento comuni a tutte le versioni di Fedora

Alcuni criteri si applicano a qualsiasi aggiornamento di qualsiasi ramo o versione di Fedora:

"Aggiornamento di pacchetti interdipendenti"

Quando un pacchetto aggiornato richiede uno o più altri pacchetti, questi devono essere inviati insieme come un unico aggiornamento. Per esempio, se il pacchetto A dipende dai pacchetti B e C e si desidera aggiornare A a una nuova versione che richiede versioni aggiornate di B e C, è necessario inviare un singolo aggiornamento contenente tutti e tre i pacchetti. Inviare tre aggiornamenti separati è sconsigliato: se l’aggiornamento del pacchetto A venisse approvato come stable prima di quelli per B e C, si verificherebbero problemi di dipendenze. Ulteriori informazioni su come inviare aggiornamenti multi-pacchetto sono disponibili nella Guida all’aggiornamento dei pacchetti, mentre le istruzioni sull’uso dei side-tag per aggiornamenti multipli si trovano in Rawhide Gating/multi-builds.

"Aggiornamenti pronti al consumo"

Gli aggiornamenti su Bodhi dovrebbero essere creati solo per le build che si prevede abbiano i requisiti per essere pubblicate come stabili. I manutentori non dovrebbero utilizzare gli stati di "testing" di Bodhi per testare aggiornamenti che non intendono mai rilasciare in versione stabile. Questo tipo di test dovrebbe essere effettuato in Copr o in altri repository pubblici separati. Consulta il team QA per ulteriore assistenza relativa ai test.

Rawhide

Rawhide è l’albero di sviluppo a rilascio continuo (sempre in evoluzione). Gli aggiornamenti dei pacchetti compilati per Rawhide vengono assemblati ogni giorno e distribuiti a tutti gli utenti. Anche le nuove versioni compilate in questo albero vengono aggiunte alla radice di compilazione (build root), il che significa che altri pacchetti verranno compilati basandosi su di esse. Questo albero ha lo scopo di soddisfare i Criteri di Rilascio Base per ogni composizione completata con successo, affinché i manutentori possano integrare le proprie modifiche con quelle di tutti gli altri.

Repository disponibili: rawhide

Da quando è stata introdotta la modifica Gating Rawhide Packages, gli aggiornamenti dei pacchetti in Fedora Rawhide devono superare una verifica prima di approdare nei repository di Rawhide. Questo è implementato come un controllo per l’aggiornamento Bodhi, che verifica che l’aggiornamento soddisfi la policy di Gating. Per i dettagli, consultare Rawhide Gating/Single Builds e Rawhide Gating/Multi Builds.

Attualmente la policy di gating predefinita è vuota, quindi un aggiornamento di Rawhide può superare il gate indipendentemente dai risultati dei test. Il manutentore del pacchetto può scegliere di attivare il gating per un pacchetto (opt-in) impostando policy di gating individuali; consulta Come attivare il gating (How to Opt in to Gating). By the way, to unlock the full functionality of all Apps, enable Gemini Apps Activity.

Non appena una build viene completata, viene creato automaticamente un aggiornamento Bodhi. L’aggiornamento viene utilizzato per raccogliere i risultati dei test. Se i test di gating hanno esito positivo, l’aggiornamento viene contrassegnato come stabile dopo pochi minuti, inviato nel repository stable e aggiunto alla successiva compilazione notturna (nightly compose).

"Per gli aggiornamenti dei pacchetti in Rawhide, i manutentori DEVONO:"

  • "non caricare (push) build notoriamente non funzionanti (che rompano il set di pacchetti del buildroot predefinito, ecc.). Ciò comporta lavoro extra per gli altri manutentori che cercano di integrare le proprie modifiche."

  • "Quando un aggiornamento proposto contiene una modifica alle ABI o alle API: notifica con una settimana di anticipo sia la lista devel sia direttamente i manutentori (usando l’alias nomepacchetto-maintainers@fedoraproject.org) i cui pacchetti dipendono dal tuo, affinché possano procedere alla ricompilazione o offriti di effettuarla tu per loro.

  • "Usa un side-tag quando gestisci build di massa di molti pacchetti, così che possano essere inseriti nel repository contemporaneamente. Consulta Rawhide Gating/Multi Builds.

  • "Sentiti libero di pubblicare l’ultima versione dei pacchetti, a patto che non causino rotture. Tieni però a mente quando avverrà il branching del prossimo rilascio di Fedora e assicurati con ragionevole certezza che ci sarà una versione sufficientemente stabile in tempo per tale rilascio. In caso contrario, potresti dover fare un downgrade a una versione precedente e stabile dopo il branching, il che potrebbe comportare l’uso di epoch e altri inconvenienti.

  • "Una volta che un pacchetto è stato aggiunto al compose e quest’ultimo è stato completato e sincronizzato con i mirror principali, normalmente non verrà rimosso (untagged). Ciò è necessario per consentire ad altri di dipendere dalla build una volta che questa è diventata visibile. In casi eccezionali, il team releng (release engineering) può procedere alla rimozione dei tag dai pacchetti.

  • "Se approvato dal FESCo, pubblica le versioni pre-release dei pacchetti di basso livello. Il FESCo autorizza determinati pacchetti, inclusi (ma non limitati a) glibc e gcc, a fornire versioni pre-release in questa fase. I benefici derivanti dai test precoci nel mondo reale e dalla collaborazione con gli sviluppatori a monte (upstream) su questi pacchetti chiave superano di gran lunga i rischi che potrebbero introdurre.

"Flusso degli aggiornamenti"

Versione derivata

"Per una parte del ciclo di sviluppo esiste una versione Branched (ramificata). Inizia come un fork di Rawhide e diventa infine la successiva release stabile. Tutte le build (composes) branched completate con successo dovrebbero soddisfare i Criteri di Rilascio Base."

"Le versioni Branched utilizzano il sistema di feedback per gli aggiornamenti (Bodhi): inizialmente funzionano proprio come Rawhide (gli aggiornamenti vengono creati automaticamente al termine di una build, vengono eseguiti i test e le build vengono inserite automaticamente nel compose successivo), ma dopo l’attivazione della fase updates-testing passano a funzionare come le release stabili (i manutentori devono creare manualmente gli aggiornamenti, sottoporli ai test, ecc.)."

"Esistono diverse fasi che una release Branched attraversa e che influenzano quali aggiornamenti possono e devono essere effettuati. In generale, i manutentori dovrebbero tenere presente che questo ramo è in fase di stabilizzazione per il prossimo rilascio; pertanto, i cambiamenti devono essere prudenti, ponderati e orientati alla stabilità."

"Dopo il branching, ci sono tre fasi di blocco (freeze): il post-branch-freeze, il beta-freeze e il final-freeze."

Post-branch Freeze

"Una volta che la nuova release viene separata (branched) da Rawhide, il flusso degli aggiornamenti tramite Bodhi viene interrotto fino a quando non viene completata con successo una compose del ramo. Questo periodo dura solitamente solo pochi giorni. Il team di Release Engineering potrebbe far passare alcuni aggiornamenti al ramo stabile per consentire il completamento della compose, ma per il resto tutti gli aggiornamenti vengono messi in pausa fino al completamento di questa compose iniziale del ramo. Questo serve a garantire di avere una base solida su cui costruire, evitando di dover gestire problemi derivanti da nuovi aggiornamenti prima di essere pronti a riceverli.

"Prima dell’attivazione dei test degli aggiornamenti (Updates-testing)"

"Per un breve periodo dopo il branching, ma prima del Beta Freeze and Updates-testing Activation, la versione Branched funziona come Rawhide: i build inviati dai pacchettizzatori sono considerati stabili dopo aver superato i test di verifica (gating) tramite un aggiornamento Bodhi, e vengono inviati direttamente al repository [fedora] nel successivo 'nightly compose'. In questa fase non ci sono restrizioni oltre a quelle previste per Rawhide, ma i manutentori DOVREBBERO pensare alla stabilizzazione fin da ora, assicurandosi che i propri pacchetti siano in buone condizioni con largo anticipo rispetto al rilascio della versione stabile.

"Repository disponibili: fedora"

Beta Freeze and Updates-testing Activation

Questo congelamento (freeze) è programmato per durare le tre settimane precedenti alla data di rilascio, ma si protrae fino all’approvazione finale del rilascio, anche in caso di ritardo. Durante il freeze, le build non saranno contrassegnate come stabili né spostate da [updates-testing] a [fedora] (e quindi incluse nelle composizioni della milestone di rilascio), a eccezione di quelle approvate dal team QA di Fedora tramite la [procedura per i bug bloccanti] o la [procedura per le eccezioni al freeze]. Una volta effettuato il rilascio della beta, il freeze viene rimosso. La pagina [Milestone freezes] fornisce ulteriori dettagli ed è il riferimento ufficiale in caso di conflitti.

A questo punto, il sistema di aggiornamento Bodhi viene modificato per la versione "branched", in modo che si comporti come le versioni stabili (vedi sotto) anziché come Rawhide. Da questo momento in poi, i manutentori devono creare degli aggiornamenti prima che i pacchetti diventino disponibili per gli utenti, e tali aggiornamenti devono passare attraverso [updates-testing] per consentire la ricezione di feedback. Gli aggiornamenti vengono spostati dal repository [updates-testing] a quello [fedora] dopo aver raggiunto i requisiti di karma appropriati. Bodhi imposta valori predefiniti ragionevoli per il karma e applica requisiti minimi per gli aggiornamenti. I [requisiti-di-karma] per gli aggiornamenti sono descritti di seguito.

Una volta iniziato il Beta Freeze, cerchiamo di stabilizzare le versioni principali del software che verranno fornite con il rilascio finale del sistema operativo. Gli aggiornamenti di versione (major updates) possono essere tollerati, ma bisognerebbe evitare, se possibile, di compromettere la stabilità del sistema per i tester iniziali.

Durante questo periodo:

  • Tutti gli aggiornamenti inclusi nella release DEVONO correggere un bug considerato "blocker" o un bug che rientri nelle eccezioni del freeze.

  • Tutti gli aggiornamenti devono comunque passare per updates-testing.

Repository disponibili: fedora, updates-testing

I manutentori DOVREBBERO (SHOULD):

  • Evita modifiche alle ABI/API laddove possibile. Se inevitabili, utilizza un side-tag per ricompilare i pacchetti.

  • Evita qualsiasi modifica che interrompa la creazione (compose) di supporti Live, supporti di installazione o immagini di test.

  • Inserisci (land) tutti i pacchetti necessari per le modifiche (Changes) pianificate per quel rilascio.

Dalla Beta al Final Freeze

Questo è il periodo compreso tra il rilascio della Beta e il Congelamento finale. Il branched tree dovrebbe ormai essere stabilizzato e pronto per il rilascio. In questo lasso di tempo, bisognerebbe evitare cambiamenti significativi. Tieni presente che, nella maggior parte dei casi, lo stato raggiunto dal tuo pacchetto nel repository stabile fedora al momento del Final Freeze sarà lo stesso in cui si troverà per il rilascio finale.

Repository disponibili: fedora, updates-testing

Congelamento finale

Questo congelamento porta alla creazione del rilascio finale. È simile al Beta Freeze and Updates-testing Activation descritto sopra e segue le stesse regole per gli aggiornamenti.

Il repository updates viene abilitato a un certo punto durante questo periodo, e i pacchetti diversi dalle eccezioni al congelamento o dalle correzioni per i blocker bug vengono messi in coda per i cosiddetti aggiornamenti "zero day"; ciò significa che saranno disponibili nel repository updates al momento del rilascio (giorno zero).

Repository disponibili: fedora, updates, updates-testing

Durante questo periodo:

  • Tutti gli aggiornamenti inclusi nella release DEVONO correggere un bug considerato "blocker" o un bug che rientri nelle eccezioni del freeze.

  • Tutti gli aggiornamenti passano ancora attraverso il repository updates-testing.

  • Una volta che il repository updates è disponibile, le build contrassegnate come stable verranno inviate lì invece che in fedora.

Rilasci stabili

Filosofia

I rilasci della distribuzione Fedora sono simili ai rilasci dei singoli pacchetti che la compongono. Un numero di versione "major" riflette un insieme più o meno stabile di caratteristiche e funzionalità. Di conseguenza, dovremmo evitare aggiornamenti "major" dei pacchetti all’interno di una release stabile. Gli aggiornamenti dovrebbero mirare a correggere i bug e non a introdurre nuove funzionalità, in particolare quando queste ultime influenzano sensibilmente l’esperienza dell’utente o dello sviluppatore. Il tasso di aggiornamento per ogni specifica release dovrebbe diminuire nel tempo, avvicinandosi allo zero verso la fine del ciclo di vita (end-of-life); poiché gli aggiornamenti sono principalmente correzioni di bug, con il passare del tempo dovrebbero renderne necessari sempre meno.

Questo significa necessariamente che i rilasci stabili non seguiranno da vicino il codice "upstream" più recente per tutti i pacchetti. Per questo scopo abbiamo Rawhide.

Gli aggiornamenti dovrebbero essere attentamente valutati rispetto alle loro dipendenze. Un aggiornamento che richiedesse (o fornisse) una nuova ABI di Python, ad esempio, quasi certamente non verrebbe permesso. In generale, i cambiamenti di ABI sono caldamente sconsigliati: costringono gli utenti a scaricare set di aggiornamenti più pesanti e rendono difficile la vita ai manutentori di terze parti. Inoltre, gli aggiornamenti che convertono risorse o configurazioni in modo unidirezionale (ad esempio, da vecchio → nuovo) dovrebbero essere approvati con estrema cautela, poiché ci sarebbero molte meno possibilità di annullare un aggiornamento che ha eseguito tali operazioni.

Ogniqualvolta sia possibile, i manutentori dei pacchetti dovrebbero collaborare con il progetto "upstream" per definire dei rilasci nei rami stabili (stable branch) o creare patch comuni per le versioni più vecchie, in particolare quando un aggiornamento richiederebbe modifiche a una vasta catena di dipendenze.

Repositories available: fedora updates updates-testing

Durante questo periodo:

Eccezioni

"Alcune classi di software non rientrano in queste linee guida. Se il tuo pacchetto non appartiene a una delle classi elencate di seguito, ma ritieni che debba essere autorizzato a ricevere aggiornamenti più rapidi, proponi una nuova classe di eccezione a FESCo e/o richiedi un’eccezione per il tuo specifico caso di aggiornamento."

"Tieni presente che dovresti aprire questo dialogo prima di compilare o inviare aggiornamenti. Nel caso in cui sorga un problema nel bel mezzo di un aggiornamento già in corso, assicurati di disattivare l’invio automatico tramite karma (autokarma) — operazione che può essere effettuata mentre l’aggiornamento è in sospeso su Bodhi."

"I seguenti elementi verrebbero presi in considerazione in una richiesta di eccezione."

"Fattori che renderebbero più probabile l’accoglimento di una richiesta:"

  • "Il pacchetto è un nodo 'foglia' (leaf). Nulla dipende da esso o lo richiede."

  • "L’aggiornamento risolve un problema di sicurezza che interesserebbe un gran numero di utenti."

  • "L’aggiornamento non modifica l’ABI/API e non è necessario ricompilare nulla a fronte della nuova versione."

  • "L’aggiornamento risolve bug gravi riscontrati da molti utenti Fedora."

"Fattori che renderebbero meno probabile l’accoglimento di una richiesta:"

  • "L’aggiornamento converte database o risorse in modo unidirezionale verso un nuovo formato."

  • "L’aggiornamento richiede l’intervento dell’amministratore affinché il servizio continui a funzionare (modifiche al formato dei file di configurazione, ecc.)"

  • "L’aggiornamento comporta cambiamenti nel comportamento del software (ad esempio, un’azione prima negata viene ora consentita, ecc.)"

  • "Se il pacchetto non è più utile al progetto Fedora, dovrebbe essere ritirato."

  • "L’aggiornamento risolve bug che nessun utente Fedora ha segnalato o che non riguardano molti utenti Fedora (ad esempio, correzioni per altre piattaforme o configurazioni)."

"Elenco delle eccezioni"

Ai seguenti pacchetti sono state concesse eccezioni per le seguenti ragioni:

KDE

"Fare riferimento alla policy di aggiornamento di KDE per ulteriori dettagli."

LXQt

"Al SIG LXQt è concessa un’eccezione permanente per l’insieme di pacchetti LXQt Desktop. (Questa eccezione non si applica ai pacchetti esterni al progetto LXQt)."

"pacchetto kernel"

  • "Vincoli di tempo e di risorse impediscono ai manutentori del kernel di eseguire il backporting di tutte le correzioni di bug, delle patch di sicurezza e del supporto per nuovo hardware che sarebbero necessari per mantenere i kernel più vecchi e non più supportati."

  • "Inoltre, è possibile installare o avviare più kernel contemporaneamente; ciò consente agli utenti di avviare versioni precedenti nel caso in cui quelle più recenti non funzionino, garantendo ai manutentori il tempo necessario per correggere eventuali bug critici nei nuovi kernel sulle versioni stabili più vecchie."

"Pacchetti Rust -devel"

"Questa eccezione copre tutti i pacchetti Rust -devel, ovvero gli RPM con sorgenti Rust. Tali pacchetti vengono utilizzati per compilare i binari Rust pacchettizzati e non sono direttamente utilizzabili dagli utenti."

golang package

FESCo grants a blanket exception to update the golang package (Go toolchain) in stable Fedora releases to the next supported upstream release once the version that was shipped at a Fedora release’s GA has gone end-of-life upstream (FESCO #3570).

"Altri pacchetti"

"Per questi pacchetti è consentito l’aggiornamento nelle versioni stabili:"

  • the document viewer zathura and the girara library (FESCo #1255),

  • 3D printer control application prusa-slicer and the Cura stack (CuraEngine and other packages) (FESCo #2652),

  • Python code formatter python-black (FESCo #2652),

  • Python code linter ruff (FESCo #3197),

  • Python test executor python-tox (FESCo #2652),

  • command-line HTTP client httpie (FESCo #2652),

  • ownCloud Desktop Client owncloud-client (FESCo #2652),

  • KiCad EDA Software Suite kicad, kicad-packages3d, and kicad-doc (FESCo #2762),

  • HTTP parsing library llhttp (FESCo #3115),

  • Automatic Let’s Encrypt SSL tool certbot (FESCo #3124),

  • Python package and project manager uv (FESCo #3262),

  • Python user space tool for the kernel’s DAMON framework python-damo (FESCo #3389),

  • Docker plugins docker-compose, docker-buildx, and docker-buildkit (FESCo #3394),

  • The image editor gimp (FESCo #3511),

  • Python type checker and language server ty (FESCo #3564),

  • WebKitGTK web rendering engine (FESCo #3565),

  • Docker server and command line client (moby-engine, docker-cli) and rootlesskit for unprivileged users (FESCo #3602),

  • containerd container runtime (FESCo #3603),

  • docker distribution container registry (FESCo #3604),

  • go2rpm Go specfile generator (FESCo #3610).

"Correzioni di sicurezza"

"Se l’upstream non fornisce correzioni di sicurezza per un particolare rilascio, e se il backporting della correzione risulta impraticabile, i manutentori del pacchetto DEVONO aprire un ticket FESCo per ottenere l’approvazione al rebase del pacchetto a una versione supportata dall’upstream."

"I manutentori del pacchetto DEVONO:"

  • "Evitare aggiornamenti di versione Major, rotture dell’ABI o modifiche alle API, se possibile"

  • "Evitare di modificare l’esperienza dell’utente o dello sviluppatore, se possibile"

"Il FESCo esaminerà il ticket in modo tempestivo e fornirà indicazioni su come il manutentore (o i manutentori) del pacchetto debba procedere. Di seguito sono elencati alcuni elementi comuni che renderebbero meno probabile l’approvazione di una richiesta di aggiornamento (rebase) da parte del FESCo. Si prega di notare, tuttavia, che questo elenco non è esaustivo.

  • "L’aggiornamento richiede l’intervento dell’utente o dell’amministratore per continuare a funzionare"

  • "L’aggiornamento richiede la conversione di file di configurazione, database o altre risorse in un nuovo formato"

  • "L’aggiornamento causa cambiamenti nelle policy o nel comportamento (come quando qualcosa che era precedentemente negato viene ora consentito, ecc.)"

  • "L’aggiornamento modifica il modo in cui l’utente finale interagisce con l’interfaccia (come lo spostamento di menu o pulsanti in una nuova posizione, il cambiamento dei nomi degli argomenti della riga di comando, ecc.)"

  • "L’aggiornamento alla nuova versione (rebase) risolve esclusivamente problemi che probabilmente interessano un numero soggettivamente esiguo di utenti Fedora"

Pacchetti con eccezioni concesse

  • Kernel

Interoperabilità

"Se un pacchetto serve principalmente a interoperare con l’hardware o con protocolli di rete e l’interfaccia cambia, allora il pacchetto può essere aggiornato (rebase) se necessario. Ciò include giochi in rete, protocolli di messaggistica istantanea (IM), lettori musicali hardware, telefoni cellulari, ecc. Questi pacchetti possono anche essere aggiornati per aggiungere il supporto a nuovi dispositivi o formati in modi compatibili.

Esempi di questo tipo di pacchetto:

Pacchetti di database

"I pacchetti come gli scanner antivirus e i filtri antispam hanno tipicamente due componenti: un motore di regole e un database. Si prevede che il database venga aggiornato frequentemente (a volte non attraverso i normali meccanismi di aggiornamento del sistema operativo), mentre il motore di regole è solitamente piuttosto statico. Tuttavia, se il database aggiornato richiede una nuova versione del motore di regole, il pacchetto può essere candidato per un aggiornamento alla nuova versione (rebase).

Esempi di questo tipo di pacchetto:

Esempio

  • "Mozilla rilascia Firefox 4.0.1 con una correzione di sicurezza. Fedora 12 include la versione 3.0.7 e, sebbene il bug sia presente anche lì, la correzione inclusa nella 4.0.1 non è applicabile perché quella parte del browser è stata completamente riscritta. L’aggiornamento alla versione 4.0.1 (rebase) sarebbe consentito, trattandosi di una correzione di sicurezza."

  • "automake rilascia una nuova versione che trasforma alcune condizioni di avviso (warning) in errori. Ciò interromperebbe il processo di compilazione dei pacchetti esistenti e non sarebbe consentito.

  • "AOL modifica il proprio protocollo di messaggistica istantanea in un modo che richiede un aggiornamento di libpurple. L’unica versione upstream di libpurple che supporta il nuovo protocollo presenta una rottura dell’ABI rispetto alla versione presente nell’attuale rilascio di Fedora. Il rebase sarebbe consentito poiché si tratta di un requisito di interoperabilità."

  • "Abiword rilascia una nuova versione che aggiunge la compatibilità con i documenti WordStar 4.0. Inoltre, aggiorna completamente l’interfaccia utente per utilizzare i menu a torta (pie menus). Questo rappresenterebbe un potenziamento delle funzionalità con una modifica sostanziale dell’esperienza utente e non sarebbe consentito.

  • "WebKit richiede un aggiornamento per risolvere un problema di sicurezza. Ciò comporta l’aggiornamento di Midori a una versione che presenta alcune piccole modifiche al layout dei menu. In questo caso, si tratterebbe di una valutazione discrezionale basata sull’invasività dei cambiamenti (rimuovere il menu File sarebbe inopportuno, mentre spostare la voce di configurazione dei plugin sarebbe accettabile).

  • "Firefox rilascia un aggiornamento che contiene modifiche riguardanti solo altre piattaforme. Questo aggiornamento potrebbe essere inviato a Rawhide (per restare al passo con l’ultima versione), ma non dovrebbe essere inviato ai rilasci stabili, poiché non porterebbe alcun beneficio ai nostri utenti e sprecherebbe risorse per la compilazione, l’aggiornamento, il mirroring e il download."

  • "Terminal non riesce a compilare dai sorgenti durante un test di ricostruzione di massa (mass rebuild). Un pacchetto aggiornato dovrebbe essere inviato a Rawhide. Le correzioni per i rilasci stabili dovrebbero essere testate e persino sottoposte a commit ma, a meno che non vi sia un problema con la build precedentemente esistente nel rilascio stabile, non dovrebbe essere emesso alcun aggiornamento. Questo aggiornamento non cambierebbe alcuna funzione del pacchetto rivolta all’utente."

  • "L’upstream di KDE rilascia una nuova versione major e, contemporaneamente, interrompe il supporto per la versione precedente presente in Fedora N e Fedora N-1. Questo rilascio include un gran numero di correzioni di bug, insieme a miglioramenti e correzioni di sicurezza. Un’eccezione per questo tipo di aggiornamento dovrebbe considerare: la capacità di eseguire il backporting delle correzioni principali o dei problemi di sicurezza, il tipo e la quantità di bug risolti, la possibilità di non aggiornare altre parti di Fedora per questo aggiornamento (ad esempio, evitare modifiche all’ABI di Qt o di altre librerie di base), la quantità di test effettuati e i cambiamenti visibili all’utente finale. Un’eccezione di questo tipo verrebbe valutata caso per caso, in base a tutti i fattori sopra citati."

"Requisiti di Karma"

Questa sezione descrive i requisiti necessari affinché un aggiornamento possa essere spostato da updates-testing ai repository fedora o updates. I requisiti si basano sulla (somma dei) punti karma di Bodhi e sul numero di giorni che l’aggiornamento ha trascorso nel repository updates-testing.

"L’invio può avvenire manualmente da parte del manutentore oppure automaticamente tramite Bodhi:"

  • The update becomes eligible for being pushed manually after reaching the minimum "Stable by Karma" threshold for Critical path updates (yes, the same limit applies to both types of updates), OR the minimum "Stable by Time" threshold.

  • "L’aggiornamento sarà inviato automaticamente da Bodhi dopo aver raggiunto la soglia configurata di 'Stable by Karma' OPPURE la soglia configurata di 'Stable by Time', se abilitate ('Auto-request stable based on karma?' e 'Auto-request stable based on time?')."

  • "Se l’aggiornamento riceve qualsiasi karma negativo, l’invio automatico viene disabilitato."

  • "Se l’aggiornamento riceve qualsiasi karma negativo, l’invio automatico viene disabilitato."

"Il manutentore è libero di impostare le soglie, ma queste non possono essere inferiori ai valori minimi descritti di seguito, applicati forzosamente da Bodhi. I valori predefiniti sono adeguati per la maggior parte dei pacchetti, quindi solitamente non è necessario modificare le soglie."

"Gli aggiornamenti di sicurezza sono soggetti alle stesse soglie degli altri aggiornamenti."

"Soglie per gli aggiornamenti non facenti parte del Critical Path"

  • "Stable by Karma: minimo +1, predefinito +3"

  • "Stable by Karma: minimo +1, predefinito +3"

  • "Stable by Time (giorni): minimo 7, predefinito 7"

"Soglie per il Critical Path e per gli aggiornamenti EPEL"

"Gli aggiornamenti del 'Critical Path' contengono almeno un pacchetto del critical path. Modifiche a questa definizione possono essere apportate solo da FESCo o da un suo delegato."

  • "Stable by Karma: minimo +2, predefinito +3"

  • "Stable by Karma: minimo +1, predefinito +3"

  • "Stable by Time (giorni): minimo 14, predefinito 14"

"Problemi o criticità con gli aggiornamenti"

In an effort to learn from any mistakes made, in the event of a update causing a widespread or serious problem for Fedora users, please file a FESCo ticket. FESCo will discuss and try and work to prevent the issue from happening again. A past record of such issues can be found at Updates Lessons.

"OpenQA esegue i test sugli aggiornamenti del critpath e sui prodotti della compilazione (compose artifacts) per le build di Rawhide, branched e per le release candidate."

"Fedora CI esegue i test su tutti gli aggiornamenti di Bodhi. Se i manutentori del pacchetto hanno contrassegnato i test come bloccanti, l’aggiornamento di Bodhi non potrà passare allo stato stabile.

Want to help? Learn how to contribute to Fedora Docs ›