I created an account for you on our GitLab : https://git.duniter.org/gma. You should have received an invitation email and should be able to fork or create a branch on clients / Cesium-grp / cesium2s · GitLab. (oups, pourquoi je parle en anglais, je ne sais pas).
Il n’y a pas vraiment de feuille de route, mais @cgeek a ouvert un ticket #142 à ce sujet qui liste déjà quelques points.
Ce qu’on fait sur Duniter-v2s, c’est de systématiquement pousser le travail en cours sur une branche et de créer une MR Draft tant que le travail est en cours. Quand le travail est prêt pour relecture, on n’a plus qu’à cliquer sur “mark as ready” pour retirer le statut draft et éventuellement tagger quelqu’un comme reviewer. C’est assez pratique pour coordonner le travail à plusieurs, je t’encourage à publier ton travail le plus tôt possible.
Merci Hugo pour la création de compte et pour le lien vers ce ticket qui donne effectivement des pistes de choses à regarder.
J’ai mis à jour les points de ce ticket, comme je suis en train de travailler sur #141 (stratégie de tests) je vois de mieux en mieux les besoins côté client.
Hum. Je vais voir comment faire. Sinon, peut etre prévoir une visio ensemble, pour que tu me contre les détails ?
Voila j’ai pousser sur /develop. L’architecture est beaucoup mieux à mon gout.
@RxStateProperty() : pour générer le code de getter/setter qui écrit/lit depuis RxState@RxStateSelect() pour déclarer un observable écoutant une propriété du RxState.
npm i)Bon du coup j’ai du code qui ne marche plus, mais je vais retravailler tout ca.
@gma redis moi si tu as des questions.
Je vais déjà regarder et tester tes dernières modifs.
Pour ce que dis Hugo à propos des MR, c’est juste faire ce que tu as fais, c’est-à-dire créer une branche avec le dev que tu as fais (perso, j’aime bien préfixer le nom de mes branches avec “feature/” ou “fix/” par exemple en fonction de si c’est le développement d’une nouvelle fonctionalité ou un correctif) et ensuite dans l’interface de gitlab, tu crées une MR en sélectionnant ta branche nouvellement créée en source et la branche où tu voudras merger à terme (la majorité du temps master). Tu peux ensuite marquer cette MR comme Draft, ce qui évite de la merger malencontreusement si jamais le dev n’est pas terminé. Et puis il y a moyen d’assigner un reviewer pour faire revoir le code par quelqu’un d’autre avant de merger, ce qui permet bien souvent de trouver des petites coquilles
Il y a aussi moyen de conditionner la possibilité de merger au fait que les tests en CI passent, ce qui est plutôt une bonne pratique aussi.
Bonjour à tous, moi aussi je suis disponible pour aider avec Cesium v2, je n’ai pas de familiarité avec ce stack en particulier (ionic/angular) mais assez d’experience avec beaucoup de stacks differents comme pour me faire utile relativement vite… plus ça si quelq’un qui déjà connais bien le code comme @kimamila est disponible pour coordiner les contributeurs et nous guider vers quelles taches il fait sense de faire en ce moment.
Je peux être disponible 5-10h pour semaine, et rejoindre quelque session de coordi si ça va aider. (Also as you may have noticed my French is not the best so I may occasionally switch to English).
@gma @txels On dirait bien qu’on commence à avoir une belle petite équipe ! 
Je ne sais pas trop comment organiser les choses… voici quelques idées :
Qu’en dites vous ?
J’ai déjà commencé les 2 premiers points que tu listes. J’essaye de me familiariser un peu avec angular, typescript et ionic qui ne sont pas des technos avec lesquelles j’ai l’habitude de travailler. Je vais prendre connaissance de Polkadot JS et RxState aussi dans les prochains jours. Tout ça demande un peu de temps pour se mettre en jambe ^^
Ensuite effectivement, ce serait probablement bien de créer des issues pour ce qu’il y a à faire et qu’on se les assigne, histoire d’éviter de faire les mêmes choses chacun de notre côté.
Moi comme @gma je suis dans le stage de faire marcher le code localement, lire quelques docs et me familiariser avec les APIs et librairies.
En plus d’écrire des issues qu’on puisse se répartir, ça que je trouve très effectif c’est de faire une session de mobbing/pairing où on attaque une des issues ensemble. Après ça je trouve que tous nous aurons plus d’empowerment pour paralleliser le travail.
@gma @HugoTrentesaux j’ai répondu à la MR !3:.
Finalement j’ai fait un merge depuis ma branche, en intégrant les modifs de @gma develop. J’ai mis à jour master avec ces modifs.
Enjoy !
Maintenant nous pourrions travailler sur un gitlab CI pour builder tout ca. J’en ai qui tourne, mais je dois les adapter à Angular 17.
Oi! J’ai essayé de prendre ça (j’ai expérience avec GitlabCI) mais après avoir mis à jour mon repo local, faire les npm install (m’assurer que j’ai le CLI de Angular 17) etc je ne réussis pas à builder.
$ npm run start
Error: src/app/shared/shared.module.ts:16:42 - error TS2307: Cannot find module '@app/shared/loading/skeleton.list/skeleton.list.component' or its corresponding type declarations.
16 import { AppSkeletonListComponent } from '@app/shared/loading/skeleton.list/skeleton.list.component';
Même chose avec npm run build. Peut-être un fichier que manque au git?
Le dossier app/shared/loading/ n’existe pas dans le repo.
Aussi, j’ai pas trouvé un .gitlab-ci.yaml dans le repo (master). Quan tu @kimamila dis “J’en ai qui tourne, mais je dois les adapter à Angular 17.” où est ça?
En attendant une réponse, j’ai crée un CI minimaliste qui au moins sert à illustrer le problème des fichiers qui manquent. SVP @kimamila si tu as du temps pour regarder à ça, sinon je pense qu’on est tous bloqués dans le moment Minimal CI to get started (!4) · Merge requests · clients / Cesium-grp / cesium2s · GitLab
Le MR !4 a été fusionné.
J’ai ajouté les fichiers manquants au develop et master.
Ca devrait maintenant compiler.
Désolé pour le délai. Je fais comme je peux.
Merci bien! J’éspère m’y remettre la semaine prochaine au retour de mes vacs. Aucune suggestion pour la prochaine tâche? Je voudrai prendre la issue que tu as écrit et en faire un breakdown en tâches minimales independantes et commencer par une d’elles.
J’ai ajouté quelque truc sur le projet (branche develop) :
Changement du noeud Duniter, via une fenêtre modal de sélection;
Ajout d’un bouton pour passer en mode sombre (en haut à droite) :
En mobile : Application des paramètres à chaque changement
(en bureau il faut les appliquer via un bouton “enregistrer”)
develop et feature/* pour le moment) : cf Pipelines · clients / Cesium-grp / cesium2s · GitLab - merci @txels pour les premiers éléments !
npm run android:build puis ouvrir et lancer le projet via android studioVoilou !
Voici une version Android (APK signé) qui fonctionne : app-release-signed.apk - Google Drive
J’ai donc maintenant un socle qui fonctionne pas trop mal (je crois) et vraiment opérationnel pour monter en charge l’équipe de dev.
De mon côté, voici les prochaines étapes qui concerneront toujours le socle :
Je voudrais commencer par tester ceci :
addressC’est déjà pas mal dans un premier temps
@HugoTrentesaux d’abord toi sur quel indexeur je dois partir ? Lequel maintiens tu ?
Je l’ai installer, ça fonctionne.
J’ai voulu tenter de récupéré mes comptes gecko avec la phrase de restauration, mais je ne tombe pas sur le même compte. Je suppose que c’est une histoire de dérivation.
Il vas falloir vous entendre sur le vocabulaire utilisé pour les users lambda.