Das CentOS-Projekt kündigte die Einführung eines kollaborativen Entwicklungsdienstes auf Basis der GitLab-Plattform an. Die Entscheidung, GitLab als primäre Hosting-Plattform für CentOS- und Fedora-Projekte zu verwenden, wurde letztes Jahr getroffen. Bemerkenswert ist, dass die Infrastruktur nicht auf eigenen Servern aufgebaut wird, sondern auf Basis des Dienstes gitlab.com, in dem der Abschnitt gitlab.com/CentOS für Projekte im Zusammenhang mit CentOS bereitgestellt wird.
Derzeit wird daran gearbeitet, den Abschnitt in die Benutzerbasis des CentOS-Projekts zu integrieren, wodurch Entwickler über vorhandene Konten eine Verbindung zum Gitlab-Dienst herstellen können. Unabhängig davon wird darauf hingewiesen, dass git.centos.org, das auf der Pagure-Plattform basiert, weiterhin als Ort zum Hosten der Quellen von von RHEL portierten Paketen sowie als Grundlage für die Bildung des CentOS Stream 8-Zweigs angesehen wird. Aber Der CentOS Stream 9-Zweig wird bereits auf Basis des neuen Repositorys in GitLab entwickelt und zeichnet sich durch die Möglichkeit aus, sich mit der Entwicklung von Mitgliedern aus der Community zu verbinden. Andere auf git.centos.org gehostete Projekte bleiben vorerst bestehen und müssen nicht migriert werden.
Gegner des Übergangs zum SaaS-Modell stellten im Diskussionsprozess der Entscheidung fest, dass die Nutzung eines vorgefertigten Dienstes von GitLab keine vollständige Kontrolle über die Infrastruktur ermögliche, es sei beispielsweise unmöglich, sicher zu sein, dass der Server Die Infrastruktur wird ordnungsgemäß gewartet, Schwachstellen werden umgehend beseitigt, Telemetriedaten und die Umgebung werden nicht beeinträchtigt und nicht durch einen externen Angriff oder die Handlungen unehrlicher Mitarbeiter gefährdet.
Bei der Auswahl einer Plattform gab es neben typischen Vorgängen mit Repositorys (Zusammenführen, Erstellen von Forks, Hinzufügen von Code usw.) Anforderungen wie die Möglichkeit, Push-Anfragen über HTTPS zu senden, Möglichkeiten zur Einschränkung des Zugriffs auf Zweigstellen und die Unterstützung privater Zweigstellen , Trennung des Zugriffs von externen und internen Benutzern (z. B. um an der Behebung von Schwachstellen während eines Offenlegungsembargos zu arbeiten), Vertrautheit der Schnittstelle, Vereinheitlichung von Subsystemen für die Arbeit mit Problemberichten, Code, Dokumentation und Planung für neue Funktionen, Verfügbarkeit von Tools für IDE-Integration, Unterstützung für gängige Workflows, die Möglichkeit, einen Bot für automatische Zusammenführungen zu verwenden (erfordert CentOS Stream, um Kernel-Pakete zu verwalten).
Source: opennet.ru