A notícia mais importante — e acionável — para a comunidade Fedora CoreOS: a equipe definiu a Test Week oficial do Fedora 43 para os dias 22 a 26 de setembro de 2025, com uma sessão ao vivo de “Test Day” no dia 22/09 (horário a ser divulgado no rastreador do projeto). Pense nisso como um “mutirão” coordenado para chacoalhar a árvore e ver que bugs caem — quanto mais gente testando, mais robusta fica a release.
Por que agora? O ciclo do Fedora entrou em beta freeze, e o lançamento beta está previsto para 16 de setembro. Traduzindo: é o momento perfeito para validar imagens, fluxos de atualização e integrações, antes que a janela se feche para mudanças maiores. A semana de testes ajuda a garantir que quem usa CoreOS em produção — clusters Kubernetes, homelabs, edge — não será surpreendido por regressões.
O que você pode fazer hoje:
- Reserve a semana de 22 a 26/09 no calendário.
- Prepare seu ambiente: VMs, bare metal ou nuvem — quanto mais diversidade, melhor.
- Planeje rodar cenários reais: provisionamento (Ignition/Butane), upgrades entre streams, validação de ostree e de containers base, checagens de rede e storage.
- Reporte tudo que encontrar com logs e passos de reprodução. Pequenas fricções agora evitam grandes incidentes depois.
Esse esforço é coletivo por design. O projeto valoriza a transparência: decisões, pendências e confirmações acontecem em reuniões abertas e issues públicas, o que facilita alinhar a “Test Week” com o cronograma maior do Fedora 43.
Nos bastidores: a modernização do sistema de build
Enquanto a comunidade se organiza para testar, o time segue afinando a engenharia que constrói o Fedora CoreOS. Há um movimento claro — e pragmático — para modernizar o pipeline, aproximando-o de práticas atuais do ecossistema de containers. Em termos simples: sair de caminhos legados e avançar para ferramentas mais modernas, como Konflux (a plataforma de supply chain do Fedora) e podman, reduzindo atritos operacionais e melhorando segurança.
O que isso significa na prática?
- Menos complexidade, mais padronização: usar podman no processo de build e integrar com Konflux tende a simplificar etapas, encurtar feedback loops e facilitar auditoria.
- Foco em segurança por padrão: a equipe está estruturando um modelo de assinatura de contêineres que permita verificar a procedência das imagens distribuídas — um pilar essencial de supply chain. Esse mecanismo convive, por ora, com o que já existe (como o uso de ostree), mas aponta para um futuro mais coeso e verificável.
- Transição com cautela: para evitar impacto em quem acompanha o Rawhide, a ideia é validar primeiro em um fluxo de desenvolvimento (devel/staging), ganhando confiança antes de ligar a chave para todos. É uma caminhada em passos firmes — não uma corrida às cegas.
Se você administra clusters, esse trabalho “invisível” interessa diretamente: builds mais previsíveis e assinados significam menos surpresas no dia a dia, melhor observabilidade e um caminho mais claro para responder a incidentes de supply chain. E, claro, tudo isso é discutido às claras — com votos, revisões e registros públicos — reforçando a cultura de engenharia aberta do Fedora.
