Voici ce que je note côté py-g1-migrator :
- ajouter la date de versement du premier DU ajouté par tuxmain dans !178
- récupérer l’adresse de la trésorerie pour déplacer la monnaie ignorée
- rendre le préfixe ss58 des addresses paramétrable (42 pour les réseaux de test, 4450 pour la Ğ1)
- s’assurer que la quantité de monnaie dans les comptes correspond à la masse monétaire
- vérifier que la conversion timestamp → nombre de blocs est cohérente
Et à part ça, il faut tenir compte de la sortie des print avec un “
” pour les incohérences détectées par le migrator.
J’ai notamment fait le tour des sujets qui parlent de ça :
- Adapter py-g1-migrator pour la migration Ğ1
- What's needed to start a ĞTest network
- Incohérence dans les données? -- certifications expirées
- V2S: Ğ1 data migration (g1-migrator)
- Date de création du DU
- Quantité de monnaie sur Duniter
- Total issuance vs monetary mass
- g1-migrator
Côté Duniter-v2s, je n’ai pas trop documenté à part dans les commentaires du code parce que je m’adaptais à ce que je faisais sortir du migrator. Mais de mémoire et en regardant le code :
- s’assurer que la trésorerie ne crée pas de monnaie au genesis (elle doit être mise à existential deposit minimum, donc si elle est à zéro de la monnaie est ajoutée)
- s’assurer qu’il y tous les check au genesis nécessaires à ne pas avoir d’incohérence de storage
Et donc pour répondre à la question, je dirais que le niveau d’avancement côté gtest est assez poussé, il faut être un peu minutieux dans les refactoring et lire les commentaires dans le code. Par contre côté gdev il faut pas hésiter à tailler dans le gras, j’ai quasiment pas touché à ce qu’avait fait elois pour éviter de casser les tests qui étaient basés sur cette manière de parser le genesis, mais le but de la factorisation étant de rapprocher les tests des conditions réelles, c’est le moment de casser des trucs.