Das CentOS-Projekt hat den Start eines kollaborativen Entwicklungsdienstes angekündigt, 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 vergangenen Jahr getroffen. Bemerkenswert ist, dass die Infrastruktur nicht auf eigenen Servern, sondern auf der Plattform gitlab.com bereitgestellt wird, auf der ein Bereich für mit CentOS verbundene Projekte zur Verfügung steht: gitlab.com/CentOS.
Aktuell wird an der Integration des Bereichs mit der Benutzerdatenbank des CentOS-Projekts gearbeitet, was es Entwicklern ermöglichen wird, sich mit bestehenden Konten bei GitLab anzumelden. Es wird außerdem darauf hingewiesen, dass git.centos.org, das auf der Plattform Pagure basiert, weiterhin als Ort für die Lagerung der Quelltexte von Paketen betrachtet wird, die aus RHEL übertragen wurden, sowie als Grundlage für die Entwicklung des CentOS Stream 8. Der CentOS Stream 9 wird jedoch bereits auf der Grundlage eines neuen Repositories in GitLab entwickelt und bietet die Möglichkeit, dass Mitglieder der Community an der Entwicklung teilnehmen. Andere Projekte, die auf git.centos.org gehostet werden, bleiben vorerst an ihrem Platz und sind nicht zur Migration gezwungen.
Gegner des Wechsels zu einem SaaS-Modell haben im Rahmen der Diskussion über die getroffene Entscheidung angemerkt, dass die Nutzung eines fertigen Dienstes, der von GitLab bereitgestellt wird, nicht die vollständige Kontrolle über die Infrastruktur ermöglicht. Es gibt beispielsweise keine Gewissheit, dass die Serverinfrastruktur ordnungsgemäß gewartet wird, dass Sicherheitsanfälligkeiten schnell behoben werden oder dass Telemetrie nicht aufgezwungen wird und die Umgebung nicht infolge eines externen Angriffs oder durch unredliche Mitarbeiter kompromittiert wurde.
Bei der Auswahl einer Plattform mussten neben typischen Vorgängen mit Repositories (Merge, Fork-Erstellung, Code-Hinzufügung usw.) auch Anforderungen wie die Möglichkeit, Push-Anfragen über HTTPS zu senden, Zugangsbeschränkungen für Branches, die Unterstützung privater Branches, die Trennung des Zugangs für externe und interne Benutzer (zum Beispiel für die Arbeit an der Behebung von Sicherheitslücken während eines Disclosure-Embargos), die Benutzerfreundlichkeit der Schnittstelle, die Vereinheitlichung der Subsysteme für die Bearbeitung von Problemen, Code, Dokumentation und Planung neuer Funktionen, die Bereitstellung von Integrationsmöglichkeiten mit IDEs, die Unterstützung typischer Arbeitsabläufe sowie die Möglichkeit der Nutzung eines Bots für automatische Merges (CentOS Stream erforderlich für die Pflege von Kernel-Paketen) erfüllt werden.
Quelle: opennet.ru
