I2P-Entwicklertreffen - 07. April 2020

22:04:29 <eyedeekay> Hallo zusammen, wer ist alles hier? 22:04:40 <eche|on> piep :-=) 22:04:46 <zlatinb> hi 22:04:48 <zzz> anwesend 22:06:18 <eyedeekay> Alles klar, erstes Thema, 0.9.46, zzz, leg los 22:06:52 <zzz> Ich schließe gerade etwa zwei Monate Arbeit an ratchet (Vorschlag 144) ab 22:07:16 <zzz> Ich bin etwa am Abschluss von "phase 2", in der es funktionskomplett ist 22:07:32 <zzz> und werde zu mehr Fehlerbehebungen und Tests übergehen 22:07:51 <zzz> also wird 46 die Version sein, in der mehr Leute es testen können, und vielleicht aktivieren wir es standardmäßig in 47 22:08:23 <zzz> Im Anschluss werde ich mich anderen Fehlerbehebungen und Themen widmen, z. B. Streaming (zusammen mit zlatinb) 22:08:56 <zzz> EOT von mir, vielleicht möchten andere sagen, woran sie für 46 arbeiten 22:09:01 <eche|on> Ich habe vor 2 Tagen gerade auf -5 aktualisiert, funktioniert weiterhin gut, der tunnel-Patch Round-Robin ist enthalten, derzeit keine großen Änderungen festgestellt 22:09:56 <zlatinb> Ich habe die TCP-RFCs immer wieder neu gelesen und viele Abweichungen in unseren Streaming- und ssu-Implementierungen bemerkt. Also habe ich sie neu geschrieben. Tickets sind auf trac 22:10:24 <eche|on> sehr, sehr detailliertes Lesen und Prüfen, zlatinb 22:11:34 <eyedeekay> Ich habe begonnen, an Überarbeitungen der i2ptunnel UI zu arbeiten, um die Menge unnötiger Informationen für neue Nutzer zu reduzieren, sowie am Mechanismus für periodische Schlüsselrotation für i2ptunnels 22:12:19 <eyedeekay> Viel Out-of-Tree-Kram auch bei mir; ich möchte das Firefox-Profile-Bundle durch etwas ersetzen, das auch auf Nicht-Windows-Plattformen funktioniert – das nimmt schon ganz gute Formen an. 22:12:32 <eyedeekay> War's das für alle? 22:12:46 <eche|on> sieht so aus 22:12:49 <eyedeekay> Hat außerdem jemand Fragen? 22:13:47 <eyedeekay> Bis hierher gut. Als Nächstes: Verschiedenes 22:14:37 <eyedeekay> Re: Git-Migration, es wurde entschieden, i2p.i2p *nach* dem nächsten Release zu migrieren und nicht davor. Andere Repositories können je nach Einzelfall früher migriert werden. 22:15:06 <eche|on> gut 22:15:20 <eyedeekay> Die Registrierung auf git.idk.i2p ist offen, erfordert aber eine manuelle Freigabe durch einen Admin. Wir sind damit zügig, aber pingt mich gern, wenn es eilig ist. 22:16:46 <eyedeekay> Der bevorzugte Ansatz ist derzeit, git mit SSH zu verwenden – mit Ausnahme des initialen clone, den ihr ausführen könnt, indem ihr das git bundle mit snark herunterladet. 22:16:50 <eyedeekay> EOT 22:17:18 <eyedeekay> Fragen an mich bzgl. Git-Migration? 22:17:31 <eche|on> Gibt es Fortschritte bei der Einbindung der trac-Tickets? 22:17:49 <eyedeekay> Ich hatte keine Zeit, an tracboat zu arbeiten, also nein, noch nicht. 22:17:58 <eche|on> ok 22:18:41 <zlatinb> Ich habe 2 Fragen zur Migration: 22:18:41 <zlatinb> 1. Gibt es eine Möglichkeit, den Network-Read-Timeout in ssh während des git clone zu ändern? Falls ja, würde eine Erhöhung auf etwa 5 Minuten die Erfolgschancen verbessern 22:18:41 <zlatinb> 2. Da trac nicht sehr zuverlässig war, ist es ok, Tickets in GitLab zu eröffnen oder zu spiegeln? Werden sie beachtet? 22:19:15 <eyedeekay> 1: Ich habe das untersucht; es scheint nicht zu gehen, aber ich kann es noch nicht abschließend beantworten. 22:19:20 <zzz> bzgl. 2) nicht von mir, wenn du i2p.i2p meinst 22:19:25 <eche|on> zu 2: tracboat wäre die Skript-Lösung, um alle trac-Tickets in git zu übernehmen 22:19:54 <zzz> Verwandte Frage: Was ist der Plan, um die dauerhaft schlechte Uptime der öffentlich erreichbaren Dienste von meeh zu verbessern? 22:20:02 <eche|on> oh, sorry, für das Kopieren/Migrieren bestehender Tickets, neue könnten ein Problem sein 22:20:18 <zlatinb> Werden die Ticketnummern beibehalten? Falls ja, was passiert mit den bereits auf GL eröffneten Tickets – müssen die gelöscht werden? 22:21:21 <eyedeekay> Ticketnummern sollten erhalten bleiben, wenn ich die Migration zum Laufen bekomme; doppelte Tickets müssen manuell gelöscht werden, wenn eines der beiden Tickets geschlossen wird. 22:22:08 <zlatinb> Und falls die Migration aus irgendeinem Grund nicht funktioniert – was ist der Backup-Plan? 22:23:12 <zzz> Wir haben einer trac-Migration bislang überhaupt nicht zugestimmt; ich nehme an, das alles sind nur Experimente. Ich schlage vor, die trac-Migration aufzuschieben, bis alle mtn-Branches (einschließlich derer, die noch gar nicht auf GH sind) nach git migriert sind 22:23:33 <zzz> vielleicht frühestens Sept. 22:23:42 <eche|on> Die Antwort darauf wird mit zzz' Frage korrelieren; derzeit gibt es keinen festen Plan. Meine Idee wäre, trac mit den älteren Tickets weiter laufen zu lassen 22:24:02 <eyedeekay> Ich habe keine Möglichkeit, trac zu reparieren; die Tickets davon weg zu migrieren ist das Einzige, was ich persönlich tun kann. Wenn ich sie nicht mit tracboat migrieren kann, muss ich es selbst machen. Die gitlab-Seite davon kenne ich; ich muss nur die trac-Seite davon lernen. Mir ist klar, dass gitlab wie ein naheliegender und attraktiver Ersatz für trac wirkt, aber das ist ein erheblicher Blocker. 22:24:03 <zlatinb> ok, und bis ein Migrationsversuch unternommen wurde, sollen wir weiterhin trac verwenden? 22:24:41 <eyedeekay> Ja 22:24:51 <eche|on> Was Tickets angeht: Bitte verwendet trac so lange, bis die Ticket-Migration erledigt ist 22:24:53 <zzz> Also, wer ist verantwortlich dafür, meehs Dienste zu reparieren? Oder haben wir aufgegeben und arbeiten jetzt daran, alles zu ersetzen, was er betreibt? Wenn wir das so machen, lasst uns das klar sagen 22:25:56 <eche|on> meeh ist für seine Dienste verantwortlich. trac sollte durch git ersetzt werden. 22:26:31 <zzz> Was die systemischen Probleme bei anderen Diensten wie dem deb-Repo und dem outproxy nicht behebt 22:26:31 <eche|on> Das Debian-Repository ist derzeit ein offener Punkt; ich habe ein Mirror davon gemacht, brauche aber noch mehr Zeit, um mir die erwartete Einrichtung anzuschauen 22:27:32 <eche|on> outproxy fasse ich überhaupt nicht an 22:27:50 <eyedeekay> Ich helfe gern dabei, meehs deb-Repo zu ersetzen, aber für outproxy kann ich nichts tun. 22:29:19 <eche|on> meeh hat uns oft gesagt, das Problem sei größtenteils das alte System auf alten IPs, das er nutzt; mit welterde, der die DNS geändert hat, hat sich das heute geändert 22:29:33 <zzz> Ich nehme an, die Ticket-Migration für einen bestimmten Branch X findet erst statt, nachdem wir für X von mtn auf git umgezogen sind 22:29:35 <eche|on> aber derzeit keine Ahnung 22:30:55 <eyedeekay> zzz Ja 22:31:08 <eyedeekay> Re: Ticket-Migration 22:31:27 <eyedeekay> So verwirren wir die Leute nicht darüber, wo issues diskutiert werden. 22:32:21 <eyedeekay> Noch etwas? 22:34:22 <eyedeekay> Timeout: 60s 22:36:22 <eyedeekay> **Bafs** OK, danke fürs Kommen, alle zusammen