Reunión de desarrolladores de I2P - 7 de abril de 2020

22:04:29 <eyedeekay> Hola a todos, ¿quiénes están aquí? 22:04:40 <eche|on> peep :-=) 22:04:46 <zlatinb> hola 22:04:48 <zzz> presente 22:06:18 <eyedeekay> Muy bien, primer tema, 0.9.46, zzz adelante 22:06:52 <zzz> terminando unos dos meses de trabajo en ratchet (propuesta 144) 22:07:16 <zzz> Estoy casi llegando a la finalización de "fase 2", donde está completo en funcionalidades 22:07:32 <zzz> y pasaré a más corrección de errores y pruebas 22:07:51 <zzz> así que la 46 será donde más gente pueda probarlo, y quizá lo activemos por defecto en la 47 22:08:23 <zzz> en adelante prestaré atención a otras correcciones de errores y temas, como el streaming (trabajando con zlatinb) 22:08:56 <zzz> EOT por mi parte, así que quizá otros quieran decir en qué están trabajando para la 46 22:09:01 <eche|on> Acabo de actualizar a -5 hace 2 días, sigue funcionando bien, el parche de round-robin de tunnel está incluido, por ahora no se nota un gran cambio 22:09:56 <zlatinb> He estado re-reeleyendo los RFC de TCP y observando muchas discrepancias en nuestras implementaciones de streaming y SSU. Así que las reescribí. Los tickets están en trac 22:10:24 <eche|on> lectura y comprobación muy, muy detalladas, zlatinb 22:11:34 <eyedeekay> He empezado a trabajar en revisiones de la UI de i2ptunnel para reducir la cantidad de información innecesaria que presentamos a los usuarios nuevos y en el mecanismo de rotación periódica de claves para i2ptunnels 22:12:19 <eyedeekay> Mucho trabajo fuera del árbol para mí también; quiero reemplazar el paquete de perfil de Firefox por algo que funcione también en plataformas no-Windows, y eso va tomando buena forma. 22:12:32 <eyedeekay> ¿Eso es todo por parte de todos? 22:12:46 <eche|on> eso parece 22:12:49 <eyedeekay> Además, ¿alguien tiene alguna pregunta? 22:13:47 <eyedeekay> Hasta ahora, todo bien. Lo siguiente es miscelánea 22:14:37 <eyedeekay> Con respecto a la migración a git, se ha decidido migrar i2p.i2p *después* de la próxima versión y no antes. Otros repositorios podrían migrarse antes caso por caso. 22:15:06 <eche|on> bien 22:15:20 <eyedeekay> El registro en git.idk.i2p está abierto, pero requiere aprobación manual de un admin. Somos puntuales con ello, pero no dudes en hacerme ping si tienes prisa. 22:16:46 <eyedeekay> Por ahora el enfoque preferido es usar git con SSH, excepto para el clone inicial, que puedes realizar descargando el git bundle con snark. 22:16:50 <eyedeekay> EOT 22:17:18 <eyedeekay> ¿Alguna pregunta para mí respecto a la migración a git? 22:17:31 <eche|on> ¿Algún progreso con la inclusión de tickets de trac? 22:17:49 <eyedeekay> No he tenido tiempo de trabajar en tracboat, así que no, aún no. 22:17:58 <eche|on> ok 22:18:41 <zlatinb> Tengo 2 preguntas sobre la migración: 22:18:41 <zlatinb> 1. ¿Hay alguna manera de cambiar el tiempo de espera de lectura de red en ssh durante el git clone? Si es así, aumentarlo a algo como 5 minutos mejorará las probabilidades de éxito 22:18:41 <zlatinb> 2. Como trac no ha sido muy fiable, ¿está bien empezar a abrir o reflejar tickets en GitLab? ¿Se les prestará atención? 22:19:15 <eyedeekay> 1: He estado investigándolo; no parece que se pueda, pero aún no puedo responder de forma concluyente. 22:19:20 <zzz> con respecto al 2), no por mí, si te refieres a i2p.i2p 22:19:25 <eche|on> sobre el 2: tracboat sería la solución con script para incluir todos los tickets de trac en git 22:19:54 <zzz> pregunta relacionada: ¿cuál es el plan para mejorar el tiempo de actividad consistentemente pobre de los servicios expuestos al público que opera meeh? 22:20:02 <eche|on> oh, perdón, para copiar/migrar tickets existentes; los nuevos quizá sean un problema 22:20:18 <zlatinb> ¿Se conservarán los números de ticket? Si es así, ¿qué pasa con los tickets ya abiertos en GL, hay que eliminarlos? 22:21:21 <eyedeekay> Los números de ticket deberían conservarse si logro que la migración funcione; los tickets duplicados habrá que eliminarlos manualmente cuando se cierre uno u otro. 22:22:08 <zlatinb> y si por la razón que sea la migración no puede funcionar, ¿cuál es el plan de respaldo? 22:23:12 <zzz> todavía no hemos acordado la migración de trac en absoluto; supongo que todo esto son solo experimentos. Propongo que la migración de trac se aplace hasta después de que todas las ramas de mtn (incluidas las que aún no están en GH) se migren a git 22:23:33 <zzz> quizá septiembre, como muy pronto 22:23:42 <eche|on> la respuesta a esto se correlacionará con la pregunta de zzz; actualmente no hay un plan fijo. Mi idea sería mantener trac funcionando con los tickets antiguos 22:24:02 <eyedeekay> No tengo manera de arreglar trac; migrar los tickets fuera de él es lo único que personalmente puedo hacer. Si no puedo migrarlos con tracboat, tendré que hacerlo yo. Conozco la parte de gitlab; solo tendré que aprender la parte de trac. Sé que gitlab parece un reemplazo obvio y atractivo para trac, pero esto es un obstáculo importante. 22:24:03 <zlatinb> ok, y hasta que se haya intentado una migración, ¿debemos seguir usando trac? 22:24:41 <eyedeekay> Sí 22:24:51 <eche|on> en cuanto a tickets: por favor, usen trac hasta que se haya realizado la migración de tickets 22:24:53 <zzz> entonces, ¿quién está a cargo de arreglar los servicios de meeh? ¿O nos hemos rendido y ahora estamos trabajando para reemplazar todo lo que él opera? Si eso es lo que estamos haciendo, seamos explícitos al respecto 22:25:56 <eche|on> meeh está a cargo de sus servicios. trac debería reemplazarse por git. 22:26:31 <zzz> lo cual no arregla los problemas sistémicos con otros servicios como el repositorio deb y el outproxy 22:26:31 <eche|on> el repositorio de Debian es un punto abierto actualmente; hice un mirror de él, pero por ahora necesito más tiempo para ver cómo dejarlo configurado como se espera 22:27:32 <eche|on> el outproxy no lo tocaré en absoluto 22:27:50 <eyedeekay> Con gusto ayudo a reemplazar el repo deb de meeh, pero no puedo hacer nada por el outproxy. 22:29:19 <eche|on> meeh a menudo nos dijo que el problema es en su mayoría el sistema antiguo en IPs antiguas que está usando; con welterde cambiando el DNS, eso sí cambió hoy 22:29:33 <zzz> Supongo que la migración de tickets para una rama concreta X ocurriría solo después de que hayamos pasado de mtn a git para X 22:29:35 <eche|on> pero por ahora no tengo idea 22:30:55 <eyedeekay> zzz Sí 22:31:08 <eyedeekay> Con respecto a la migración de tickets 22:31:27 <eyedeekay> De ese modo no confundiríamos a la gente sobre dónde se están discutiendo las incidencias. 22:32:21 <eyedeekay> ¿Algo más? 22:34:22 <eyedeekay> timeout: 60s 22:36:22 <eyedeekay> **Bafs** OK, gracias por venir a todos