Lapack: Referenz-LAPACK/lapack vs. Referenz-LAPACK/lapack-release

Erstellt am 29. Sept. 2020  ·  10Kommentare  ·  Quelle: Reference-LAPACK/lapack

Hey,

Warum gibt es zwei *.gits, die mehr oder weniger dasselbe darstellen? Verpasse ich etwas?

Reference-LAPACK/lapack-release fehlt v.3.9.0 und natürlich alle neueren Commits und Reference-LAPACK/lapack fehlen die Tags ab 3.6.0.
In der Release-Version repräsentieren verschiedene Branches die Tags.

Wenn alle Tags bis 3.1.0 implementiert werden könnten, könnten Tags in Reference-LAPACK/lapack Reference-LAPACK/lapack gelöscht werden.

Enhancement

Hilfreichster Kommentar

Hallo, ich bin nicht gegen eine Reorganisation der Gesamtstruktur und gehe in der Zeit zurück, um die Dinge nach der neuen reorganisierten Struktur zu machen. Wir sind tatsächlich vor ein paar Jahren von SVN zu GIT gewechselt, und dann sind vielleicht ein paar Updates durchgeschlüpft. Wenn jemand die Führung übernehmen, taggen, umstrukturieren und den LAPACK-GitHub wie ein Beispiel für die beste Git-Repository-Praxis aussehen und sich anfühlen lassen möchte, wäre dies großartig. Julien.

Alle 10 Kommentare

Ich vermute, dass dies einfach ein Ergebnis der Konvertierung von einem beliebigen CVS-System ist, das vor 3.7 verwendet wurde, und der Umstellung auf Github. Was wäre gewonnen, wenn man einen von ihnen löscht und in dem anderen nachträglich Releases markiert (was mühsam oder sogar technisch unmöglich sein kann, je nachdem, wie Quellbäume in früheren Tagen gehandhabt wurden, und auf jeden Fall die "Archivqualität" des Habens entfernen würde die alten Versionen genau so, wie sie erstellt wurden) ?

Der Vorteil wäre weniger Verwirrung aufgrund der Konsistenz. Jetzt gibt es überlappende Daten.

Zum Beispiel sucht jemand nach der neuesten Release-Version von lapack und findet zuerst das Repository Reference-LAPACK/lapack-release . Dann hält er fälschlicherweise 3.8.0 für die neuste. Dies kann insbesondere passieren, wenn das Repository explizit release heißt.
Auch das Bereitstellen von Feedback durch das Erstellen von Issues erfolgt derzeit in beiden Repositories und zusätzlich auf Netlib.

Wenn es aus Archivierungsgründen aufbewahrt werden soll, sollte es mit Verweis auf das aktuelle SCM als solches gekennzeichnet und Ausgaben deaktiviert werden, um Verwechslungen zu vermeiden.

Die README.md im Repo "lapack-release" weist bereits darauf hin, und ich stelle fest, dass dieses Setup in den letzten Jahren anscheinend funktioniert hat, so ungewöhnlich es auch aussehen mag. (Wenn irgendetwas ein 3.9.0-Zweig zum Lapack-Release-Repository hinzugefügt werden muss, vermute ich, dass beide Betreuer ihre Aufmerksamkeit auf neuartige Unterrichtsbedingungen lenken mussten, die durch die Covid-Pandemie kurz nach der 3.9.0-Veröffentlichung geschaffen wurden).

Sie haben wahrscheinlich nur vergessen, 3.9.0 zu lapack-release hinzuzufügen. Scheint eine SVN-Gewohnheit zu sein, dies als Trunk und das andere als Release-Kopie zu haben.

Aber die Leute verwenden sowieso kaum GitHub für die LAPACK-Verteilung, da die meisten entweder zu NetLib zum Download gehen oder sowieso eine andere spezialisierte Implementierung verwenden.

Ich stelle fest, dass dieses Setup in den letzten paar Jahren funktioniert zu haben scheint, so ungewöhnlich es auch aussehen mag.

Dies bedeutet nicht, dass es das perfekte Setup ist oder dass es keine Anpassungen geben kann.

(Wenn irgendetwas ein 3.9.0-Zweig zum Lapack-Release-Repository hinzugefügt werden muss, vermute ich, dass beide Betreuer ihre Aufmerksamkeit auf ...

Dies könnte beispielsweise vermieden werden, so einfach es aussehen mag.

Sie haben wahrscheinlich nur vergessen, 3.9.0 zu Lapack-Release hinzuzufügen. Scheint eine SVN-Gewohnheit zu sein, dies als Trunk und das andere als Release-Kopie zu haben.

Ich stimme zu, es sieht aus wie SVN-Zweig, Stamm, Tag-Struktur.

Hallo, ich bin nicht gegen eine Reorganisation der Gesamtstruktur und gehe in der Zeit zurück, um die Dinge nach der neuen reorganisierten Struktur zu machen. Wir sind tatsächlich vor ein paar Jahren von SVN zu GIT gewechselt, und dann sind vielleicht ein paar Updates durchgeschlüpft. Wenn jemand die Führung übernehmen, taggen, umstrukturieren und den LAPACK-GitHub wie ein Beispiel für die beste Git-Repository-Praxis aussehen und sich anfühlen lassen möchte, wäre dies großartig. Julien.

Ich habe kein Problem damit, außer dass ich gesehen habe, dass „Lasst uns das Repository neu anordnen“ das Ende von mehr als einem „Legacy“-Projekt wurde, und ich mache mir viel mehr Sorgen über unbehandelte Probleme und neue Funktionen, die nicht genehmigt werden.

Dies ist sehr verwirrend, da der Slogan für Lapack-Release "LAPACK Official Release Branches" lautet. Besteht die Möglichkeit, dass dies in etwas wie "Old LAPACK Release Branches" geändert werden könnte?

Hallo @jfowkes. "LAPACK Official Release Branches" ist für mich nicht verwirrend. Wir könnten die weltweiten "vorherigen" Release-Zweige hinzufügen. Ich kann "zurück" hinzufügen, aber ich ziehe es vor, die Dinge so zu lassen, wie sie sind. Kommentare willkommen. @langu

Hallo @langou , das Hinzufügen von "zurück" wäre großartig. Als ich „offizielle Veröffentlichungszweige“ las, ging ich davon aus, dass alle Veröffentlichungszweige vorhanden sein würden, und war sehr verwirrt, als die neuesten fehlten.

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen