Linux News

CentOS project moves to development using GitLab

Share on Facebook Share on Twitter Pinterest LinkedIn Tumblr

The CentOS Project announced the launch of a collaborative development service based on the GitLab platform. The decision to use GitLab as the primary hosting platform for CentOS and Fedora projects was made last year. It is noteworthy that the infrastructure was raised not on its own servers, but on the basis of the service, in which the section is provided for projects related to CentOS.

At the moment, work is underway to integrate the section with the user base of the CentOS project, which will allow developers to connect to the Gitlab service using existing accounts. Separately, it is noted that based on the Pagure platform will continue to be considered as a place to host the source code of packages ported from RHEL, as well as as the basis for the formation of the CentOS Stream 8 branch. But the CentOS Stream 9 branch is already developing on the basis of a new repository in GitLab and is distinguished by the ability to connect to the development of contributors from the community. Other projects hosted on remain in place for now and are not forced to migrate.

Voyager Linux 21.10 Available to Download Based on Ubuntu 21.10

Opponents of the transition to the SaaS model, during the discussion of the decision, noted that the use of a ready-made service provided by GitLab does not allow full control of the infrastructure, for example, it is impossible to be sure that the server infrastructure is properly maintained, vulnerabilities are eliminated promptly, telemetry and the environment will not begin to be imposed was not compromised as a result of an external attack or the actions of dishonest employees.

When choosing a platform, in addition to standard operations with repositories (merging, creating forks, adding code, etc.), there were such requirements as the ability to send push requests over HTTPS, means of limiting access to branches, support for private branches, sharing access to external and internal users (for example, to work on eliminating vulnerabilities during an embargo on disclosure of information about a problem), familiarity of the interface, unification of subsystems for working with problem reports, code, documentation and planning for new features, availability of tools for integration with IDE, support for standard workflows, the ability to use a bot for automatic merges (requires CentOS Stream to maintain packages with the kernel).

1 Comment

  1. Pingback: System76 is a toxic collaborator, denounced from GNOME -

Write A Comment