Lapack: Référence-LAPACK/lapack vs Référence-LAPACK/lapack-release

Je soupçonne que c'est simplement le résultat de la conversion de n'importe quel système CVS utilisé avant la version 3.7 et du passage à github. Qu'est-ce que l'on gagnerait en supprimant l'un d'eux et en étiquetant rétroactivement les versions dans l'autre (ce qui peut être fastidieux ou même techniquement impossible, selon la façon dont les arbres source ont été manipulés dans les premiers jours, et en tout cas supprimerait la qualité « archivistique » d'avoir les anciennes versions exactement telles qu'elles ont été créées) ?

L'avantage serait moins de confusion en raison de la cohérence. Maintenant, il y a des données qui se chevauchent.

Par exemple, quelqu'un recherche la dernière version de lapack et il trouve le dépôt Reference-LAPACK/lapack-release en premier. Ensuite, il prend faussement 3.8.0 pour le plus récent. Cela peut se produire en particulier lorsque le référentiel est explicitement appelé release .
Fournir également des commentaires en créant des problèmes est actuellement effectué dans les deux référentiels et en plus sur netlib.

S'il doit être conservé pour des raisons d'archivage, il doit être marqué comme tel en référence au SCM actuel et les problèmes doivent être désactivés pour éviter toute confusion.

Le fichier README.md du référentiel "lapack-release" pointe déjà ici, et je note que cette configuration semble avoir fonctionné au cours des deux dernières années, aussi inhabituelle qu'elle puisse paraître. (Si une branche 3.9.0 devait être ajoutée au référentiel lapack-release, je soupçonne que les deux responsables ont dû porter leur attention sur les nouvelles conditions d'enseignement créées par la pandémie de covid peu après la version 3.9.0).

Ils ont juste oublié d'ajouter 3.9.0 à lapack-release probablement. Cela semble être une habitude SVN d'avoir ceci comme tronc et l'autre comme copie de version.

Mais presque jamais, les gens n'utilisent de toute façon GitHub pour la distribution de LAPACK puisque la plupart vont soit sur NetLib pour le téléchargement, soit utilisent de toute façon une autre implémentation spécialisée.

Je note que cette configuration semble avoir fonctionné au cours des deux dernières années, aussi inhabituelle qu'elle puisse paraître.

Cela ne signifie pas que c'est la configuration parfaite ou qu'il ne peut pas y avoir d'ajustements.

(Si une branche 3.9.0 devait être ajoutée au référentiel lapack-release, je soupçonne que les deux responsables ont dû porter leur attention sur...

Cela pourrait être évité par exemple aussi simple que cela puisse paraître.

Ils ont juste oublié d'ajouter 3.9.0 à lapack-release probablement. Cela semble être une habitude SVN d'avoir ceci comme tronc et l'autre comme copie de version.

Je suis d'accord, cela ressemble à une branche SVN, un tronc, une structure de balises.

Salut, je ne suis pas contre la réorganisation de la structure globale et remonter dans le temps pour faire les choses suivant la nouvelle structure réorganisée. Nous sommes en effet passés de SVN à GIT il y a quelques années, puis quelques mises à jour ont peut-être échappé. Si quelqu'un veut prendre les devants, baliser, restructurer et faire en sorte que le GitHub LAPACK ressemble à un exemple de la meilleure pratique de référentiel Git, ce serait formidable. Julien.

Je n'ai aucun problème avec cela, sauf que j'ai vu "réorganisons le référentiel" devenir la fin de plus d'un projet "hérité", et je suis beaucoup plus préoccupé par les problèmes non traités et les nouvelles fonctionnalités non approuvées.

C'est très déroutant car le slogan de lapack-release est "LAPACK official release branches", y a-t-il une chance que cela puisse être changé en quelque chose comme "Old LAPACK release branches" ?

Salut @jfowkes. "LAPACK official release branches" ne me dérange pas. Nous pourrions ajouter les branches de version "précédentes" du monde. Je serai d'accord pour ajouter "précédent", mais ma préférence est de laisser les choses telles quelles. Commentaires bienvenus. @langou

Salut @langou , ajouter "précédent" serait super. Quand j'ai lu "branches de publication officielles", j'ai supposé que toutes les branches de publication seraient là et j'ai été très confus lorsque les dernières manquaient.