Le projet CentOS a annoncé le lancement d'un service de co-développement basé sur la plateforme GitLab. La décision d'utiliser GitLab comme plateforme principale pour l'hébergement des projets CentOS et Fedora a été prise l'année dernière. Fait intéressant, l'infrastructure est hébergée non pas sur ses propres serveurs, mais sur la plateforme gitlab.com, qui a un espace dédié aux projets liés à CentOS à l'adresse gitlab.com/CentOS.
Actuellement, des travaux sont en cours pour intégrer la section avec la base d'utilisateurs du projet CentOS, ce qui permettra aux développeurs de se connecter au service GitLab en utilisant leurs comptes existants. Il est également précisé que git.centos.org, basé sur la plateforme Pagure, continuera d'être considéré comme un lieu pour héberger les sources des paquets migrés depuis RHEL, ainsi que comme base pour la formation de la branche CentOS Stream 8. Toutefois, la branche CentOS Stream 9 est déjà en développement sur la base d'un nouveau dépôt dans GitLab et se distingue par la possibilité pour les participants de la communauté de s'engager dans le développement. Les autres projets hébergés sur git.centos.org restent pour l'instant en place et ne sont pas contraints à la migration.
Les opposants à la transition vers un modèle SaaS, lors de la discussion de la décision adoptée, ont souligné que l'utilisation d'un service prêt à l'emploi fourni par GitLab ne permet pas de contrôler complètement l'infrastructure ; par exemple, il n'est pas certain que l'infrastructure serveur soit correctement maintenue, que les vulnérabilités soient corrigées rapidement, que la télémétrie ne soit pas imposée, et que l'environnement n'ait pas été compromis à la suite d'une attaque externe ou d'actions de salariés malveillants.
Lors du choix d'une plateforme, au-delà des opérations typiques avec les dépôts (fusion, création de forks, ajout de code, etc.), des exigences telles que la possibilité d'envoyer des requêtes push via HTTPS, des outils de restriction d'accès aux branches, la prise en charge de branches privées, la séparation des accès pour les utilisateurs externes et internes (par exemple, pour travailler sur la correction de vulnérabilités durant l'embargo sur la divulgation des informations sur le problème), la familiarité de l'interface, l'unification des sous-systèmes pour travailler avec les problèmes, le code, la documentation et la planification de nouvelles fonctionnalités, la disponibilité d'outils d'intégration avec les IDE, la prise en charge des flux de travail standard, et la possibilité d'utiliser un bot pour des fusions automatiques (CentOS Stream est requis pour maintenir les paquets avec le noyau) étaient requises.
Source : opennet.ru
