Tres PRs a Rowboat en 24 horas y siete issues reclamados que nunca dieron código

Un desarrollador ha dedicado una jornada a mandar pull requests a Rowboat, el proyecto open source que acumula 17.500 estrellas en GitHub. Salieron tres, con un commit limpio cada uno, y el relato de cómo llegó hasta ellos dice bastante sobre el estado de los trackers de issues en proyectos populares.

El primero (#1031) arregla el subtítulo de Meetings en la barra lateral: un evento de día completo de la semana siguiente aparecía como si fuera de hoy y tapaba otro evento con hora más cercana. La causa era un orden que colocaba los eventos de día completo primero sin mirar la fecha, duplicado en dos componentes. Lo corrigió ordenando por hora de inicio y añadiendo un calificador de fecha a los eventos futuros de día completo, para que nunca se lean como de hoy.

El segundo (#1032) es el más interesante de operar. En modo hijo, si el rowboat-server lanzado moría, la aplicación se limitaba a registrarlo y la interfaz se quedaba con datos viejos. Ahora lo relanza con retroceso exponencial (de 1 a 16 segundos, con tope de 30) y se rinde tras cinco fallos consecutivos con un mensaje claro, sin relanzar cuando el apagado fue intencionado. La parte fina está en el intercambio de estado: el forwarder de RPC cachea una promesa de "listo", así que el relanzamiento tiene que sustituir esa promesa o la app sigue hablando con un proceso muerto.

El tercero (#1033) añade un modo de CLI para mostrar el emparejamiento en el servidor sin interfaz. Antes había que entrar por SSH, leer el fichero de clave del servidor y mirarlo con lupa. Ahora un comando imprime las URL de emparejamiento, el código de acceso y el payload exacto que escanea la app móvil, opcionalmente como QR en la terminal. Sin dependencias nuevas.

Los fantasmas del tracker

Mientras elegía qué tocar se encontró con un patrón. Siete issues sobre endurecimiento del servidor estaban reclamados por la misma persona, todos en un solo día, diez días antes de que él llegara. Ninguno tenía pull request detrás. Reclamar y desaparecer, dice, es como reservar mesa en un restaurante y no pedir nunca.

Dos de esos issues ya estaban resueltos en main: la lista blanca de la cabecera Host y la autenticación de WebSocket que prioriza cabeceras habían entrado en un PR de endurecimiento ya fusionado. Los issues simplemente nunca se cerraron. Dejó comentarios con nombres de fichero y referencias de línea para que un maintainer lo verificara de un vistazo, incluida una autocorrección: reclamó el issue de WebSocket, miró el código antes de escribir nada, vio que el arreglo ya estaba dentro y lo dijo con la evidencia delante.

En el capítulo de revisión, su propio agente le jugó una: en el tercer PR había ramificado desde la rama del PR anterior, lo que habría arrastrado un commit ajeno. Lo cazó revisando el diff y lo llevó a main limpio con un cherry-pick. Ninguno de los tres ha recibido revisión todavía; eran las dos de la mañana en la franja horaria de los maintainers.

Queda una observación sobre cómo elegir tarea. Los issues fáciles del repositorio están ya cogidos, así que el hueco real está en leer el código y comparar lo que dice el issue con lo que hace main de verdad. A veces la contribución es exactamente esa diferencia.