Lapack: リファレンス-LAPACK / lapackとリファレンス-LAPACK / lapack-release

これは、3.7より前に使用されていたCVSシステムからの変換とgithubへの移行の結果であると思われます。 それらの1つを削除し、もう1つのリリースにさかのぼってタグを付けることで得られるもの（これは、以前のソースツリーの処理方法によっては、面倒で技術的に不可能な場合があり、いずれにせよ、古いリリースは作成されたとおりです）？

一貫性があるため、混乱が少なくなるという利点があります。 現在、重複するデータがあります。

たとえば、誰かがlapackの最新リリースバージョンを検索していて、リポジトリReference-LAPACK/lapack-release最初に見つけました。 それから彼は最新のもののために3.8.0を偽りに取っています。 これは、リポジトリが明示的にreleaseと呼ばれる場合に特に発生する可能性があります。
また、Issuesを作成してフィードバックを提供することは、現在、リポジトリとnetlibの追加の両方で行われています。

アーカイブ品質のために保持する必要がある場合は、現在のSCMを参照してそのようにマークし、混乱を避けるために問題を非アクティブ化する必要があります。

「lapack-release」リポジトリのREADME.mdはすでにここを指しています。この設定は過去数年間は機能しているように見えますが、見た目は珍しいかもしれません。 （3.9.0ブランチをlapack-releaseリポジトリに追加する必要がある場合は、両方のメンテナが3.9.0リリースの直後にcovidパンデミックによって作成された新しい教育条件に注意を向ける必要があったと思います）。

彼らはおそらくlapack-releaseに3.9.0を追加するのを忘れていました。 これをトランクとして、もう一方をリリースコピーとして持つSVNの習慣のようです。

しかし、ほとんどの場合、ダウンロードのためにNetLibにアクセスするか、他の特殊な実装を使用するため、LAPACKの配布にGitHubを使用することはほとんどありません。

この設定は過去数年間は機能しているように見えますが、見た目は珍しいことに注意してください。

これは、それが完璧なセットアップである、または調整ができないという意味ではありません。

（3.9.0ブランチをlapack-releaseリポジトリに追加する必要がある場合は、両方のメンテナが注意を向ける必要があったと思います...

これは、たとえば見た目が単純なため、回避できます。

彼らはおそらくlapack-releaseに3.9.0を追加するのを忘れていました。 これをトランクとして、もう一方をリリースコピーとして持つSVNの習慣のようです。

私は同意します、それはSVNブランチ、トランク、タグ構造のように見えます。

こんにちは、私は全体的な構造の再編成に反対していません。そして、新しい再編成された構造に従って物事を作るために時間を遡ります。 私たちは確かに数年前にSVNからGITに移行しましたが、その後、いくつかの更新がすり抜けた可能性があります。 誰かがこれを主導し、タグを付け、再構築し、LAPACK GitHubをGitリポジトリのベストプラクティスの例のように見せたい場合は、これは素晴らしいことです。 ジュリアン。

「リポジトリを再配置しましょう」が複数の「レガシー」プロジェクトの終わりになり、未処理の問題や新機能が承認されないことをはるかに心配していることを除けば、問題はありません。

lapack-releaseのタグラインは「LAPACK公式リリースブランチ」であるため、これは非常に混乱します。これが「古いLAPACKリリースブランチ」のようなものに変更される可能性はありますか？

こんにちは@jfowkes。 「LAPACK公式リリースブランチ」は私を混乱させません。 世界の「以前の」リリースブランチを追加できます。 「前」を追加しても大丈夫ですが、私の好みはそのままにしておくことです。 コメントを歓迎します。 @langou

こんにちは@langou 、「前へ」を追加するのは素晴らしいことです。 「公式リリースブランチ」を読んだとき、すべてのリリースブランチがそこにあると思い、最新のものが欠落していると非常に混乱しました。