Lapack: Reference-LAPACK/lapack 대 Reference-LAPACK/lapack-release

나는 이것이 단순히 3.7 이전에 사용되었던 CVS 시스템에서 변환하고 github으로 이동한 결과라고 생각합니다. 그 중 하나를 삭제하고 다른 릴리스에 소급 태그를 지정하여 얻을 수 있는 것 생성된 그대로의 이전 릴리스) ?

일관성 때문에 이점이 덜 혼란스러울 것입니다. 이제 중복되는 데이터가 있습니다.

예를 들어 누군가 lapack의 최신 릴리스 버전을 검색하고 Reference-LAPACK/lapack-release 저장소를 먼저 찾습니다. 그런 다음 그는 3.8.0을 최신 버전으로 잘못 사용하고 있습니다. 이것은 특히 저장소가 명시적으로 release 라고 하는 경우에 발생할 수 있습니다.
또한 문제를 생성하여 피드백을 제공하는 것은 현재 저장소와 netlib에서 추가로 수행됩니다.

보관 품질을 위해 보관해야 하는 경우 현재 SCM을 참조하여 표시해야 하며 혼동을 피하기 위해 문제를 비활성화해야 합니다.

"lapack-release" 리포지토리의 README.md는 이미 여기를 가리키고 있으며 이 설정은 지난 몇 년 동안 작동한 것으로 보이지만 이례적으로 보일 수 있습니다. (만약 3.9.0 분기를 lapack-release 저장소에 추가해야 하는 경우 두 관리자 모두 3.9.0 릴리스 직후 코로나바이러스 대유행으로 인해 생성된 새로운 교육 조건으로 주의를 옮겨야 했다고 생각합니다.)

아마도 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님 , "이전"을 추가하는 것이 좋습니다. "공식 릴리스 분기"를 읽었을 때 모든 릴리스 분기가 거기에 있을 거라고 가정했고 최신 분기가 없을 때 매우 혼란스러워했습니다.