Reunión de desarrolladores de I2P - 07 de abril de 2016

20:00:05 <zzz> 0) Hola 20:00:05 <zzz> 1) Puntos pendientes de reuniones anteriores http://zzz.i2p/topics/2093 20:00:05 <zzz> 2) Sustitución de los roles y servicios de kytv http://zzz.i2p/topics/2098 20:00:05 <zzz> 3) Actualización de la planificación de la 0.9.26 http://i2p-projekt.i2p/en/get-involved/roadmap http://zzz.i2p/topics/1960 20:00:05 <zzz> 4) Planificación para HOPE http://zzz.i2p/topics/1968 20:00:05 <zzz> 5) Breve revisión de las reuniones mensuales y de la gestión del proyecto tras 3 meses 20:00:10 <zzz> 0) Hola 20:00:12 <zzz> hola 20:00:38 <zzz> 1) Puntos pendientes de reuniones anteriores http://zzz.i2p/topics/2093 20:00:55 <orignal_> hola 20:01:00 <zzz> - Preparación de la campaña de Reseed, para finales de enero: 20:01:00 <zzz> ** Sadie contactará con backup para hablar de OPEN, nueva fecha 5 de abr. 20:01:11 <zzz> sadie, ¿estado? 20:02:10 <zzz> - Fortalecimiento de la red: página de inicio y páginas adicionales 20:02:10 <zzz> ** str4d, gravy, cacapo: Añadir casos de uso, en qué somos mejores, más "pasión" y "sustancia", añadir / destacar Bote, para finales de enero OPEN, str4d añadirá casos de uso al sitio web para el 6 de mar., más cambios en pasión etc. para el 5 de abr. 20:02:15 <zzz> str4d, ¿estado? 20:03:06 <zzz> - Añadir la "Historia" de I2P / historia / por qué 20:03:06 <zzz> ** comraden para editar / pulir / mejorar / publicar para finales de febrero OPEN, nueva fecha 1 de abr., borrador de vuelta a zzz para mediados de marzo 20:03:11 <zzz> comradenosebleed, ¿estado? 20:03:34 <str4d> hola 20:04:40 <zzz> Gestión de tickets: actualmente ad hoc 20:04:40 <zzz> ** Sadie revisará, hará recomendaciones o posiblemente empezará a gestionarlos (¿para cuándo?) OPEN, str4d y sadie programarán una reunión o harán un informe para el 5 de abr.(?) 20:04:50 <zzz> sadie, str4d: ¿estado? 20:05:49 <hottuna> hola 20:05:59 <zzz> str4d OPEN - Lanzamiento de Android 0.9.24 el 3 de marzo, lista TODO recopilada para el 6 de mar., borrador de roadmap para el 6 de mar., para revisar el 5-6 de mar. 20:06:05 <zzz> str4d, ¿estado? 20:06:33 <str4d> Lo hablamos 20:06:41 <str4d> (perdón, estoy en 2 reuniones a la vez) 20:06:54 <zzz> str4d y zzz revisarán el ticket VRP para el 12 de feb.; Tomaremos algunas decisiones durante las reuniones de roadmap del 5-6 de marzo (zzz hecho el 8 de feb., str4d para el 6 de mar.) 20:06:56 <str4d> sobre: tickets 20:06:57 <zzz> str4d, ¿estado? 20:07:29 <zzz> sadie y anonimal volverán con unas ediciones del CoC (Código de Conducta) basadas en Monero 0mq en la reunión del 5 de abril 20:07:36 <zzz> sadie, anonimal: ¿estado? 20:08:25 <str4d> Decidí previamente tener el estado "new" para los tickets que necesiten clasificación, y sigo pensando que es el camino a seguir 20:09:00 <str4d> También creo que podría ser buena idea fijar un horario regular para que unos pocos de nosotros revisemos esos tickets 20:09:09 <str4d> sobre: android 20:09:59 <str4d> Aún no ha ocurrido porque está bloqueado por el script de compilación 20:10:17 <eche|on> uhh 20:10:54 <str4d> Ticket VRP: no ha ocurrido aún porque he estado enfermo cuando planeaba trabajar en ello 20:11:00 <zzz> está claro que el estilo actual de gestión del proyecto no está funcionando porque no está pasando nada. Sigamos, y puse el punto 5) en la agenda para decidir si debemos continuar con las reuniones mensuales o no 20:11:10 <zzz> casi todos estos puntos tienen 3 meses y 1/3 20:11:19 <str4d> Lo que sí ha pasado, que no está en la lista de zzz, es que terminé la migración de la especificación y estoy en plena migración de las propuestas 20:11:37 <zzz> grandes noticias sobre specs/proposals, bien hecho 20:12:09 <str4d> Así que diría que "nada" es incorrecto, solo se movieron prioridades que no se reflejan en el estilo actual de gestión del proyecto 20:12:17 <str4d> Así que sí, necesitamos refinar 20:12:20 <zzz> ok. buena perspectiva 20:12:25 <zzz> ¿algo más en 1) ? 20:13:04 <str4d> Para todos los demás aquí, lo de las propuestas está en http://vekw35szhzysfq7cwsly37coegsnb4rrsggy5k4wtasa6c34gy5a.b32.i2p/spec/proposals - por favor, revisad y comentad :) 20:13:26 <zzz> 2) Sustitución de los roles y servicios de kytv http://zzz.i2p/topics/2098 20:13:34 <zzz> hay una lista de unas 20 cosas que hacía 20:13:44 <str4d> Nada más por mi parte 20:13:47 <str4d> (sí hice trabajo en I2P Android, solo que no llegué a lanzar) 20:13:55 <zzz> Me he centrado en lo que vi como prioridades más altas: launchpad y debian 20:14:14 <zzz> otros están investigando otras cosas, y cambiamos un par de enlaces de la página de inicio de la consola en la .25 20:14:33 <zzz> para mí lo siguiente más importante es un responsable de Tails 20:15:06 <zzz> ¿hay alguien aquí que conozca Tails Y el empaquetado de debian y pueda ayudar? si no, haré el llamado en twitter cuanto antes 20:15:24 <zzz> nos van a echar de Tails tan pronto como en el próximo lanzamiento en dos meses 20:15:32 <zzz> 2.4 creo 20:15:50 <zzz> es más de lo que puedo manejar. No lo haré. 20:16:02 <str4d> Uf 20:16:19 <str4d> ¿Qué exige Tails como mínimo 20:16:19 <str4d> ? 20:16:20 <zzz> el trabajo es tomar el empaquetado debian que hago, y ajustarlo/integrarlo en Tails, probar probar probar, más una serie de tickets existentes de i2p en Tails 20:16:49 <zzz> hay una gran redacción que hizo kytv creo, está enlazada desde el hilo de kytv en zzz.i2p 20:17:04 <zzz> básicamente la entrada a Tails es un paquete deb 20:17:19 <zzz> pero creo que tienen una lista de quejas acumuladas 20:17:25 <eche|on> call out on twitter 20:17:33 <str4d> +1 en Twitter 20:17:35 <zzz> ¿alguien más tiene algo que informar sobre la sustitución de kytv? 20:18:07 <str4d> No he avanzado más en el servidor de CI Buildbot desde que lo mencioné en IRC hace una o dos semanas 20:18:23 <str4d> Haré más trabajo en ello este fin de semana 20:18:42 <zzz> ok. hay mucho en la lista, que cada uno elija algo importante. 20:19:02 <zzz> última llamada para 2) 20:19:46 <str4d> Si nadie más lo hace, yo *podría* coger el bot/relay de IRC. Poco probable por ahora. 20:20:34 <zzz> creo que los builds de deb están en buen estado pero aún hay cosas como arm para jessie que puede que haya arreglado hoy, o puede que no 20:21:19 <zzz> 3) Actualización de la planificación de la 0.9.26 http://i2p-projekt.i2p/en/get-involved/roadmap http://zzz.i2p/topics/1960 20:21:33 <zzz> ok quiero hacer 3a) calendario y luego 3b) GMP 6 20:21:38 <zzz> 3a) calendario 20:22:03 <zzz> la hoja de ruta dice 'mayo' y 6-7 semanas desde la última versión, el 22 de marzo, sería principios-mediados de mayo 20:22:36 <zzz> en las reuniones de la hoja de ruta hace un mes, ideamos un plan ambicioso incluyendo el protocolo de suscripción de la libreta de direcciones 20:23:16 <zzz> pero todo se vino abajo al día siguiente cuando todo lo de kytv cayó y fue menos probable que regresara 20:23:36 <zzz> así que no he empezado aún nada relacionado con la 26. las últimas 2-3 semanas han sido a tiempo completo con debian/launchpad 20:24:01 <str4d> ~siete semanas desde ahora es finales de mayo. ¿Crees que sería factible? 20:24:15 <str4d> (Ahora que lo de debian está mayormente bajo control) 20:24:19 <zzz> eso empujará la 26 probablemente a junio, y estaremos muy por detrás de la fecha límite de Tails 2.4 20:24:37 <str4d> Uf 20:24:37 <zzz> finales de mayo podría suceder, pero cada día es menos probable 20:24:42 <str4d> ¿Cuándo es la fecha límite de Tails? 20:25:11 <zzz> no lo sé de memoria. Ya les volví a pedir que incorporaran la 25 ellos mismos (ya se negaron una vez) 20:25:23 <eche|on> I think june is fine, as tails is on the judge currently 20:25:45 <zzz> no tienen visibilidad del uso de i2p en Tails y no oyen ningún clamor, así que lo ven como más problema que beneficio 20:26:18 <eche|on> yeas 20:26:33 <zzz> normalmente, para una gran función como el protocolo de suscripción de la libreta de direcciones, lo tendría terminado una semana antes del lanzamiento _previo_, listo para hacer 'prop' 20:26:54 <zzz> así que eso son 3 semanas de retraso, más el tiempo de desarrollo que es un par de semanas al menos, o 5 semanas de retraso en total 20:27:39 <zzz> ese es el estado. Aún no he publicado nada en la hoja de ruta oficial, pero tendré que hacerlo pronto 20:27:49 <zzz> ¿algo más en 3a) calendario? 20:27:58 <str4d> ¿Qué planeamos incluir en la versión 0.9.27? 20:28:16 <zzz> mira el enlace de la hoja de ruta arriba 20:28:31 <zzz> ntcp2/dh/pt temprano 20:29:18 <str4d> Sigo pensando que las cosas deben suceder en el orden de ahí, así que lo que podríamos hacer es mover el protocolo de suscripción de direcciones a la 0.9.27 20:29:27 <str4d> Eso te da mayo para trabajar en ello 20:29:47 <zzz> pero aún no hay .26. no ha pasado nada. no hay nada ahí salvo cambios de deb 20:29:50 <str4d> Y entonces la .26 pueden ser CRLs y algo de limpieza general quizá 20:30:08 <zzz> hasta que alguien (incluyéndome) haga algo, no hay nada que lanzar 20:30:27 <zzz> así que veremos cómo va. También tengo que tomarme un par de días para hacer mis impuestos :) 20:30:37 <zzz> ¿algo más en 3a) calendario? 20:30:55 <eche|on> no miréis demasiado el calendario planificado 20:30:56 <str4d> Tengo algunos retoques iniciales de UI que han salido de mis conversaciones con sadie que podría aplicar 20:31:20 <zzz> 3b) GMP 6 20:31:25 <str4d> (no el rediseño mayor que tengo planeado sino algunos refinamientos generales) 20:31:50 <zzz> tras unos 15 meses de trabajo, tuna y yo estamos casi listos para hacer 'prop' de la rama gmp6 a trunk para la 26 20:32:05 <zzz> tuna tiene cerca de un centenar de binarios construidos durante los últimos 6 meses, esperando commit 20:32:25 <zzz> construidos de varias formas: VMs, nativo, microsoft, sistemas prestados, etc. 20:32:53 <zzz> tradicionalmente hemos registrado notas detalladas del entorno de compilación (revisiones del compilador, detalles del SO del sistema, etc.) para cada binario que registramos 20:33:13 <zzz> por desgracia, tuna no guardó registros de ninguna de las compilaciones. 20:34:06 <zzz> así que la pregunta es, ¿empezamos de cero (posiblemente nos cueste 6 meses), o solo compilo los binarios de linux e ignoro todo lo demás, o realmente no necesitamos estas notas y seguimos adelante aceptando todo lo que ha hecho tuna? 20:34:08 <eche|on> ¿alguna posibilidad de rehacerlos? 20:34:47 <zzz> tuna dice que imposible. cualquiera podría compilar los binarios linux 32/64. pero todo lo demás es problemático 20:35:00 <eche|on> buena pregunta, en este caso: rehacer o aceptar, no hay término medio 20:35:25 <eche|on> necesitamos el material de gmp para mac, win y arm 20:35:29 <zzz> lo último que me dijo tuna fue o lo tomas o lo dejas, él ya ha terminado 20:35:54 <zzz> incluso si los builds son rápidos, las pruebas son lentas 20:36:25 <str4d> ¿Tenemos el proceso de pruebas escrito en algún sitio? 20:36:54 <zzz> si vas a la última página de http://zzz.i2p/topics/1960 ha enviado todas las notas de compilación que tiene 20:36:56 <eche|on> (solo para constar, ya aceptamos otras cosas sin notas) 20:37:07 <str4d> porque esto suena exactamente a lo que deberíamos meter en un servidor de CI (integración continua) 20:37:38 <zzz> ha actualizado los readme sobre cómo compilar. hay algo de info en el hilo sobre cómo probar, y yo también he desarrollado mis propios métodos 20:38:07 <zzz> recuerda que ha lanzado 13 versiones de la colección de binarios en los últimos 6 meses 20:38:36 <zzz> hottuna, ¿tienes algo que añadir? 20:38:37 <str4d> Si alguien puede redactar una metodología de pruebas, puedo convertir eso en un tipo de compilación en Buildbot 20:38:58 <str4d> Luego solo es cuestión de encontrar máquinas que conectarlo. 20:39:08 <hottuna> un segundo 20:39:24 <str4d> Estoy pensando que probablemente deberíamos invertir en un Mac que podamos dejar corriendo en algún sitio como buildslave (agente de compilación) 20:39:44 <hottuna> eche|on: sobre reconstruir: no es imposible, pero es demasiado trabajo para mí ahora. con mucho. 20:40:02 <str4d> nada demasiado caro, pero algo que podamos usar realmente para completar el trío (ya tendremos buildslaves de linux y windows una vez que arregle lo de las VMs con eche) 20:40:10 <eche|on> hottuna: ¿hay alguna forma de cómo reconstruir? 20:40:27 <zzz> incluso si la compilación de los 100 archivos ocurriera mañana, serían 3 meses de pruebas 20:40:39 <hottuna> hay un documento readme que _debería_ contener todo lo que necesitas. 20:40:48 <str4d> Al menos, nos hemos beneficiado de las mejoras de hottuna en los distintos scripts 20:41:10 <str4d> Pero la otra pregunta es, si recompilamos ahora, ¿saltamos a 6.1 20:41:11 <zzz> además hay cambios masivos en el propio código de cpuid 20:41:23 <hottuna> str4d: los scripts no son perfectos ahora, pero en cualquier caso están mejor. 20:41:23 <zzz> correcto, quizá 6.1 20:41:25 <str4d> Sí 20:41:30 <hottuna> str4d: si recompilamos, deberíamos saltar a 6.1 20:41:44 <eche|on> ¿el nuevo código funciona bien? 20:41:57 <hottuna> eche|on: por lo que sabemos no tiene bugs (¡ja!). 20:42:07 <zzz> por supuesto, en builds de debian enlazamos dinámicamente, así que obtendrías 6.1 igualmente si está instalada (y esto me recuerda, no hemos probado las libs dinámicas de gmp 6) 20:42:10 <str4d> No estoy seguro de cuánto necesitan cambiar los scripts para hacer 6.1, pero esperaría que básicamente funcionen tal cual 20:42:14 <eche|on> si las pruebas fueron bien, inclúyelo. y reconstruyamos con 6.1 en un canal paralelo y dejemos que la info llegue después 20:42:38 <eche|on> por lo que veo, ya lo hemos probado bastante bien 20:42:51 <hottuna> eche|on: la parte complicada no fue realmente ejecutar los scripts. conseguir máquinas, preparar entornos y probar fue la parte complicada/lenta 20:43:03 <eche|on> sí 20:43:13 <str4d> hottuna, eso es lo que quiero meter en CI 20:43:15 <zzz> volvamos a la pregunta original. ¿Queremos tirar 6 meses de trabajo (en realidad llevamos con ello desde principios de 2015) o podemos aceptar los binarios que tenemos, sin notas sobre los detalles? 20:43:25 <str4d> ¿Cuántas máquinas distintas crees que usaste? 20:43:37 <zzz> dejemos CI etc. a un lado por el momento y decidamos si tenemos un problema o no 20:43:52 <hottuna> str4d: debería ser mayormente plug and play, con uno o dos targets añadidos. no tiene sentido no tener soporte para las últimas arquitecturas soportadas por gmp 20:44:13 <str4d> zzz, me inclinaría por aceptar los binarios condicionado a que hagamos una migración a 6.1 20:44:24 <hottuna> str4d: ~6 entornos distintos 20:44:29 <zzz> 6.1 está en la hoja de ruta para finales de este año 20:44:39 <zzz> los binarios actuales son 6.0 20:44:41 <str4d> ¿Cuáles son los efectos colaterales de aceptar los binarios? 20:44:41 <hottuna> str4d: no necesariamente máquinas diferentes al hacer cross-compiling 20:44:51 <str4d> 1) acaban en mtn 20:45:01 <zzz> además recuerda, nos da grandes mejoras de velocidad en cierto hardware, y también tiempo constante 20:45:17 <str4d> 2) se incluyen en los archivos de actualización e instalación pertinentes 20:45:21 <zzz> ¿'efecto colateral' = cosas malas? 20:45:28 <str4d> 2a) aumentando mucho el tamaño del archivo de actualización 20:45:44 <str4d> 3) si está roto en algún sistema particular, ¿qué pasa? 20:46:03 <str4d> Planeábamos 1) de todos modos 20:46:26 <zzz> solo registramos los binarios si se van a hacer prop inmediatamente para la .26. 20:46:28 <str4d> Lo mismo con 2), pero los binarios 6.0 serían reemplazados por los 6.1 así que no es gran cosa 20:46:37 <str4d> El que me preocupa es el 3) 20:46:43 <zzz> solo se registrarán los binarios para la release 20:47:00 <str4d> 3a) ¿hay código existente para verificar un estado de fallo? 20:47:04 <zzz> 3) es un riesgo genérico para cualquier cambio 20:47:19 <zzz> fallos en gmp suelen ser crash de la JVM 20:47:26 <str4d> 3b) ¿Hay forma de hacer fallback a un libjbigi anterior que funcione? 20:47:44 <str4d> (sea automática o manual) 20:48:00 <str4d> ¿Podríamos p. ej. renombrar el viejo libjbigi para que si hay un problema, podamos decir a los usuarios "ve y renombra este archivo"? 20:48:22 <zzz> str4d, ¿estás explorando si deberíamos cambiar jbigi alguna vez? estos son impactos genéricos por cambiar gmp en absoluto 20:49:14 <str4d> zzz, tu preocupación es no saber el origen preciso de estos binarios. Mi suposición entonces es que nos preocupa que si hay un problema, se haga mucho más difícil rastrear la fuente. 20:49:27 <str4d> Así que estoy pensando en términos de estrategias de mitigación 20:50:00 <zzz> podríamos no incluir jbigi.jar en la actualización 26, así solo las instalaciones nuevas lo tendrían. Sería un despliegue más lento. 20:50:25 <zzz> instalaciones nuevas + launchpad/deb 20:50:57 <zzz> la corrección genérica es eliminar libjbigi.so y jbigi.jar, entonces funcionas sin 20:51:01 <str4d> Podría ser buena idea de todos modos 20:51:30 <str4d> Desplegar a instalaciones nuevas, y si no oímos problemas, desplegar en actualizaciones en la próxima versión. 20:51:43 <zzz> Supongo que el punto de tuna es que nada es reproducible de todos modos. Son todos sistemas prestados y VMs ya desaparecidas 20:52:23 <zzz> eche|on, ¿está disponible la info del sistema y de msvc de la máquina que usó hottuna para los builds de win? 20:53:10 <zzz> tuna no se ofreció a ninguna investigación en absoluto, pero ¿no tomó prestado el portátil de sadie también? ¿o es todo inútil ya que puede que se hayan hecho actualizaciones mientras tanto? 20:53:24 <eche|on> tuvo acceso a la máquina win 10 en mi host kvm. Puedo iniciar sesión y comprobar 20:53:33 <str4d> Mmm, por eso me gustaría hacer los builds 6.1 en Buildbot con servidores de compilación que podamos rastrear. 20:53:57 <hottuna> zzz: tomé prestados dos Mac OS X de amigos distintos 20:53:58 <eche|on> no cambié la vm en absoluto 20:54:33 <zzz> nadie se ha ofrecido ni a coger un mac gratis que paguemos nosotros, porque nadie quiere ser el 'chico mac' 20:54:51 <zzz> así que es realmente una falta de tiempo y de gente, no de dinero 20:55:17 <hottuna> zzz: yo simplemente no quiero cacharros que tenga que cargar. 20:56:01 <zzz> aquí están las notas de compilación completas de hottuna: 20:56:03 <zzz> Notas de compilación jbigi: 20:56:03 <zzz> ------------------ 20:56:03 <zzz> Windows: Compilación cruzada, hosts linux. Compilador: GCC 20:56:03 <zzz> Linux: Compilación nativa. Compilador: GCC 20:56:03 <zzz> FreeBSD: Compilación nativa, VM. Compilador: GCC 20:56:03 <zzz> OSX: Compilación nativa. Compilador: GCC 20:56:03 <zzz> Notas de compilación jcpuid: 20:56:03 <zzz> ------------------- 20:56:03 <zzz> Windows: Compilación nativa. Compilador: MSVC 20:56:03 <zzz> Linux: Compilación nativa. Compilador: GCC 20:56:03 <zzz> FreeBSD: Compilación nativa. Compilador: GCC 20:56:03 <zzz> OSX: Compilación nativa. Compilador: GCC 20:56:17 <zzz> ¿son suficientes o empezamos de cero? 20:57:14 <str4d> Dado que vamos a migrar a 6.1 a finales de año, y que estos binarios han tenido pruebas razonables, me inclino a decir que sí. 20:57:41 <zzz> ¿alguna objeción? 20:57:45 <eche|on> al menos es un comienzo, pero en términos de "compilaciones reproducibles de Tor" no es nada. ¿qué tipo de estándares queremos? 20:58:03 <hottuna> no 20:58:34 <eche|on> Me gustaría incluirlos en instalaciones nuevas con el flag "temp". Sé que es trabajo duro. 20:59:14 <zzz> básicamente las pruebas actuales han caído a cero. La única forma de obtener más pruebas es meterlos en trunk, y una release. 20:59:17 <susbarbatus> Disculpas por engancharme a esto; tengo varios mac, y no tengo problema en ser el tipo de mac o bsd. Si alguien puede decirme qué se requiere después de la reunión o así, puedo evaluar si sería algo a lo que pueda contribuir si tengo suficiente conocimiento / lo pueda aprender. 20:59:29 <zzz> genial susbarbatus 20:59:44 <str4d> susbarbatus, eso sería fantástico 20:59:47 <zzz> ok entonces pidamos a hottuna que los registre 20:59:53 <eche|on> zzz: sí, nunca dijimos que la release es 100% segura y completa^^ 21:00:05 <zzz> hottuna, la rama es i2p.i2p.str4d.gmp6 (NO i2p.i2p.zzz.gmp6) 21:00:17 <hottuna> ok 21:00:38 <zzz> hottuna, no olvides hacer mtn drop de los que haya que eliminar. Cuando termines, el directorio debe coincidir exactamente con lo que hay en tu zip v13 21:00:50 <zzz> ¿algo más en 3b) ? 21:00:55 <hottuna> ¿quieres que eliminemos los viejos jcpuid/binarios de plataformas para las que no construimos? 21:01:09 <str4d> susbarbatus, lo que querría montar es un servidor de compilación, si puedes comprometerte a tener un mac siempre encendido y estar disponible para preguntas/asistencia cuando algo falle. En general no requeriría mucha participación por tu parte, porque el servidor de compilación se controlaría automáticamente :) 21:01:28 <zzz> Creo que la propuesta de hottuna era que v13 fuera EXACTAMENTE lo que se iba a lanzar, nada más, nada menos. 21:01:38 <zzz> si quieres podemos revisarlo de nuevo después de la reunión 21:01:38 <str4d> O si no siempre encendido, al menos fácilmente iniciable en la configuración del servidor de compilación 21:01:51 <hottuna> zzz: espléndido 21:01:54 <str4d> (el buildmaster manejará buildservers que no estén siempre online) 21:02:12 <zzz> dejemos el tema del servidor de compilación sobre la mesa y pasemos a 4) 21:02:22 <zzz> 4) Planificación para HOPE http://zzz.i2p/topics/1968 21:02:23 <susbarbatus> str4d: no hay problema. Puedo conectar mi mac mini ~2012 para eso. Es lento pero no estará haciendo nada más. 21:02:24 <str4d> ACK 21:02:33 <str4d> ^5 susbarbatus :) 21:02:52 <eche|on> hope - I got a ticket to spent 21:02:57 <zzz> Me reuní con Lance esta semana. la propuesta sigue siendo que nos ofrezca una sala de conf. pequeña todo el día, o el día antes o después de HOPE 21:03:04 <zzz> es decir, 21 o 25 de julio 21:03:22 <zzz> Le insistí en que necesitamos una fecha y compromiso pronto, para poder comprar billetes de avión 21:03:46 <zzz> esto no estaría abierto al público. solo por invitación, 5-6 personas, simplemente un espacio para reuniones de la hoja de ruta, etc. 21:03:51 <str4d> A estas alturas no puedo comprometerme a estar allí, aunque hay una pequeña posibilidad de que realmente esté en EE. UU. para entonces 21:04:00 <zzz> además le presentamos lo que estamos haciendo y viceversa 21:04:30 <zzz> ahora mismo tengo a mí y a sadie como seguros, con comradenosebleed y lazygravy como posibles. ¿Quién más? 21:04:49 <zzz> ¿y cuál es la fecha límite para que tengáis listos los arreglos de viaje? 21:05:33 <zzz> si solo somos sadie y yo quizá podemos cancelar todo, pero veamos 21:05:39 <zzz> ¿alguien? 21:06:04 <zzz> ¿viene hottuna? 21:06:07 <str4d> (todo depende de cuándo se convoque mi defensa de tesis, no tengo idea de cuándo será aún) 21:06:09 <str4d> (y también de otros temas relacionados con el visado) 21:06:17 <str4d> Si mi defensa de tesis es antes, me gustaría estar allí (aunque solo sea volando de paso) 21:06:17 <eche|on> Estoy interesado, pero no puedo pagar el vuelo y hotel. esp. si nos reunimos más tarde en can 21:06:17 <str4d> Así que pregúntame de nuevo en un mes o así 21:06:45 <zzz> ok, mantendré la presión sobre lance para concretarlo, y espero que aparezca la gente 21:06:50 <zzz> última llamada sobre 4) 21:07:00 <hottuna> zzz: es realmente incómodo para mí por fechas. tengo que estar en la UE el 16 de jul. para una boda. 21:07:15 <hottuna> No creo que me atreva a comprometerme ahora,. 21:07:20 <zzz> genial, pasa por NYC a la vuelta :) 21:07:26 <hottuna> (o en absoluto si tiene que ser ahora) 21:07:33 <hottuna> hmmph.. 21:07:44 <hottuna> no es mala idea 21:07:47 <zzz> 5) Breve revisión de las reuniones mensuales y de la gestión del proyecto tras 3 meses 21:07:59 <str4d> Así que apúntame como un "ojalá" para la quedada, y poco probable para HOPE (ya que no puedo comprometerme a necesitar una entrada, pero usaré una de sobra si resulta que estoy allí) 21:08:26 <zzz> ok, desde mi perspectiva esto no está funcionando en absoluto, casi no se completan puntos de acción, así que ¿se pueden arreglar las cosas o deberíamos dejar las reuniones mensuales? 21:08:40 <str4d> Creo que se pueden arreglar 21:08:42 <zzz> si nadie hace nada, no hay nada que gestionar. No es tan malo, pero casi 21:09:11 <str4d> Como mínimo, creo que las reuniones mensuales son útiles 21:09:30 <zzz> el objetivo también era transferir la gestión del proyecto a sadie pero ni siquiera está asistiendo a las reuniones así que eso tampoco va por buen camino 21:09:32 <hottuna> Coincido en eso 21:09:44 <str4d> Ella pensó que era una hora antes 21:09:49 <str4d> Está en otra reunión ahora 21:10:19 <str4d> (llegó una hora antes y nadie hablaba aquí) 21:10:41 <zzz> claro, a todo el mundo le encantan las reuniones cuando no tienen que dirigirlas. Pero yo quedo como un tonto preguntando cada mes si algo que alguien prometió hace 3 meses ha pasado. Estoy cansado. 21:10:49 <str4d> He hablado de esto con sadie, y ahora tenemos reuniones semanales para mantenernos al día con los puntos en los que ambos estamos trabajando 21:11:19 <str4d> zzz, entonces no hagas que el foco de la reunión sea "¿hiciste esto?" 21:11:36 <zzz> quizás esto suene demasiado grave pero con la falta de progreso y la desaparición de kytv creo que estamos en serios problemas 21:11:40 <hottuna> zzz: ¿cuándo se supone que debe ocurrir la transición a sadie? 21:11:40 <str4d> Creo que las reuniones mensuales deberían ser más para reevaluaciones de prioridades y reorganizaciones 21:11:58 <zzz> ok, entonces ¿cómo mantenemos a la gente en curso para hacer lo que prometieron? 21:12:13 <str4d> mientras que el "¿has hecho esto?" necesita a) más responsabilidad personal y b) más seguimiento uno a uno 21:12:30 <hottuna> zzz: no es genial de ninguna manera, pero "serios problemas" probablemente sea exagerar. 21:13:02 <str4d> zzz, en mi caso, he establecido reuniones semanales con sadie para ayudarme a mantenerme en curso, y le he dado acceso a mi lista de tareas de I2P para que ayude a priorizar 21:13:07 <susbarbatus> str4d: Creo que el punto es más bien que, si todos cumplieran promesas/compromisos, entonces zzz no tendría que hacer la pregunta de si hiciste esto ;). 21:13:12 <str4d> (solo hemos tenido una reunión hasta ahora, así que aún tengo que ver cómo funciona) 21:13:17 <str4d> susbarbatus, sí 21:13:50 <str4d> Debemos ser lo suficientemente flexibles para manejar el hecho de que la gente hace esto por diversión/voluntariado fuera de su trabajo regular 21:14:13 <zzz> correcto. Mi sistema actualmente es que cuando terminas algo, lo informas en el hilo de zzz.i2p de la reunión, para que NO tengamos que ocupar tiempo de reunión con ello 21:14:15 <str4d> Pero también debemos enfatizar que si alguien no está haciendo cosas, no está ayudando 21:14:28 <zzz> solo cuando la gente no termina y no informa es cuando tenemos que perder tiempo aquí 21:14:42 <str4d> y es mejor pasar un punto a otra persona que bloquear indefinidamente 21:14:54 <str4d> (lo dice el tipo que actualmente está bloqueando indefinidamente I2P Android :P ) 21:15:19 <zzz> así que str4d y sadie han configurado un sistema paralelo de gestión del proyecto no público como experimento. eso es interesante, pero por supuesto no está claro cómo se relaciona con lo que estoy haciendo, o si debería seguir haciéndolo 21:15:55 <str4d> zzz, es una parte del panorama más amplio 21:16:28 <str4d> Como dije arriba, creo que intentar hacer el "¿por qué no hiciste esto?" en una reunión mensual no es tan útil como pensamos que podría ser 21:16:35 <zzz> así que la gestión del proyecto vía mi foro y poner en evidencia en reuniones mensuales, estoy preparado para declararla un fracaso 21:16:50 <str4d> porque si no han hecho nada durante las primeras tres semanas, no es probable que lo terminen la última 21:17:21 <str4d> de ahí que piense que revisiones rápidas más regulares para quienes tienen puntos pendientes es mejor, que es lo que estoy probando con sadie 21:17:34 <zzz> a estas alturas no creo que vuelva a recibir el borrador de comradenosebleed, ni un CoC, ni casos de uso en la web, ni un lanzamiento de android, al menos no para una fecha concreta por lejos que se ponga 21:18:10 <zzz> así que propongo detener la revisión mensual de puntos de acción. Como siempre, la gente hará o no lo que quiera en código abierto, y es muy muy difícil convencer a alguien de hacer algo por aquí. 21:18:36 <zzz> la gente hará lo que quiera, y las zanahorias y palos que tengo no son efectivos 21:19:50 <str4d> Yo voto que mantengamos las reuniones mensuales, y las usemos para seguir ajustando nuestras prioridades basándonos en lo que SÍ se hace y lo que ha pasado en el último mes (p. ej. lo que acabamos de hacer sobre la .26 tras kytv) 21:20:56 <susbarbatus> Bien, ¿cómo va ese sistema de recompensas en este momento? P. ej. es una lista pública resumida con incentivo pagado. ¿La gente sigue mirándola? 21:20:59 <susbarbatus> Lo que quiero mencionar; ¿qué hay de micropagos por tareas? 21:21:03 <str4d> mientras, si alguien acepta hacer algo, también debería aceptar mantener a sadie informada sobre el progreso, o al menos dar a sadie un canal de comunicación para regañarles :P 21:21:21 <zzz> ok entonces propongo dimitir como gestor del proyecto, a ser reemplazado por algún sistema y persona por determinar. Tendremos reuniones mensuales pero sin revisión de puntos de acción 21:21:54 <zzz> la próxima reunión será el mar. 3 de mayo 21:21:58 <zzz> ¿algo más en 5) 21:22:10 <zzz> ¿algo más para esta reunión? 21:22:35 <str4d> Nada por mi parte 21:22:53 <zzz> gracias a todos, reunión larga hoy 21:22:58 * zzz *bafs* the meeting closed