I2P Dev Meeting - November 25, 2014

20:04:39 <str4d> Yo 20:04:44 <str4d> C'est l'heure de la réunion 20:06:47 <str4d> zzz, psi, kytv, Meeh, dg 20:07:30 <psi> ah bon ? 20:07:39 <psi> ah mardi 20:09:03 <zzz> présent 20:09:48 <orignal> réunion ? 20:10:11 <str4d> orignal : on discute la liste des tâches de Java I2P 20:10:35 <str4d> En attendant que les autres arrivent : http://trac.i2p2.i2p/wiki/Roadmaps/1.0 20:10:41 <kytv> Présent aussi, même si je suis généralement inutile pour ce genre de choses. 20:11:37 <str4d> J'ai ajusté le diagramme de Gantt sur la page ci‑dessus (que j'avais mis en place pour le cycle de dev 0.9.13–0.9.16) pour montrer ce que je pense que nous avons fait. 20:13:30 <zzz> intéressant 20:14:06 <zzz> multiple dests per tunnel <-- ça n'est pas arrivé 20:14:22 <str4d> Ah non ? Ok, ma faute. 20:14:27 <zzz> findbugs pass <-- ça a eu lieu, mais on peut toujours le refaire 20:14:56 <str4d> Multi-sessions par I2CP — ça non plus n'est pas arrivé *derp* 20:14:56 * str4d corrige 20:15:48 <zzz> wow, on a eu une bonne année (à mon humble avis) 20:16:38 <eche|on> oui 20:17:14 <str4d> zzz : oui, je l'avais qualifié spécifiquement de préparation à l'audit, mais tu as raison. 20:17:39 <zzz> examiner un nouveau DH <---- je dirais à moitié fait seulement, en ce qui concerne NTCP2 de toute façon 20:20:26 <str4d> Gantt ne montre pas facilement le « à moitié fait » :P 20:20:34 <str4d> Rechargez la page, corrections 20:21:36 <str4d> Ok, voilà ce que nous avons fait le cycle dernier. 20:21:36 <zzz> donc pas fait 20:23:45 <str4d> Le but de cette réunion est de commencer à planifier ce qui doit être fait au prochain cycle. 20:23:46 <zzz> Je voudrais réitérer qu'un cycle de planification de 3 à 5 versions semble très utile pour concentrer nos esprits et nos ressources 20:23:47 <str4d> (Quand je mettrai à jour le diagramme de Gantt, je laisserai les tâches à moitié faites et je les repousserai) 20:23:47 <str4d> À la précédente réunion, j'ai demandé aux participants de proposer chacun quelques points de choses qu'ils souhaitent voir réalisées dans I2P, et autour d'I2P 20:23:47 <str4d> Pouvez‑vous les coller maintenant, s'il vous plaît ? 20:24:21 <str4d> +1 20:24:36 <str4d> Et maintenant nous en avons la preuve ! 20:26:15 <zzz> sans entrer dans ce qui est plus important que le reste, je pense que presque tout ce qui est affiché et non terminé sur le diagramme de Gantt est toujours important 20:27:01 <str4d> Je suis d'accord. 20:27:07 <str4d> Je veux quand même voir quelles idées les gens ont eues la semaine dernière, s'il y en a. 20:27:45 <str4d> Voici les miennes : http://pastethis.i2p/show/jF2RkHwrIPkCb0yOpI7l/ 20:27:46 <iRelay> Titre : Paste #jF2RkHwrIPkCb0yOpI7l | LodgeIt! (at pastethis.i2p) 20:28:07 <eche|on> Je suis à court d'options; je vois pour faire connaître I2P, avec l'aide de Bote sur Android, i2p messenger est une option, un serveur XMPP, et Syndie. Désolé, je considère toujours Syndie important. 20:28:27 <str4d> eche|on : super, merci ! 20:28:43 <str4d> Continuez à envoyer :) 20:28:53 <eche|on> et avec l'appli Android viennent les routes restreintes 20:28:54 <zzz> ma liste de nouveautés : résoudre le problème ECDSA de Red Hat, migrer vers EdDSA, Jetty 9 / Java 7, étendre la base d'utilisateurs Vuze, et plus de marketing / sensibilisation / partenariats / intégration 20:29:36 <str4d> Pour la postérité des logs, j'écrirai mes idées ici aussi : 20:30:11 <str4d> À faire dans I2P : analyse et refonte UX de la Routerconsole ; prendre des idées du design HS 2.0 de Tor et les appliquer aux I2P Destinations (destinations I2P) ; planification de la bande passante. À faire autour d'I2P : améliorations du thème du site web ; implémenter les relais de récupération d'I2P‑Bote ; recherche 20:30:23 <zzz> un autre : orchid : le réparer ou l'abandonner 20:30:32 <str4d> +100 20:31:13 <kytv> En ce qui concerne le problème ECDSDA sous RedHat/Gentoo, on pourrait/devrait peut‑être afficher un message dans la barre latérale (ou les logs) avec un lien de téléchargement. Ou peut‑être demander à l'utilisateur si « nous » devons le télécharger dans ./lib 20:31:35 <zzz> un autre : améliorations des tests, matériel de test, tests sous Windows 20:31:58 <str4d> kytv : bonnes idées (mais on peut en discuter à une autre réunion :) 20:32:03 <zzz> un autre : dépenser plus d'argent 20:32:36 <zzz> un autre : Chine 20:32:58 <str4d> Entre ces idées et la liste des éléments non terminés sur la page ci‑dessus, nous avons un bon vivier de projets potentiels. 20:33:34 <str4d> Mon objectif est de ranger, formaliser et publier ces projets sur la page des tâches du site web 20:34:11 <str4d> Après avoir fouillé les pages « à faire » d'autres projets, voici le format que je propose : 20:34:11 <str4d> http://pastethis.i2p/show/nvexU3ZvSFOI6L5DrrqM/ 20:34:12 <iRelay> Titre : Paste #nvexU3ZvSFOI6L5DrrqM | LodgeIt! (at pastethis.i2p) 20:34:54 <eche|on> bonne idée 20:35:10 <kytv> Pareil pour Orchid 20:35:10 <kytv> Mon principal « À faire autour d'I2P » concerne les tests. Pas des tests automatisés avec des logiciels, à proprement parler, mais le fait que l'un de nos services passe en production sans aucun test... juste [pouf], « c'est en ligne... je ne sais pas si ça marche par contre. » 20:35:12 <kytv> Dans I2P : faire en sorte que l'Installeur installe dans le répertoire utilisateur sous Windows pour éviter tout problème de permissions. Ça devrait être facile, mais je ne sais pas comment. 20:35:16 <kytv> Chrome faisait ça (le fait peut‑être encore ?) 20:35:41 <str4d> Mon résultat final idéal : les utilisateurs peuvent aller sur la page des tâches et y trouver la liste de toutes les idées que nous avons pour des projets dans et autour d'I2P. 20:36:11 <zzz> un autre : GSoC 20:36:14 <str4d> Il y aura un nuage de tags en haut sur lequel ils pourront cliquer pour filtrer les projets qui nécessitent certaines compétences 20:36:17 <str4d> compétences 20:36:21 <zzz> un autre : rencontre estivale 20:37:54 <zzz> un autre : enquête GNS, 2e passage ? 20:38:28 <str4d> mmm 20:38:54 <zzz> ou peut‑être, juste une autre discussion avec ces gars suffira 20:39:09 <str4d> Là tout de suite, je vais retirer du Gantt les tâches que nous avons terminées. 20:39:27 <zzz> peux‑tu l'enregistrer et en commencer un nouveau ? 20:39:29 <str4d> zzz : lesquels des quelques du bas ont été terminés (détection de relecture SSU, etc.) ? 20:39:38 <str4d> Bien sûr. 20:39:49 <zzz> c'est plutôt sympa de montrer que nous accomplissons effectivement des choses 20:40:19 <eche|on> zzz : la plupart des choses ont été faites par toi, à mon avis 20:40:35 <EinMByte> j'ai raté la réunion ? 20:40:37 <zzz> Je pense avoir signalé tout ce qui était du mauvais côté de « terminé ou pas » 20:42:39 <str4d> Nouveau diagramme en ligne 20:43:55 <str4d> zzz : des trois du bas, lesquels faut‑il repousser ? Je pense que le verrouillage côté client est encore un problème ? 20:43:59 <zzz> J'aimerais voir beaucoup plus de planification et d'attention sur les choses non liées au code dans les prochains mois. Bien trop de choses sont soit assez désorganisées, soit n'avancent pas à un rythme qui soit un tant soit peu discipliné ou régulier 20:44:09 <str4d> (verrouillage des tunnels côté client) 20:44:18 <str4d> zzz : je suis d'accord. 20:44:34 <str4d> Cela sera, à mon avis, facilité en travaillant sur la page des tâches. 20:44:56 <str4d> Si nous pouvons expliquer les projets non liés au code d'une manière que les nouveaux puissent comprendre et réaliser, ça nous aide aussi. 20:44:59 <zzz> pas sûr à 100 % pour l'instant de ce qu'est cet élément de verrouillage client, mais je pense qu'il est toujours inachevé 20:45:08 <str4d> (De même pour les projets de code) 20:45:32 <zzz> ouaip 20:45:53 * str4d repousse aussi les améliorations du streaming 20:46:03 <str4d> Puis‑je retirer la détection de relecture de session SSU alors ? 20:46:04 <dg> Tu veux dire les problèmes de doublons ? 20:46:18 <dg> Le cas où on se retrouve avec des tunnels qui ne se désenregistrent pas d'I2PTunnel et n'autorisent pas de nouveaux tunnels ? Ce genre de chose ? 20:46:30 <zzz> str4d, je dois revenir vers toi à propos de la relecture SSU, pas sûr pour l'instant 20:46:45 <dg> Je voudrais voir moins de mort des tunnels plutôt que du débit 20:46:59 <str4d> dg : c'est peut‑être ça. Il y a aussi le problème séparé du démarrage d'I2PTunnel qui verrouille l'UI 20:47:29 <zzz> ajoute « mort des tunnels » là‑dedans comme nouvel élément, pourquoi pas 20:48:01 <dg> str4d : j'avais oublié ça ! 20:48:03 <str4d> k 20:48:39 <zzz> Je pense avoir quelque chose non activé en code pour ce truc de verrouillage, ça traîne depuis environ 18 mois, mais ce n'est toujours pas bon 20:48:40 <str4d> Ensuite : parcourez les idées ci‑dessus. Lesquelles doivent figurer sur *notre* feuille de route sur 6 mois (c.-à-d. lesquelles dois‑je ajouter au Gantt) ? 20:50:16 <psi> EinMByte : réunion en cours 20:50:21 <psi> (non) 20:51:51 <zzz> Je suggère de tout y mettre pour l'instant, puis on parlera des priorités plus tard, ou on laisse les dépendances du Gantt nous dire quoi faire ensuite ? 20:52:52 <str4d> mmk 20:53:04 * str4d extrait la liste ci‑dessus et la met en forme maintenant 20:53:08 <EinMByte> psi : oh super. 20:54:08 <psi> élément potentiel : faire un benchmark du débit des tunnels et des taux de perte de messages 20:54:26 <str4d> EinMByte : as‑tu des idées pour notre liste de tâches ? 20:55:15 <EinMByte> NTCP2, possiblement. Même si ce serait à long terme 20:56:39 <str4d> EinMByte : pour référence : http://trac.i2p2.i2p/wiki/Roadmaps/1.0 20:56:53 <EinMByte> merci 20:57:04 <EinMByte> (j'allais le demander) 21:00:23 <str4d> Voici la liste des idées de tout le monde : 21:00:24 <str4d> http://pastethis.i2p/show/K0fGRb2708ADbCTZ9u9K/ 21:00:25 <iRelay> Titre : Paste #K0fGRb2708ADbCTZ9u9K | LodgeIt! (at pastethis.i2p) 21:01:01 <str4d> Presque toutes peuvent être transformées en projets pour la page des tâches du site web. 21:01:36 <str4d> Sujet de discussion suivant : lesquelles parmi celles‑ci (et celles actuellement sur le Gantt) sont les plus importantes à faire pour nous dans les six prochains mois ? 21:02:48 <psi> les routes restreintes sont probablement l'élément le plus important, à mon avis 21:02:50 <EinMByte> à propos de Syndie, peut‑être : je travaillais sur ce plugin — pas le temps maintenant toutefois). Cela pourrait être une des choses qui peuvent (?) attirer plus d'attention sur Syndie. 21:03:20 <dg> str4d : la mort des tunnels est absente et je trouve que c'est assez important 21:03:37 <EinMByte> Si quelqu'un est intéressé par le développement de plugins Firefox / Icedove : vous savez quoi faire 21:03:37 <str4d> dg : c'est là (verrouillage de thread de tunnel) 21:03:41 <str4d> Je pensais que c'était ça 21:03:49 <dg> oh, désolé str4d, je parlais des connexions interrompues brutalement 21:03:54 <dg> ma faute 21:04:04 <str4d> Ah, k 21:04:55 <EinMByte> psi : je suis d'accord, les routes restreintes sont importantes. Mais je pense aussi qu'il faut réaliser que ça prendra pas mal de temps à implémenter 21:05:21 <EinMByte> (je ne sais pas combien du design / concept a déjà été fait) 21:05:35 <dg> Dans I2P : routes restreintes, problèmes ECDSA de RedHat, HS 2.0 de Tor, puis le reste. Autour d'I2P : base d'utilisateurs Vuze, GSoC, recherche, benchmark, puis le reste. 21:06:04 <dg> Je suis d'accord avec EinMByte… la refonte de la console du router est importante mais cela pourrait prendre une durée indéterminée. 21:07:15 <EinMByte> str4d : une chose de plus, peut‑être. Je connais des chercheurs qui ont développé un nouveau concept de DWSE (moteur de recherche web distribué), ils pourraient être intéressés pour le développer comme application I2P 21:07:42 <str4d> EinMByte : sympa ! 21:07:49 <EinMByte> Comme la plupart des DWSE ne fonctionnent pas vraiment bien en ce moment, ce serait très intéressant d'avoir ça, à mon avis 21:08:01 <zzz> non, par « mort des tunnels » je voulais dire les cassures de tunnel de 3 minutes, le test de datagrammes du gars de Vuze, etc. Distinct des problèmes de verrouillage local d'i2ptunnel. 21:08:07 <EinMByte> C'est aussi quelque chose que je considérerais implémenter 21:08:20 <dg> Je ne pensais pas précisément à 3 minutes mais ça en faisait partie. 21:08:34 <EinMByte> (avec de l'aide, espérons‑le) 21:09:03 <str4d> k, rechargez la page Gantt 21:10:34 <EinMByte> str4d : de toute façon, ne compte pas trop là‑dessus, ça dépend si les utilisateurs d'I2P sont réellement intéressés par quelque chose comme ça. 21:11:14 <EinMByte> Aussi, je ne suis pas sûr pour le truc GNS. En tout cas, ça ne devrait pas être très prioritaire. 21:11:56 <str4d> Nouveau paste des idées à jour : http://pastethis.i2p/show/1qxHbkWjD27N7SdzNJZL/ 21:11:57 <iRelay> Titre : Paste #1qxHbkWjD27N7SdzNJZL | LodgeIt! (at pastethis.i2p) 21:12:35 <zzz> je dirais que 4 grandes catégories sont de la plus haute importance : 1) poursuite de la migration crypto à court terme (carnet d'adresses, muiltidest, etc.) 2) planification/recherche crypto à plus long terme (DH, LS2, NTCP2) 3) tout ce qui est tests 4) tout ce qui n'est pas du code 21:13:48 <EinMByte> zzz : est‑ce par ordre d'importance ? 21:14:05 <str4d> Les problèmes ECDSA entrent dans la première catégorie ; Tor HS 2.0 entre dans la deuxième catégorie. 21:14:21 <zzz> non. importance à peu près égale 21:14:44 <str4d> Donc le seul élément non représenté dans ces catégories est les routes restreintes 21:15:28 <jenkins@kyirc> Démarrage de la build #556 pour le job i2pd (build précédente : SUCCÈS) 21:15:30 <jenkins@kyirc> Projet i2pd build #556 : SUCCÈS en 8,2 s : http://jenkins.killyourtv.i2p/job/i2pd/556/ 21:15:31 <jenkins@kyirc> * orignal : a éliminé NTCPServerConnection 21:15:32 <jenkins@kyirc> * orignal : a déplacé le code client NTCP vers Transports 21:16:34 <EinMByte> peut‑être que NTCP2 n'est pas *si* important 21:16:50 <zzz> et la raison pour laquelle je les ai groupées ainsi et je parle de priorité égale, c'est qu'il s'agit probablement de 4 groupes distincts de personnes pour ces 4 catégories, qui pourraient chacun faire avancer les choses 21:17:08 <EinMByte> ou, au moins, avant de pouvoir commencer correctement sur NTCP2, nous devons faire beaucoup de recherche, et aussi répondre à quelques questions très importantes 21:17:33 <jenkins@kyirc> Projet i2pd (Linux x86) build #33 : SUCCÈS en 1 min 47 s : http://jenkins.killyourtv.i2p/job/i2pd%20(Linux%20x86)/33/ 21:17:44 <EinMByte> zzz : en effet 21:17:51 <JekabsR> il est intéressant de voir que le réseau i2p a tendance à rassembler tous les routers rapides 21:17:58 <jenkins@kyirc> Démarrage de la build #33 pour le job i2pd (Linux x64) 21:18:03 <zzz> oui. « NTCP2 » est juste un raccourci pour un tas de choses qui peuvent ou non aboutir réellement à quelque chose appelé « NTCP2 » 21:18:34 <JekabsR> et ils ne préfèrent pas les routers lents 21:18:40 <EinMByte> Oui. En tout cas, si nous changeons les couches de transport, il est extrêmement important de ne pas faire d'erreurs, car cela casserait probablement complètement I2P. 21:19:19 <psi> JekabsR : les routers plus lents sont toujours utilisés, juste moins 21:19:43 <jenkins@kyirc> Projet i2pd (Linux x64) build #33 : SUCCÈS en 1 min 52 s : http://jenkins.killyourtv.i2p/job/i2pd%20(Linux%20x64)/33/ 21:20:05 <EinMByte> zzz : si le 2 c'est « recherche », alors tu as raison 21:20:33 <EinMByte> ça peut être fait simultanément 21:21:52 * str4d est en train de remanier le Gantt en ces quatre catégories (plus une catégorie Autre) 21:22:12 <JekabsR> mais il y a un problème — les destinations de type client obtiennent rarement des connexions de router rapides 21:22:40 <eche|on> non ? 21:22:46 <psi> JekabsR : pas totalement sûr que ce soit exact 21:23:46 <zzz> str4d, avons‑nous oublié Android, ou est‑ce une feuille de route séparée ? 21:23:59 <str4d> zzz : nous l'avons oublié 21:24:01 <eche|on> JekabsR : les routers en mode masqué ont bien quelques problèmes, mais les autres obtiennent des connexions rapides, car suffisamment de routers rapides sont disponibles et ont de la capacité libre 21:24:26 <str4d> Techniquement, I2P Android relève de la catégorie « dans I2P » 21:24:35 <psi> oh autre question de recherche : quelle capacité i2p a‑t‑il réellement en ce moment ? 21:25:14 <zzz> peut‑être qu'une 5e catégorie pour Android a plus de sens 21:25:46 <zzz> mais je ne suis pas bloqué sur les catégories. J'ai juste mentionné les 4 comme un moyen rapide de communiquer ce que je pense important 21:25:54 <JekabsR> parce qu'ils ont tendance à créer un petit nombre de connexions vraiment rapides et un grand nombre de connexions lentes 21:26:11 <dg> [source requise] 21:26:15 <JekabsR> mon router a commencé à abandonner les tunnels lents 21:26:24 <str4d> zzz : je pense que c'était une bonne idée 21:26:56 <str4d> Actualisez la page Gantt maintenant 21:27:07 <eche|on> JekabsR: https://geti2p.net/_static/pdf/I2P-PET-CON-2009.1.pdf 21:30:12 <eche|on> JekabsR : les tunnels ne sont abandonnés qu'à la fin de la durée de vie du tunnel et si les tunnels propres ont besoin de la capacité. 21:30:29 <str4d> Si vous actualisez http://trac.i2p2.i2p/wiki/Roadmaps/1.0 vous verrez maintenant les en‑têtes, chacun avec une barre de six mois. Cela donne une indication du temps disponible pour tout caser. 21:32:43 <str4d> Maintenant que nous avons quelques idées pour les six prochains mois, nous devons commencer à planifier les échéances. 21:33:18 <str4d> Et qui va s'occuper de quoi. 21:33:52 <JekabsR> ma console signale fréquemment qu'elle a trop de connexions entrantes et que des tunnels sont partiellement rejetés. Comment i2p décide‑t‑il lesquels rejeter ? 21:34:08 <dg> « trop de connexions entrantes » ? 21:34:21 <dg> JekabsR : une réunion est en cours, tu voudras peut‑être attendre qu'elle soit terminée 21:35:00 <str4d> J'aimerais aussi des volontaires pour aider à transformer la liste d'idées en une page de projets exploitable sur la page des tâches du site web 21:35:12 <JekabsR> Connexions NTCP : 425. Limite : 425. Timeout : 2 min. 21:35:30 <JekabsR> Connexions UDP : 1149. Limite : 1275. Timeout : 4 min. 21:36:14 <JekabsR> les limites sont atteintes 21:37:42 <JekabsR> le router utilise 80 % de la puissance CPU 21:38:23 <str4d> Quelqu'un ? 21:39:36 <kytv> JekabsR : 1) réunion en cours, tu voudras peut‑être attendre ; 2) regarde http://127.0.0.1:7657/peers#help 21:41:16 <JekabsR> kytv : je vais regarder 21:41:44 <zzz> str4d, je pense que tu as perdu tout le monde après 1 h 45. Peut‑être qu'on peut déclarer victoire pour l'instant et on fera plus de progrès une autre fois ? 21:41:45 <str4d> Essayons quelques questions plus spécifiques. 21:41:52 <str4d> Ou ça./ 21:41:55 <JekabsR> 330,0 / 342,4 KBps ma charge actuelle 21:42:06 <str4d> Oui, nous avons définitivement bien progressé. 21:42:30 <JekabsR> et des envois torrent à 2‑5 kb de vitesse :( 21:44:17 <str4d> Merci pour les discussions, tout le monde ! 21:44:20 * str4d warms up the baffer 21:44:20 * str4d ***bafs the meeting closed