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

Suspeito que isso seja simplesmente resultado da conversão de qualquer sistema CVS usado antes do 3.7 e da mudança para o github. O que se ganharia com a exclusão de um deles e a marcação retroativa de lançamentos no outro (o que pode ser tedioso ou mesmo tecnicamente impossível, dependendo de como as árvores de origem foram tratadas nos dias anteriores e, em qualquer caso, removeria a qualidade de "arquivamento" de ter as versões antigas exatamente como foram criadas) ?

O benefício seria menos confusão por causa da consistência. Agora há dados sobrepostos.

Por exemplo, alguém está procurando a versão mais recente do lapack e encontra o repositório Reference-LAPACK/lapack-release primeiro. Então ele está tomando 3.8.0 falsamente para o mais novo. Isso pode acontecer especialmente quando o repositório é explicitamente chamado release .
Também fornecer feedback criando problemas agora é feito em ambos os repositórios e adicionalmente no netlib.

Se ele deve ser mantido para qualidade de arquivamento, deve ser marcado como tal com referência ao SCM atual e os problemas devem ser desativados para evitar confusão.

O README.md no repositório "lapack-release" já aponta aqui, e noto que essa configuração parece ter funcionado nos últimos dois anos, por mais incomum que possa parecer. (Se alguma coisa que uma ramificação 3.9.0 precisar ser adicionada ao repositório lapack-release, suspeito que ambos os mantenedores tiveram que mudar sua atenção para novas condições de ensino criadas pela pandemia de covid logo após o lançamento 3.9.0).

Eles simplesmente esqueceram de adicionar 3.9.0 a lapack-release provavelmente. Parece um hábito do SVN ter isso como tronco e o outro como cópia de lançamento.

Mas quase nunca, as pessoas usam o GitHub para distribuição LAPACK de qualquer maneira, já que a maioria vai para o NetLib para download ou usa alguma outra implementação especializada de qualquer maneira.

Observo que essa configuração parece ter funcionado nos últimos dois anos, por mais incomum que possa parecer.

Isso não significa que seja a configuração perfeita ou que não possa haver ajustes.

(Se algo de um branch 3.9.0 precisar ser adicionado ao repositório lapack-release, suspeito que ambos os mantenedores tiveram que mudar sua atenção para ...

Isso poderia ser evitado, por exemplo, por mais simples que possa parecer.

Eles apenas esqueceram de adicionar 3.9.0 ao lapack-release provavelmente. Parece um hábito do SVN ter isso como tronco e o outro como cópia de lançamento.

Eu concordo, parece que SVN branch, trunk, tag estrutura.

Olá, não sou contra a reorganização da estrutura geral e volto no tempo para fazer as coisas seguindo a nova estrutura reorganizada. De fato, mudamos do SVN para o GIT há alguns anos e, em seguida, algumas atualizações podem ter escapado. Se alguém quiser liderar isso, marcar, reestruturar e fazer com que o LAPACK GitHub pareça um exemplo da melhor prática de repositório Git, isso seria ótimo. Julien.

Não tenho nenhum problema com isso, exceto que vi "vamos reorganizar o repositório" se tornar o fim de mais de um projeto "legado", e estou muito mais preocupado com problemas não tratados e novas funcionalidades que não são aprovadas.

Isso é muito confuso, pois o slogan para o lançamento do lapack é "ramificações oficiais de lançamento do LAPACK", alguma chance disso ser alterado para algo como "ramificações de lançamento do LAPACK antigas"?

Olá @jfowkes. "Ramos de lançamento oficial do LAPACK" não é confuso para mim. Poderíamos adicionar as ramificações de lançamento "anteriores" do mundo. Eu vou ficar bem adicionando "anterior", mas minha preferência é deixar as coisas como estão. Comentários são bem-vindos. @langou

Oi @langou , adicionar "anterior" seria ótimo. Quando li "ramos de lançamento oficiais", presumi que todos os ramos de lançamento estariam lá e fiquei muito confuso quando os mais recentes estavam faltando.