Das CentOS-Projekt hat den Start eines dienstes zur gemeinsamen Entwicklung bekannt gegeben, der auf der GitLab-Plattform basiert. Die Entscheidung, GitLab als primäre Plattform für das Hosting von CentOS- und Fedora-Projekten zu nutzen, wurde im letzten Jahr getroffen. Bemerkenswert ist, dass die Infrastruktur nicht auf eigenen Servern, sondern auf der Plattform gitlab.com aufgebaut ist, wo für die mit CentOS verbundenen Projekte ein Bereich unter gitlab.com/CentOS bereitgestellt wurde.
Derzeit wird an der Integration des Bereichs mit der Benutzerdatenbasis des CentOS-Projekts gearbeitet, was Entwicklern ermöglichen wird, sich mit bestehenden Konten bei GitLab anzumelden. Zudem wird betont, dass git.centos.org auf der Basis der Pagure-Plattform weiterhin als Ort für die Ablage des Quellcodes von Paketen, die aus RHEL übertragen wurden, betrachtet wird, sowie als Grundlage für die Bildung des CentOS Stream 8-Zweigs. Der Zweig CentOS Stream 9 hingegen entwickelt sich bereits auf der Grundlage eines neuen Repositories in GitLab und zeichnet sich durch die Möglichkeit aus, dass Mitglieder der Community sich an der Entwicklung beteiligen können. Andere Projekte, die derzeit auf git.centos.org gehostet werden, bleiben vorerst an ihrem Platz und sind nicht zur Migration verpflichtet.
Gegner des Übergangs zu einem SaaS-Modell wiesen während der Diskussion über die getroffene Entscheidung darauf hin, dass die Nutzung des von GitLab bereitgestellten Fertigdienstes keinen vollständigen Kontrolle über die Infrastruktur ermöglicht. Zum Beispiel kann man sich nicht sicher sein, dass die Serverinfrastruktur ordnungsgemäß gewartet wird, Schwachstellen zeitnah behoben werden, keine Telemetrie aufgezwungen wird und die Umgebung nicht infolge externer Angriffe oder unredlicher Mitarbeiter kompromittiert wurde.
Bei der Auswahl der Plattform wurden neben Standardoperationen mit Repositories (wie Merging, Fork-Erstellung, Code-Hinzufügung usw.) auch Anforderungen wie die Möglichkeit, Push-Anfragen über HTTPS zu senden, Zugriffsbeschränkungen für Branches, Unterstützung privater Branches, die Trennung des Zugriffs für externe und interne Nutzer (zum Beispiel für die Arbeit an der Behebung von Schwachstellen während eines Embargos bezüglich der Offenlegung von Informationen über das Problem), Benutzerfreundlichkeit des Interface, Vereinheitlichung der Subsysteme für die Bearbeitung von Problemen, Code, Dokumentation und die Planung neuer Funktionen, die Verfügbarkeit von Integrationsmittel für IDEs sowie die Unterstützung typischer Arbeitsabläufe gefordert. Darüber hinaus sollte die Möglichkeit bestehen, Bots für automatische Zusammenführungen zu nutzen (CentOS Stream ist erforderlich, um Kernpakete zu unterstützen).
Quelle: opennet.ru
