Un año después de que Guix se mudó a Codeberg

 (guix.gnu.org)
1 puntos por GN⁺ 3 시간 전 | 1 comentarios | Compartir por WhatsApp
  • Guix trasladó en 2025 su forma de colaboración, que durante más de 10 años había funcionado con Savannah y Debbugs basado en correo electrónico, a Codeberg, cambiando de forma importante el punto de entrada para contribuir en un proyecto en el que participan más de 400 personas al año
  • La transición fue el primer caso real del procedimiento de Guix Consensus Document introducido en diciembre de 2024, y el GCD 002 entró en vigor a inicios de mayo de 2025 tras dos meses de discusión
  • El flujo de trabajo anterior, basado en correo electrónico, era eficiente para personas con experiencia gracias a herramientas como Emacs, mumi y qa.guix.gnu.org, pero en una encuesta con 900 respuestas fue señalado con frecuencia como una barrera para contribuir
  • Después del cambio a Codeberg aumentaron la cantidad de autores y de nuevos autores, pero salvo por un pico temporal en junio de 2025, es difícil confirmar un efecto Codeberg claro
  • Se abren más de 500 pull requests al mes y el backlog está creciendo, por lo que reducir la falta de CI, los requisitos de firma y la carga de revisión sigue siendo la siguiente tarea práctica de Guix

Del trabajo colaborativo por correo electrónico a Codeberg

  • En 2025, Guix trasladó a Codeberg el alojamiento del código fuente, el seguimiento de issues y los pull requests
    • Antes alojaba el código durante más de 10 años en Savannah
    • Los reportes de errores y los parches se manejaban por correo electrónico y se seguían en una instancia de Debbugs
    • Como es un proyecto al que contribuyen más de 400 personas al año, la transición en sí fue un cambio importante
  • Quienes más contribuían ya estaban acostumbrados al flujo de trabajo por correo y trabajaban de forma eficiente con el paquete Debbugs para Emacs o con clientes de correo avanzados
    • Debbugs depende de unos cientos de líneas de código en Perl, además de estándares de correo electrónico y una estructura federada, mientras que una forja web como Forgejo es un sistema más grande con muchas dependencias de Go
  • Alrededor de ese flujo por correo ya existían herramientas auxiliares
  • En la primera encuesta pública a usuarios y contribuyentes, publicada en enero de 2025, respondieron más de 900 personas, y quienes contribuían señalaron con frecuencia el flujo por correo como una barrera para participar

Una decisión basada en consenso mediante GCD 002

  • Guix no tenía un “benevolent dictator” para tomar decisiones, así que en diciembre de 2024 introdujo el proceso de Guix Consensus Document
  • El proceso GCD busca construir consenso más que hacer una simple votación
    • Quien redacta la propuesta debe ajustarla junto con las personas participantes
    • En lugar de limitarse a oponerse, quienes participan deben proponer sus necesidades y cambios concretos para reflejarlas
    • En la versión final, la postura se expresa como support, accept o disapprove
  • El GCD 002 se presentó en febrero de 2025 como propuesta para migrar a Codeberg
    • La discusión duró dos meses, el periodo máximo previsto por el procedimiento
    • Dos tercios del equipo de Guix participaron en la deliberación
    • Entre quienes participaron, 72% eligió support y el 28% restante accept
    • No hubo disapprove, y la propuesta entró en vigor a inicios de mayo de 2025
  • Algunas personas con muchos años contribuyendo sentían que un flujo de trabajo percibido como orientado primero a la web era menos eficiente que el correo, y también les incomodaba abandonar parte de la infraestructura basada en email
  • La posibilidad de conectar con una comunidad más amplia y mejorar la experiencia de desarrollador respaldó la transición
  • La preferencia por una forja basada en software libre y alojada por la organización sin fines de lucro Codeberg e.V. no generó gran controversia y además encajaba con la orientación de Guix

Una transición gradual y una falta de CI mayor a la esperada

  • El cambio a Codeberg se realizó de forma gradual, tal como se acordó en el GCD
    • El repositorio principal fue migrado el 25 de mayo de 2025
    • El repositorio anterior sigue existiendo como mirror
    • El rastreador anterior de issues y parches se mantendrá hasta el 1 de enero de 2026
    • Después de eso, los issues y pull requests de Codeberg serán el único mecanismo soportado
    • Los reportes de errores y parches históricos siguen disponibles en línea
  • Gracias al plan elaborado durante la discusión de consenso, hubo pocos problemas graves o situaciones inesperadas al hacer la transición
  • La calidad del servicio por parte del personal y del voluntariado de Codeberg e.V. fue buena, y las caídas ocasionales normalmente fueron breves y claramente anunciadas
  • Para quienes prefieren flujos de trabajo fuera del navegador, ayudaron las mejoras en la interfaz de Emacs
    • fj.el y Emacs-Forgejo avanzaron bastante
    • La posibilidad de crear pull requests con el flujo AGit también redujo la fricción de adaptación
  • El problema que no se anticipó lo suficiente fue la integración continua para pull requests
    • La función de qa.guix.gnu.org que construía parches enviados por correo no fue portada a Codeberg
    • Durante varios meses, las personas revisoras tuvieron que comprobar por sí mismas si los pull requests causarían problemas, algo que no era sostenible
  • En septiembre de 2025 se desplegó una instancia de Cuirass en pulls.ci.guix.gnu.org y comenzó a construir pull requests
    • Al inicio tenía más limitaciones que qa.guix.gnu.org y se consideraba una solución temporal
    • Actualmente los paquetes se construyen para una sola arquitectura
    • Quienes recién contribuyen pueden ver de inmediato en el pull request los resultados de éxito o fallo que deja guix-cuirass-bot

