search

open-source-uc / latex-templates

Repositorio donde se recopilan los templates creados por la comunidad OSUC
MIT License
39 stars 9 forks source link

Centralizar o no centralizar: esa es la cuestión #1

Closed agucova closed 3 years ago

agucova commented 3 years ago

Se propuso anteriormente centralizar en este repositorio todas las plantillas de LaTeX dispares que tenemos repartido en repositorios de esta organización. Esta idea está presente en las actas de 05-01, 05-15, 05-29. Para este propósito, @FarDust elaboró una guía para reunir los historiales de git de cada repo individual.

En la reunión del 07-10 se comentó (@Dietr1ch) que tal vez reunificar todas las plantillas podría ser contraproducente, dado que puede sobrecargar el repositorio, reunir issues sin relación o hacer mas díficil la descarga.

agucova commented 3 years ago

Mi punto de vista es que unificar los repos tiene las siguientes ventajas:

agucova commented 3 years ago

Un contraargumento que encontré válido es que es más difícil que una persona llegue y descargue la plantilla que quiere desde GitHub, sin embargo esto sería el caso de todas formas si usamos submódulos para solucionar el problema de código común.

Como propuso @FarDust podemos automatizar la generación de ZIPs individuales y publicarlos automáticamente en una web estática. (Esto es relativamente trivial, solo requiere empacar cada carpeta y subir como build artiffacts)

nico-mac commented 3 years ago

Creo que es muy útil poder tener el marco común para todas la plantillas, va a simplificar mucho hacer actualizaciones o correcciones, también hace más fácil ir agregando plantillas nuevas asegurando que cumplan con ciertos estándares.

Eso si, para usar las plantillas de forma práctica creo que es necesario poder tener links de descarga individuales en alguna parte, puede ser en una página dedicada, dentro de la página de la organización o en el mismo Readme.

Dietr1ch commented 3 years ago

Mi punto de vista es que unificar los repos tiene las siguientes ventajas:

  • Nos permite trabajar en un solo lugar sin tener que cambiar repos constantemente, dado que la mayoría de los cambios son universales. Esto aplica a código, issues y PRs.

Un repo con el código común permite eso también. Además aunque tengas un repo unificado, va a pasar que van a haber issues/PRs específicos con un template.

  • Nos permite establecer un marco común para todas las plantillas (agregando un .sty, por ejemplo), que permita tener funcionalidad consistente y actualizada en todas las plantillas, el problema principal que queremos enfrentar.

Esto es el caso de uso de submódulos. Además al cambiar el código común, de todas maneras hay que asegurarse de que funciona bien en todos los templates, y es más fácil hacer el bump individual de templates que revisar todos, ya que se puede distribuir o hacer a medida que el tiempo lo permita en vez de forzar a tener un commit que requiere mucho más tiempo.

  • Reúne las estrellas en un solo lugar

Entonces ahora no se sabe cuáles son los templates que merecen esas estrellas y cuáles no.

  • Facilita el uso de linters y acciones que midan la calidad de todo el código en conjunto.

No entiendo por qué es más fácil. si es que el setup de linters es común, entonces puede ser un submódulo. Y si no fuese completamente común, entonces va a ser un problema al unificar.

Creo que es muy útil poder tener el marco común para todas la plantillas, va a simplificar mucho hacer actualizaciones o correcciones, también hace más fácil ir agregando plantillas nuevas asegurando que cumplan con ciertos estándares.

Esto realmente habla de compartir código entre los distintos templates en vez de cómo organizar el o los repos.

Con respecto al agregar nuevas plantillas, puede que convenga tener un repo de una plantilla base, y que todos sean un fork de el, así crear un repo nuevo es hacer un fork, y actualizar algo común es trabajar en el repo base y hacer rebases

Bueno, finalmente son libres de experimentar con un repo común, pero en mi opinión hacerlo es no aprovechar git bien, aunque entiendo lo falta de tooling y conocimiento extra requerido para manejar muchos repos.

Yo creo que de acá lo más interesante es desarrollar esa librería común para que los templates sean un poco más unformes donde se pueda (hay informes que son bien específicos con el formato). Si quieren armar esa librería en un mono-repo creo que está bien. Sería útil que mantengan esa parte común en un branch y los templates sean rebases sobre ella para que pueda usarse como submódulo también.

BTW, como ya dijeron, los zips autogenerados no incluyen submódulos issue, pero en los releases se puede automatizar, https://github.com/release-it/release-it y hay herramientas para manejar varios repos a la vez (gr, mr, repo.

FarDust commented 3 years ago

Con respecto al agregar nuevas plantillas, puede que convenga tener un repo de una plantilla base, y que todos sean un fork de el, así crear un repo nuevo es hacer un fork, y actualizar algo común es trabajar en el repo base y hacer rebases

Me interesa esta idea en particular, soy partidario de tener los repositorios separados pero entiendo que juntarlos simplificaría muchísimo la logística.

En especial, podríamos identificar aquellos repos que tienen ese formato regido y realmente merecen sus repositorio aparte. Igual me gustaría saber como cada uno afrontaría la mantenibilidad de estos repos en los diferentes escenarios.

agucova commented 3 years ago

Estoy un poco con este mood:

Gracias xkcd por siempre tener cómics relevantes. Ahora al asunto en cuestión:

Un repo con el código común permite eso también. Además aunque tengas un repo unificado, va a pasar que van a haber issues/PRs específicos con un template.

En git siempre hay muchas maneras de hacer las cosas, y estoy de acuerdo que submódulos es, dentro de todo, una opción totalmente viable. He trabajado con submódulos en el pasado y creo que son una herramienta útil en muchos contextos, especialmente cuando es necesario manejar dependencias cambiantes de forma independiente al mantenedor original, o cuando la expectativa es manejar con granularidad el código compartido en un proyecto de alta complejidad.

Sin embargo la razón fundamental de mi resistencia a simplemente modularizar todo es pragmática: los submódulos agregan complejidad y aumentan significativamente la barra de entrada para contribuidores. Y creo que estás de acuerdo conmigo:

(...) aunque entiendo la falta de tooling y conocimiento extra requerido para manejar muchos repos.

La mayor dificultad que tiene este proyecto por delante no es tooling, no son conflictos entre dependencias y definitivamente no es tener una codebase demasiada grande, si no que es fundamentalmente motivar a contribuidores a participar y hacer aportes con tal de revivir el proyecto. Todas las plantillas llevan sobre 5 años abandonadas, actualmente no hay nadie a cargo del proyecto, y las pocas personas que se habían ofrecido en el pasado eran a lo más, principiantes de git.

Tal vez a futuro los submódulos si serán necesarios, pero ahora mismo creo que hay que atenerse a la prioridad fundamental del proyecto: sumar gente y ponerse a trabajar.

Ahora, dicho todo esto, si todavía creen que los beneficios de los submódulos de git justifican la complejidad y barrera de entrada más alta, no tengo problema si es que:

Si no podemos cumplir con ambos, estamos discutiendo algo que nunca va a poder concretarse y simplemente no podremos levantar este proyecto.

Oh, what a tangled web we weave. — Sir Walter Scott

FarDust commented 3 years ago

Ultimátum, se realizo el merge de las plantillas de una manera hibrida.