Un an après la migration de Guix vers Codeberg

 (guix.gnu.org)
1 points par GN⁺ 3 시간 전 | 1 commentaires | Partager sur WhatsApp
  • En 2025, Guix a déplacé vers Codeberg son mode de collaboration auparavant organisé depuis plus de 10 ans autour de Savannah et de Debbugs par e-mail, changeant en profondeur le point d’entrée des contributions pour un projet qui réunit plus de 400 participants par an
  • Cette transition a constitué le premier cas concret de la procédure Guix Consensus Document, introduite en décembre 2024, et le GCD 002 est entré en vigueur début mai 2025 après deux mois de discussion
  • Le workflow historique par e-mail restait efficace pour les contributeurs expérimentés grâce à des outils comme Emacs, mumi ou qa.guix.gnu.org, mais, dans une enquête ayant recueilli 900 réponses, il a souvent été désigné comme un obstacle à la contribution
  • Après le passage à Codeberg, le nombre d’auteurs et de nouveaux auteurs a augmenté, mais en dehors d’un pic temporaire en juin 2025, il reste difficile de confirmer un effet Codeberg net
  • Plus de 500 pull requests sont ouvertes chaque mois et le backlog continue de grossir, si bien que la réduction des lacunes de CI, des exigences de signature et de la charge de revue reste le prochain chantier opérationnel de Guix

Du travail collaboratif par e-mail à Codeberg

  • En 2025, Guix a migré vers Codeberg l’hébergement du code source, le suivi des issues et les pull requests
    • Auparavant, le code était hébergé depuis plus de 10 ans sur Savannah
    • Les rapports de bug et les patchs étaient traités par e-mail et suivis via une instance Debbugs
    • Pour un projet comptant plus de 400 contributeurs au code chaque année, cette transition représentait en soi un changement majeur
  • Les contributeurs historiques étaient habitués au workflow par e-mail et travaillaient efficacement avec le paquet Debbugs pour Emacs ou des clients mail avancés
    • Debbugs repose sur quelques centaines de lignes de Perl ainsi que sur les standards e-mail et une structure fédérée, alors qu’une forge web comme Forgejo est un système plus vaste avec de nombreuses dépendances Go
  • Des outils auxiliaires existaient déjà autour de ce flux par e-mail
    • mumi fournit une interface web pour Debbugs
    • Le service Quality Assurance appliquait automatiquement les séries de patchs envoyées par e-mail à des branches Git, puis y construisait les paquets
  • La première enquête publique auprès des utilisateurs et contributeurs, publiée en janvier 2025, a recueilli plus de 900 réponses, et les contributeurs y citaient souvent le workflow par e-mail comme un frein à la contribution

Une décision fondée sur le consensus via le GCD 002

  • Guix n’avait pas de “benevolent dictator” pour trancher, et le projet a introduit en décembre 2024 le processus Guix Consensus Document
  • La procédure GCD vise la construction d’un consensus plutôt qu’un simple vote
    • L’auteur d’une proposition doit l’ajuster avec les participants
    • Les participants ne doivent pas se limiter à s’opposer, mais proposer leurs besoins et des changements concrets pour les prendre en compte
    • La version finale permet d’exprimer sa position avec support, accept ou disapprove
  • Le GCD 002 a été soumis en février 2025 pour proposer la migration vers Codeberg
    • La discussion a duré deux mois, soit la durée maximale prévue par la procédure
    • Deux tiers des membres de l’équipe Guix ont pris part à la délibération
    • Parmi les participants, 72 % ont choisi support et les 28 % restants accept
    • Aucun disapprove n’a été exprimé, et la proposition est entrée en vigueur début mai 2025
  • Certains contributeurs de longue date jugeaient qu’un workflow perçu comme prioritairement web était moins efficace que l’e-mail, et voyaient aussi d’un mauvais œil l’abandon d’une partie de l’infrastructure e-mail existante
  • La possibilité d’élargir les points de contact avec la communauté et d’améliorer l’expérience développeur a soutenu la transition
  • La préférence pour une forge basée sur le logiciel libre et hébergée par l’association à but non lucratif Codeberg e.V. n’a pas suscité de grand débat et correspondait à l’orientation de Guix

