Lapack: Referencia-LAPACK/lapack vs Referencia-LAPACK/lapack-lanzamiento

Sospecho que esto es simplemente el resultado de la conversión de cualquier sistema CVS que se haya utilizado antes de 3.7 y el cambio a github. ¿Qué se ganaría eliminando uno de ellos y etiquetando versiones retroactivamente en el otro (lo que puede ser tedioso o incluso técnicamente imposible, dependiendo de cómo se manejaron los árboles fuente en días anteriores y, en cualquier caso, eliminaría la calidad de "archivo" de tener las versiones anteriores exactamente como fueron creadas)?

El beneficio sería menos confusión debido a la consistencia. Ahora hay datos superpuestos.

Por ejemplo, alguien está buscando la versión más reciente de lapack y encuentra el repositorio Reference-LAPACK/lapack-release primero. Entonces él está tomando 3.8.0 falsamente por el más nuevo. Esto puede suceder especialmente cuando el repositorio se llama explícitamente release .
También proporcionar comentarios mediante la creación de problemas se realiza ahora en ambos repositorios y, además, en netlib.

Si debe conservarse por calidad de archivo, debe marcarse como tal con referencia al SCM actual y los problemas deben desactivarse para evitar confusiones.

El README.md en el repositorio "lapack-release" ya apunta aquí, y observo que esta configuración parece haber funcionado durante los últimos dos años, por inusual que parezca. (Si es necesario agregar una rama 3.9.0 al repositorio de lanzamiento de lapack, sospecho que ambos mantenedores tuvieron que centrar su atención en las nuevas condiciones de enseñanza creadas por la pandemia de covid poco después del lanzamiento de 3.9.0).

Simplemente se olvidaron de agregar 3.9.0 a lapack-release probablemente. Parece un hábito de SVN tener esto como tronco y el otro como copia de lanzamiento.

Pero casi nunca, la gente usa GitHub para la distribución de LAPACK de todos modos, ya que la mayoría va a NetLib para descargar o usa alguna otra implementación especializada de todos modos.

Observo que esta configuración parece haber funcionado durante los últimos dos años, por inusual que parezca.

Esto no quiere decir que sea la configuración perfecta o que no pueda haber ajustes.

(Si es necesario agregar una rama 3.9.0 al repositorio de lapack-release, sospecho que ambos mantenedores tuvieron que centrar su atención en...

Esto podría evitarse, por ejemplo, por simple que parezca.

Probablemente se olvidaron de agregar 3.9.0 a lapack-release. Parece un hábito de SVN tener esto como tronco y el otro como copia de lanzamiento.

Estoy de acuerdo, parece una rama SVN, troncal, estructura de etiquetas.

Hola, no estoy en contra de la reorganización de la estructura general y retroceder en el tiempo para hacer las cosas siguiendo la nueva estructura reorganizada. De hecho, pasamos de SVN a GIT hace unos años, y luego algunas actualizaciones podrían haberse deslizado. Si alguien quiere tomar la iniciativa en esto, etiquetar, reestructurar y hacer que LAPACK GitHub se vea y se sienta como un ejemplo de las mejores prácticas de repositorio de Git, esto sería genial. julián

No tengo ningún problema con eso, excepto que he visto que "reorganicemos el repositorio" convertirse en el final de más de un proyecto "heredado", y estoy mucho más preocupado por los problemas no manejados y la nueva funcionalidad que no se aprueba.

Esto es muy confuso ya que el eslogan para el lanzamiento de lapack es "Sucursales de lanzamiento oficial de LAPACK", ¿hay alguna posibilidad de que esto pueda cambiarse a algo así como "Sucursales de lanzamiento de LAPACK antiguas"?

Hola @jfowkes. "Sucursales de lanzamiento oficial de LAPACK" no es confuso para mí. Podríamos agregar las ramas de lanzamiento "anteriores" del mundo. Estaré bien agregando "anterior", pero mi preferencia es dejar las cosas como están. Comentarios bienvenidos. @langou

Hola @langou , agregar "anterior" sería genial. Cuando leí "ramas oficiales de lanzamiento", supuse que todas las ramas de lanzamiento estarían allí y me confundí mucho cuando faltaban las últimas.