Aumentó el flujo de contribuciones, pero también el backlog

  • Si se toma como base la cantidad de commits a la rama principal entre mayo de 2024 y mayo de 2026, el ritmo de commits de Guix se mantuvo continuamente entre “alto” y “muy alto”
  • Como el ritmo de commits por sí solo no muestra bien los cambios, resultan más útiles métricas como la cantidad mensual de autores de commits, committers y nuevos autores de commits
  • La cantidad mensual de autores y de nuevos autores siguió aumentando
    • Justo después de la migración a Codeberg, en junio de 2025, hubo un pico tanto en autores como en nuevos autores
    • Fuera de ese periodo, el crecimiento en 2025–2026 fue similar al de 2024–2025
    • Guix sigue atrayendo nuevas personas contribuyentes, pero no hubo un efecto Codeberg claramente grande
  • El aumento mensual en la cantidad de committers fue más moderado que el aumento en autores, lo que podría indicar que los committers están procesando más contribuciones
  • Los datos de pull requests se recopilaron a través de la API de Forgejo de Codeberg
  • Se abren más de 500 pull requests cada mes y la velocidad de merge también es alta, pero es ligeramente menor que el flujo de entrada, por lo que el backlog sigue creciendo
    • Actualmente hay unos 639 pull requests abiertos de un total de 6,459, alrededor de 10%
    • Como referencia, en Nixpkgs hay 12k pull requests abiertos de un total de 473k, alrededor de 2.5%
    • El backlog de Guix podría deberse a demasiada fricción o a retroalimentación insuficiente del CI
  • Guix exige que cada commit tenga la firma de un committer aprobado
    • No funciona como en muchos proyectos, incluido Nixpkgs, donde basta con presionar el botón Merge
    • La persona que hace el merge tiene la responsabilidad de aplicar el cambio y firmarlo
    • Guix prioriza la seguridad de la cadena de suministro de software entre la comodidad del desarrollador y la seguridad de los usuarios
    • Aún está por verse si ese costo puede reducirse

Una colaboración más visible en Codeberg

  • Después de la migración a Codeberg, la actividad del proyecto se volvió más visible
  • Los resultados del CI aparecen directamente dentro de los pull requests, de modo que quienes contribuyen pueden revisarlos al instante
  • Los equipos de Guix están implementados como equipos de Codeberg
    • El alcance de cada equipo está especificado en el archivo CODEOWNERS
    • Las personas responsables de ese alcance son llamadas automáticamente
    • Un bot agrega etiquetas como team-python, lo que permite filtrar issues y pull requests por etiqueta
  • Sigue siendo una incomodidad el problema por el cual el equipo no recibe notificaciones en issues con esa etiqueta
  • Las referencias cruzadas entre issues y pull requests, así como funciones como los milestones, también parecen ayudar a la colaboración

Tareas de infraestructura pendientes y relación con Codeberg

Lecturas relacionadas

1 comentarios

 
GN⁺ 3 시간 전
Opiniones en Lobste.rs

  • Ver métricas reales del proyecto relacionadas con la migración a Codeberg resulta muy interesante. En lo personal, tengo demasiadas razones para dejar GitHub, así que me gustaría que Codeberg se convirtiera en el nuevo GitHub, pero yo me mudé a mi propio servidor de Forgejo y ahora uso Codeberg como destino de respaldo para todos mis repositorios

    • Entiendo que lo dicen con buena intención, pero creo que sería mejor que, en vez de que todo se concentre en Codeberg, varias forjas independientes se comuniquen entre sí mediante ForgeFed
      No hace falta otro nuevo hub centrado en código abierto
    • No creo que Forgejo esté lo suficientemente escalado por ahora como para asumir ese papel. Del lado de Codeberg están haciendo lo que pueden y ojalá mejore, pero parece que tomará tiempo
    • Al final, todo mi trabajo personal lo pasé a Fossil, y para las cosas que quiero hacer públicas para otros monté mi propio servidor de Fossil
      Hasta ahora ha sido excelente y definitivamente lo prefiero sobre git. Aunque para los estándares actuales esa barrera no sea tan alta

  • Desde que empecé a usar Codeberg, lo que de verdad me ha frustrado es que casi no hay herramientas que soporten bien la integración con git, y la mayoría en la práctica están hechas solo para GitHub / GitLab

    • Como usuario de magit forge, dan ganas de llorar

  • No entiendo la parte de mantener el rastreador antiguo de issues y parches hasta el 1 de enero de 2026 y después pasar a soportar solo issues y pull requests de Codeberg
    Si una parte importante de los contribuidores no quiere ese nuevo flujo, no sé por qué forzarlo, y también me pregunto si hay algún costo oculto en permitir varios flujos de trabajo. Cuestiono por qué habría que imponer la misma forma de trabajar a todo el mundo
    Es un detalle menor, pero no parecía que Codeberg tuviera varios empleados asalariados; según yo, solo había uno. Corrección: dicen que en diciembre del año pasado contrataron a un segundo empleado