O Fedora está afinando o seu processo de qualidade para a era do UEFI — mas sem largar a mão de quem ainda depende de BIOS legado. A equipe de QA do Fedora propôs limitar o status de “bloqueador de lançamento” para falhas que ocorram apenas em alguns cenários específicos quando o boot é em BIOS. A equipe do Fedora CoreOS concordou com a direção: em vez de insistir em testes manuais abrangentes nesse modo, vai confiar na sua CI (Integração Contínua) e em um “test day” por ciclo do Fedora para garantir cobertura suficiente. Na prática, o suporte continua; o que muda é a prioridade: um bug que afete exclusivamente BIOS pode não segurar mais um release inteiro — especialmente agora, às vésperas do Fedora 43 entrar em Beta Freeze.
A proposta: foco em testes automatizados
Pense no QA como uma equipe de resgate: quando o número de chamados cresce e o mapa da cidade muda (com UEFI predominando), você realoca viaturas para onde há mais risco e probabilidade de ocorrência. É esse o espírito da proposta do Fedora QA: tornar “release-blocking” apenas um conjunto reduzido de cenários em BIOS — instalações padrão com particionamento automático, upgrades do sistema, boot de imagens em nuvem (ex.: EC2) e funcionalidades essenciais. O restante segue sendo suportado, mas não trava o cronograma se algo falhar.
O argumento é simples e pragmático: testar tudo em BIOS e em UEFI duplica o esforço humano e alonga filas, enquanto BIOS-only é cada vez mais raro no parque de hardware atual. A automação, por outro lado, escala bem — e é aqui que o Fedora CoreOS vem reforçar a mudança.
A posição da equipe CoreOS
A equipe do Fedora CoreOS foi clara: “não vemos problema” em o Fedora QA reduzir os testes manuais de CoreOS em BIOS. Por quê? Porque o projeto já vive, no dia a dia, da sua CI e pipelines que cobrem boot e cenários críticos — inclusive BIOS — de forma repetível e rápida. Além disso, há um test day manual uma vez por ciclo do Fedora para capturar arestas que a automação não pega.
Há também um detalhe tático importante sobre cadência: quando se fala em “bloquear o lançamento”, o Fedora tradicional trabalha com marcos semestrais (alfa, beta, final), enquanto o CoreOS lança a cada duas semanas. Se um artefato específico do CoreOS tropeça, a equipe pode corrigi-lo rapidamente no próprio fluxo, sem precisar paralisar toda a edição do Fedora. Em outras palavras, menos ansiedade e mais velocidade de recuperação.
O que muda para você (usuário e admin)
Se você está em BIOS legado, seu sistema não perde suporte. A diferença é que um bug restrito a BIOS tende a ser tratado como prioridade operacional do CoreOS (via CI e hotfixes) em vez de virar um freio de mão para todo o Fedora. Na prática:
- Mais previsibilidade de releases: menos chances de adiamentos por regressões que afetam um nicho.
- Correções mais ágeis no CoreOS: a cadência quinzenal e o CI ajudam a resolver rapidamente.
- Cobertura realista de testes: foco em cenários de maior impacto, com “rede de segurança” num test day por ciclo.
É um compromisso moderno: a comunidade prioriza onde o risco é maior hoje (UEFI), sem deixar de olhar para trás quando necessário (BIOS).
Por que isso importa agora (Fedora 43)
O timing não é coincidência. O Fedora 43 entrou em Beta Freeze em 26 de agosto de 2025 — aquele período em que a atenção vira totalmente para estabilização e correções. Refinar o que realmente pode “bloquear” um lançamento ajuda o projeto a atravessar o freeze com menos barulho e mais foco. Em termos de engenharia de produto, é a diferença entre tentar abraçar o mundo e escolher batalhas que maximizam a qualidade percebida por mais gente.
E os riscos?
Toda mudança de processo traz perguntas. E se algo passar batido justamente porque não foi testado manualmente? A equipe do CoreOS reconhece a possibilidade, mas aposta na redundância: o CI detecta o comum, o test day captura os cantos, e a cadência rápida do CoreOS permite mitigação sem contaminar o resto do Fedora. É como usar cinto e airbag: você confia no cinto (CI) para 99% dos casos, mas sabe que existe uma proteção extra quando precisa (test day e hotfixes).
Rodapé da reunião
A discussão foi pública e registrada: proposta no fórum, issue de rastreio aberta e, na reunião semanal, ficou combinado que Dusty Mabe comunicaria oficialmente a posição da equipe no tópico do fórum. Transparência e accountability — o caminho padrão da comunidade Fedora.
Outros assuntos em duas linhas
Além do tema BIOS, a reunião passou rapidamente por cronograma do F43 (ramificação feita; Beta Freeze chegando) e por tópicos de automação interna do CoreOS — sem impacto direto imediato para o usuário final, mas coerentes com o foco em processos mais automáticos e escaláveis.
