Si pudiera crear mi propio GitHub

 (matduggan.com)
5 puntos por GN⁺ 2 시간 전 | 1 comentarios | Compartir por WhatsApp
  • Los forge modernos como GitHub, GitLab y Gitea comparten el modelo al estilo GitHub, pero en el trabajo real lo central sucede más dentro de funciones del forge como PR, Actions, Issues y Releases que en git mismo
  • Un nuevo forge debería ejecutar de forma remota hooks pre-commit obligatorios que den retroalimentación antes del push y no después del commit, para reducir commits repetidos como Feature, fix, actually fix y asdfasdf
  • La aprobación de PR debería ir más allá de la dicotomía aprobar/rechazar y, como Gerrit, admitir aprobaciones débiles y marcas para revisarlo después; además, cambios pequeños cuyo autor sea mantenedor y que un LLM considere de bajo riesgo deberían poder pasar con más flexibilidad
  • Los stacked PR deberían ser una función de primera clase tanto del forge como del VCS, y el repositorio local debería representar el estado completo del repositorio, incluyendo no solo código sino también aprobaciones de PR e issues
  • La combinación deseada sería JJ como VCS, un nuevo forge que pueda alojarse en unidades pequeñas, y Actions con soporte para firmas, SHA y ejecución offline; en una era en la que GitHub es el forge gigante predeterminado, todavía no existe una alternativa claramente definida

Los problemas de los forge modernos

  • GitHub, GitLab y Gitea siguen casi el mismo modelo de diseño, aunque difieran en detalles, y se parecen más a herramientas que trasladaron el patrón de la industria creado por GitHub
  • La mayor parte de las funciones de los forge actuales casi no se relaciona directamente con git en sí, y los clientes están desconectados de la forma en que realmente se usan
  • git es un sistema de control de versiones distribuido que encaja bien en entornos como el desarrollo del kernel, adecuado para flujos de trabajo basados en alta confianza donde se envían parches por correo a mantenedores y estos administran su área y deciden si fusionarlos
  • Pero en la mayoría de los trabajos, git se parece más a un medio para hacer pull/push de código desde un repositorio guardado en un forge central, y el trabajo importante ocurre dentro del forge
    • Los Pull Request se convierten en un medio para hacer cumplir el principio de cuatro ojos
    • GitHub Actions ejecuta pruebas y linting en los Pull Request para verificar funcionalidad y cumplimiento de requisitos de la organización
    • La identidad de usuario dentro del forge se convierte en el criterio para validar a los usuarios
    • Los Issues se usan para rastrear problemas de código, y los Releases para crear versiones que los usuarios puedan descargar
  • En este flujo de trabajo hay más funciones del forge construidas sobre git que de git mismo, así que si se fuera a crear un nuevo forge, hay menos razones para quedar necesariamente atado a la restricción de git

