53 lines
4.6 KiB
Markdown
53 lines
4.6 KiB
Markdown
|
---
|
||
|
|
title: Politiche dei Repository
|
||
|
|
description:
|
||
|
|
published: true
|
||
|
|
date: 2020-05-06T09:36:21.786Z
|
||
|
|
tags: policies, cooker, qa
|
||
|
|
---
|
||
|
|
|
||
|
|
# Politiche dei Repository
|
||
|
|
|
||
|
|
## Cooker
|
||
|
|
Cooker è un ramo sperimentale che ogni tanto può guastarsi.
|
||
|
|
|
||
|
|
Fare modifiche in questo ramo va bene nella maggior parte dei casi, anche aggiornare ad una versione beta o perfino ad uno snapshot git/svn/cvs/hg di un pacchetto dalla fonte principale.
|
||
|
|
|
||
|
|
Per essere sicuri di non "fare sorprese" altri altri sviluppatori guastando tutto, i cambiamenti principali devono essere coordinati. Si può fare in vari modi:
|
||
|
|
- parlarne in un TC meeting
|
||
|
|
- inviare una pull request nel relativo repository e attendere l'accettazione
|
||
|
|
- mandare una email alla mailing list cooker e aspettare le risposte positive degli altri membri
|
||
|
|
|
||
|
|
Le modifiche che richiedono la coordinazione includono, ma non sono limitati a:
|
||
|
|
- cambiare un componente principale di sistema con qualcosa di diverso (ad esempio cambiare Xorg con Wayland, Qt 5 con Qt 6, wpa_supplicant con iwd, systemd con qualsiasi altro sistema di init, ecc.); ogni cambiamento del genere dovrebbe essere prima testato in un repository personale.
|
||
|
|
- aggiornamenti che richiedono una quantità enorme di rebuild (es. aggiornare libpng a una versione con un nuovo *soname*).
|
||
|
|
- rimuovere un pacchetto largamente utilizzato da molti elementi nel sistema (es. rimuovere qt5 al momento dell'uscita di qt6 stabile)
|
||
|
|
- cambiamenti che potrebbero rovinare l'hardware
|
||
|
|
|
||
|
|
Cooker è di solito aperto a qualsiasi tipo di sviluppo, ma talvolta può essere congelato in modo da concentrare tutti gli sforzi su un solo ramo.
|
||
|
|
|
||
|
|
## Rolling
|
||
|
|
Normalmente Rolling deve sempre essere utilizzabile. Elementi che potrebbero guastare il sistema in maniera rilevante non possono andare nel repository Rolling.
|
||
|
|
|
||
|
|
Per essere sicuri che Rolling sia sempre utilizzabile:
|
||
|
|
- Qualsiasi cosa pubblicata nel repo Rolling deve essere prima compilata per Cooker.
|
||
|
|
Eccezione: qualcosa di cui Cooker ha già una versione più recente, ad esempio può avere senso spingere LLVM 8.0.1 in Rolling se Rolling è a 8.0 anche quando Cooker è già alla versione 9.0.
|
||
|
|
- Gli sviluppatori devono pubblicare i pacchetti in `rolling/testing` -non in `rolling/release` - quando ritengono che qualcosa sia pronto per l'uso generale. Spostare materiale da `rolling/testing` a `rolling/release` è compito del QA (coloro che assicurano la qualità), per essere sicuri che i pacchetti siano testati nell'ambiente Rolling.
|
||
|
|
- Rolling non dovrebbe di norma utilizzare release beta/snapshots della fonte principale del software. Ci sono eccezioni a questa regola, ad esempio quando il sorgente non ha più rilasciato aggiornamenti uno snapshot/beta è l'unica cosa che funziona nel nostro ambiente, ad esempio la release "stable" usa ancora Qt 4 o Python 2, oppure ci sono altre buone ragioni.
|
||
|
|
Rolling viene congelata poco prima di una nuova release, in modo che le release possano essere fatte essenzialmente come degli snapshot di rolling/release.
|
||
|
|
|
||
|
|
## Rock
|
||
|
|
Questo è il ramo di release stabile. Esso riceverà solo gli aggiornamenti importanti, come aggiornamenti sicurezza o correzionii per i crash di sistema.
|
||
|
|
|
||
|
|
Le persone che vogliono le versioni più aggiornate del software dovrebbero usare Rolling invece di Rock.
|
||
|
|
Ciò significa che gli utenti che usano Rock vogliono qualcosa che non si guasta mai. Ogni cambiamento in Rock deve essere valutato con la massima attenzione.
|
||
|
|
- Qualsiasi cosa pubblicata nel repo Rock deve essere prima compilata per Rolling.
|
||
|
|
Eccezione: Qualcosa di cui cooker ha una versione più recente, ad esempio può avere senso spingere LLVM 8.0.1 in Rock se Rock è a 8.0 anche se Rolling è già alla versione 0.9.
|
||
|
|
- Gli sviluppatori devono pubblicare i pacchetti in `rock/testing` - non in `rock/release` - quando ritengono che qualcosa sia pronto per l'uso generale. Spostare materiale da `rock/testing` a `rock/release` è compito del QA (coloro che assicurano la qualità), per essere sicuri che i pacchetti siano testati nell'ambiente Rock.
|
||
|
|
- Rock non dovrebbe di norma utilizzare release beta/snapshots della fonte principale del software. Fai ancora più attenzione di quanto lo hai fatto per Rolling. Ci sono eccezioni a questa regola, ad esempio quando il sorgente non ha più rilasciato aggiornamenti uno snapshot/beta è l'unica cosa che funziona nel nostro ambiente, ad esempio la release "stable" usa ancora Qt 4 o Python 2, oppure ci sono altre buone ragioni.
|
||
|
|
- Gli aggiornamenti non dovrebbero modificare l'interfaccia dell'utente. Le persone che utilizzano Rock vogliono qualcosa di familiare e non vogliono sorprese.
|
||
|
|
- **Se sei in dubbio, non farlo**. Le persone che vogliono aggiornare qualcosa di non importante dovrebbero usare Rolling.
|
||
|
|
|
||
|
|
|
||
|
|
|