Developers who are behind the projects of the popular Linux distributions "CentOS and Fedora" released recently through an ad the decision to create a joint development service, which named as "Git Forge".
This new service will be built using the GitLab platform which will become the main platform to interact with Git repositories and to host projects related to distributions CentOS and Fedora.
When evaluating the possible solutions for the new Git Forge, Pagure and Gitlab were considered. Based on studying approximately 300 reviews and suggestions from Fedora, CentOS, RHEL, and CPE project participants, functionality requirements formed and decision made in favor of Gitlab.
In addition to the typical operations with repositories, the security, usability and stability of the platform were declared among the key requirements.
The requirements included features such as sending push requests via HTTPS, means to restrict access to versions, support for private versions, share access between external and internal userss (for example, to work on fixing vulnerabilities during the embargo to reveal information about a problem), unification of subsystems to work with problem reports, code, documentation and planning of new features, the availability of tools for integration with the IDE, support for typical workflows.
Among the GitLab features that ultimately influenced the decision to choose this platform, the support of subgroups with selective access to repositories was mentioned, la possibility to use a bot for automatic merges (CentOS Stream is required to support packages with the kernel), the presence of integrated tools for planning development, the possibility of using a ready-to-use SAAS service with a guaranteed level of availability (it will free up resources to maintain the server infrastructure ).
The decision has already caused criticism among developers, regarding the fact that the decision was made without prior preliminary discussion.
As well there were concerns that the service would not use the free Comminity edition of GitLab. In particular, the capabilities required to implement the Git Forge requirements outlined in the announcement are only available in the proprietary version of GitLab Ultimate.
The intention to take advantage of the SAAS service provided by GitLab (application as a service) was also criticized, instead of implementing GitLab on their servers, which makes the service out of control (for example, it is impossible to ensure that all vulnerabilities in the system are fixed quickly, the infrastructure is properly maintained and not a single moment of telemetry will be imposed and sabotage by third-party personnel will be ruled out).
The solution also does not fit well with the fundamental principles of Fedora, which specify that a project should give preference to free alternatives.
While, GitLab announced the opening of deployments of 18 functionalities which previously they were only offered in paid editions of GitLab:
- Attaching a related issue;
- GitLab export issue to CSV.
- The way to plan, organize and visualize the development process of individual features or releases.
- Built-in service to link project participants with third parties via email.
- Web terminal for web IDE.
- The ability to sync files to test code changes in the web terminal.
- Design management tools that allow you to upload designs and resources for the problem, using the problem as a single point of access to everything that is required to develop a new feature.
- Quality reporting code.
- Support for Conan (C / C ++), Maven (Java), NPM (node.js) and NuGet (.NET) package managers.
- Support for Canarian implementations, which allows you to install a new version of the application in a small part of the system.
- Incremental distribution, allowing first to deliver new versions for only a small number of systems, gradually bringing coverage to 100%.
- Functionality activation flags, which give the opportunity to deliver the project in various editions, dynamically activating certain features.
- General deployment mode that allows you to assess the health of each Kubernetes-based continuous integration environment.
- Support for defining multiple Kubernetes clusters in the configurator
- Support for defining container network security policies that allow differentiation of access between Kubernetes pods.
Source: Centos Blog - Fedora Blog