Réunion des développeurs I2P - 06 février 2007

15:02 <jrandom> 0) salut 15:02 <jrandom> 1) État du réseau 15:02 <jrandom> 2) État du développement de Syndie 15:02 <jrandom> 3) Gagnants du concours de récolte de bogues de janvier ! 15:02 <jrandom> 4) ??? 15:02 <jrandom> 0) salut 15:02 * jrandom fait coucou 15:02 <jrandom> les notes d'état hebdomadaires sont publiées sur http://dev.i2p.net/pipermail/i2p/2007-February/001333.html 15:03 <jrandom> on passe à 1) État du réseau 15:03 <jrandom> Je n'ai pas grand-chose à ajouter ici (comme vous pouvez sans doute le deviner ;) 15:03 <jrandom> quelqu'un a quelque chose à soulever concernant l'état du réseau ? 15:04 <+void> c'était mieux avant, d'une certaine manière... 15:04 <+void> mais pas mal 15:05 <jrandom> c'est étrange, depuis une semaine environ nos taux de build sont repartis à la hausse, d'après stats.i2p 15:05 <tethrage> y a-t-il une tendance à long terme ? 15:06 <tethrage> (dans l'évolution du taux de build) 15:07 <jrandom> autant que je puisse voir, les tendances ont été associées à la capacité de routers puissants, mais cela ne donne qu'une vision très limitée du réseau (puisque je ne sais à peu près que ce qui est public) 15:07 <tethrage> je vois 15:08 <tethrage> y a-t-il des informations qui pourraient aider ? 15:08 <tethrage> venant de routers ordinaires, je veux dire 15:08 <jrandom> pas vraiment, de mon point de vue 15:09 <tethrage> je vois 15:09 <jrandom> (en gros, nous devons juste implémenter quelques changements de code avant d'aller plus loin) 15:10 <tethrage> je vois 15:11 <jrandom> ok, quelqu'un a autre chose pour 1) État du réseau ? 15:12 <jrandom> sinon, passons à 2) État du développement de Syndie 15:14 <jrandom> beaucoup de choses en cours ici, comme vous pouvez le lire 15:14 <+fox> <mk> mineur : peut-être changer 'signed by' en 'authorization' ? Je suis un peu nerveux à propos des lignes floues entre forums, identités, signatures, etc. 15:14 <+fox> <mk> -d 15:15 <jrandom> ah, c'est une bonne idée 15:16 <+void> mk : un forum est une identité :) 15:16 <+void> et vice versa 15:17 <jrandom> ouais, même si on ne veut pas trop embrouiller les gens en rendant visible cette étrange dualité 15:17 <+fox> <mk> je sais, mais c'est encore flou. Je comprends très bien maintenant, mais je crains que les nouveaux utilisateurs ne soient déroutés par le manque de différenciation 15:18 <+void> ah 15:18 <jrandom> exact - les gens perçoivent les forums différemment des identités, il faut donc s'assurer que nous nous comportons comme attendu 15:18 <+fox> <mk> autre chose qui vaudrait la peine d'être implémentée dans la gestion des forums ou des identités : l'instruction explicite 'post to this forum only under author x authorization y', ce qui éliminerait les confusions. Tu n'aurais même pas besoin d'une liste déroulante sur les nouveaux messages 15:19 <+fox> <mk> (une liste déroulante pour les clés) 15:20 <+void> je préférerais une liste déroulante d'identité globale visible en permanence 15:20 <+fox> <mk> genre, sous quelle identité tu postes ? 15:20 <jrandom> hmm 15:21 <+fox> <mk> peut-être, mais je ne pense pas qu'il y ait vraiment beaucoup de différence entre l'avoir toujours en haut et ne l'afficher que lors des publications 15:22 <jrandom> ok, avant d'aller trop loin, il existe un canal parallèle non traité actuellement dans syndie qui peut lier plusieurs identités 15:22 <+void> bien que ton identité ne soit utilisée nulle part ailleurs que pour publier 15:22 <+fox> <mk> qu'est-ce que tu veux dire ? 15:23 <+void> pousser de nouveaux messages ? 15:23 <jrandom> si tu dois avoir des identités totalement non liables entre elles, tu dois exécuter des instances de syndie séparées - tu peux les synchroniser l'une avec l'autre, et n'en utiliser qu'une pour pull/push vers les autres archives, mais l'archive locale contient des informations auxquelles seules certaines identités ont accès 15:23 <+fox> <mk> (je suis d'accord pour dire qu'on devrait probablement garder les grosses discussions pour le forum dev, mais c'est sympa d'avoir plusieurs personnes qui en parlent en même temps) 15:24 <+void> c'est vrai 15:24 <jrandom> cependant, toutes les identités sur l'archive locale peuvent accéder à ces informations, et si elles agissent en conséquence (publier avec ces clés, etc.), elles divulgueraient la possibilité de les relier 15:25 <jrandom> peut-être pouvons-nous trouver un moyen d'accomplir tout cela de manière transparente via l'interface graphique (GUI) 15:26 <jrandom> (faire tourner plusieurs archives localement sans avoir à lancer syndie deux fois) 15:26 <+fox> <mk> il y a beaucoup d'autres points — comme marquer certaines archives comme exclusives entre elles — qui pourraient aider à l'anonymat. Nous devrions essayer de définir tous ces scénarios et trouver un moyen de les gérer de façon très utilisable 15:27 <tethrage> syndie ne vise pas l'anonymat, seulement la sécurité 15:27 <tethrage> c'est bien la couche de transport sur laquelle il fonctionne qui devrait gérer ça, non ? :/ 15:27 <jrandom> syndie vise l'anonymat 15:27 <tethrage> (corrigez-moi si je me trompe) 15:28 <jrandom> la couche de transport ne gère qu'une petite partie de l'anonymat — nous devons nous occuper du reste 15:28 <jrandom> s/small// 15:28 <tethrage> vraiment ? :/ 15:28 <+fox> <mk> oui, c'est ça. syndie gère surtout les fuites d'information 15:29 <jadeSerpent> anonymat de l'adresse IP vs anonymat de l'identité 15:29 <tethrage> je vois. Je pensais que tu avais dit il y a quelque temps que syndie était conçu comme une appli sécurisée qui employait de la crypto mais n'était pas strictement anonyme ? 15:29 <tethrage> (pas de la même manière qu'i2p etc., de toute façon) 15:29 <+fox> <mk> la sécurité de l'information est assurée par la redondance des archives 15:29 <jrandom> mk : je ne suis pas sûr de ce que tu entends par marquer les archives, mais j'adorerais un post sur le forum dev de syndie pour en discuter :) 15:29 <jrandom> tethra : syndie peut être utilisé pour des choses qui ne nécessitent pas d'anonymat 15:30 <jrandom> mais syndie doit être utilisable pour des choses qui l'exigent 15:30 <jrandom> (sinon, il n'y aurait aucune raison de l'implémenter dans le cadre du projet i2p) 15:31 <tethrage> ouais 15:31 <+void> jrandom : bon, pour être juste, il y aurait quand même un intérêt si syndie fournissait l'anonymat en utilisant i2p 15:31 <+void> mais peu importe 15:31 <+void> c 15:31 <tethrage> à part se protéger contre les fuites d'information et le code douteux, qu'est-ce que syndie fait pour garder les gens anonymes ? :/ 15:32 <tethrage> sauf indication contraire, on accède directement aux archives, non ? 15:32 <+fox> <mk> tethrage, des fuites d'information de toutes sortes. Si tu veux, on peut entrer un peu plus dans le détail tout à l'heure 15:33 <jrandom> tethra : par exemple, quelqu'un qui accède à un eepsite avec JavaScript activé 15:33 <jadeSerpent> tethrage : il n'y a aucune garantie que les messages que tu pousses vers une archive viennent de toi, quelqu'un a peut-être poussé ces messages vers ton archive 15:34 <tethrage> jrandom : ouais, le JS peut révéler des infos et tout. Mais c'est plutôt une question de sécurité que d'anonymat si tu n'utilises pas un réseau anonyme d'une manière ou d'une autre, non ? 15:34 <tethrage> cela dit, je suppose que je chipote sur les mots, donc je vais m'arrêter 15:34 <tethrage> :/ 15:34 <jadeSerpent> je soutiendrais que faire tourner ta propre archive publiquement accessible augmente ton anonymat à cet égard 15:34 <+fox> <mk> jrandom, je ferai ce post. Aussi, j'ai bricolé un design pour un navigateur (je n'aime pas ouvrir de nouveaux onglets pour les nouvelles sections), donc je vais essayer d'en faire un prototype et peut-être poster quelques gribouillis sur dev 15:34 <jrandom> la « sécurité contre les fuites d'information » est au cœur de l'anonymat — contrôler qui connaît des faits sur ton identité 15:35 <jrandom> ah, énorme mk, merci ! 15:35 <jrandom> jadeSerpent : certainement 15:35 <tethrage> je vois 15:35 <tethrage> message reçu 15:36 <jrandom> mk : s'il y a de meilleures façons de présenter l'UI de syndie, je suis 100 % pour (seule une toute petite partie du code est liée à ces composants basés sur des onglets) 15:36 <jrandom> et après tout nous sommes en alpha 15:38 <+void> jrandom : je suppose que ce n'est pas difficile de transformer l'interface à onglets en interface à fenêtres ? 15:38 <+fox> <mk> oui. Et si certains préfèrent l'approche tout-en-onglets, aucun problème pour l'utiliser 15:38 <+fox> <mk> (en plus de l'onglet du navigateur) 15:39 <jadeSerpent> pitié pas de MDI, je suggère quelque chose à mi-chemin entre les onglets et le MDI, les « perspectives » d'Eclipse 15:39 <+void> le MDI, c'est mauvais, je suis d'accord 15:40 <jadeSerpent> NetBeans a quelque chose comme ça aussi, je ne me souviens plus du nom 15:40 <jadeSerpent> des vues ou des postes de travail ou quelque chose du genre, ça fait un moment 15:41 <jrandom> des croquis .webp sont appréciés :) 15:41 * jrandom est parti sur le style tout-en-onglets parce que tout le monde adore Firefox (/etc) 15:42 <jadeSerpent> quand j'aurai fini les icônes je pourrais bidouiller un peu ça 15:42 <+fox> <mk> le cycle de sortie de 2 semaines est une bonne chose. J'aime voir ces objectifs explicites, mais j'aimerais aussi voir des objectifs plus « souples » listés — doc pour dev puis pour utilisateurs, diagrammes, etc. 15:42 <jrandom> génial 15:42 <jadeSerpent> les onglets sont très bien pour l'instant imo, c'est utilisable 15:42 <jrandom> mk : http://syndie.i2p.net/roadmap.html ? 15:42 <jrandom> (même s'il n'y a pas de dates sur la feuille de route) 15:43 <+fox> <hottuna> sympa :=) ... je viens de poster à ce sujet dans les tâches en attente :P 15:44 <+fox> <mk> oui, mais je parle d'objectifs plus petits. « documenter les interactions générales entre les classes dans syndie.gui », ou « rédiger une doc concernant le bannissement » etc. 15:44 <jrandom> ah, bon point 15:45 <jrandom> je voulais justement recenser à nouveau toutes les tâches à faire de bas/moyen/haut niveau 15:45 * jrandom ajoute ça à la liste des tâches 15:47 <jrandom> ok, quelqu'un a autre chose à aborder pour 2) État du développement de Syndie ? 15:48 <jrandom> (bien sûr, on a toujours les forums dev dans syndie, mais IRC est utile pour des échanges rapides) 15:49 <jrandom> sinon, passons à 3) Gagnants du concours de récolte de bogues de janvier ! 15:50 <jrandom> félicitations à Darn, voyde, mk et Anonymous, et merci à tous ceux qui ont aidé 15:51 * jrandom réalise que le concours était à l'origine pour les 3 premiers, mais le compte était si serré 15:51 <jrandom> il y a un nouveau concours ce mois-ci aussi, mêmes règles qu'avant 15:51 <jadeSerpent> comment sais-tu qu'« Anonymous » n'était qu'une seule personne ? ;) 15:51 <+fox> <mk> 225 (selon mon compte) bogues au total — impressionnant 15:51 <+void> :) 15:52 <+fox> <mk> jade, la clé, je pense :) 15:52 <jrandom> jadeSerpent: urn:syndie:meta:d7:channel44:Ffn4RhCunO6gwMfAYfOoPY7FGwPNDy65dS4DyuyorME=e :) 15:53 <jrandom> cela pourrait être cinq personnes partageant cette clé toutefois 15:53 <jrandom> mais alors ils devront se partager les 50 $USD ;) 15:53 <jrandom> (le premier avec la clé privée qui me signe un message en spécifiant sur quel compte egold l'envoyer gagne ;) 15:53 <jadeSerpent> à moins que l'un tue les autres 15:54 <jadeSerpent> mais ce genre de chose n'arriverait qu'en Roumanie 15:54 <tethrage> et en Russie 15:54 <jrandom> (et la Grande-Bretagne, et l'Australie, et...) 15:55 <+fox> <mk> 50 USD, c'est beaucoup d'argent... 15:55 <jadeSerpent> en Russie ils seraient tous tués, et le propriétaire prendrait l'argent et le passerait à la mafia comme racket de protection 15:55 <tethrage> pas en GBP ;p 15:55 <+fox> <mk> je sais, *moi* je tuerais pour ça 15:55 <tethrage> j'imagine que demander d'où tu viens n'obtiendrait pas de réponse, mk ? 15:55 <tethrage> :/ 15:56 <+fox> <dw_g> ok, je le prends ;) 15:56 <+fox> <mk> de Russie à l'origine :D maintenant au Canada 15:56 <jadeSerpent> 225 bogues, c'est impressionnant, combien ont été résolus ? 15:56 <tethrage> ice. 15:56 <tethrage> +n 15:57 <jrandom> jadeSerpent : je l'estimerais à peut-être 75-80 % traités 15:57 <jadeSerpent> bien 15:58 <jrandom> (avec peut-être 5-10 % supplémentaires invalid/wontfix) 15:58 <jrandom> mais en fait, c'est l'une des tâches de plus haut niveau — avoir une véritable interface de gestion pour le suivi des bogues 15:58 * jadeSerpent recommande Trac 15:58 <jrandom> (ça m'a pris un moment de parcourir tous les messages et de les compter manuellement) 15:58 <+fox> <mk> externe à syndie ? 15:59 <jrandom> hmm, avec un système d'export syndie-->track ? 15:59 <jrandom> s/ck// 15:59 <+fox> <mk> un joli projet serait de brancher syndie sur un gestionnaire de bogues 15:59 <jadeSerpent> ouais 15:59 * jrandom parie que quelques requêtes SQL et inserts feraient l'affaire 16:00 <jrandom> ce serait tout de même assez utile, au moins dans une perspective Trac en lecture seule 16:00 <+void> mais synchroniser les mises à jour faites dans Trac de retour vers syndie risque d'être délicat, je pense 16:00 <jrandom> une intégration sur tout le cycle est très difficile 16:00 <jrandom> oui 16:00 <+fox> <mk> à un moment, il vaudrait peut-être la peine d'envisager un système de type « révision » 16:00 <jrandom> mais pouvoir interroger et explorer dans Trac, et générer des rapports, etc. 16:01 <+fox> <mk> où les messages supplantent les plus anciens 16:01 <jrandom> ah, oui il y a des hooks pour ça, mais les en-têtes Overwrite* ne sont pas actuellement pris en compte 16:02 <jrandom> ce ne serait pas trop difficile toutefois, juste un interrupteur dans l'UI pour naviguer vers les révisions précédentes du même message, plus quelques lignes de code pour vérifier que le message est autorisé à écraser l'ancien 16:03 <jadeSerpent> je comprends le souhait d'utiliser syndie lui-même pour le signalement des bogues, mais sa conception n'inclut pas le suivi des tickets, et il sera toujours sous-optimal pour cette tâche ; imo vous devriez utiliser un vrai gestionnaire de tickets 16:04 <+fox> <mk> vu le nombre de bogues signalés, je suis d'accord avec jadeSerpent 16:05 <jrandom> mais d'un autre côté, combien de bogues ont été découverts par ceux qui utilisaient syndie pour déclarer les bogues ? 16:05 * jrandom n'est pas totalement opposé à Trac ou à un autre système de suivi des bogues 16:05 <jadeSerpent> ce genre de bogues sera de toute façon découvert 16:05 <+void> eh bien, les sévérités, composants, versions et la fermeture/ouverture/réouverture de bogues peuvent être gérés avec des tags syndie 16:05 <jrandom> oui 16:06 <+void> (et la plupart le sont déjà) 16:06 <jadeSerpent> comme l'autre jour quand ça a gelé chez quelqu'un qui postait un rapport de bogue, ça aurait gelé chez lui s'il postait sur n'importe quel sujet, le fait que ce soit un rapport de bogue n'y change rien 16:06 <jrandom> si nous pouvons alimenter un vrai gestionnaire de tickets via des messages pseudonymes (et authentiques), ce serait super 16:06 * jrandom a aussi reçu quelques rapports de bogue privés, contenant des informations sensibles — ceux-ci sont protégés par le chiffrement de syndie 16:07 <+fox> <mk> eh bien, pourquoi ne pas garder les deux ? 16:08 <jadeSerpent> je suis d'accord qu'il n'existe toutefois aucun gestionnaire de tickets conçu avec l'anonymat ou une confidentialité plus que triviale à l'esprit 16:09 <+fox> <mk> ce serait bien que syndie dispose de ce genre de gestionnaire de bogues, mais l'anonymat n'est pas un gros problème pour la plupart des rapports de bogue 16:10 <jadeSerpent> peut-être qu'on pourrait modifier Trac pour utiliser les fonctionnalités de syndie là-dessus 16:10 <+fox> <mk> jade, ce serait difficile. Les navigateurs n'implémentent pas la signature 16:12 <jrandom> hmm. ce que nous avons est à l'origine basé sur : http://syndiemedia.i2p.net:8000/blog.jsp?blog=ovpBy2mpO1CQ7deYhQ1cDGAwI6pQzLbWOm1Sdd0W06c=&entry=ovpBy2mpO1CQ7deYhQ1cDGAwI6pQzLbWOm1Sdd0W06c=/1132012800003 16:12 <jrandom> plus http://dev.i2p.net/~jrandom/bugsp1.txt et http://dev.i2p.net/~jrandom/bugsp2.txt 16:13 <jrandom> je suis d'accord que nous avons besoin de mieux que ce que nous avons pour suivre ces tickets, et je suis ouvert à ce qui nous fera le mieux avancer 16:13 <jrandom> mais j'aimerais que ce soit minimal si possible, parce que nous construisons syndie, pas un gestionnaire de bogues :) 16:14 <jadeSerpent> ouais, eh bien tu sembles t'en sortir pour l'instant sans ça ;) 16:14 <jrandom> mais je suis sûr que certains passeront entre les mailles du filet, et que d'autres auront plus de mal à trouver ce qui est connu/etc., et à contribuer des correctifs 16:15 <+fox> <mk> nous n'avons probablement même pas besoin de l'implémenter via syndie. C'est utile jusqu'à un certain point, mais 200+ bogues, c'est vraiment beaucoup. Nous devrions choisir un tracker et le rendre disponible sur le Web et via i2p 16:16 <+fox> <mk> fournir un lien vers celui-ci en haut de l'écran « signaler un bogue » de syndie, et de cette façon nous avons les deux options. Implémenter un gestionnaire de bogues dans syndie n'est pas quelque chose sur quoi utiliser des ressources maintenant 16:17 * jrandom aime avoir le suivi des bogues intégré (ainsi les gens n'ont pas besoin de créer des comptes de suivi, d'utiliser de fausses adresses e-mail, etc.), mais je suis ouvert aux propositions sur la solution à utiliser 16:17 <+fox> <mk> je pense qu'on devrait garder ça, mais avoir aussi ce gestionnaire de bogues 16:18 <jadeSerpent> un accès en lecture seule pour le court terme serait bien 16:18 <jadeSerpent> je préfère une interface de recherche plus orientée bogues 16:18 <jrandom> ça ne serait pas si mal, on pourrait peut-être écrire un export unidirectionnel syndie-->issue tracker sans trop de difficultés aussi, of r ceux qui ne peuvent pas ne veulent pas utiliser celui basé sur le web 16:19 <jrandom> s/of r/for/ 16:19 <+fox> <mk> la soumission intégrée de bogues, c'est très bien, mais nous ne devrions pas utiliser l'archive syndie pour suivre plus de 200 bogues 16:20 <jrandom> même si c'est excellent pour tester nos capacités de recherche :) [ouais, ok, je suis convaincu] 16:20 <jrandom> donc, une voix pour Trac. D'autres votes ? Merci de poster sur le forum dev de syndie, avec la justification, bien sûr 16:21 <jadeSerpent> deux voix pour Trac, à moins que tu aies déjà compté la mienne ;) 16:21 <jrandom> ouais, c'est ce que je comptais ;) 16:21 <+fox> <mk> quelles sont les options ? Je ne connais rien aux trackers 16:21 <jadeSerpent> j'espérais que c'était ton propre vote, mais ok 16:22 <jadeSerpent> j'ai travaillé avec Trac, excellent support tiers 16:22 <jadeSerpent> Bugzilla je dirais bof 16:22 <jrandom> au fait, si quelqu'un est très familier d'un gestionnaire de tickets, ce serait utile pour pondre un export syndie-->issue tracker 16:22 <jrandom> ouais, Bugzilla est une bête 16:22 <jadeSerpent> JIRA est bien aussi, comme Trac 16:23 <+void> Trac est probablement familier à beaucoup de gens aussi 16:23 <jrandom> ouais, et des gens sympas aussi (ils ont donné une licence à i2p, même si nous ne l'avons pas encore utilisée) 16:23 <jadeSerpent> vous avez une licence JIRA ? 16:23 <jrandom> ouais, JIRA et FishEye 16:24 <jadeSerpent> cool, autant essayer 16:24 <jadeSerpent> au fait, le plugin Mylar d'Eclipse s'intègre entièrement à Bugzilla, Trac et JIRA 16:24 <jadeSerpent> grandes louanges pour son interface 16:25 <jrandom> maudite guerre NetBeans/Eclipse 16:25 <bar> (les bogues sont signalés automatiquement quand ils sont créés ? ;) 16:25 <tethrage> (haha) 16:26 <+fox> <mk> hah, sympa 16:26 <jadeSerpent> jrandom : le support NetBeans est sur la feuille de route de Mylar iirc 16:26 <jrandom> cool 16:26 <+fox> <modulus> c'est ce qui arrive à ceux qui supportent fanatiquement Sun :-) 16:27 * jrandom bombarde modulus de javabeans 16:27 <jadeSerpent> même si Mylar est officiellement sous l'égide de la fondation Eclipse 16:27 <+fox> * mk ne trouve pas de site Trac en production 16:27 <+fox> <modulus> http://trac.wordpress.org/ 16:27 <jrandom> mk : http://feedspace.i2p/ pour le moment 16:28 <+void> http://trac.edgewall.com/ 16:29 * jrandom ne veut pas passer beaucoup de temps à évaluer plein de systèmes différents, donc si quelqu'un veut défendre un système spécifique, merci de le faire sur le forum dev de syndie 16:29 <jadeSerpent> http://overlays.gentoo.org/proj/alt/wiki 16:29 <+void> (^ meta-trac officiel) 16:29 <+fox> <mk> ouais, ça m'est égal 16:30 * jrandom va supposer que c'est tout pour * 3) Gagnants du concours de récolte de bogues de janvier ! et nous passer à 4) ??? 16:30 <jrandom> quelqu'un a autre chose pour la réunion ? 16:30 <+fox> <mk> « le meilleur » est surcoté. Celui qui a le plus d'expérience avec ces trucs devrait probablement tirer à pile ou face 16:32 * jrandom ne cherche pas vraiment un système de planification de projet / planification de sorties, ni un navigateur de code source (un wiki gratuit ne fait pas de mal, mais on a aussi ugha.i2p) 16:32 <jrandom> le suivi des tickets est la seule fonctionnalité qui m'importe pour ça 16:37 <jrandom> ok, s'il n'y a rien d'autre pour la réunion... 16:37 * jrandom conclut 16:37 * void tend à jrandom le baffer 16:37 * jrandom *baf* clôt la réunion