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

Tal y como se esperaba, y, para el que no lo sepa, KDE lanza las nuevas versiones de Plasma siguiendo una serie de Fibonacci (1, 1, 2, 3 y 5 semanas después de la versión punto cero), el proyecto hizo oficial oficia el martes el lanzamiento de Plasma 5.25.4. Es la cuarta actualización de mantenimiento de esta serie, y, según parte de la comunidad y los responsables de algunas distribuciones, falta le hace, ya que 5.25 parece haber salido un poco «buggy».

Nate Graham, pieza clave en todo lo relacionado a KDE, ha ido adelantando durante los fines de semana muchos cambios que llegarían junto a Plasma 5.25.4, y no son pocos si tenemos en cuenta el punto en el que estamos. Esto le daría la razón a lo que está haciendo, por ejemplo, Manjaro, quien está retrasando la llegada de Plasma 5.25 a su rama Stable, pero también hay usuarios, entre los que me incluyo, que hemos probado la ya-no-tan-nueva versión y no hemos experimentado fallos tan groseros como para tener que esperar tanto.

Algunas novedades de Plasma 5.25.4

• Bastantes widgets de Plasma han ganado características de accesibilidad mejoradas, después de usarlos con un lector de pantalla.
• En la sesión de Plasma Wayland:
  • El cursor ya no se vuelve invisible a veces cuando se utilizan ciertos controladores gráficos heredados muy rotos.
  • Se ha corregido una forma en la que KWin podía bloquearse cuando se pulsaban botones físicos en una tableta de dibujo conectada.
  • La animación de retroalimentación de lanzamiento del cursor que se reproduce al lanzar una aplicación XWayland ahora deja de reproducirse una vez que la aplicación se ha lanzado.
  • El cambio de escritorios virtuales con un gesto de deslizamiento del panel táctil ya no puede provocar a veces el bloqueo de aplicaciones y juegos de WINE o Steam Proton.
• La hoja «Añadir Regla» en la página de Firewall de Preferencias del Sistema es ahora completamente legible y se ve mejor.
• Se puede volver a navegar entre las ventanas y los escritorios utilizando el teclado en el efecto Rejilla del escritorio.
• En la sesión de Plasma X11, la función «Window shade» vuelve a funcionar.
• Se ha corregido la forma final en que los títulos de los menús podían cortarse cuando un título de menú largo se emparejaba con elementos de menú cortos.
• En la página de Colores de Preferencias del Sistema, las vistas previas de la combinación de colores son ahora 100% precisas y reflejan realmente sus colores.
• Los ratones conectados en caliente ya no pierden su configuración cuando el sistema se despierta o se desacopla.
• Se ha corregido una regresión reciente en el soporte de Actividades que causaba problemas extraños al cambiar entre Actividades.
• Discover ya no etiqueta erróneamente varias aplicaciones y complementos como si tuvieran licencias propietarias cuando no es así.
• Arrastrar una ventana sobre otras ventanas en Visión General o Ventanas Presentes ya no activa sus efectos de resaltado y ya no hace que la ventana arrastrada aparezca extrañamente debajo de ellas.
• Ahora se pueden arrastrar las aplicaciones de los resultados de la búsqueda de Kickoff a un área vacía del Administrador de Tareas para fijarlas allí.
• Se ha corregido un caso en el que Discover podía bloquearse al salir después de realizar con éxito las actualizaciones.
• Cuando se cierra la ventana principal de Discover mientras está en medio de la instalación de actualizaciones, la notificación que aparece en su lugar muestra ahora un recuento preciso de los elementos que quedan por actualizar.

Plasma 5.25.4 se anunció el día 2, lo que significa que ya está disponible su código. Los nuevos paquetes ya están en el repositorio Backports de KDE (para distribuciones basadas en Debian/Ubuntu), y lo mismo es válido para KDE neon, el sistema que más controlan por no estar bajo el paraguas de Canonical. En cuanto a cuándo llegará a otras distribuciones, dependerá de su filosofía. El mencionado Manjaro aún podría esperar hasta la quinta actualización de punto, pero su «padre» no esperará tanto y ya debería estar disponible..

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