{"id":102267,"date":"2021-11-11T15:36:40","date_gmt":"2021-11-11T13:36:40","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/proekt-centos-perehodit-na-razrabotku-s-ispolzovaniem-gitlab"},"modified":"2021-11-11T15:36:40","modified_gmt":"2021-11-11T13:36:40","slug":"proekt-centos-perehodit-na-razrabotku-s-ispolzovaniem-gitlab","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/novosti-interneta\/proekt-centos-perehodit-na-razrabotku-s-ispolzovaniem-gitlab","title":{"rendered":"Il progetto CentOS passa allo sviluppo utilizzando GitLab","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
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 \u00e8 stata presa lo scorso anno. \u00c8 interessante notare che l'infrastruttura non \u00e8 ospitata sui propri server, ma utilizza il servizio gitlab.com, dove \u00e8 stata creata una sezione specifica per i progetti legati a CentOS su gitlab.com\/CentOS. <\/p>\n
Attualmente \u00e8 in corso il lavoro per integrare la sezione con il database utenti del progetto CentOS, il che permetter\u00e0 agli sviluppatori di accedere al servizio GitLab utilizzando le loro credenziali esistenti. Si sottolinea che git.centos.org, basato sulla piattaforma Pagure, continuer\u00e0 a essere considerato come luogo per l'archiviazione dei codici sorgente dei pacchetti migrati da RHEL, nonch\u00e9 come base per la creazione della branch CentOS Stream 8. Tuttavia, la branch CentOS Stream 9 \u00e8 gi\u00e0 in fase di sviluppo su un nuovo repository in GitLab e si caratterizza per la possibilit\u00e0 di coinvolgere nella sviluppo membri della comunit\u00e0. Altri progetti ospitati su git.centos.org rimangono al loro posto e non sono costretti alla migrazione. <\/p>\n
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\u00f2 essere certi che l'infrastruttura server sia adeguatamente gestita, che le vulnerabilit\u00e0 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. <\/p>\n
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\u00e0 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\u00e0 durante un embargo sulla divulgazione delle informazioni sul problema), facilit\u00e0 d'uso dell'interfaccia, unificazione dei sottosistemi per la gestione dei problemi, del codice, della documentazione e della pianificazione di nuove funzionalit\u00e0, disponibilit\u00e0 di strumenti per l'integrazione con IDE, supporto per workflow standard, e la possibilit\u00e0 di utilizzare un bot per fusioni automatiche (\u00e8 necessaria CentOS Stream per il mantenimento dei pacchetti relativi al kernel). \n Fonte: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"