Se você já atualizou seu sistema com aquela sensação de “é só um patchzinho” e, minutos depois, percebeu que algo essencial quebrou, você já entende a dor que motivou esta conversa no Fedora. Um incidente recente envolvendo o pacote Mesa no Fedora 43 reacendeu um debate bem antigo no mundo de software: como equilibrar atualizações rápidas com estabilidade, sem transformar cada falha numa caça às bruxas.
A proposta na mesa agora é criar um novo SIG (Special Interest Group) focado em “Production Stability and Incident Management”, com a missão de profissionalizar processos: definir o que é um incidente relevante, como comunicar riscos, como coordenar resposta e, principalmente, como aprender com o que deu errado.
O caso Mesa e a necessidade de mudança
O gatilho foi uma atualização do Mesa (citada na discussão como mesa-25.2.7-2.fc43) que chegou ao canal estável e acabou associada a quebras para parte dos usuários. A conversa não ficou só no “quem apertou o botão”: surgiram relatos de surpresa com mudanças que teriam entrado sem o nível de validação esperado, e também a percepção de que o problema não é apenas técnico, mas de colaboração.
Um ponto importante é que o caso já foi revisado pelo time de QA, inclusive em uma reunião formal em 24 de novembro de 2025, às 16:00 UTC. Mesmo assim, participantes argumentam que o episódio expôs algo mais profundo: fricção entre práticas internas da Red Hat, o trabalho do maintainer e as expectativas (e limites) de voluntários que contribuem no projeto, sem que ninguém “tenha direito” de exigir tempo ou energia deles.
Aprendendo com os erros (sem culpa)
Aqui entra a ideia de “incident management” aplicada ao open source. Em empresas, isso é quase um ritual: acontece um incidente, abre-se uma resposta coordenada, registra-se o impacto, comunica-se o status e depois vem o post-mortem. O detalhe que muda tudo é o “blameless”, ou seja, sem caça aos culpados. A lógica é simples: se cada falha vira julgamento, as pessoas escondem problemas, evitam tocar em áreas arriscadas e a qualidade piora.
Na discussão, aparece também um problema bem humano: comunicação em crise costuma cair nas costas de uma ou duas pessoas, que viram “central de atendimento” improvisada e terminam exaustas. O SIG é visto como uma forma de criar um mecanismo organizacional para dividir esse peso, melhorar práticas como “Common Issues” e reduzir burnout, sem transformar o grupo numa polícia.
O que mudaria na prática com um SIG
Na prática, a proposta tenta amarrar três coisas que hoje ficam soltas: diminuir a chance de uma atualização problemática chegar ao repositório stable, melhorar a comunicação enquanto o incidente está acontecendo (prazo, mitigação, downgrade e status), e garantir que cada falha resulte em aprendizado incorporado ao processo de testes e releases. A ideia é que isso seja um trabalho de coordenação e método, não um tribunal para buscar culpados.
A proposta não tenta ditar soluções prontas. A ambição é criar um espaço fixo para desenhar processos e combinados, por exemplo:
- critérios e gatilhos para tratar algo como incidente de produção;
- um playbook mínimo de resposta, triagem e comunicação com usuários;
- retrospectivas com ações concretas (e responsabilidade compartilhada) entre QA, mantenedores e contribuidores;
- um canal claro para traduzir “o que aconteceu” em melhorias de teste, empacotamento e coordenação.
No fundo, é uma tentativa de alinhar todo mundo em torno do mesmo objetivo: um Fedora que continue inovando rápido, mas que quebre menos, e quando quebrar, que aprenda melhor.
