Réunion des développeurs I2P - 07 avril 2020

22:04:29 <eyedeekay> Salut tout le monde, qui est là ? 22:04:40 <eche|on> coucou :-=) 22:04:46 <zlatinb> salut 22:04:48 <zzz> présent 22:06:18 <eyedeekay> Très bien, premier sujet, 0.9.46, zzz à toi 22:06:52 <zzz> je finalise environ deux mois de travail sur ratchet (proposal 144) 22:07:16 <zzz> Je suis à peu près à l'achèvement de "phase 2", où c'est complet sur le plan fonctionnel 22:07:32 <zzz> et je passerai à davantage de correction de bugs et de tests 22:07:51 <zzz> donc la 46 sera celle où davantage de personnes pourront le tester, et peut-être que nous l'activerons par défaut en 47 22:08:23 <zzz> par la suite je porterai mon attention sur d'autres corrections de bugs et sujets, comme le streaming (en travaillant avec zlatinb) 22:08:56 <zzz> EOT pour moi, donc peut-être que d'autres voudraient dire sur quoi ils travaillent pour la 46 22:09:01 <eche|on> Je viens de faire la mise à niveau vers -5 il y a 2 jours, ça fonctionne toujours bien, le patch de tunnel round-robin est inclus, aucun gros changement constaté pour l'instant 22:09:56 <zlatinb> J'ai relu, re-relu les RFC TCP et j'ai remarqué de nombreuses divergences dans nos implémentations du streaming et de ssu. Donc je les ai réécrites. Les tickets sont sur trac 22:10:24 <eche|on> lecture et vérifications très, très détaillées, zlatinb 22:11:34 <eyedeekay> J'ai commencé à travailler sur des révisions de l'UI i2ptunnel pour réduire la quantité d'informations inutiles que nous présentons aux nouveaux utilisateurs, ainsi que sur le mécanisme de rotation périodique des clés pour les i2ptunnels 22:12:19 <eyedeekay> Beaucoup de out-of-tree (en dehors de l'arbre des sources) pour moi aussi, je veux remplacer le paquet de profil Firefox par quelque chose qui fonctionne également sur des plateformes non-Windows, ça prend plutôt bien forme. 22:12:32 <eyedeekay> C'est tout pour tout le monde ? 22:12:46 <eche|on> on dirait bien 22:12:49 <eyedeekay> Aussi, quelqu'un a des questions ? 22:13:47 <eyedeekay> Jusqu'ici tout va bien. La suite, c'est divers 22:14:37 <eyedeekay> Re: migration vers git, la décision a été prise de migrer i2p.i2p *après* la prochaine version et non avant. D'autres dépôts peuvent être migrés plus tôt au cas par cas. 22:15:06 <eche|on> bien 22:15:20 <eyedeekay> L'inscription sur git.idk.i2p est ouverte, mais elle nécessite une approbation manuelle d'un admin. Nous sommes réactifs à ce sujet, mais n'hésitez pas à me pinguer si vous êtes pressé. 22:16:46 <eyedeekay> L'approche privilégiée pour l'instant est d'utiliser git via SSH, sauf pour le clonage initial, que vous pouvez effectuer en téléchargeant le bundle git avec snark. 22:16:50 <eyedeekay> EOT 22:17:18 <eyedeekay> Des questions pour moi re: migration vers git ? 22:17:31 <eche|on> des progrès sur l'inclusion des tickets trac ? 22:17:49 <eyedeekay> Je n'ai pas eu le temps de travailler sur tracboat, donc non, pas encore. 22:17:58 <eche|on> ok 22:18:41 <zlatinb> J'ai 2 questions concernant la migration: 22:18:41 <zlatinb> 1. Y a-t-il un moyen de changer le délai d'expiration de lecture réseau dans ssh pendant le clonage git. Si oui, l'augmenter à environ 5 minutes améliorera les chances de réussite 22:18:41 <zlatinb> 2. Comme trac n'a pas été très fiable, est-ce acceptable de commencer à ouvrir ou dupliquer des tickets vers GitLab. Seront-ils examinés ? 22:19:15 <eyedeekay> 1 : J'ai investigué cela, cela ne semble pas possible mais je ne peux pas encore répondre de façon définitive. 22:19:20 <zzz> re: 2) pas par moi, si tu parles de i2p.i2p 22:19:25 <eche|on> pour 2 : tracboat serait la solution script pour inclure tous les tickets trac dans git 22:19:54 <zzz> question liée : quel est le plan pour améliorer la disponibilité constamment médiocre des services exposés au public gérés par meeh ? 22:20:02 <eche|on> oh, désolé, pour la copie/la migration des tickets existants, les nouveaux pourraient poser problème 22:20:18 <zlatinb> les numéros de ticket seront-ils préservés ? Si oui, qu'arrive-t-il aux tickets déjà ouverts sur GL, faut-il les supprimer ? 22:21:21 <eyedeekay> Les numéros de ticket devraient être préservés si j'arrive à faire fonctionner la migration ; les tickets dupliqués devront être supprimés manuellement lorsque l'un ou l'autre ticket sera fermé. 22:22:08 <zlatinb> et si, pour quelque raison, la migration ne peut pas fonctionner, quel est le plan de secours ? 22:23:12 <zzz> nous n'avons pas encore convenu d'une migration de trac du tout ; je suppose que tout cela n'est que des expérimentations. Je propose que la migration de trac soit reportée jusqu'à ce que toutes les branches mtn (y compris celles qui ne sont pas du tout sur GH encore) soient migrées vers git 22:23:33 <zzz> peut-être sept. au plus tôt 22:23:42 <eche|on> la réponse à cela sera corrélée à la question de zzz, actuellement il n'y a pas de plan fixé. Mon idée serait de garder trac en service avec les anciens tickets 22:24:02 <eyedeekay> Je n'ai pas de moyen de réparer trac, migrer ses tickets est la seule chose que je puisse faire personnellement. Si je ne peux pas les migrer avec tracboat, je dois le faire moi-même. Je connais le côté gitlab, il faudra simplement que j'apprenne le côté trac. Je sais que gitlab semble être un remplacement évident et séduisant pour trac, mais c'est un blocage important. 22:24:03 <zlatinb> ok, et tant qu'aucune migration n'a été tentée, devons-nous continuer à utiliser trac ? 22:24:41 <eyedeekay> Oui 22:24:51 <eche|on> côté tickets : merci d'utiliser trac tant que la migration des tickets n'a pas été effectuée 22:24:53 <zzz> alors qui est chargé de réparer les services de meeh ? ou bien avons-nous abandonné et travaillons-nous maintenant à remplacer tout ce qu'il gère ? Si c'est ce que nous faisons, soyons explicites 22:25:56 <eche|on> meeh est responsable de ses services. trac devrait être remplacé par git. 22:26:31 <zzz> ce qui ne règle pas les problèmes systémiques des autres services tels que le dépôt deb et l'outproxy 22:26:31 <eche|on> le dépôt Debian est un point ouvert actuellement, j'en ai fait un miroir, mais j'ai actuellement besoin de plus de temps pour voir comment le configurer comme prévu 22:27:32 <eche|on> à l'outproxy je ne toucherai pas du tout 22:27:50 <eyedeekay> Je suis heureux d'aider à remplacer le dépôt deb de meeh, mais je ne peux rien faire pour l'outproxy. 22:29:19 <eche|on> meeh nous a souvent dit que le problème vient surtout de l'ancien système sur de vieilles IP qu'il utilise, avec welterde changeant le DNS, cela a changé aujourd'hui 22:29:33 <zzz> Je suppose que la migration des tickets pour une branche particulière X n'aurait lieu qu'après notre passage de mtn à git pour X 22:29:35 <eche|on> mais pour l'instant aucune idée 22:30:55 <eyedeekay> zzz Oui 22:31:08 <eyedeekay> Re: migration des tickets 22:31:27 <eyedeekay> Ainsi, nous n'embrouillerions pas les gens sur l'endroit où les problèmes sont discutés. 22:32:21 <eyedeekay> Autre chose ? 22:34:22 <eyedeekay> timeout: 60s 22:36:22 <eyedeekay> **Bafs** OK merci à tous d'être venus