¿Qué quieren de un forge?

• Se está discutiendo sobre usuarios de Jujutsu y de otros sistemas de control de versiones, así como sobre flujos de trabajo puros de Git que los principales forges no cubren lo suficiente
• El interés central no está en la forma de implementación, como SPA/JS o HTML renderizado en el servidor, sino en cómo el repositorio representa y hace funcionar las capacidades de control de versiones
• Existen ideas como Tangled, los stacked PRs de GitHub y forgefed, pero es difícil encontrar un espacio donde se reúnan opiniones de usuarios sobre el diseño
• También se incluyen los stacked PR/MR y modelos alternativos de colaboración, y el punto clave es la experiencia de control de versiones más allá de los forges existentes
• La visualización de objetos del repositorio como tags, commits, trees y blobs suele ser bastante similar entre forges, y casi no hay debate más allá de pequeñas diferencias de formato

[GN⁺]

Opiniones de Lobste.rs

• Los comentarios de revisión de código son imposibles si no forman parte del propio repositorio
  Guardar contexto histórico valioso en listas de correo, silos de bases de datos o capas separadas que no quedan fijadas al hash del commit HEAD es fundamentalmente el mismo tipo de riesgo que GitHub
  Fossil va un poco en esa dirección, pero solo con issues; la revisión de código sigue siendo por parches por email: https://fossil-scm.org/home/doc/tip/www/contribute.wiki
  Una vez que esa información está dentro del sistema de control de versiones, encima ya se le puede montar una buena web UI, feeds RSS y listas de correo
  La segunda función es soporte integrado para una merge queue. En proyectos que no son triviales, los contribuidores individuales no deberían poder hacer push directo a la rama main; al marcar cierto commit como “listo para integrar”, un bot debería serializar los cambios propuestos, programar CI de forma óptima y avanzar main a un hash verificado
  La tercera función es CI como ejecutor de trabajos aislado en entornos heterogéneos como Windows, macOS, etc.: https://gregoryszorc.com/blog/2021/…

  • Además, hace falta un enfoque claro para lidiar con spam y abuso
    Cualquiera debería poder crear una cuenta y abrir un issue, pero no debería haber spam
    Hoy GitHub lo hace bastante bien. A veces veo spam, pero tras reportar abuso lo quitan muy rápido. Me imagino que detrás hay una mezcla de automatización tonta y un equipo real de clasificación
  • ¿Hay alguna herramienta que hoy guarde los comentarios de revisión de código dentro del repositorio?
    Estoy viendo Fossil como “forge” para proyectos hobby, y no espero tener muchos contribuidores externos, así que la revisión de código sería más bien un extra agradable
  • No quisiera meter issues y pull requests dentro del repositorio en sí
    En cambio, quiero una base de datos SQLite que se pueda sincronizar, enviar y consultar como uno quiera
    Lo siguiente grande que quiero hacer en git-pr es exponer la base de datos SQLite mediante un comando SSH: ssh pr.pico.sh sql
    SQLite está en todas partes, es generalista y sirve para todo lo que hace falta, pero le falta usabilidad cuando se trata como parte de una forge
  • La idea de poner los comentarios de revisión de código dentro del propio repositorio es realmente interesante
    Pero me pregunto, cuando el historial se reescribe con cosas como force-push o squash merge, a qué quedarían “anclados” después esos comentarios para que el usuario pueda encontrarlos
    En GitHub, ese criterio es el Pull Request, así que puedes ver la discusión aunque cambien los commits incluidos
    Me pregunto si este sistema también tendría un concepto separado de PR almacenado en el repositorio, o si se espera algo más estrechamente integrado
  • No tengo claro cómo combinar esto con los hashes de commit, ni qué pensar del problema de que los metadatos del repositorio cambien tanto
    Aun así, como uso bastante jj, quizá en la práctica no sea un problema tan grande

