{"id":76255,"date":"2020-04-01T07:42:05","date_gmt":"2020-04-01T05:42:05","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/fedora-i-centos-zapuskayut-git-forge-gitlab-otkryvaet-18-proprietarnyh-vozmozhnostej"},"modified":"2020-04-01T07:42:05","modified_gmt":"2020-04-01T05:42:05","slug":"fedora-i-centos-zapuskayut-git-forge-gitlab-otkryvaet-18-proprietarnyh-vozmozhnostej","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/novosti-interneta\/fedora-i-centos-zapuskayut-git-forge-gitlab-otkryvaet-18-proprietarnyh-vozmozhnostej","title":{"rendered":"Fedora und CentOS betreiben Git Forge. GitLab bietet 18 propriet\u00e4re Funktionen an.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Projekte CentOS<\/a><\/noindex> und , aber bisher ist er noch nicht in<\/a><\/noindex> haben mitgeteilt<\/a><\/noindex> Es geht um die Entscheidung zur Schaffung eines gemeinsamen Entwicklungsdienstes namens Git Forge, der auf der Plattform GitLab basieren wird. GitLab wird die prim\u00e4re Plattform f\u00fcr die Interaktion mit Git-Repositories und f\u00fcr das Hosting von Projekten, die mit den Distributionen CentOS und Fedora verbunden sind, sein. Der zuvor genutzte Dienst Pagure<\/a><\/noindex> wird weiterhin bestehen, jedoch wird er in die Obhut einer Gemeinschaft \u00fcbergeben, die an der Fortsetzung der Entwicklung interessiert ist. Pagure wird nicht mehr von dem angestellten Team CPE (Community Platform Engineering) bei Red Hat betreut, das f\u00fcr die Unterst\u00fctzung der Infrastruktur f\u00fcr die Entwicklung und Ver\u00f6ffentlichung von Fedora- und CentOS-Releases verantwortlich ist.<\/p>\n

Bei der Bewertung m\u00f6glicher L\u00f6sungen f\u00fcr das neue Git Forge wurden
\n Pagure und GitLab in Betracht gezogen. Auf Basis von etwa 300 R\u00fcckmeldungen<\/a><\/noindex> und W\u00fcnschen von Teilnehmern der Projekte Fedora, CentOS, RHEL und CPE wurden die funktionalen Anforderungen definiert und die Entscheidung fiel zugunsten von GitLab. Neben den typischenOperationen mit Repositories (Merge, Fork-Erstellung, Code-Integration usw.) wurden Sicherheit, Benutzerfreundlichkeit und Stabilit\u00e4t der Plattform als Schl\u00fcsselkriterien festgelegt. <\/p>\n

Zu den Anforderungen geh\u00f6rten Funktionen wie das Senden von Push-Anfragen \u00fcber HTTPS, M\u00f6glichkeiten zur Zugriffsbeschr\u00e4nkung auf Branches, die Unterst\u00fctzung privater Branches, die Trennung des Zugangs f\u00fcr externe und interne Benutzer (zum Beispiel f\u00fcr die Arbeit an der Beseitigung von Schwachstellen w\u00e4hrend eines Embargos zur Offenlegung von Problemdetails), Benutzerfreundlichkeit der Schnittstelle, die Vereinheitlichung von Subsystemen zur Bearbeitung von Fehlermeldungen, Code, Dokumentation und Planung neuer Funktionen sowie Integrationsm\u00f6glichkeiten mit IDEs und die Unterst\u00fctzung g\u00e4ngiger Arbeitsabl\u00e4ufe.<\/p>\n

Zu den Funktionen von GitLab, die letztendlich die Entscheidung zur Auswahl dieser Plattform beeinflussten, z\u00e4hlen die Unterst\u00fctzung von Untergruppen mit selektivem Zugriff auf Repositories, die M\u00f6glichkeit zur Nutzung eines Bots f\u00fcr automatische Zusammenf\u00fchrungen (CentOS Stream wird ben\u00f6tigt, um Pakete mit dem Kern zu unterst\u00fctzen), die Verf\u00fcgbarkeit integrierter Planungstools f\u00fcr die Entwicklung sowie die M\u00f6glichkeit, einen fertigen SAAS-Service mit garantierter Verf\u00fcgbarkeit zu nutzen (dies wird Ressourcen f\u00fcr die Wartung der Serverinfrastruktur freisetzen).<\/p>\n

Die Entscheidung steht bereits verursachte<\/a><\/noindex> Kritik unter Entwicklern, da die Entscheidung ohne vorherige umfassende Diskussion getroffen wurde. Zudem wurden Bedenken ge\u00e4u\u00dfert, dass der Service nicht die freie Community-Edition von GitLab nutzen wird. Insbesondere sind die Funktionen, die f\u00fcr die Umsetzung der im Ank\u00fcndigung genannten Anforderungen an Git Forge erforderlich sind, nur in der propriet\u00e4ren Version verf\u00fcgbar. GitLab Ultimate<\/a><\/noindex>. <\/p>\n

Kritisiert wurde ebenfalls die Absicht, den von GitLab angebotenen SAAS-Service (Software-as-a-Service) zu nutzen, anstatt GitLab auf eigenen Servern bereitzustellen, was den Service aus der Kontrolle nimmt (z. B. kann man sich nicht sicher sein, dass alle Sicherheitsanf\u00e4lligkeiten im System zeitnah behoben werden) ordnungsgem\u00e4\u00df<\/a><\/noindex> wird die Infrastruktur nicht mehr aufgedr\u00e4ngte Telemetrie<\/a><\/noindex> und eine Diversion durch Mitarbeiter eines Drittunternehmens ausgeschlossen). Die Entscheidung steht zudem im Widerspruch zu den grundlegenden Prinzipien von Fedora<\/a><\/noindex>, die definieren, dass das Projekt freien Alternativen den Vorzug geben sollte.<\/p>\n

In der Zwischenzeit hat das Unternehmen GitLab hat bekannt gegeben<\/a><\/noindex> Die Einf\u00fchrung von 18 Funktionen, die zuvor nur in propriet\u00e4ren Versionen von GitLab angeboten wurden. Diese Funktionen decken verschiedene Bereiche des vollst\u00e4ndigen Softwareentwicklungszyklus ab, einschlie\u00dflich Entwicklungsplanung, Projektverwirklichung, Verifizierung, Paketverwaltung, Release-Management, Konfiguration und Sicherheit. <\/p>\n

Die folgenden Funktionen wurden in die freie Version \u00fcberf\u00fchrt:<\/p>\n