Une transition progressive et une lacune de CI plus importante que prévu

  • Conformément au consensus du GCD, la migration vers Codeberg s’est faite de manière progressive
    • Le dépôt principal a été migré le 25 mai 2025
    • L’ancien dépôt reste encore aujourd’hui en miroir
    • L’ancien système de suivi des issues et patchs sera maintenu jusqu’au 1er janvier 2026
    • Après cela, les issues et pull requests Codeberg deviendront le seul mécanisme officiellement pris en charge
    • Les anciens rapports de bug et patchs restent accessibles en ligne
  • Grâce au plan élaboré pendant la phase de consensus, la transition a connu peu de problèmes majeurs ou de surprises
  • La qualité de service des salariés et bénévoles de Codeberg e.V. a été jugée bonne, et les indisponibilités ponctuelles étaient généralement brèves et clairement annoncées
  • Pour les contributeurs préférant travailler hors navigateur, l’amélioration des interfaces Emacs a aidé
  • Le point le moins bien anticipé concernait la CI pour les pull requests
    • La fonction de qa.guix.gnu.org qui construisait les patchs envoyés par e-mail n’a pas été portée vers Codeberg
    • Pendant plusieurs mois, les reviewers ont dû vérifier eux-mêmes si les pull requests introduisaient des problèmes, une situation jugée non durable
  • En septembre 2025, une instance Cuirass a été déployée sur pulls.ci.guix.gnu.org pour commencer à construire les pull requests
    • Au départ, elle était plus contrainte que qa.guix.gnu.org et a été considérée comme une solution provisoire
    • Aujourd’hui, les paquets ne sont construits que pour une seule architecture
    • Les nouveaux contributeurs peuvent immédiatement voir dans les pull requests les résultats de réussite ou d’échec laissés par guix-cuirass-bot

Le flux de contributions augmente, mais le backlog aussi

  • En prenant comme référence le nombre de commits sur la branche principale entre mai 2024 et mai 2026, le rythme de commit de Guix est resté constamment entre “élevé” et “très élevé”
  • Comme ce seul rythme rend mal les évolutions, le nombre mensuel d’auteurs de commits, de committers et de nouveaux auteurs de commits s’avère plus utile
  • Le nombre mensuel d’auteurs et de nouveaux auteurs continue d’augmenter
    • Juste après la migration vers Codeberg, en juin 2025, on a observé un pic à la fois du nombre d’auteurs et de nouveaux auteurs
    • En dehors de cette période, la croissance sur 2025–2026 est similaire à celle observée sur 2024–2025
    • Guix continue donc d’attirer de nouveaux contributeurs, mais sans effet Codeberg nettement marqué
  • La hausse du nombre mensuel de committers est plus modérée que celle des auteurs, ce qui peut indiquer que les committers absorbent une part plus importante du traitement des contributions
  • Les données sur les pull requests ont été collectées via l’API Forgejo de Codeberg
  • Plus de 500 pull requests sont ouvertes chaque mois, et malgré un rythme de fusion élevé, il reste légèrement inférieur au flux entrant, ce qui fait croître le backlog
    • Environ 639 pull requests sont actuellement ouvertes sur un total de 6 459, soit près de 10 %
    • À titre de comparaison, Nixpkgs compte environ 12k pull requests ouvertes sur un total de 473k, soit environ 2,5 %
    • Le backlog de Guix peut refléter des frictions excessives ou un retour de CI insuffisant
  • Guix exige que chaque commit porte la signature d’un committer approuvé
    • Il ne s’agit pas d’un simple clic sur le bouton Merge, comme dans beaucoup de projets dont Nixpkgs
    • La personne qui fusionne un changement doit l’appliquer et le signer elle-même
    • Guix privilégie la sécurité de la chaîne d’approvisionnement logicielle entre commodité pour les développeurs et sécurité des utilisateurs
    • Il reste à voir s’il est possible de réduire ce coût

Une collaboration plus visible sur Codeberg

  • Depuis la migration vers Codeberg, l’activité du projet est devenue plus visible
  • Les résultats de CI apparaissent directement dans les pull requests, ce qui permet aux contributeurs de les vérifier immédiatement
  • Les équipes de Guix sont matérialisées sous forme d’équipes Codeberg
    • Leur périmètre est défini dans le fichier CODEOWNERS
    • Les responsables du périmètre concerné sont automatiquement sollicités
    • Un bot ajoute des labels comme team-python, ce qui permet de filtrer issues et pull requests par label
  • Le problème empêchant les équipes d’être notifiées sur les issues portant ces labels reste un point gênant
  • Les références croisées entre issues et pull requests, ainsi que des fonctions comme les milestones, semblent également aider à la collaboration