Funciones deseables en un nuevo forge

  • La retroalimentación debe llegar antes del commit, no después

    • Es común ver PR con commits como Feature, fix, fix, actually fix, please y asdfasdf
    • Cuando el ciclo de retroalimentación llega después del commit, la gente termina sufriendo y corrigiendo hasta tarde
    • El forge debería ofrecer hooks pre-commit obligatorios que ejecuten trabajo en remoto, para que la persona reciba retroalimentación antes de hacer push

  • La aprobación de PR es demasiado binaria

    • Hoy los PR se dividen entre aprobados o no aprobados, pero en una revisión de código real hay mucho terreno intermedio
    • Reacciones humanas como “por ahora está bien, luego lo vemos” también deberían poder expresarse con un botón
    • Gerrit ofrece un mejor modelo en este aspecto
    • Si un mantenedor da una aprobación débil, debería poder marcarse para volver a revisarlo después

  • La política de PR debería ser más flexible

    • No todos los cambios necesitan revisión de cuatro ojos, especialmente en un entorno donde existen los LLM
    • El costo de esperar a que un ingeniero senior deje un LGTM en un PR de cuatro líneas es excesivo
    • Si el autor es mantenedor y el LLM lo considera de bajo riesgo o sin riesgo, debería poder controlarse más fácilmente para dejarlo pasar de inmediato

  • Los stacked PR deberían ser una función de primera clase

    • Los stacked PR hacen más fácil revisar y comprender
    • No deberían ser una función añadida por herramientas externas al VCS, sino tratarse como ciudadanos de primera clase en el forge y el VCS

  • El forge no debería intentar hacerlo todo

    • Se necesita seguimiento de issues, pero probablemente no un tablero Kanban
    • También es cuestionable si hace falta una wiki
    • Las herramientas que meten de todo terminan bajando de calidad, y aunque agregar funciones es fácil, el costo de mantenimiento sigue existiendo sin importar la tasa de adopción
    • En cuanto alguien empieza a usar una función en algún lado, uno queda atado a ella

  • La unidad de hosting es demasiado grande

    • Operar GitHub Enterprise es un trabajo grande, y operar GitLab también es una carga considerable
    • Estos productos son sistemas complejos con muchas partes móviles
    • Deberían poder crearse unidades de hosting individuales más pequeñas y conectarlas para formar una organización
    • No hace falta una federación global y está bien si hay que crear cuentas por organización, pero una organización debería tener la flexibilidad de poder decir: “estas 12 Raspberry Pi son mi organización”

  • El repositorio local debe representar no solo el código, sino todo el repositorio

    • La copia local debería representar el repositorio completo, incluyendo no solo el código sino también aprobaciones de PR e issues
    • Debería poder aprobarse un PR en el mismo VCS con el que se hace check-in del código
    • Debería poder revisarse issues igual que se recorren archivos locales

  • No siempre hace falta pagar el costo de almacenar todo el historial completo

    • Para trabajar bien con un equipo hace falta estar online, así que no es necesario obligar siempre a asumir todo el costo de almacenamiento
    • El VCS y el forge deberían trabajar juntos
    • Al clonar un repositorio, se debería recibir solo historial limitado, y cuando haga falta ir al pasado, levantar un worker que traiga desde el VCS lo necesario
    • No hace falta seguir enviando al forge solicitudes enormes de clone solo por asumir que algún día alguien podría reconstruir el forge a partir del historial completo del proyecto

  • Actions debería tener firma, SHA y uso offline

    • Actions es importante, así que necesita firma, SHA y posibilidad de uso offline
    • Si se quiere, debería poder descargarse el tarball de todas las actions y guardarlo en el repositorio, e indicarle al sistema que no traiga la checkout action desde afuera sino que use la que está en el repositorio local
    • Si se especifica latest, debería funcionar abriendo un PR que meta en el repositorio el tarball más reciente, como hace hoy Dependabot
    • Si se quiere, Actions también debería poder ejecutarse en la máquina local a través del mismo VCS

Ya existen herramientas que hacen partes de esto, pero hace falta combinarlas

  • Ya hay muchas herramientas que cubren parte de estos requisitos
  • Lo que hace falta es tomar esas herramientas, unirlas y hacer que encajen bien
  • La combinación deseada es JJ como VCS, un sistema nuevo como forge, y la expectativa de que una persona pueda usar durante mucho tiempo y con satisfacción una sola Raspberry Pi como forge
  • El nuevo forge debería diseñarse en torno a conceptos modernos como object storage, shallow clone y solicitudes persistentes de bots LLM

Grietas en la era en que GitHub es el valor predeterminado

  • Si GitHub estuviera haciendo bien las cosas, no habría necesidad de escribir una idea como esta
  • GitHub es el valor predeterminado, y convencer a alguien de ir más allá del valor predeterminado suele ser casi una pérdida de tiempo
  • Hasta 2026, si se iba a usar un forge, hacía falta una razón muy fuerte para no elegir la herramienta que usa todo el mundo
  • Hasta hace poco, los otros forge se veían más como sustitutos que como opciones realmente deseables
  • Pero el único forge gigante se está resquebrajando, y todavía no se ha construido un reemplazo
  • Quienes tienen dinero están ocupados con cohetes, quienes tienen gustos marcados están ocupados con su trabajo principal, y el resto abre a medianoche un PR llamado asdfasdf, espera la revisión de robots y se pregunta desde cuándo la herramienta que usan todo el día dejó de estar hecha para sus usuarios

Lecturas relacionadas

