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

I suspect this is simply a result of converting from whatever CVS system was used prior to 3.7 and the move to github. What would be gained by deleting one of them and retroactively tagging releases in the other (which may be tedious or even technically impossible, depending on how source trees where handled in earlier days, and in any case would remove the "archival" quality of having the old releases exactly as they were created) ?

The benefit would be less confusion because of consistency. Now there is overlapping data.

For example someone is searching for the newest release version of lapack and he finds the repository Reference-LAPACK/lapack-release first. Then he is taking 3.8.0 falsfully for the newest one. This can happen especially when the repository is explicitliy called release.
Also providing feedback by creating Issues is right now done in both repositories and additionaly on netlib.

If it should be kept for archival quality it should be marked as such with reference to the current SCM and issues should be deactivated to avoid confusion.

The README.md in the "lapack-release" repo already points here, and I do note that this setup appears to have worked for the past couple of years, however unusual it might look. (If anything a 3.9.0 branch might need to be added to the lapack-release repository, I suspect both maintainers had to move their attention to novel teaching conditions created by the covid pandemic soon after the 3.9.0 release).

They just forgot to add 3.9.0 to lapack-release probably. Seems like an SVN habit to have this as trunk and the other as the release copy.

But hardly ever, people use GitHub for LAPACK distribution anyways since most either goes to NetLib for download or use some other specialized implementation anyways.

I do note that this setup appears to have worked for the past couple of years, however unusual it might look.

This does not mean it is the perfect setup or there can not be adjustments.

(If anything a 3.9.0 branch might need to be added to the lapack-release repository, I suspect both maintainers had to move their attention to...

This could be avoided for example as simple it might look.

They just forgot to add 3.9.0 to lapack-release probably. Seems like an SVN habit to have this as trunk and the other as the release copy.

I agree, it looks like SVN branch, trunk, tag structure.

Hi, I am not against reorganization of the overall structure and go back in time to make things following the new reorganized structure. We indeed moved from SVN to GIT a few years back, and then a few updates might have slipped through. If someone wants to take the lead on this, tag, restructure, and have the LAPACK GitHub looks and feel like an example of best Git repository practice, this would be great. Julien.

I have no problem with that except that I have seen "let's rearrange the repository" become the end of more than one "legacy" project, and I am far more concerned about unhandled issues and new functionality not getting approved.

This is very confusing as the tagline for lapack-release is "LAPACK official release branches", any chance this could be changed to something like "Old LAPACK release branches"?

Hi @jfowkes. "LAPACK official release branches" is not confusing to me. We could add the world "previous" release branches. I'll be OK adding "previous", but my preference is to leave things as is. Comments welcome. @langou

Hi @langou, adding "previous" would be great. When I read "official release branches" I assumed that all the release branches would be there and got very confused when the latest ones were missing.