Hace poco se dio a conocer la noticia de que GitLab planea modificar sus términos de servicio para el próximo mes (en septiembre), según los cuales los proyectos alojados en cuentas gratuitas de GitLab.com se eliminarán automáticamente si sus repositorios permanecen inactivos durante 12 meses.

El cambio tiene como objetivo reducir los costos de mantenimiento del alojamiento al liberar recursos para almacenar y procesar proyectos abandonados y bifurcaciones que no están en desarrollo.

Se estima que el mantenimiento de la infraestructura para proyectos abandonados representa hasta una cuarta parte de todos los costos de alojamiento de GitLab.com, y la purga automática de dichos proyectos podría ahorrar hasta un millón de dólares al año.

The Register se enteró de que dichos proyectos representan hasta una cuarta parte de los costos de alojamiento de GitLab, y que la eliminación automática de proyectos podría ahorrarle al servicio de colaboración de codificación en la nube hasta $ 1 millón al año. Por lo tanto, se ha sugerido la política para ayudar a que las finanzas de GitLab sigan siendo sostenibles.

Las personas con conocimiento de la situación, que solicitaron el anonimato ya que no están autorizadas a discutirlo con los medios, dijeron a The Register que la política entrará en vigor en septiembre de 2022.

Antes de la eliminación real, dentro de semanas o meses, se enviarán notificaciones a los propietarios de los repositorios que solicitan la eliminación con una advertencia para confirmar la relevancia del proyecto. Solo se prevé eliminar los proyectos abandonados, cuyos autores no responden a las advertencias, no se registraron cambios en el repositorio durante el año, no se publicaron nuevos números y no se enviaron comentarios.

Sin embargo, algunos miembros en la comunidad consideran que la eliminación propuesta es una mala práctica, ya que el código de los repositorios inactivos puede usarse como dependencia en otros proyectos que permanecen activos.

También se observa que los cambios permanentes no son el objetivo de algunos autores, quienes bien pueden considerar que el estado actual de su proyecto ha alcanzado un nivel óptimo, y el código es lo suficientemente bueno y no requiere mejoras, o descubrir inicialmente que no están planeados para ser desarrollados, pero que pueden resultar útiles para quienes te rodean.

Geoff Huntley, un defensor del código abierto y participante de la comunidad abierta .Net, describió la política como «absolutamente salvaje».

“El código fuente no ocupa mucho espacio en disco, que alguien elimine todo ese código es destrucción de la comunidad. Van a destruir su marca y buena voluntad. La gente aloja su código allí porque existe la idea de que estará disponible para el público en general para reutilizarlo y mezclarlo.

Por supuesto, no hay garantías de que siempre estará alojado allí, pero las reglas no escritas en código abierto son que haces que el código esté disponible y no lo eliminas. Tuvimos mantenedores que extrajeron el código y hubo una gran indignación en la comunidad al respecto», dijo, señalando que otros proyectos que dependen de un producto eliminado sufrirán.

«Todas las dependencias no se pueden compilar», lamentó.

Además, los recursos externos pueden hacer referencia al código de los proyectos inactivos y, al eliminarlo, se perderá una copia maestra verificada a la que se puede hacer referencia (no se garantiza que las copias no oficiales estén libres de actividad maliciosa), por lo que en lugar de eliminar, probablemente sería más óptimo archivar el estado manteniendo la capacidad de acceder al código en modo de solo lectura.

Para ahorrar espacio en disco al almacenar bifurcaciones basura, puede usar métodos más eficientes para manejar duplicados, por ejemplo, GitHub almacena todos los objetos del repositorio principal y sus bifurcaciones asociadas juntas para evitar la duplicación de datos, separando lógicamente la propiedad de las confirmaciones.

Por último cabe mencionar que los cambios de reglas aún no se han anunciado oficialmente y se encuentran en la etapa de planificación interna.

Finalmente, para quienes estén interesados en poder conocer más al respecto sobre la nota, pueden consultar la publicación original en el siguiente enlace.

from Linux Adictos https://ift.tt/cT24wNG
via IFTTT