• Después de usar tanto Gerrit como email, me da pena que el modelo de pull request sea el que más domina
  Sobre todo cuando un maintainer podría simplemente arreglar observaciones menores de estilo en vez de dejarlas como comentario, y al contribuidor probablemente ni le importe tanto ese estilo
  Pero lo que más pena me da es que con Darcs o Pijul, que últimamente uso cada vez más, no exista ningún flujo de trabajo que no sea por email
  Me gustaría que fuera basado en XMPP en lugar de email. Permitiría colaboración distribuida en tiempo real sobre parches en progreso, e incluso podría haber un MUC por patchset
  Los MUC ya se pueden abrir como un chat de voz, y además tienen roles, adjuntos, reacciones, búsqueda, MAM, moderación y tombstoning al terminar, todo ya definido en XEPs
  Para las suscripciones se podría usar PubSub, y también servir como medio de entrega para CI
  Para que fuera práctico haría falta un cliente dedicado, pero muchas funciones podrían simplemente funcionar desde cualquier cliente
  Siendo realistas, quizá esto tenga más que ver con que últimamente me atrae ver cómo viejas tecnologías federadas terminan escalando de formas inesperadas

• La revisión y aprobación de código es el cuello de botella
  La comunicación con quien envía el código tiene latencias enormes, a veces de semanas o meses, y además poca confiabilidad. Hay gente que abre un PR y desaparece
  El modelo de GitHub, que asume interacción de ida y vuelta, aquí se rompe por completo
  Sería bueno poder modificar el código directamente durante la revisión y hacer amend de commits al estilo git-absorb. Ir y volver con quien lo envió por detalles menores como typos es una pérdida de tiempo, y el hack de GitHub de Edit Suggestion es incómodo y ensucia el historial
  No quiero revisar el mismo código otra vez. Si el problema está solo en una función o en un commit, el resto debería poder aprobarse de antemano, y si quien lo envió lo arregla con force-push, no debería tener que volver a mirar todo
  Sería bueno poder hacer merge solo de una parte del PR, o quitar commits sin cerrar el PR. A veces no quieres la funcionalidad en sí, pero sí vale la pena conservar el trabajo base; otras veces se meten “limpiezas” o formateos innecesarios
  Si la persona original no responde, otras personas deberían poder colaborar en el PR, pulirlo y resolver problemas. En teoría el modelo de GitHub lo permite, pero en la práctica se parece más a una técnica escondida de hacer PRs sobre otros PRs, y ni ese código ni esas notificaciones son visibles para el proyecto destino. Cuando la gente hace fork y manda PRs para arreglar otro PR, lo único que sale es confusión y conflictos de merge
  Muchas veces el código enviado está más o menos bien, pero quiero algunas mejoras pequeñas. Desde la perspectiva de quien contribuye, es frustrante sentir que su PR queda de rehén hasta terminar todos los detalles; desde la perspectiva del maintainer, si haces merge de inmediato corres el riesgo de que luego desaparezca y esas mejoras nunca se hagan. Sería bueno tener una forma de hacer un merge temporal con la obligación de limpiar después. Por ejemplo, hacer merge a una rama de staging, pero no hacer cherry-pick a la rama estable hasta que se resuelvan los FIXME
  En proyectos open source populares a veces hay una sola persona capaz de hacer la revisión y aprobación que realmente mueve el proyecto hacia adelante, mientras hay 500 personas que quieren contribuir y ayudarse entre sí. El modelo de GitHub no aprovecha en absoluto ese exceso de capacidad de contribución. En vez de facilitar colaboración, lo convierte en crisis, confusión y presión colectiva enojada. Debería haber mucho mejor soporte para gestionar forks y copiar código entre forks, de modo que otras personas puedan experimentar y hacer avanzar el proyecto sin quedar bloqueadas por un único maintainer, y que luego el maintainer pueda elegir fácilmente cambios populares y ya validados en varios forks

  • Si quien envía el PR no activó la opción para bloquearlo, el dueño del repositorio puede hacer push directo a la rama del PR
    Creo que en organizaciones esa opción venía activada por defecto, pero en cualquier caso ahí puedes arreglar las cosas directamente y de forma limpia con force-push
    Yo siempre hago eso con cambios pequeños que no valen una ida y vuelta
  • Si crees que quien contribuye responde lento, espera a ver lo que es esperar respuesta del maintainer
    Normalmente se siente como algo medido en meses o años
    A veces yo también soy maintainer, y admito que tampoco siempre soy más rápido que eso
  • Aunque la interfaz web de revisión no permita modificar el código directamente, estaría bien que se acercara mucho más a un IDE
    Quiero cosas como ir a definición y popups al pasar el cursor que muestren firmas o comentarios de documentación
    Eso se puede hacer si haces checkout de la rama y revisas en tu editor preferido, pero como dije, la revisión es el cuello de botella
    El trabajo extra de estar cambiando de rama cada vez que revisas varios PRs es demasiado

