Compreendendo o ciclo de lançamento do Arch Linux

Question

Sou novo no Arch e talvez essa pergunta tenha sido feita centenas de vezes antes, mas eu não encontrei uma resposta nem mesmo na documentação oficial do Arch como esta: link

Arch é uma distro de lançamento. Isso é claro para mim. Mas, o que acontece quando uma nova versão de um componente é lançada? Vamos usar o kernel como exemplo:
Um novo kernel estável está disponível em www.kernel.org (por exemplo, 3.12.8). Este kernel é empacotado como está e é enviado para o repositório do Arch ou:

1. há algum loop de controle de qualidade (teste) antes de enviar um pacote para o repo?
2. algumas correções são aplicadas?

No arco, se eu digitar uname -r , receberei 3.12.8-1 . Então, -1 significa alguma customização / correção?

    

Answer 1

1. Para atualizações em que o pacote provavelmente não interrompe a inicialização do sistema, é provável que não haja muito controle de qualidade antes que o pacote seja atualizado, a não ser verificar se ele é compilado e executado corretamente. Geralmente é esperado que o upstream faça o teste em vez da distribuição.
2. O Arch Linux normalmente não aplica correções ao upstream, exceto para corrigir erros críticos. Veja The Arch Way , especialmente as partes sobre simplicidade.
3. uname -r imprime a versão do kernel, que no Arch também contém o número de lançamento (conhecido como pkgrel em PKGBUILDs, consulte aqui ). Não indica necessariamente um nível de patch. Na página vinculada:

This value allows users to differentiate between consecutive builds of the same version of a package. When a new package version is first released, the release number starts at 1. As fixes and optimizations are made to the PKGBUILD file, the package will be re-released and the release number will increment by 1. When a new version of the package comes out, the release number resets to 1.

    

Answer 2

O nível de controle de qualidade é dependente do tipo Repo.

Core has fairly strict quality requirements. Developers/users need to signoff on updates before package updates are accepted. For packages with low usage, a reasonable exposure is enough: informing people about update, requesting signoffs, keeping in testing up to a week depending on the severity of the change, lack of outstanding bug reports, along with the implicit signoff of the package maintainer.

Veja link e link