A ce compte la peut-être que nous devrions annuler la 1.7 et nous consacrer directement au développement de la 2.0 
(après que le 1.6 sera stable bien entendu)
1 Like
Il y avait quoi de prévu pour la 1.7 ?
L’objectif principal de la 1.7 de mon point de vue, c’est de faire passer la commande sync ainsi que la gestion des interfaces réseau par ws2p pour pouvoir supprimer définitivement le crawler bma et ne plus dépendre de code bma pour la config réseau. Mais ca on peut très bien le faire directement pour la 2.0 !
Après il y a aussi plein de correctifs et améliorations diverses qu’on a reporter parce qu’on avait geler la 1.6 :
Je pense qu’on peut dédier la 1.7 à la stabilisation en virant BMA et en réglant les issues, puis partir sur la 2.0 qui proposera de gros changements comme la version 11 du protocole, et la refonte de certaines parties qui se font vieilles.
De quelle commande sync tu parles, elle n’est pas déjà disponible ?
En fait c’est un travail énorme, il faut réécrire toute la partie download du mécanisme de sync et faire évoluer en profondeur le protocole WS2P, je pense qu’on peut changer de protocole dans la foulée, car en réalité supprimer complètement BMA c’est déjà une très très grosse métamorphose de duniter-ts !
En revanche, s’il y a des correctifs qui ne peuvent pas attendre (typiquement tout ce qui est correctif de sécurité), on peut très bien sortir d’autres releases 1.6 même après la stable et qui contiendrais uniquement des correctifs de sécurité.
Actuellement la commande sync passe entièrement par BMA.
Je vois, et ça correspond bien à la refonte que j’avais en tête, dans laquel on casserait surement certaines retro-compatibilités.
Je pense qu’on peut réserver la 1.7 comme dernière version stable avant la 2.0, dans laquelle les issues sont corrigées sans grandes nouvelles fonctionnalités, pendant que les nouvelles sont développées sur une branche à part.
Il faudrait que je “rattrape le retard” avec duniter-rs pour qu’il puisse participer au lancement de la 2.0, en tout cas en tant que noeud alternatif. Je prend soin à le développer pour qu’il soit le plus extensible possible, il sera alors beaucoup plus simple d’ajouter de nouvelles fonctionalités. Je ne sais pas l’état du code de duniter-ts, donc je ne peux pas juger à ce niveau là.
2 Likes
Dans ce cas je vais reporter la sync WS2P a la 2.0 car c’est une grosse nouvelle fonctionnalité. je pense reporter aussi la plupart des nouvelles features WS2P que j’avais en tête. D’ailleurs comme ça, ça me laissera le temps de rédiger une RFC ws2p v2 pour qu’on se mette d’accord sur des nouvelle spec solides 
1 Like
Ca me semble mieux.
Il faudrait aussi travailler sur une doc détaillée à jour de chaques protocoles, et de vérifier que le code fait bien ce qui est prévu, corriger les erreurs et supprimer ce qui n’est pas utile, pour simplifier un maximum la codebase, dans un esprit KISS ^^
Proposer les changements en RFC me semble beaucoup plus péreine et assurera que tous les contributeurs puissent donner leur avis, sans aucune barrière de langage.
3 Likes
Ceci dit, faire des petites évolutions par petit incrément de version évite de se retrouver avec trop de bugs à corriger d’un coup 
. Ce qui me semble plus facile à maintenir au vue de la taille actuelle de l’équipe.
Il faut surtout d’après mois s’astreindre à faire vivre le réseau de test. On le voit, même des versions mineures qu’on estime peut risquées sont finalement assez critiques. On devrait toujours valider les pre-release sur le réseau de test avant de passer sur le réseau de prod.
Ca n’empêche pas @elois de faire une RFC pour la 1.7.0 de toute façon, il va bien falloir communiquer sur le protocole WS2P… Pour l’instant tout ça c’est quand même vachement dans la tête de @cgeek et toi 
3 Likes
OUI OUI OUI !
je m’interroge sur quelle vague surfer 
en lisant ces propos en cet instant :
manège à sensation forte garantie 
1 Like
Attention. La suppression de BMA empêchera l’envoi des documents (transactions, certifications, et wot related) des clients aux nœuds.
Avant de définitivement tuer BMA, il faut une nouvelle API cliente et que les principaux clients aient implémentés l’envoi de tous ces documents.
1 Like
@Moul nous en avons parfaitement conscience, mais ce dont tu parle n’est en fait que la partie passive de BMA, parti que nous garderons évidemment jusqu’a ce que la nouvelle API Client soit développée, stabilisée et intégrée dans les clients.
En fait je faisais référence a d’autres parties de BMA (crawler et rooter), qui ne sont pas utilisés par les clients