Resumo

  • As políticas da Mozilla distinguem aprovação por responsável ou peer de módulo, nível individual de acesso ao repositório, integração de código e gestão de marcos e árvores pelos Release Drivers.
  • Um recibo de revisão a lançamento deve guardar módulo, mudança, papel que revisou, fundamento de acesso quando relevante, revisão integrada, ramificação, decisão de lançamento e artefato público em vez de transformar um único OK numa promessa de Firefox.

Quatro fatos escondidos numa aprovação

“A Mozilla aprovou” pode ser uma frase verdadeira e ainda assim insuficiente. Ela pode falar da revisão de um patch dentro de um módulo, da credencial de uma pessoa, do pouso de uma revisão numa ramificação de desenvolvimento, da escolha para um marco ou de um artefato já oferecido a usuários do Firefox. São decisões com responsáveis, registros e efeitos diferentes.

A política de Module Ownership atribui a liderança do trabalho de um módulo ao seu responsável. Para um módulo de código, o OK do responsável é necessário para que código entre ali. Ele pode designar peers que também aprovam código e deve entregar a avaliação do próprio código a um peer. Pode pedir alterações, recusar um patch ou adiar uma revisão, explicando o motivo no bug pertinente. Se uma controvérsia não se resolver, a estrutura de Module Ownership pode intervir.

Isso é uma autorização de julgamento técnico delimitada. Não é uma credencial geral de repositório e não escolhe o conteúdo de uma versão do Firefox. A própria Mozilla separa responsável de módulo e proprietário de componente Bugzilla: um dirige e revisa código; o outro é destinatário padrão de relatórios. Os papéis às vezes são exercidos pela mesma pessoa, mas a sobreposição não elimina a fronteira.

Acesso de commit é confiança numa pessoa

A Commit Access Policy pergunta outra coisa: quais permissões uma pessoa precisa para fazer commit em repositórios diferentes? Ela define níveis de acesso e exigências de aval distintas. No acesso ao produto central, aplicam-se os avais previstos de responsáveis ou peers de módulo relevantes, ou de Tree Sheriffs. Mesmo nesse nível, a política diz que controles sociais podem impedir check-ins de certas pessoas em certas árvores.

Assim, acesso não é licença portátil para ignorar as demais regras. É uma decisão de confiança e familiaridade relativa a um indivíduo. O procedimento público exige que o candidato informe o nível, forneça chave SSH, concorde com os requisitos e obtenha os apoios necessários antes que a conta seja verificada e criada. Os avalistas assumem responsabilidade inicial pelos commits e, nas circunstâncias previstas, podem pedir revogação. Nada disso responde sozinho se uma alteração concreta merece entrar num módulo.

Um responsável de módulo pode participar do aval de acesso. Mas uma revisão favorável não emite automaticamente uma permissão, e alguém com permissão não vira o revisor adequado de toda alteração que consiga alcançar. A explicação pública precisa manter trilha de revisão e fundamento da credencial como fatos separados.

Integração não é promessa de entrega

Uma integração liga a mudança a uma revisão, repositório e ramificação. É informação valiosa, mas não prova que chegará ao usuário. O guia de envio do Firefox descreve firefox-main, firefox-beta e firefox-release, com os canais Nightly, Beta e Release. O movimento entre eles tem ritmo e condições próprios; para seguir a beta, o código precisa primeiro ter pousado em main.

Release Drivers têm outra função: gestão de projeto dos lançamentos de marco, orientação sobre correções importantes e decisões de gestão de árvores. A revisão do módulo pode permitir a próxima passagem, mas não seleciona sozinha uma versão pública. Uma prioridade de lançamento tampouco reescreve a avaliação técnica. Dot releases dependem de um driver suficientemente importante; não decorrem automaticamente de um OK anterior.

Um registro para cada passagem

Uma afirmação relevante deveria começar com a identidade estável da mudança e do módulo. Deve indicar o responsável ou peer que revisou, a discussão pública e a data. Se invocar acesso, deve registrar o nível ou caminho autorizado aplicável sem divulgar dados pessoais desnecessários. Depois, revisão integrada, repositório e ramificação. Para uma afirmação de lançamento, canal ou ramo alvo, evidência da seleção, artefato público e data.

O registro também deve dizer onde a prova termina. Revisão não é concessão de acesso; acesso não é revisão; uma revisão de código não é lançamento. Isto não impõe um novo procedimento à Mozilla. Apenas torna visível a separação que suas políticas já criaram e impede que um leitor converta um patch em produto antes da decisão que falta.

Sources

  1. Mozilla Modules and Module Owners
  2. Mozilla Commit Access Policy
  3. Becoming A Mozilla Committer
  4. Mozilla Roles and Leadership
  5. Pocket Guide: Shipping Firefox
  6. Lu Heng, The Multi-Stakeholder Mirage
  7. Lu Heng, Running-Code Primacy