• Hace falta modo de usuario único, o al menos un modo así
  ¿Por qué tendría que aguantar URLs como https://code.chrismorgan.example/chrismorgan/repository-name? Si podría ser https://code.chrismorgan.example/repository-name
  Lo digo completamente en serio, y si ves https://github.com/go-gitea/gitea/issues/11028 está claro que hay bastante gente que quiere esto
  Una de las tres razones principales por las que no tengo cuenta en el Fediverse es precisamente que las direcciones son horribles
  Si uso una dirección como mi correo principal, algo tipo @‌me@‌chrismorgan.info, siento que para algunas personas podría verse simplemente como “@‌me”, y @‌chrismorgan@‌chrismorgan.info me da rechazo solo de verlo
  En esto ATProto lo hizo muy bien. Los nombres de dominio funcionan excelente como handle, y si hacen falta varios usuarios, con subdominios basta
  Incluso en una forge compartida, usar subdominios podría hacer que lógicamente se sienta como de usuario único. Pensar en chris-morgan.github.com en vez de github.com/chris-morgan podría ser divertido
  La estética importa
  Ir hacia usuario único también tiene consecuencias más grandes. Si reduces algo como Mastodon para una sola persona, sigue siendo pesado, pero los proyectos del Fediverse diseñados desde cero para un solo usuario encajan mucho mejor con ese uso
  Quiero operar mi propio servidor, pero con yo como único usuario local, y no quiero hacer concesiones por la posibilidad de que existan otros usuarios
  Esto también significa que quiero hacer push con un nombre de usuario como chris, como en SSH normal, y no con usuarios genéricos como git que suelen usar las forges
  Para una forge en el sentido habitual, la federación desde luego hace falta. Pero estaría bueno que en el “home server” de cada quien hubiera un solo usuario local

  • ¿Y cómo manejas tu dirección de email?
    Si usas un dominio con tu propio nombre, ¿no tienes ahí un problema parecido?

• Me gustó el artículo de Nesbitt sobre este tema
  En especial la parte de mejor comunicación con downstream

• Debería ser posible hacer revisión de código local en el editor que uno elija
  No quiero quedar atrapado a la fuerza en una interfaz web torpe, con tipografías que no se pueden cambiar y un resaltado de sintaxis terrible
  Ahora mismo uso un flujo de trabajo con herramientas custom para Neovim para ver diffs lado a lado de forma agradable, y el comando git pr para hacer checkout de pull requests
  Pero en cuanto quiero algo apenas más allá, como dejar comentarios de revisión, termino dependiendo de algún CLI de alguien o de una herramienta que habla con la API de GitHub y que probablemente no siga mantenida dentro de 5 años
  Más específicamente, no solo hacen falta herramientas que puedan “ejecutarse” localmente, sino herramientas local-first que se integren localmente con el editor y demás
  La razón por la que esto cuesta ser una función de primer nivel es el esfuerzo requerido. Una sola interfaz web “funciona” en todas las plataformas y entornos de edición porque fuerza a la gente a usarla, pero una integración más estrecha requiere N integraciones si hay N editores y entornos
  Lo mismo aplica a CI. Quiero poder correr tests fácilmente en Linux, FreeBSD y macOS sin tener que hacer push de commits a una rama y esperar 15 minutos a que me los tomen
  Algo como run-remotely some-command --on freebsd,linux,mac bastaría
  Básicamente hace falta un sistema de CI descentralizado y local-first, pero que al mismo tiempo soporte un sistema central como fuente única de verdad para garantizar que todo el código pase por el mismo sistema “aprobado” antes del merge
  Esto va más allá de un simple ssh user@host command ..., porque necesitas copiar código fuente, hacer caché, instalar dependencias necesarias, etc., para llegar siempre al mismo estado confiable

  • Últimamente he estado pensando algo parecido
    Solo que no creo que eso sea una función de forge. Debería ofrecerse como una herramienta ejecutora de trabajos que se pueda usar sin una forge específica y que cualquier forge pueda invocar
    Creo que tendría que ser un poco “basada en drivers”. Podrías correr el mismo trabajo completamente en local, o enviarlo a un sistema remoto para que lo lance. Ese trabajo podría correr en una VM, en un contenedor o directamente sobre el host

