Visión de los mantenedores del proyecto Bitcoin Core

https://twitter.com/kanzure/status/1136568307992158208

¿Cómo piensan o sienten los mantenedores que va todo? ¿Hay frustraciones? ¿Podrían los colaboradores ayudar a eliminar estas frustraciones? Eso es todo lo que tengo.

Sería bueno tener una mejor supervisión o visión general sobre quién está trabajando en qué dirección, para ser más eficientes. A veces he visto gente trabajando en lo mismo, y ambos hacen un pull request similar con mucho solapamiento. Esto es más un problema de coordinación. Creo que en general el proceso de mantenimiento funciona bastante bien. Tener a MarcoFalke ha sido realmente útil, y fanquake con las etiquetas, y meshcollider, estamos en un buen estado.

¿Debería fanquake ser un mantenedor? ¿Es un buen momento para nominarlo? Claro, sí. Sí. Si se convierte en mantenedor, ¿va a dejar de etiquetar? En realidad es un equipo de personas en una granja en Australia. Actualmente no tiene su clave en el archivo del mantenedor. Técnicamente podría fusionar algo, pero entonces todo fallaría. Las ramas están todas protegidas también. Github lo verifica también, ¿verdad? En efecto.

Hay demasiados pull requests abiertos. Por favor, no abran más pull requests, especialmente para cosas pequeñas. Si cambias el código consensuado, por favor, ten puntos de referencia y demuestra que es mejor. A veces hay una falta de motivación para los pull requests. Esa es mi principal queja.

¿Cuándo podemos hurgar y conseguir un benchmark de descarga de bloques inicial en travis-ci? Esto afecta a los usuarios. La mayoría de los benchmarks son microbenchmarks, pero este realmente afectaría a los usuarios. Ahora mismo puedes decir "sí, es más rápido" pero no hacer nada realmente. ¿Cuándo vamos a tener integración de benchmarks en los bots? Podríamos tener algo que se ejecute automáticamente basado en las etiquetas. Sólo hay unos pocos pull requests que son sensibles al rendimiento. Es algo que se puede solicitar para un pull request, como needs-build y needs-benchmark. También podría hacer una construcción una vez al día para el maestro y notificar para las regresiones. Ya tenemos eso, para la evaluación comparativa y las regresiones de rendimiento. No avisa, pero puedes ir a comprobarlo. Probablemente deberíamos añadir una alerta. Hace IBD hasta una cierta altura de un par local, así como la ejecución de todas las pruebas y los puntos de referencia y todas esas cosas. Marco lo vigila de cerca. Pero sí, está ahí arriba. Hay 11 máquinas dedicadas allí. Son servidores genéricos HP de 4 núcleos o algo así. La mitad de ellos tienen discos duros, algunos tienen SSDs. O un sistema donde se puede hacer clic en una solicitud de extracción en una cosa, y luego obtener todas esas construcciones.

La cartera ha ido bien en los últimos meses. Tenemos reuniones quincenales. Parece que hemos hecho mucho trabajo. El trabajo de los descriptores es un enfoque común. Así que tenemos un grupo de personas que se ocupan de lo mismo. Históricamente, el tiempo de progreso significativo en ciertos dominios de código, es a menudo cuando hay un grupo de personas todas activas con un objetivo común y probablemente tienen un mantenedor a bordo. Cuando hay suficiente impulso, tener subproyectos o grupos de trabajo o grupos de interés especial o como quieras llamarlo, parece ayudar. Y es más divertido. Los ciclos de interacción son mucho más pequeños. No hay que esperar tanto para la revisión porque hay otras personas a las que puedes hacer rebotar las ideas y ver las cosas inmediatamente. No sé cómo escalar esto a otras cosas porque el requisito previo es que la gente tiene que estar interesada.

¿Hay otras áreas en las que se pueda crear un impulso, pero que no se produzca de forma orgánica? Hay secciones en las que me gustaría que se creara un impulso, como un montón de trabajo p2p interesante. ¿Y qué hay de la división en redes p2p separadas? Como tener una red de bloques, y una red de transacciones, que básicamente operan de forma independiente la una de la otra. Resuelven diferentes problemas que te interesan. Deberíamos hablar de esto más tarde. ¿Deberíamos tener reuniones p2p semanales? Tendríamos que encontrar un mantenedor de p2p. Hay una verdadera escasez de gente que entienda de p2p. Debería haber un documento técnico de la filosofía de diseño p2p para Bitcoin Core. La gente no entiende el modelo actual, o por qué Dandelion es importante. ((Alguna confusión sobre cómo pronunciar diente de león; parece que nos hemos decantado por dan-dillion)). Para crear un impulso en torno al p2p... los descriptores están añadiendo impulso para la cartera y las reuniones de la cartera, y tener un mantenedor de la cartera. Pero sin un mantenedor de p2p, parece que aj, sdaftuar, carl están interesados.

Otra área de impulso es el sistema de construcción. ¿Cuándo vamos a revisar el sistema de construcción? ¿Cuándo lo vamos a fusionar? Parece que cada dos años aparece alguien que quiere reescribirlo desde cero. No se trata de "cuándo cambiamos a cmake", sino de "cuándo abandonamos gitian". No tengo una respuesta a eso, pero es un trabajo en progreso.

Una de las cosas que fue útil fue cuando fanquake comenzó el triaje, y la curaduría de las solicitudes de extracción un poco. ¿Hay más cosas en esa línea que se podría hacer? ¿Es útil para los mantenedores tener a otras personas ayudando en esas tareas? Podría ser bueno tener una etiqueta "esperando al autor". Es una buena idea. Sí. ¿Reemplazaría esto a la etiqueta "necesita base"? Porque esa también es "esperando autor". Tal vez se podría combinar. No es común para nosotros, pero podríamos hacer el rebase en el momento de la fusión nosotros mismos. Pero no lo hacemos porque queremos mostrar que lo que el autor ha enviado ha sido fusionado. Para cosas triviales, lo hice en el pasado a veces. Pero REST se fusionó en un estado en el que no podíamos usarlo, así que nos equivocamos con eso en el pasado. Las solicitudes de extracción podrían cerrarse automáticamente después de unos meses de no recibir comentarios del autor. 3 semanas es demasiado pronto.

Añadimos la etiqueta "necesita concepto ACK" ayer, ¿verdad? Digamos que necesitamos añadir una etiqueta "necesita autor" o algo así, ¿debemos enviar un mensaje a fanquake? Pide a uno de los mantenedores que edite, no importa quién o dónde. Los autores no pueden añadir o eliminar etiquetas. Los mantenedores mantienen las etiquetas. Podríamos tener etiquetas de usuarios en los comentarios, y un bot para analizar el texto del comentario, pero querríamos filtrarlas de las etiquetas curadas por los mantenedores. El bot puede comprobar si la persona está en el grupo de reinicio de Travis.

Los usuarios pueden editar temas y añadir etiquetas, pero no empujar al repositorio. Esto es posible con ramas protegidas en github, pero esto no está soportado en github realmente. Si te olvidas de una rama, es un problema.

Alguien en China está atacando mainnet y testnet con un DDoS en este momento. Bueno, al menos alguien está usando testnet por una vez...