Je trouve dommage de ne plus avoir de réseau Duniter-v2s en ce moment. J’aimerais dégrossir ici les objectifs de ces réseaux pour discuter de ce qu’on attend du prochain réseau de test pendant la Prochaine visio dev -- septembre 2023.
Un réseau de test
sert de support pour développer les différents outils de l’écosystème (clients, indexeur…)
permet aux “apprentis forgerons” de se familiariser et s’entraîner à administrer un nœud
permet au “comité technique” de s’entraîner à publier des runtime upgrade
révèle des bugs de duniter v2s
nous entraîne collectivement à opérer un réseau
génère des données “monde réel” pour les live tests
permet aux junistes intéressés d’avoir un aperçu sur les avancées réalisées sur la v2
crée une source de motivation pour s’intéresser au projet
Quelques questions pour guider la réflexion
doit-on lancer un nouveau réseau immédiatement / attendre la fusion des prochaines grosses MR ?
doit-on “prendre soin” du réseau (cela implique des efforts) ou “avancer vite” (et potentiellement le casser) ?
un réseau de test doit-il rester essentiellement technique, ou doit-on impliquer plus de personnes de la Ğ1 ?
S’il y a des MR intéressantes à incorporer, autant attendre, c’est pas tous les jours qu’on lance une monnaie de test.
Ça dépend des objectifs qu’on se fixe. Stabiliser une implémentation ? Tester de nouveaux changements fondamentaux ?
Je dirais principalement technique pour l’instant. De ce que j’ai compris il y a encore des changements majeurs à implémenter et à tester. Les personnes non techniques peuvent cependant déjà tester.
Je voulais avoir une idée de la durée d’attente (pour moi au-delà d’octobre c’est trop loin) et j’ai donc pris de l’avance sur une branch hugo-flash pour résoudre les conflits qui allaient émerger pour la fusion des “grosses MR”. La plus grosse difficulté était de mettre à jour l’oracle de distance de substrate/subxt v0.9.32 vers v0.9.42 mais j’ai réussi à avoir une branche :
avec une version de substrate v0.9.42
qui compile duniter avec un runtime gtest compatible avec la sortie de py-g1-migrator
qui compile l’oracle de distance
Donc on devrait y arriver en un temps raisonnable.
Je dirais qu’on est plutôt à l’étape “tester des nouveaux changements fondamentaux” au sens où il nous reste encore à ajouter l’exonération des frais de transaction. Après ça et si on n’a rien oublié sur le Migration board, on pourra passer à une phase de stabilisation (il y a juste les commentaires de transaction pour lesquels j’aimerais malgré tout trouver une solution).
Le fait d’industrialiser la création d’un réseau Ğx, c’est à la fois pour faciliter et fiabiliser les lancements de ĞTest et Ğ1, mais aussi pour se permettre des reboot régulier de ĞDev sans surcoût.
Pour moi :
pas besoin de prendre grand soin de la ĞDev (qui est un réseau de développement – technique)
mais prendre soin des ĞTest (qui est une préprod) et de la Ğ1 (qui est une prod)
Concernant l’attente, j’aimerais vraiment pouvoir réaliser mon ticket #125 afin de lancer le réseau. Certes tu pourrais aller plus vite car tu disposes de beaucoup de temps, mais ce serait à mon avis contre-productif à d’autres égards. J’espère finir ce ticket dans les 2 semaines à venir.