• También debería dar soporte a sistemas de control de versiones que no sean Git
  Tiene que ser posible importar y exportar cosas como issues y wiki en formatos cómodos, para no quedar atado a un sistema específico
  También debería ser fácil de self-hostear

  • Dar soporte a todos los sistemas de control de versiones que no sean Git es una lista bastante larga
    Supongo que habría cierto subconjunto realmente importante
    El Heptapod del comentario hermano es para Mercurial, y sourcehut, también
    Fossil tiene su propia forge, y allura, la versión Apache de SourceForge, ofrece Subversion

• Me gustaría una forge que ofreciera algo parecido a Bazel en la capa de CI
  No en el sentido de “puedes correr Bazel en CI”, sino de que lleve naturalmente a la gente a escribir buenos conjuntos de tests y builds con dependencias bien definidas, para no quemar tiempo de CI porque sí
  Relacionado con esto, creo que el modelo de “un proyecto = un repositorio” ha creado muchos problemas
  Podrías describirlo como mejor soporte para monorepos, pero básicamente CI e issues y demás deberían poder tener un alcance más grande que “la raíz de este directorio”
  Muchos proyectos terminan partidos en varios repositorios por razones de forge o de CI, y trabajar así no es nada divertido
  Como revisor, también quiero división de parches inline
  O sea, poder escoger las partes que sí me gustan y aprobar solo esas, para integrar lo que ya está bien
  Los PR apilados me siguen pareciendo un concepto demasiado pesado
  Si alguien dice “quiero cambiar estos 4 archivos y veo esto como un solo PR”, el revisor debería poder decir “ok, estos 2 archivos están bien” y convertir ese conjunto en una parte separada del PR, o incluso hacer merge solo de ese fragmento como commit aparte
  Incluso los PR apilados de hoy siguen tratando al PR como una unidad atómica. En la mayoría de sistemas, siento que los PR son demasiado pesados

  • Solo como observación, JetBrains se opuso durante mucho tiempo a permitir commits por hunk
    La razón era “eso es solo un subconjunto del archivo, así que no sabes si compila”
    No estoy para nada de acuerdo con esa postura, pero al ver este comentario me hizo pensar en eso, porque hacer algo así desde una vista web sí requiere bastante cuidado
    Claro, dejando de lado por un momento el comentario de arriba sobre que, si eres dueño del repositorio, siempre puedes hacer force-push de tu versión preferida a la rama

• Hace falta una configuración CI/CD sin esfuerzo
  Solo con make build, make test, make upload debería bastar
  Que el resto quede en el makefile, y desde ahí ya se podrá evolucionar a un mejor sistema de build
  Quiero pasar de una idea a un artefacto publicado en menos de 2 minutos

  • ¿Por qué usar justamente Make, que además tiene varias versiones?
    En lugar de eso, como hacen la mayoría de sistemas CI/CD, bastaría con usar un archivo de configuración en una ubicación conocida, o poner tres scripts de shell con nombres conocidos dentro de un directorio conocido
    De bonus, si necesitas builds de Windows, podrían ser archivos .bat
  • Ese enfoque suena bien, pero probablemente haga falta alguna forma de instalar dependencias
    Puede variar según el sistema operativo y quizá no quieras meterlo dentro del makefile
  • Estoy construyendo un CI local-first que puede aportar aislamiento por sí mismo: https://ci.pico.sh
    La ventaja es que todos los trabajos se ejecutan en su propio pty bajo zmx
    Puedes adjuntarte a un trabajo fallido y volver a correrlo con flecha arriba y Enter

• Quiero advisories de seguridad con guardrails para que se publique información de buena calidad
  Hace falta un ecosistema centrado en commits para que todos los proyectos puedan publicar datos significativos, y también debería haber integración para que los proyectos que quieran puedan emitir sus propios CVE directamente