I2P Entwicklertreffen - 06. Februar 2007

15:02 <jrandom> 0) hi 15:02 <jrandom> 1) Netzstatus 15:02 <jrandom> 2) Syndie Entwicklungsstatus 15:02 <jrandom> 3) Gewinner des Januar-Bug-Ernte-Wettbewerbs! 15:02 <jrandom> 4) ??? 15:02 <jrandom> 0) hi 15:02 * jrandom winkt 15:02 <jrandom> Wöchentliche Statusnotizen veröffentlicht unter http://dev.i2p.net/pipermail/i2p/2007-February/001333.html 15:03 <jrandom> weiter zu 1) Netzstatus 15:03 <jrandom> Ich habe hier nicht wirklich viel hinzuzufügen (wie man wohl merkt ;) 15:03 <jrandom> Hat jemand etwas zum Netzwerkstatus einzubringen? 15:04 <+void> war früher irgendwie besser... 15:04 <+void> aber nicht schlecht 15:05 <jrandom> Seltsam, in der letzten Woche oder so sind unsere Buildraten laut stats.i2p wieder gestiegen 15:05 <tethrage> gibt es ein langfristiges Muster? 15:06 <tethrage> (bei der Änderung der Buildrate) 15:07 <jrandom> soweit ich sehe standen die Muster im Zusammenhang mit der Kapazität leistungsstarker routers, aber das ist nur eine sehr eingeschränkte Sicht auf das Netzwerk (da ich im Wesentlichen nur das kenne, was öffentlich verfügbar ist) 15:07 <tethrage> verstehe 15:08 <tethrage> gibt es Informationen, die bereitgestellt werden könnten, um zu helfen? 15:08 <tethrage> von normalen routers, meine ich 15:08 <jrandom> nicht wirklich, aus meiner Sicht 15:09 <tethrage> verstehe 15:09 <jrandom> (im Grunde müssen wir nur ein paar Code-Änderungen implementieren, bevor wir weitergehen) 15:10 <tethrage> verstehe 15:11 <jrandom> ok, hat jemand noch etwas zu 1) Netzstatus? 15:12 <jrandom> wenn nicht, springen wir weiter zu 2) Syndie Entwicklungsstatus 15:14 <jrandom> hier passiert viel, wie ihr lesen könnt 15:14 <+fox> <mk> klein: vielleicht 'signed by' in 'authorization' ändern? Ich bin etwas nervös wegen der verschwommenen Grenzen zwischen Foren, Identitäten, Signaturen und so weiter 15:14 <+fox> <mk> -d 15:15 <jrandom> ah, das ist eine gute Idee 15:16 <+void> mk: Ein Forum ist eine Identität :) 15:16 <+void> und umgekehrt 15:17 <jrandom> Ja, aber wir wollen die Leute nicht zu sehr verwirren, indem wir diese seltsame Dualität sichtbar machen 15:17 <+fox> <mk> Ist mir bewusst, aber es ist trotzdem unscharf. Ich verstehe es inzwischen gut, aber ich sorge mich, dass neue Nutzer durch die fehlende Differenzierung verwirrt werden könnten 15:18 <+void> ah 15:18 <jrandom> Genau – Leute denken über Foren anders als über Identitäten, daher müssen wir sicherstellen, dass wir uns entsprechend verhalten 15:18 <+fox> <mk> etwas anderes, das sich lohnen könnte, im Forum- oder Identitätsmanagement zu implementieren, wäre explizit ‚nur in dieses Forum unter Autor x, Autorisierung y posten‘, was Verwechslungen vermeiden würde. Man bräuchte nicht einmal ein Dropdown in neuen Beitragsnachrichten 15:19 <+fox> <mk> (ein Dropdown für Schlüssel) 15:20 <+void> ich würde ein globales Identitäts-Dropdown bevorzugen, das jederzeit sichtbar ist 15:20 <+fox> <mk> Also, unter welcher Identität du postest? 15:20 <jrandom> hmm 15:21 <+fox> <mk> vielleicht, aber ich denke, es macht nicht viel Unterschied, ob es immer oben sichtbar ist oder nur bei Beiträgen erscheint 15:22 <jrandom> ok, bevor wir zu tief graben – es gibt einen Nebenkanal, der in Syndie derzeit nicht adressiert ist, der mehrere Identitäten verknüpfen kann 15:22 <+void> obwohl deine Identität außerhalb des Postens nicht verwendet wird 15:22 <+fox> <mk> was meinst du? 15:23 <+void> neue Beiträge pushen? 15:23 <jrandom> Wenn du völlig nicht verknüpfbare Identitäten brauchst, musst du getrennte Syndie-Instanzen betreiben – du kannst sie gegenseitig synchronisieren und nur eine zum Pull/Push zu den anderen Archiven verwenden, aber das lokale Archiv enthält Informationen, auf die nur einige der Identitäten Zugriff haben 15:23 <+fox> <mk> (Ich stimme zu, dass wir große Diskussionen wohl fürs Dev-Forum aufheben sollten, aber es ist schön, wenn viele Leute gleichzeitig darüber reden) 15:24 <+void> stimmt 15:24 <jrandom> Allerdings können alle Identitäten im lokalen Archiv auf diese Informationen zugreifen, und wenn sie danach handeln (mit diesen Schlüsseln posten usw.), würden sie die Verknüpfbarkeit verraten 15:25 <jrandom> Vielleicht finden wir einen Weg, das alles transparent über die GUI zu erledigen 15:26 <jrandom> (lokal mit mehreren Archiven laufen, ohne Syndie zweimal starten zu müssen) 15:26 <+fox> <mk> es gibt viele weitere Themen – etwa das Markieren bestimmter Archive als gegenseitig exklusiv –, die der Anonymität helfen könnten. Wir sollten all diese Szenarien definieren und einen Weg finden, in sehr gut bedienbarer Form damit umzugehen 15:27 <tethrage> Syndie zielt nicht auf Anonymität, nur auf Sicherheit 15:27 <tethrage> darum sollte sich doch die Transportschicht kümmern, auf der es läuft, oder? :/ 15:27 <jrandom> Syndie zielt auf Anonymität 15:27 <tethrage> (korrigiere mich, wenn ich falsch liege) 15:28 <jrandom> Die Transportschicht deckt nur einen kleinen Teil der Anonymität ab – um den Rest müssen wir uns kümmern 15:28 <jrandom> s/small// 15:28 <tethrage> Tut sie das? :/ 15:28 <+fox> <mk> ja, genau. Syndie kümmert sich speziell um Informationslecks 15:29 <jadeSerpent> IP-Adress-Anonymität vs. Identitäts-Anonymität 15:29 <tethrage> verstehe. Ich dachte, du hättest neulich gesagt, Syndie sei als sichere App gedacht, die Krypto verwendet, aber nicht strikt anonym sei? 15:29 <tethrage> (jedenfalls nicht auf die gleiche Weise wie i2p usw.) 15:29 <+fox> <mk> Informationssicherheit wird durch die Redundanz der Archive gewährleistet 15:29 <jrandom> mk: Ich bin mir nicht sicher, was du mit dem Markieren der Archive meinst, aber ich würde mich über einen Beitrag dazu im Syndie-Dev-Forum freuen :) 15:29 <jrandom> tethra: Syndie kann für Dinge genutzt werden, die keine Anonymität erfordern 15:30 <jrandom> aber Syndie muss für Dinge nutzbar sein, die es tun 15:30 <jrandom> (ansonsten gäbe es keinen Grund, es als Teil des i2p-Projekts zu implementieren) 15:31 <tethrage> ja 15:31 <+void> jrandom: um fair zu sein, es gäbe trotzdem einen Sinn, wenn Syndie Anonymität durch die Nutzung von i2p bereitstellen würde 15:31 <+void> aber egal 15:31 <+void> c 15:31 <tethrage> Was tut Syndie außer Schutz vor Informationslecks und fehlerhaftem Code, um Leute anonym zu halten? :/ 15:32 <tethrage> Greift man nicht, sofern nichts anderes festgelegt ist, direkt auf die Archive zu usw.? 15:32 <+fox> <mk> tethrage, Informationslecks aller Art. Wenn du magst, können wir gleich näher darauf eingehen 15:33 <jrandom> tethra: Zum Beispiel jemand, der eine eepsite mit aktiviertem JavaScript aufruft 15:33 <jadeSerpent> tethrage: Es gibt keine Garantie, dass die Beiträge, die du in ein Archiv pushst, von dir stammen; jemand könnte sie in dein Archiv gepusht haben 15:34 <tethrage> jrandom: Ja, JS kann Dinge verraten und so weiter. Aber das ist doch eher eine Frage der Sicherheit als der Anonymität, wenn man kein anonymes Netzwerk irgendeiner Art nutzt, oder? 15:34 <tethrage> Andererseits streite ich wohl nur über Semantik, also halte ich jetzt den Mund 15:34 <tethrage> :/ 15:34 <jadeSerpent> Ich würde argumentieren, dass der Betrieb eines eigenen öffentlich zugänglichen Archivs in dieser Hinsicht deine Anonymität erhöht 15:34 <+fox> <mk> jrandom, ich schreibe diesen Beitrag. Außerdem habe ich mit einem Design für einen Browser herumgespielt (ich mag es nicht, neue Tabs für neue Bereiche zu öffnen), ich werde also versuchen, einen Prototypen dafür zu bauen und vielleicht ein paar Skizzen ins Dev-Forum zu posten 15:34 <jrandom> „Schutz vor Informationslecks“ ist der Kern von Anonymität – zu kontrollieren, wer Tatsachen über deine Identität kennt 15:35 <jrandom> ah, großartig, mk, danke! 15:35 <jrandom> jadeSerpent: sicher 15:35 <tethrage> verstehe 15:35 <tethrage> verstanden 15:36 <jrandom> mk: Wenn es bessere Wege gibt, die Syndie-UI zu präsentieren, bin ich zu 100 % dafür (nur ein sehr kleiner Teil des Codes ist an diese tab-basierten Komponenten gebunden) 15:36 <jrandom> und wir sind schließlich Alpha 15:38 <+void> jrandom: Ich vermute, es ist nicht schwer, die Tab-Oberfläche in eine Fenster-Oberfläche zu verwandeln? 15:38 <+fox> <mk> ja. Und wenn manche den Ansatz „Tabs für alles“ bevorzugen, ist es kein Problem, den zu verwenden 15:38 <+fox> <mk> (neben dem Browser-Tab) 15:39 <jadeSerpent> bitte kein MDI, ich schlage etwas zwischen Tabs und MDI vor, Eclipses Perspektiven 15:39 <+void> MDI ist schlecht, da stimme ich zu 15:40 <jadeSerpent> NetBeans hat so etwas auch, ich habe vergessen, wie es heißt 15:40 <jadeSerpent> Views oder Workbenches oder so, ist schon eine Weile her 15:41 <jrandom> .webp-Skizzen sind willkommen :) 15:41 * jrandom habe den Tab-für-alles-Stil gewählt, weil jeder Firefox (/etc) liebt 15:42 <jadeSerpent> wenn ich die Icons fertig habe, könnte ich an etwas davon herumhacken 15:42 <+fox> <mk> Der Zweiwochen-Releasezyklus ist gut. Ich sehe diese Ziele gerne explizit, aber ich würde auch gerne ein paar „weichere“ Ziele sehen – Entwickler- und später Benutzerdokumentation, Diagramme usw. 15:42 <jrandom> klasse 15:42 <jadeSerpent> Tabs sind fürs Erste ok, meiner Meinung nach, sie sind benutzbar 15:42 <jrandom> mk: http://syndie.i2p.net/roadmap.html ? 15:42 <jrandom> (auch wenn es keine Daten auf der Roadmap gibt) 15:43 <+fox> <hottuna> nett :=) ... habe gerade etwas dazu zu den offenen Aufgaben gepostet :P 15:44 <+fox> <mk> ja, obwohl ich kleinere Ziele meine. „die allgemeinen Interaktionen zwischen Klassen in syndie.gui dokumentieren“ oder „ein Dokument zum Thema Banning schreiben“ etc. 15:44 <jrandom> ah, guter Punkt 15:45 <jrandom> ich wollte schon länger die To-do-Punkte auf niedriger/mittlerer/hoher Ebene wieder zusammenstellen 15:45 * jrandom fügt das der To-do-Liste hinzu 15:47 <jrandom> ok, hat jemand noch etwas zu 2) Syndie Entwicklungsstatus? 15:48 <jrandom> (Natürlich haben wir die Dev-Foren in Syndie, aber IRC ist nützlich für schnelle Hin-und-her-Gespräche) 15:49 <jrandom> wenn nicht, springen wir weiter zu 3) Gewinner des Januar-Bug-Ernte-Wettbewerbs! 15:50 <jrandom> Glückwunsch an Darn, voyde, mk und Anonymous, und danke an alle, die geholfen haben 15:51 * jrandom stellt fest, dass der Wettbewerb ursprünglich für die Top 3 gedacht war, aber die Zählung war so knapp 15:51 <jrandom> Es läuft auch diesen Monat ein neuer Wettbewerb, gleiche Regeln wie zuvor 15:51 <jadeSerpent> woher weißt du, dass „Anonymous“ nur eine Person war? ;) 15:51 <+fox> <mk> 225 Bugs insgesamt (nach meiner Zählung) – beeindruckend 15:51 <+void> :) 15:52 <+fox> <mk> jade, der Schlüssel, würde ich sagen :) 15:52 <jrandom> jadeSerpent: urn:syndie:meta:d7:channel44:Ffn4RhCunO6gwMfAYfOoPY7FGwPNDy65dS4DyuyorME=e :) 15:53 <jrandom> Es könnten aber auch fünf Leute sein, die sich diesen Schlüssel teilen 15:53 <jrandom> aber dann müssen sie sich die 50 USD teilen ;) 15:53 <jrandom> (der Erste mit dem privaten Schlüssel, der mir eine signierte Nachricht schickt, welches e-gold-Konto zu verwenden ist, gewinnt ;) 15:53 <jadeSerpent> es sei denn, einer bringt die anderen um 15:54 <jadeSerpent> aber so etwas würde nur in Rumänien passieren 15:54 <tethrage> und Russland 15:54 <jrandom> (und Großbritannien, und Australien, und...) 15:55 <+fox> <mk> 50 USD sind eine Menge Geld... 15:55 <jadeSerpent> In Russland würden sie alle umgebracht, und der Vermieter nähme das Geld und gäbe es als Schutzgeld an die Mafia weiter 15:55 <tethrage> nicht in GBP ;p 15:55 <+fox> <mk> Ich weiß, dafür würde ich töten 15:55 <tethrage> Ich nehme an, die Frage, woher du bist, wird keine Antwort bringen, mk? 15:55 <tethrage> :/ 15:56 <+fox> <dw_g> ok, ich nehme es ;) 15:56 <+fox> <mk> ursprünglich Russland :D jetzt Kanada 15:56 <jadeSerpent> 225 Bugs sind beeindruckend, wie viele davon wurden geschlossen? 15:56 <tethrage> ice. 15:56 <tethrage> +n 15:57 <jrandom> jadeSerpent: Ich würde schätzen, dass etwa 75–80 % bearbeitet sind 15:57 <jadeSerpent> schön 15:58 <jrandom> (mit vielleicht weiteren 5–10 % ungültig/wontfix) 15:58 <jrandom> aber das ist tatsächlich einer der höherstufigen To-do-Punkte – eine echte Management-UI fürs Bug-Tracking bekommen 15:58 * jadeSerpent empfiehlt Trac 15:58 <jrandom> (Es hat eine Weile gedauert, alle Beiträge durchzugehen und sie manuell zu zählen) 15:58 <+fox> <mk> außerhalb von Syndie? 15:59 <jrandom> hmm, mit einem Syndie-->Track-Exportsystem? 15:59 <jrandom> s/ck// 15:59 <+fox> <mk> Ein schönes Projekt wäre, Syndie an einen Bugtracker anzubinden 15:59 <jadeSerpent> ja 15:59 * jrandom wettet, dass ein paar SQL-Queries & Inserts genügen würden 16:00 <jrandom> Es wäre aber durchaus lohnend, zumindest aus einer Read-only-Trac-Perspektive 16:00 <+void> aber Updates aus Trac zurück nach Syndie zu synchronisieren, wird schwierig, denke ich 16:00 <jrandom> Eine vollständige Zyklus-Integration ist sehr schwer 16:00 <jrandom> richtig 16:00 <+fox> <mk> irgendwann könnte es sich lohnen, ein „Revision“-artiges System in Betracht zu ziehen 16:00 <jrandom> aber die Möglichkeit, in Trac abzufragen & hinein zu drillen und Berichte zu erzeugen usw. 16:01 <+fox> <mk> bei dem Beiträge ältere ersetzen 16:01 <jrandom> ah, ja, dafür gibt es Hooks, aber die Overwrite*-Header werden derzeit nicht berücksichtigt 16:02 <jrandom> Wäre aber nicht allzu schwer, nur ein UI-Schalter, um zu früheren Revisionen desselben Beitrags zu navigieren, plus ein paar Zeilen Code, um zu überprüfen, dass der Beitrag berechtigt ist, den alten zu überschreiben 16:03 <jadeSerpent> Ich verstehe das Bedürfnis, Syndie selbst fürs Bugreporting zu verwenden, aber sein Design umfasst kein Issue-Tracking und es wird dafür immer suboptimal sein; meiner Meinung nach solltet ihr einen echten Issue-Tracker verwenden 16:04 <+fox> <mk> Angesichts der Anzahl gemeldeter Bugs stimme ich jadeSerpent zu 16:05 <jrandom> Auf der anderen Seite: Wie viele Bugs wurden von denen entdeckt, die Syndie zum Melden der Bugs benutzt haben? 16:05 * jrandom ist nicht völlig gegen Trac oder ein anderes Bug-Tracking-System 16:05 <jadeSerpent> solche Bugs werden sowieso entdeckt 16:05 <+void> nun, Schweregrade, Komponenten, Versionen und das Schließen/Öffnen/Wiederöffnen von Bugs kann man mit Syndie-Tags abbilden 16:05 <jrandom> richtig 16:06 <+void> (und das meiste davon wird bereits so gemacht) 16:06 <jadeSerpent> wie neulich, als es jemandem beim Posten eines Bugreports eingefroren ist – es wäre ihm auch eingefroren, wenn er über irgendein anderes Thema gepostet hätte, es spielte keine Rolle, dass es ein Bugreport war 16:06 <jrandom> if we can feed a real issue tracker via pseudonymously (and authentic) messages, that would be great 16:06 * jrandom hat auch ein paar private Bugreports erhalten, die sensible Informationen enthalten – diese sind durch Syndies Verschlüsselung geschützt 16:07 <+fox> <mk> nun, warum nicht beides behalten? 16:08 <jadeSerpent> Ich stimme zu, dass es jedoch keinen Issue-Tracker gibt, der mit Blick auf Anonymität oder mehr als triviale Vertraulichkeit entworfen wurde 16:09 <+fox> <mk> Es wäre schön, wenn Syndie so eine Art Bugtracker hätte, aber Anonymität ist beim Einreichen der meisten Bugreports kein allzu großes Problem 16:10 <jadeSerpent> vielleicht könnte Trac so modifiziert werden, dass es Syndies Funktionen dafür nutzt 16:10 <+fox> <mk> jade, das wäre schwierig. Browser implementieren kein Signieren 16:12 <jrandom> hmm. Was wir haben, basiert ursprünglich auf: http://syndiemedia.i2p.net:8000/blog.jsp?blog=ovpBy2mpO1CQ7deYhQ1cDGAwI6pQzLbWOm1Sdd0W06c=&entry=ovpBy2mpO1CQ7deYhQ1cDGAwI6pQzLbWOm1Sdd0W06c=/1132012800003 16:12 <jrandom> plus http://dev.i2p.net/~jrandom/bugsp1.txt und http://dev.i2p.net/~jrandom/bugsp2.txt 16:13 <jrandom> Ich stimme zu, dass wir etwas Besseres als das Bestehende brauchen, um diese Issues zu verfolgen, und ich bin offen für alles, was uns am besten voranbringt 16:13 <jrandom> aber ich würde es, wenn möglich, minimal halten, denn wir bauen Syndie, nicht einen Bugtracker :) 16:14 <jadeSerpent> ja gut, du scheinst es vorerst auch ohne zu schaffen ;) 16:14 <jrandom> aber ich bin sicher, manches fällt durch die Maschen, und andere haben es schwerer herauszufinden, was bekannt ist usw. und Fixes beizutragen 16:15 <+fox> <mk> wir müssen es wahrscheinlich nicht einmal durch Syndie implementieren. Es ist dort bis zu einem gewissen Grad nützlich, aber 200+ Bugs sind wirklich viel. Wir sollten uns für einen Tracker entscheiden und ihn über das WWW und über i2p verfügbar machen 16:16 <+fox> <mk> oben auf dem „Bug melden“-Bildschirm in Syndie einen Link dahin setzen, und so haben wir beide Optionen. Eine Bugtracker-Implementierung in Syndie ist nichts, worauf wir jetzt Ressourcen verwenden sollten 16:17 * jrandom mag integriertes Bug-Tracking (damit Leute keine Bugtracker-Accounts erstellen, Fake-E-Mail-Adressen verwenden usw. müssen), aber ich bin offen für Vorschläge, welche Lösung wir nutzen sollten 16:17 <+fox> <mk> Ich denke, das sollten wir behalten, aber zusätzlich den Bugtracker haben 16:18 <jadeSerpent> Kurzfristig wäre Nur-Lesezugriff schön 16:18 <jadeSerpent> ich bevorzuge eine stärker bug-orientierte Suchoberfläche 16:18 <jrandom> wouldn't be so bad, could perhaps write a one-way syndie-->issue tracker export without much trouble too, of r those who can't dont want to use the web based one 16:19 <jrandom> s/of r/for/ 16:19 <+fox> <mk> integriertes Bug-Submission ist toll, aber wir sollten das Syndie-Archiv nicht nutzen, um 200+ Bugs zu tracken 16:20 <jrandom> obwohl es großartig ist, um unsere Suchfähigkeiten zu testen :) [ja, ok, ich bin überzeugt] 16:20 <jrandom> also, eine Stimme für Trac. weitere Stimmen? bitte im Syndie-Dev-Forum posten, mit Begründung natürlich 16:21 <jadeSerpent> zwei Stimmen für Trac, außer du hast meine schon gezählt ;) 16:21 <jrandom> Ja, das habe ich gezählt ;) 16:21 <+fox> <mk> welche Optionen gibt es? Ich kenne mich mit Trackern gar nicht aus 16:21 <jadeSerpent> ich hatte gehofft, das sei deine eigene Stimme, aber ok 16:22 <jadeSerpent> ich habe mit Trac gearbeitet, großartige Unterstützung durch Drittanbieter 16:22 <jadeSerpent> Bugzilla würde ich „bläh“ sagen 16:22 <jrandom> allerdings, nebenbei: Wenn sich jemand mit einem Issue-Tracker gut auskennt, wäre das hilfreich, um einen Syndie-->Issue-Tracker-Export herauszuhauen 16:22 <jrandom> ja, Bugzilla ist ein Biest 16:22 <jadeSerpent> JIRA ist auch gut, wie Trac 16:23 <+void> Trac ist wahrscheinlich auch vielen Leuten vertraut 16:23 <jrandom> Ja, und gute Leute außerdem (sie haben i2p eine Lizenz gegeben, auch wenn wir sie noch nicht genutzt haben) 16:23 <jadeSerpent> ihr habt eine JIRA-Lizenz? 16:23 <jrandom> ja, JIRA und Fisheye 16:24 <jadeSerpent> cool, dann probiert es ruhig aus 16:24 <jadeSerpent> übrigens integriert sich Eclipses Mylar-Plugin vollständig in Bugzilla, Trac und JIRA 16:24 <jadeSerpent> großes Lob für seine Oberfläche 16:25 <jrandom> verdammt, dieser NetBeans/Eclipse-Kampf 16:25 <bar> (Bugs werden automatisch gemeldet, wenn sie erstellt werden? ;) 16:25 <tethrage> (haha) 16:26 <+fox> <mk> hah, schön 16:26 <jadeSerpent> jrandom: NetBeans-Unterstützung steht, soweit ich mich erinnere, auf der Mylar-Roadmap 16:26 <jrandom> cool 16:26 <+fox> <modulus> das kommt davon, wenn man Sun fanatisch unterstützt :-) 16:27 * jrandom bewirft modulus mit Javabeans 16:27 <jadeSerpent> obwohl Mylar offiziell unter der Ägide der Eclipse Foundation steht 16:27 <+fox> * mk kann keine Live-Site für Trac finden 16:27 <+fox> <modulus> http://trac.wordpress.org/ 16:27 <jrandom> mk: http://feedspace.i2p/ atm 16:28 <+void> http://trac.edgewall.com/ 16:29 * jrandom möchte nicht viel Zeit damit verbringen, viele verschiedene Systeme zu evaluieren, also wenn jemand ein bestimmtes System befürworten will, bitte im Syndie-Dev-Forum tun 16:29 <jadeSerpent> http://overlays.gentoo.org/proj/alt/wiki 16:29 <+void> (^ offizielles Meta-Trac) 16:29 <+fox> <mk> ja, ist mir alles recht 16:30 * jrandom nehme an, das war's für * 3) Gewinner des Januar-Bug-Ernte-Wettbewerbs! und wir gehen über zu 4) ??? 16:30 <jrandom> Hat noch jemand etwas für das Treffen? 16:30 <+fox> <mk> „Beste“ ist überbewertet. Wer die meiste Erfahrung mit diesen Dingen hat, sollte wahrscheinlich eine Münze werfen 16:32 * jrandom suche nicht wirklich ein System für Projekt-/Release-Planung oder einen Sourcecode-Browser (ein freies Wiki schadet nicht, aber wir haben auch ugha.i2p) 16:32 <jrandom> Issues nachzuverfolgen ist die einzige Funktion, die mir dabei wichtig ist 16:37 <jrandom> ok, wenn es nichts Weiteres für das Treffen gibt... 16:37 * jrandom rundet ab 16:37 * void reicht jrandom den Baffer 16:37 * jrandom *baf*s das Treffen