Il progetto CentOS ha annunciato il lancio di un servizio per la co-sviluppo, basato sulla piattaforma GitLab. La decisione di utilizzare GitLab come piattaforma primaria per l'hosting dei progetti CentOS e Fedora è stata presa lo scorso anno. È interessante notare che l'infrastruttura non è ospitata sui propri server, ma utilizza il servizio gitlab.com, dove è stata creata una sezione specifica per i progetti legati a CentOS su gitlab.com/CentOS.
Attualmente è in corso il lavoro per integrare la sezione con il database utenti del progetto CentOS, il che permetterà agli sviluppatori di accedere al servizio GitLab utilizzando le loro credenziali esistenti. Si sottolinea che git.centos.org, basato sulla piattaforma Pagure, continuerà a essere considerato come luogo per l'archiviazione dei codici sorgente dei pacchetti migrati da RHEL, nonché come base per la creazione della branch CentOS Stream 8. Tuttavia, la branch CentOS Stream 9 è già in fase di sviluppo su un nuovo repository in GitLab e si caratterizza per la possibilità di coinvolgere nella sviluppo membri della comunità. Altri progetti ospitati su git.centos.org rimangono al loro posto e non sono costretti alla migrazione.
I sostenitori del passaggio al modello SaaS, nel corso della discussione della decisione presa, hanno sottolineato che l'uso del servizio preconfezionato fornito da GitLab non consente di avere un controllo completo sull'infrastruttura. Ad esempio, non si può essere certi che l'infrastruttura server sia adeguatamente gestita, che le vulnerabilità vengano risolte tempestivamente, che non venga imposta telemetria, e che l'ambiente non sia stato compromesso a causa di attacchi esterni o dell'operato di dipendenti disonesti.
Quando si sceglie una piattaforma, oltre alle operazioni standard sui repository (fusioni, creazione di fork, aggiunta di codice, ecc.), sono stati avanzati requisiti come la possibilità di inviare richieste push tramite HTTPS, strumenti per limitare l'accesso ai rami, supporto per rami privati, separazione dell'accesso tra utenti esterni e interni (ad esempio, per lavorare sulla risoluzione delle vulnerabilità durante un embargo sulla divulgazione delle informazioni sul problema), facilità d'uso dell'interfaccia, unificazione dei sottosistemi per la gestione dei problemi, del codice, della documentazione e della pianificazione di nuove funzionalità, disponibilità di strumenti per l'integrazione con IDE, supporto per workflow standard, e la possibilità di utilizzare un bot per fusioni automatiche (è necessaria CentOS Stream per il mantenimento dei pacchetti relativi al kernel).
Fonte: opennet.ru
