Submetendo uma correção do Gaia

Até agora você pode fazer uma alteração do código e verificar que está funcionando no Gaia. O próximo passo é submeter sua correção para o repositório central e como fazer isso é o objetivo desse artigo.

Submissão de correção

Siga essas etapas para submter sua correção do Gaia:

Primeiramente, submeta um bug no bugzilla para indicar o que você está fazendo se ainda não existir uma correção em andamento. Você deve submeter o bug em Firefox OS product, e fornecer um título que descreva bem o que o seu código faz.
Agora é hora de criar uma pull request para sua correção. Se você está seguindo nosso guia desde o início, você deve ter suas alterações realizadas num fork local do repositório do Gaia. Depois, git add . suas alterações, então git commit -m 'my commit message'.
'my commit message' precisa ser substituído por uma string contendo o número e o título do bug no Bugzilla, mais alguma informação descrevendo o que a correção faz e quem realizou o commit. Por exemplo
```
Bug 9999999 - Fix that annoying bug R=johndoe
```
Envie o código para o seu fork do Gaia no Github, então crie o PR para oferecer o código para inclusão.
Inclua a URL da PR no histórico do Bug no Bugzilla (na seção Add an attachment).
No bug, solicite que alguém revise sua correção. Você deve fazer isso incluindo a flag review: ?, então inclua o proprietário do módulo que sua correção está atualizando (veja o página de proprietários dos módulos para maiores detalhes).
Espere que o seu bug seja atribuído a um revisor e que seja revisado. Neste ponto serão incluídos alguns comentários solicitando alterações/correções no PR do Github, e relacioná-los no Bugzilla.
Verifique os comentários dos revisores, faça as alterações necessárias, em seguida envie as alterações para o mesmo PR, anexando o flag review: ?.
Uma vez que os comentários dos revisores foram atendidos e eles deram o flag r+ (significando que a correção foi revista e aprovada), você deve juntar todos os commits em um único commit (leia também dicas do rebase do Gaia).
Adicione uma palavra-chave checkin-needed no campo de palavras-chave. Nesse ponto, você precisa esperar alguém colocar sua correção no fonte do Gaia.
Parabéns! Seu código agora é parte do Firefox OS!

Nota: Nós recomendamos fazer um commit por revisão.

Nota: Mais instruções de submissão de correções podem ser encontradas em contributing.md.

Dicas no Rebase do Gaia

O branch master do Gaia muda constantemente (muitas, muitas vezes no dia). Depois de criar uma correção que leva 2 horas, você pode descobrir que o branch master foi alterado desde a última vez que você baixou os fontes para trabalhar.

A partir do seu branch de trabalho (por exemplo my-code-fix), sua primeira tentativa de fazer um rebase será parecido com isso:

git checkout -b my-code-fix-r1
git pull --rebase upstream master

Se não houver conflitos, você pode continuar:

git checkout my-code-fix
git pull --rebase upstream master
git branch -D my-code-fix-r1

Se você encontrar conflitos, entre em contato com os desenvolvedores responsáveis por resolver os conflitos e repita o procedimento de rebase descrito acima.

Qual a diferença entre status tracking e bugs da engenharia?

Mozilla possui um perfil especial chamado Sheriff. Sheriffs são encarregados do merge de códigos e são responsáveis por manter os status dos branches. Uma vez que nós temos um número limitado de Sheriffs para testes de falhas nas equipes do Firefox OS, fica difícil para eles voltarem o processo de todas as correções imperfeitas.

Portanto, no Firefox OS, ao examinar se uma correção funciona ou não, preferimos abrir um novo bug para lançar novas correções para consertar o novo problema. Do contrário pode trazer problemas no status de rastreamento para as equipes de QA e de gerenciamento de projetos.

Assim, nós separamos os bugs em dois status: tracking bugs e engineering bugs.

Bugs com Status tracking devem ser identificados com a palavra-chave "meta". O bug pode ser reaberto se ele não cumprir os critérios de aceitação ou falhou durante os passos para reproduzir.
Um bug "engineering" pode ser reaberto somente se falhou nos testes automáticos ou a correção não funciona como um todo. Se um patch corrige um engineering bug parcialmente, você deve clonar o bug e usar o campo "See also" para referenciar o bug original descrevendo o ponto de falha.

Nota: Se também for um bug "story bug", o gerente de projeto deve regsitrar o campo user story com o histórico e o critério de aceitação.

Como eu recupero se acidentalmente lançar uma correçaão no bug com status tracking?

Não entre em pânico! Se você acidentalmente lançou uma correção, tem um review+, lançou no tunk ou tem reportado como nada corrigido, a seguir o que você precisa fazer:

Pressione "Clone this bug" no canto inferior direito da tela para criar um novo bug, clonando a maioria dos campos originais. Verifique os os campos: witheboard, keyword e STR/User Story foram copiados para o novo bug.
Marque o novo bug como bloqueado pelo bug anterior. O novo bug terá o novo status tracking bug.
Use a flag needinfo para alertar o gerente de projeto. Você pode pode encontrar os endereços de e-mail dos gerentes de projeto do Firefox OS na nossa Wiki.
Crie um novo engineer bug para descrever o passo com a falha ou o critério de aceitação. Também use o novo bug para bloquear o status tracking bug.
Tente consertar o novo bug.

Promovendo correções para branches antigos

Você pode encontrar versões diferentes de tags nos bugs. Se você deseja promover correções para branches antigos do Firefox OS, certifique-se que preencham as regras para lançamento de uma correção. Maiores detalhes nessa página.