Bitcoin Core y GitHub (2022-10-11)
Transcripción De: Bryan Bishop
Traducción Por: Blue Moon
Tags: Bitcoin core
Categoría: Core dev tech
Bitcoin Core y GitHub
Creo que en este punto está bastante claro que no es necesariamente un “si” salimos de github, sino un cuándo y cómo. La pregunta sería, ¿cómo lo haríamos? Esto no es realmente una presentación. Es más bien una discusión. Hay algunas cosas a tener en cuenta, como el repo de bitcoin-gh-meta, que captura todas las cuestiones, comentarios y pull requests. Es bastante bueno. La capacidad de reconstruir lo que hay aquí en otra plataforma no parece posible en su totalidad.
Los issues podrían reconstruirse con relativa facilidad. El código, obviamente, no será un problema. Las revisiones y el etiquetado de las cosas a las líneas individuales, así como una especie de mantener el hilo de lo que está en github parece casi imposible. No lo he intentado. No he sido capaz de encontrar a nadie que sea capaz de hacerlo.
¿Las cosas de revisión línea por línea no están en bitcoin-gh-meta? ¿Tiene las reacciones de los emoticonos? Los PRs se consideran issues. ¿Tiene el repo de la GUI? ¿Después de que se dividiera? No lo sé.
BB: Podrías hacer que haya un universo paralelo y que github se convierta en un espejo. Habría un único usuario con privilegios de publicación.
La cuestión no es cómo lo hacemos, sino quién lo hará. Simplemente se haría cada vez más evidente que este movimiento tiene que ocurrir. Tiene que haber un libro de jugadas y/o un equipo que realmente lo haga realidad. Además, cuando se empieza a introducir como, si es gitlab, o algo más, pero gitlab parece estar ganando impulso como una solución de auto-alojamiento. ¿Quién lo alojará?
BB: Github también se ha autoalojado. Eso podría ser un trampolín si es necesario.
Es como Github Enterprise. Les pagas dinero. No sería permanente. En el escenario del día del juicio final de Github queriendo censurar el proyecto bitcoin, si es auto-alojado ¿tienen la capacidad de interferir de alguna manera con él? Tienen alojamiento on-prem. ¿Qué pasa si te cortan el acceso? No pueden entrar por ssh y tomarlo, pero es de suponer que a una empresa no se le permitiría seguir usándolo. Podría ser una alternativa a raspar todo, tal vez sólo mantener una versión on-prem y sería más fácil que mantenerlo fuera de un script.
Tener una copia de seguridad está muy bien, pero siempre hay que probar la redistribución de la copia de seguridad antes de poder confiar en ella.
¿Qué pasa si por casualidad estamos violando los términos de servicio de gitlab? Bueno, no dependes de ellos, simplemente lo usas y lo alojas tú mismo. Hay una edición comunitaria de gitlab CE que puede tener una licencia que pueden ajustar contra los proyectos presumiblemente. Pero son tus datos.
Independientemente de gitlab vs github, en términos de migrar todo lo que pueda sobre, hay que. Pero habrá alguna pérdida de datos. ¿Cuál es la tolerancia a esa pérdida? Creo que, en cierto modo, es bastante positivo tener este momento de ruptura de la utilización de la antigua plataforma a la migración a una nueva plataforma. Hay 450 relaciones públicas abiertas. Hay 450 cuestiones abiertas en este momento. Algunos de ellos sería genial para tener usuarios activos como reabrir esas cosas. En lugar de una migración, ¿propones un comienzo limpio? Sería una purga, sí. El código y las cuestiones se trasladarían, pero los PR pendientes tendrían que reabrirse. Los problemas son bastante fáciles de trasladar. No sé cómo funcionan los nombres de usuario. Para los usuarios que no tienen claves públicas en su github, se puede prohibir a esos usuarios o congelar sus cuentas, y los usuarios existentes de github que establecen su clave pública pueden ser portados y verificados como el mismo usuario.
En mi opinión, gitlab debe tener un importador de issues y pull requests. ¿Por qué no lo usamos? Podríamos. Tengo entendido que el importador para la parte de pull requests no es tan fiable como la migración de issues. ¿Podemos pagar a alguien para que lo haga? Un contratista no tendría que saber nada sobre bitcoin. Sólo tiene que ponerlo en marcha y trasladar todo. Nos darían scripts y códigos para hacerlo. No hay nada de dominio específico aquí. Es un proyecto de alcance muy específico. Es bueno para una recompensa o un contratista. Probablemente hay personas que son expertos en estas cosas. Nosotros no somos expertos en esto.
¿Qué hay de la verificabilidad? ¿Cómo podría alguien verificar que todos los datos fueron transportados?
¿Quién albergaría el nuevo? ¿Quién lo pagaría? ¿Puede haber una versión federada? ¿Qué tal un enlace IPFS y entonces cualquiera podría almacenarlo?
¿Hemos descartado los sistemas descentralizados? ¿El proyecto radicalue? No he jugado con él. Cuando se busca una oferta descentralizada…
¿Quién sería el administrador continuo del servidor? Digamos que Chaincode lo paga en AWS… habría un servidor. No estaría en el edificio de Chaincode, pero pagan la factura, quizá haya una cámara. Es una cosa. Podría alimentar a los trolls. Si no quieres que lo alojemos, entonces ayúdanos, y lo alojas tú en su lugar. Podrías configurar un sistema primario, y luego una copia de seguridad pura. Cualquiera podría ejecutar una réplica en vivo. Si a alguien no le gusta Chaincode, entonces cambia los DNS a otro. ¿Quién controlaría los DNS? No vamos a resolver esa cuestión en esta reunión.
Para minimizar las críticas, se podría tener un repo de github que tenga todos los scripts necesarios para ponerlo en marcha de inmediato. Lo alojamos en este DNS, no queremos, y si quieres ejecutar el tuyo, lo ejecutas en 10 minutos con los contenedores docker y el playbook y ya lo tienes. Todavía estamos en github en este punto, pero nos damos un descanso en caso de incendio donde cualquiera - si github censura, entonces cualquiera puede girar para arriba y ejecutarlo.
¿Vale la pena hacer eso de forma preventiva o queremos esperar hasta que github nos de la razón? Bueno, si tienes dos sistemas, la sincronización bidireccional es difícil. Github debería ser de sólo lectura, excepto para un escritor. Una vez que la migración ocurre, no deberíamos tener que hacerlo de nuevo en el futuro.
¿Por qué no nos movemos de Github y lo hacemos? ¿A qué estamos esperando? Cuanto antes salgas del sistema y empieces en el nuevo mundo, entonces no tendrás que esperar. Los pasos iniciales que se dan son los mismos para ambas estrategias.
La cuestión de quién dirige el servidor y quién es su propietario es mucho más relevante si te estás mudando. Pero si ya lo tienes listo para ir, entonces puedes ir a martillear sobre quién lo maneja y es el dueño más tarde. Si intentas hacer ambas cosas al mismo tiempo, puedes tener más controversia. Si tenemos algo que es mejor y es un modelo mejor, entonces deberíamos hacerlo. Pues no creo que funcione mejor. Github con todos sus defectos es realmente un buen producto. No creo que lo sea. ¿Lo es? ¿Alguien tiene acceso con Chaincode o Spiral hosting o ambos?
La realidad es que github es la autoridad central ahora mismo. Si lo trasladamos a otra autoridad central, no puede ser peor. Github podría considerarse más neutral.
Tornado Cash y youtube-dl son dos historias de github que importan aquí. O los repos de github iraníes. ¿Será Chaincode capaz de montar una defensa tan buena como la de Github? Se trata sobre todo de sus abogados, pero al mismo tiempo hay que luchar allí en los sistemas centralizados contra el gobierno.
¿Alguien ha hablado con Github a alto nivel? Sólo para preguntarles, ¿son positivos en cuanto a que alojen el proyecto bitcoin? ¿Es algo que vale la pena mirar? Github fue a batear para youtube-dl que estaba luchando contra el conglomerado de derechos de los medios digitales. Youtube-dl fue después de la adquisición de Microsoft pero antes de que el anterior CEO se fuera. ¿Te creerías la respuesta que te diera Microsoft? No sé si su respuesta sería relevante. La razón por la que quiero estar fuera de github es que moralmente creo que está mal que hayan prohibido el repositorio de Tornado Cash. Si revierten eso, sería bueno. Github ha entrenado a Copilot en el software de código abierto… hay un montón de cosas grises que hacen. Como plataforma, no son súper grandes.
He visto algún “Login con Github” aunque no esté alojado en github. Eso puede ser bueno para la gente que está acostumbrada a los inicios de sesión de los usuarios de github. Usando oauth podemos hacer que las identidades de github se transporten.
Un reescritor de url para los enlaces de github sería un buen comienzo. Podría ser un dominio de redirección que va a github. Más tarde podría ser redirigido a una nueva ubicación en el futuro si las cosas se mueven fuera de github.
La acción inmediata es encontrar a alguien que configure una réplica tan buena como sea posible y proporcione un libro de jugadas para en el caso de una emergencia cómo moverse fuera de github y realmente entregar este proyecto. El siguiente paso sería socializar con un público más amplio la idea de un traslado y averiguar los detalles de la propiedad de los DNS, quién aloja el primario, qué otras copias de seguridad habría, etc. El primer punto de acción podría basarse en una recompensa. Podríamos iniciar un documento en el que digamos que queremos contratar a alguien. Deberíamos acordar cuáles son las características mínimas. ¿Cuáles son los criterios de realización? Vamos a estar en desacuerdo en esos puntos así que vamos a escribirlo… ¿cuáles son las cosas que queremos? Tal vez alguien podría hacer funcionar el importador de gitlab github y preservar mejor los metadatos.
La API graphql de Github es bastante potente. La API heredada no tanto. Pero la de graphql es bastante buena. ¿Puedes obtener datos históricos de ella? Lo miré hace tres años cuando estaba pensando en hacer un bot de Twitter que tuiteara cada vez que alguien hiciera una revisión. Eso era factible. Tal vez podríamos complementar lo que falta con como hacer una exportación mientras estamos todavía en github y en buenos términos con ellos. Las aprobaciones de solicitudes de extracción de Github y los emoticonos podrían ser más difíciles de contextualizar, pero también bastante marginal en valor. Pero si no estás usando cosas de git nativamente, entonces eso te hace más dependiente de bitcoin-gh-meta. Deberíamos averiguar qué capta el importador y qué no. Alguien debería comprobarlo. ¿Cómo se pueden organizar los datos después de sacarlos? ¿Cómo podemos recrear algo que es nativo de cómo funciona github, y hacer que se aplique a gitlab o alguna otra plataforma?
Tal vez llegar a gitlab y ver si esto sería una pluma en su gorra y tal vez podría ayudar con este tipo de migración. Es un poco su marca.
¿Y si volcamos todas las líneas de código y los comentarios y todo, pero no nos preocupamos de tenerlo en gitlab? Sólo un sitio web archivado con HTML estático. Eso podría ser más fácil. Tener una estática está bien, pero ahora tienes dos o más lugares para realizar una búsqueda. ¿Alguien utiliza la búsqueda en github? Parece que algunas personas podrían estar utilizando la búsqueda de github.
Los comentarios de código en las solicitudes de extracción pueden ser difíciles porque algunos comentarios pueden ser para las ramas que ya no existen en un PR o se adjuntan a un commit que no existe. Github almacena las ramas antiguas que crees que se han eliminado si se comentan en los pull requests del repositorio padre. Los push forzados pueden ser difíciles de atrapar. Los push forzados podrían tener una fecha de caducidad en github, tienen reglas de recolección de basura para eso.
Tal vez github estaría dispuesto a darnos un volcado de toda la historia incluyendo force pushes, comentarios en las ramas bifurcadas, etc.