1 comentarios

 
GN⁺ 2 시간 전
Opiniones en Hacker News

  • La crítica de que la aprobación de PR es demasiado binaria parece una contradicción. Aprobar un PR es otorgar permiso, así que al final no puede ser más que un booleano: o puedes fusionar el código o no puedes
    De lo que se habla aquí se parece más a un mecanismo para sentirse un poco mejor al aprobar código que no te gusta, diciendo algo como “hay que volver a revisarlo después...”. Simplemente abre un ticket nuevo

    • Gerrit tiene una escala de -2 a +2
      -2: es una mala idea, no lo hagan
      -1: es una buena idea, pero necesita mejoras
      +1: se ve bien, pero no tengo el conocimiento o la autoridad para aprobarlo
      +2: aprobado
    • Ojalá existiera un botón para decir: “estos 3 commits apruébalos y fusiónalos ahora, estos otros 2 necesitan retrabajo”
    • Hay casos en los que el código está aprobado pero no se fusiona. En ese momento, un mantenedor puede aplicar manualmente cambios adicionales y hasta poner al autor del PR como coautor de ese commit de cambio
    • El problema más grande parece ser que GitHub está demasiado separado del sistema de seguimiento de issues. La carga de tener que sincronizar todo manualmente es grande, y aunque Linear resuelve algo de eso, no es lo ideal
    • Decir “o puedes fusionar el código o no” suena a que no eres precisamente intuicionista

  • Es cierto eso de que “Y hace algunas de esas cosas”, pero tangled.org sí hace la mayoría de ellas

    1. Usa JJ como sistema de control de versiones: tangled soporta PRs apilados con jj change-id. https://blog.tangled.org/stacking El propio tangled también se construye mucho así: https://tangled.org/tangled.org/core/pulls
    2. Un forge que pueda correr por mucho tiempo en una Raspberry Pi: eso también se puede. El shim del servidor git es muy ligero, no es más que una capa XRPC sobre el repositorio git y una base de datos sqlite3. Hay gente que lo corre en placas RISC-V con 512 MB de RAM
    3. Actions es importante y debería poder ejecutarse en la máquina local: creo que ese requisito está un poco mal enfocado. Que algo sea hermético, ejecutable en cualquier parte y capaz de manejar compilaciones cruzadas normalmente es tarea del sistema de build. Estaría buenísimo poder “promover” esos resultados de build dentro del propio forge
    • Me sorprendió que saliera Raspberry Pi al hablar de alojar datos clave para el flujo de trabajo. Antes sufrí demasiadas veces por corrupción de tarjetas SD; me pregunto si ahora usan unidades NVME
    • Sí, eso le toca al sistema de build. Pero el problema que la gente quiere resolver con Actions ejecutables localmente normalmente no es el fallo de compilación en sí, sino la integración completa
      La definición en YAML, los secretos, exactamente qué comandos se ejecutan, cómo se restauran las herramientas y la caché, ese tipo de cosas. Un sistema de build puede encargarse de parte de eso, pero las primitivas que ofrece GHA son muy pobres. Al final todo termina en el problema de correr el sistema completo en otra parte, por eso estos sistemas suelen avanzar más por prueba y error
    • Exacto, y más allá de eso, la idea sería extender el concepto de build hermético para que sea fácil ejecutarlo localmente o en cualquier lugar donde haya recursos de cómputo
      El problema de fondo al que apunta eso es que es muy doloroso iterar en ese ciclo de cambios, commits y llamadas de red hasta que el CI finalmente queda en verde. ¡La mejor manera de evitar esa iteración es no escribir bugs nunca! Es broma
    • Tanto Radicle como Tangled se están perdiendo de algo clave. Están pensados para colaboración pública, pero ¿qué pasa con los repositorios privados? Mucha gente tiene side projects y usa GitHub private para eso
      Si aprendes GitHub, también terminas empezando tus proyectos públicos en GitHub. Mientras no permitan crear repos privados para proyectos personales, les va a costar mucho ser adoptados masivamente. Lo que la gente quiere es poder crear un repo privado, irse unos meses y volver para encontrarlo ahí esperándola
    • Vaya, el soporte de jujutsu en Tangled es exactamente lo que estaba buscando. Mi fin de semana ya se fue en armar un setup self-hosted

  • Si quieres clonar solo historial limitado y traer datos antiguos cuando hagan falta, puedes usar blobless clone
    git clone --filter=blob:none
    Trae el historial y solo descarga los blobs cuando se necesitan. GitHub tiene un buen artículo al respecto: https://github.blog/open-source/git/get-up-to-speed-with-par...

  • Cuando la solución se vuelve el problema, se abre una oportunidad para la innovación disruptiva. Se está hablando bastante de esto últimamente, y me pregunto si alguna de las muchas alternativas emergentes logrará tomar impulso antes de que GitHub corrija el rumbo

    • Creo que el problema es que Microsoft apostó todo a la IA. Ya no hay vuelta atrás, y GitHub no tiene forma de no verse afectado
      La propaganda de Microsoft dirá que la IA es la solución para todo, pero en la práctica vamos a seguir viendo los mismos problemas repetirse. Puede que una caída de GitHub no esté directamente relacionada con IA, pero la estrategia de Microsoft ya cambió, así que la mayoría de las decisiones se alinearán con ese control vertical centrado en IA. Que se rompa el flujo de trabajo de la gente que usa GitHub es, para Microsoft, a lo mucho una preocupación secundaria, y ese problema va a seguir apareciendo una y otra vez. Tal vez haya tres meses de calma, pero estoy 100% seguro de que pronto volveremos a ver otro drama sobre la decadencia de GitHub. Ghostty no será el último. Será interesante ver si aparecen alternativas, aunque esas alternativas no pueden ser malas, y muchos sitios web sí son bastante malos
    • Yo estoy construyendo mis propias herramientas. También creo que la gente debería construir sus propias herramientas
      En el futuro, en vez de software pago u open source, quizá recibamos paquetes de documentos de requisitos para un code forge, una especie de receta. Cada quien lo hornea por su cuenta y lo adapta a su uso y a sus gustos

  • Creo que hay espacio en el mercado para un servicio git mucho más simple. Lo único que necesito es un host remoto donde hacer push de mis proyectos para que otras personas puedan verlos; no quiero realmente cosas como PRs o Actions
    Una función de “releases” para subir assets binarios compilados localmente sí estaría bien. Los forks se pueden resolver si la gente clona el repo y lo publica como proyecto nuevo

    • ¿No se resuelve gran parte de esto apagando las funciones que no necesitas? Acabo de revisar mi instancia de Forgejo y tiene opciones por repositorio para desactivar Code, Projects, Releases, Packages, Actions, Issues, PRs y Wikis
    • https://sr.ht/
    • Entonces, ¿estaríamos volviendo a cgit?

  • La idea de que los datos de revisión también puedan vivir en un repositorio git como el código es bastante convincente
    Se podría implementar muy fácilmente usando una rama por revisión con un prefijo conocido, pero el espacio de nombres de ramas por defecto se ensuciaría rápido. Se podría separar del espacio principal con git namespaces, o tener una rama especial como .reviews que solo contenga los IDs de commit finales de cada rama de revisión. Si alguien se interesa lo suficiente como para crear una especificación y una implementación realmente usable, quizá la gente empiece a adoptarlo. Supongo que la razón por la que GitHub y otros forges no eligieron ese camino es que mantener los metadatos de revisión encerrados dentro de su ecosistema es parte del valor de la plataforma. Si cualquiera pudiera revisar el código de otros con las herramientas locales que prefiera, habría menos lock-in con el proveedor. Aunque también hay otras razones para querer que los metadatos de revisión vivan en otro repo, como el control de acceso o las revisiones entre repositorios

  • Me encanta el flujo de trabajo de Gerrit de revisar diferencias en vez de PRs. Pero comparado con algo como gitea, parece difícil convencer a mucha gente porque le faltan el resto de las funciones que hoy se esperan de un hosting git, como issues, planeación de proyectos, etc.
    Ojalá existiera una buena plataforma de revisión de diffs como Phabricator; se extraña

    • Pero entonces, ¿por qué Gitea no agrega eso? Ya tiene todo lo demás; no entiendo por qué estos forges siempre se quedan como copias de GitHub y no van más allá

  • Creo que el formato base para guardar todos los mensajes, como PRs, comentarios de revisión e issues, debería ser RFC2822, y al mostrarlos bastaría con decorarlos con CommonMark
    Todos los metadatos pueden ir en headers, y se pueden enlazar entre sí con headers Message-ID/In-Reply-To/References. Si usas un formato bien definido así, puedes elegir cómo almacenar y transportar todos los mensajes. Puedes meterlos en un repositorio git, usar correo electrónico o cualquier otro mecanismo que encaje. Personalmente creo que Gerrit es mucho mejor para revisión de código que GitHub y similares. El CI preferiría dejarlo lo más posible por fuera, y quedarme solo con hooks para iniciar pipelines, mostrar resultados y decidir si se permite fusionar

    • Creo que uno de los atractivos de GitHub es que integra revisión de código, exploración de código fuente, seguimiento de tickets y CI
      No hace extraordinariamente bien ninguna de las cuatro, pero sí hace bien el trabajo de unirlas. Estoy de acuerdo en que Gerrit tiene un mejor modelo de revisión de código, pero sin las otras tres piezas no hay producto. Incluso cuando usaba Gerrit todos los días en Google, me frustraba la pobre integración entre búsqueda de código, revisión de código y CI. Las herramientas internas de Google, como Google3/Critique/Forge, conectaban mucho mejor todo eso

  • Acabo de pensar en una ventaja del flujo de trabajo basado en correo electrónico. Si ya te sentaste a ver el correo, normalmente estás en el estado mental adecuado para eso, y en ese estado esperas no tener otras distracciones, así que te concentras mejor
    El problema con las notificaciones es que tienen esa fuerza de hacerte querer quitártelas de encima apenas aparecen. Pero eso no garantiza que en ese momento tengas la energía para atenderlas. La mayoría de los sistemas de notificaciones web parecen imitaciones torpes de algo que los clientes de correo ya habían resuelto hace décadas. Tal vez los antiguos sí tenían razón con lo del email

    • El correo también es una notificación; ¿podrías explicar mejor cómo es que justo al llegar te pone en el humor adecuado para recibirlo?

  • Mucha gente ya estaba molesta cuando Microsoft absorbió GitHub. Pero siendo realistas, las alternativas a menudo eran malas. Sourceforge hace que abrir issues sea una experiencia interminablemente frustrante, GitLab es mejor que Sourceforge pero aun así me desagrada crear issues ahí, y Codeberg parece haber cambiado recientemente su UI pero sigue siendo bastante incómodo
    Lo que GitHub hizo bien al principio fue facilitar o simplificar mucho las cosas con una UI enfocada en la gente que usa GitHub. No hizo todo bien; por ejemplo, creo que el soporte de wiki es terrible. Es tan malo que casi no uso wikis. Pero el problema realmente grande me parece que son los intereses comerciales, o sea, intereses privados. Microsoft es solo un ejemplo; es un problema presente en casi todos los sitios parecidos. Antes puse como ejemplo la discusión de un issue sobre la utilidad con backdoor de xz, y yo también participé en esa discusión, pero al día siguiente Microsoft la bajó por completo. Da igual si fue Microsoft o el dueño del repositorio. El problema es que una persona puede censurar demasiado fácilmente información potencialmente útil. Esa discusión del issue era útil y fue censurada. Si recuerdo bien, en ese momento no se restauró todo. Puede que alguien la haya espejado, pero no vi el enlace. Esto muestra cómo el control vertical puede ser realmente dañino. Sinceramente, ¿cuánto se puede confiar en Microsoft? Necesitamos algo descentralizado, que funcione de forma estable, con una buena UI por defecto y con un flujo simple o al menos bueno. También deberíamos evitar una situación en la que un actor privado tenga a todo el mundo de rehén. No tengo idea de cómo resolverlo; quizá hagan falta varios enfoques al mismo tiempo. La web cambió, y siento que especialmente los intereses privados de las megacorporaciones en los últimos 10 o 15 años han empeorado mucho la situación. Tiene que cambiar

    • El problema es que operar un producto SaaS cuesta mucho dinero
      Las megacorporaciones pueden pagar ese costo, pero aunque se junten muchos desarrolladores con presupuestos chicos, no alcanza para financiar lo mismo. Por eso cualquier proyecto comercial termina inevitablemente alineándose más con los intereses de las megacorporaciones que con los de la persona promedio