Les chantiers d’infrastructure restants et la relation avec Codeberg

  • L’infrastructure Guix a besoin de davantage de soutien
    • Il faut améliorer les performances de build de pulls.ci.guix.gnu.org
    • Il serait souhaitable de pouvoir construire aussi pour des architectures non x86
    • Cuirass présente encore plusieurs limites, dont certaines sont en cours de résolution dans la série 1.4.x
    • pulls.ci.guix.gnu.org reste centré sur les paquets, alors qu’il serait utile de pouvoir aussi lancer des tests système lorsque c’est pertinent
  • Le workflow des packageurs peut lui aussi être amélioré
  • Guix doit éviter de créer une charge excessive sur les serveurs Codeberg et surveiller aussi l’usage du stockage des dépôts
  • Une solution envisagée consisterait à imposer aux nouveaux contributeurs de créer leurs pull requests via le workflow AGit
    • AGit est déjà populaire parmi les contributeurs de Guix
    • Mais certains le jugent moins familier qu’un workflow de pull request classique, donc comme une forme de “downgrade”
    • Comme dans le cas de Gentoo, l’ajout d’une icône “AGit fork” pourrait améliorer sa découvrabilité
  • La Guix Foundation a voté pour devenir membre de soutien de Codeberg e.V., en signe de gratitude et de soutien
  • Une pull request ajoutant Forgejo et le service permettant de le configurer dans Guix a été soumise
    • Cela va dans le sens d’un déploiement déclaratif de la forge et reproductible directement dans Guix

À lire aussi

1 commentaires

 
GN⁺ 3 시간 전
Avis sur Lobste.rs

  • Il est très intéressant de voir des indicateurs de projet concrets liés à la migration vers Codeberg. Personnellement, j’ai bien trop de raisons de quitter GitHub, donc j’espère que Codeberg deviendra le nouveau GitHub, mais j’ai migré vers mon propre serveur Forgejo et j’utilise maintenant Codeberg comme cible de sauvegarde pour tous mes dépôts

    • Je sais que c’est dit avec de bonnes intentions, mais je pense qu’il vaudrait mieux avoir plusieurs forges indépendantes qui communiquent entre elles via ForgeFed, plutôt que de voir tout converger vers Codeberg
      Nous n’avons pas besoin d’un nouveau hub centralisé autour de l’open source
    • Je ne pense pas que Forgejo soit actuellement assez mature pour assumer pleinement ce rôle. L’équipe de Codeberg fait ce qu’elle peut, et j’espère que cela va s’améliorer, mais ça prendra sans doute du temps
    • Tout ce que je fais à titre personnel a fini par migrer vers Fossil, et pour ce que je veux rendre public, j’ai mis en place mon propre serveur Fossil
      Jusqu’ici, l’expérience est excellente, et je le préfère clairement à git. Ce n’est pas une barrière si élevée que ça de nos jours, même si elle existe

  • Depuis que j’ai commencé à utiliser Codeberg, ce qui m’a vraiment agacé, c’est que très peu d’outils prennent correctement en charge l’intégration git, et qu’en pratique la plupart sont exclusivement conçus pour GitHub / GitLab

    • Quand on utilise magit forge, ça fait pleurer

  • Je ne comprends pas la décision de maintenir l’ancien système de suivi des tickets et des patchs jusqu’au 1er janvier 2026, puis de ne plus prendre en charge que les issues et pull requests de Codeberg après cette date
    Si une part importante des contributeurs n’aime pas ce nouveau fonctionnement, je ne vois pas pourquoi le changement devrait être imposé, et je me demande aussi s’il existe un coût caché à permettre plusieurs modes de contribution. Je m’interroge sur la nécessité d’imposer la même méthode à tout le monde
    Petit pinaillage, mais il ne me semblait pas que Codeberg ait plusieurs employés rémunérés ; à ma connaissance, il n’y en avait qu’un. Correction : un deuxième employé a été recruté en décembre dernier