El proyecto CentOS ha anunciado el lanzamiento de un servicio para el desarrollo colaborativo, basado en la plataforma GitLab. La decisión de utilizar GitLab como la plataforma principal para el hospedaje de proyectos de CentOS y Fedora se tomó el año pasado. Es notable que la infraestructura no se haya levantado en sus propios servidores, sino en la base del servicio gitlab.com, donde se ha proporcionado una sección para los proyectos relacionados con CentOS en gitlab.com/CentOS.
Actualmente se está trabajando en la integración de la sección con la base de usuarios del proyecto CentOS, lo que permitirá a los desarrolladores conectarse al servicio de GitLab utilizando cuentas existentes. Se destaca que git.centos.org, basado en la plataforma Pagure, seguirá siendo considerado como el lugar para alojar los códigos fuente de los paquetes trasladados desde RHEL, así como la base para la formación de la rama CentOS Stream 8. Sin embargo, la rama CentOS Stream 9 ya se está desarrollando en una nueva repositorio en GitLab y se distingue por la posibilidad de que los participantes de la comunidad se conecten al desarrollo. Otros proyectos alojados en git.centos.org permanecen en su lugar y no se les obliga a migrar.
Los opositores a la transición al modelo SaaS, durante la discusión de la decisión adoptada, señalaron que el uso de un servicio ya existente proporcionado por GitLab no permite un control completo de la infraestructura, por ejemplo, no se puede tener la certeza de que la infraestructura del servidor esté debidamente mantenida, que las vulnerabilidades sean corregidas de manera oportuna, que no se imponga telemetría y que el entorno no se haya visto comprometido como resultado de un ataque externo o acciones de empleados deshonestos.
Al elegir una plataforma, además de las operaciones estándar con repositorios (fusión, creación de bifurcaciones, adición de código, etc.), se presentaron requisitos tales como la posibilidad de enviar solicitudes push a través de HTTPS, herramientas para limitar el acceso a ramas, soporte para ramas privadas, separación del acceso para usuarios externos e internos (por ejemplo, para trabajar en la corrección de vulnerabilidades durante un embargo en la divulgación de información sobre el problema), facilidad de uso de la interfaz, unificación de subsistemas para manejar mensajes sobre problemas, código, documentación y planificación de nuevas funcionalidades, disponibilidad de herramientas para la integración con IDEs, soporte para flujos de trabajo típicos y la posibilidad de usar un bot para fusiones automáticas (se requiere CentOS Stream para mantener los paquetes del núcleo).
Fuente: opennet.ru
