Soumettre un correctif pour Gaia

À cette étape, vous devriez avoir apporté une modification au code de Gaia et avoir testé que cette modification n'impacte pas Gaia. La prochaine étape consiste à soumettre votre correctif sur le dépôt central. Cet article explique ces étapes.

Soumettre des correctifs pour Gaia peut paraitre un peu déroutant, jusqu'à ce que vous en ayez pris l'habitude. Cela implique d'utiliser Bugzilla et Github, ainsi que l'utilisation de drapeaux spéciaux dans Bugzilla pour que tout se déroule correctement. Vous pouvez aussi voir à quoi ressemble le processus complet, dans la section Envoi_manuel_d'un_correctif; cependant, nous vous conseillons d'utiliser l'outil Autolander au quotidien, sauf si vous avez une bonne raison de ne pas le faire, voir la section suivante.

Envoi de correctif de manière aisée avec Autolander

Autolander est un outil qui prend en charge automatiquement, beaucoup d'étapes nécessaires à l'envoi d'un correctif pour Gaia (et d'autres projets qui l'utilisent), réduisant le temps, et les erreurs possibles, tout au long de la procédure. Autolander réalise l'automatisation des processus entre Bugzilla et Github en attachant les pull requests (de Github) aux bugs (de Bugzilla), et en les intégrants une fois que l'attachement à reçu un drapeau r+, et que le mot-clé autoland est ajouté au bug. Pour utiliser Autolander :

Tout d'abord, si le bug correspondant n'existe pas, créez-en un pour le produit Firefox OS, et donnez-lui un titre explicite détaillant le but de votre correctif.
Vous pouvez alors créer une pull request pour votre correctif. Si vous avez suivi ce guide depuis le début, vos changements devraient être présents dans une branche spécifique, unique, de votre fork en local. Pour ajouter vos modifications, faites git add . puis git commit -m 'mon message de commit'.
'mon message de commit' devra être modifié afin de contenir le numéro de bug de Bugzilla et le titre du bug afin de donner plus d'informations sur ce que fait le correctif et qui doit l'examiner. Par exemple :
```
Bug 9999999 - Corrige ce bug Toto R=jeanbiche
```
Poussez votre code sur le fork de Gaia présent sur Github puis créez une pull request pour mettre à disposition le code de ce correctif.
Une fois que le pull request est ouvert, celui-ci est automatiquement attaché, au bug trouvé dans le titre du PR.
Prochainement, une fois que cet attachement aura reçu le drapeau r+ par un validateur, vous pourez ajouter le mot-clé autoland, dans le champ mots-clés "keywords" de bugzilla pour intégrer le code dans la branche master de Gaia. Autolander intègrera donc le code au master, mettra votre commit dans le bug, et marquera le bug comme résolu et corrigé "resolved fixed". Cependant, pour l'instant, cette fonctionnalité est toujours en cours de développement, donc pour le moment, vous devez ajouter le mot-clé "keyword" checkin-needed, et attendre qu'une personne intègre le code pour vous.

A noter : Autolander lance des tests d'intégration avant d'intégrer un correctif au master. Si les tests d'intégration échouent, Autolander refusera d'intégrer le code. D'autres validations basiques sont effectuées, comme s'assurer que votre pull request et votre message de commit contiennent bien un numéro de bug.

A noter : Les pull request sont intégrés par ordre d'arrivé. Les pull request sont fusionnés à une branche d'intégration, et les tests d'intégration sont lancés en parallèle dans cette branche. Si un PR échoue les tests d'intégration, il est rejeté de la branche d'intégration, et nous reconstruisons la branche d'intégration avec les commits restants. Quand un commit passe, le master progresse de ce commit.

Envoi manuel d'un correctif

Pour soumettre manuellement votre correctif à Gaia, suivez ces étapes :

Tout d'abord, si le bug correspondant n'existe pas, créez-en un pour le produit Firefox OS, et donnez-lui un titre explicite détaillant le but de votre correctif.
Vous pouvez alors créer une pull request pour votre correctif. Si vous avez suivi ce guide depuis le début, vos changements devraient être présents dans une branche spécifique, unique, de votre fork en local. Pour ajouter vos modifications, faites git add . puis git commit -m 'mon message de commit'.
'mon message de commit' devra être modifié par une phrase contenant le titre du bug, ainsi que des informations supplémentaire sur ce que fait le correctif et qui doit l'examiner. Par exemple :
```
Corrige ce bug Toto R=jeanbiche
```
Il est vraiment préférable d'indiquer un numéro de bug dans le message du commit, mais ne pas le faire est le seul moyen de contourner Autolander. Inutile de vous dire que ce n'est pas recommandé, vous devriez vraiment utiliser Autolander.
Poussez votre code sur le fork de Gaia présent sur Github puis créez une pull request pour mettre à disposition le code de ce correctif.
Ajoutez l'URL de cette pull request comme pièce jointe du bug sur Bugzilla (utilisez le lien « Add an attachment link », choisissez le mode texte pour la pièce jointe puis saisissez l'URL de la pull request comme contenu de la pièce jointe, vous pouvez ensuite saisir une description)
Pour cette pièce jointe sur la fiche Bugzilla, demandez à ce que votre correctif soit passé en revue. Pour le faire, ajoutez l'étiquette (flag) review: ? à la pièce jointe en incluant le nom du responsable du module concerné par votre code (voir la page des responsables de module pour plus d'informations (en anglais).)
Attendez qu'une personne soit affectée pour passer en revue votre correctif. À cette étape, généralement, cette personne demandera d'ajouter ou non des modifications à la pull request (PR) sur Github et de lier ces changements sur Bugzilla.
Effectuez les modifications demandées sur la même PR que précédemment puis reliez une pièce jointe avec le flag review: ?.
Une fois que vous avez effectué les modifications demandées et que vous avez obtenu le flag r+ (qui signifie que le correctif a été revu/approuvé), vous devriez aplatir (squash) vos commits en un seul (voir le paragraphe Tips_on_Gaia_Rebasing ci-après).
Ajoutez un mot-clé checkin-needed dans le champ adéquat (keywords). Pour cette étape, vous devez désormais attendre que quelqu'un intègre (land en anglais) votre correctif au code source de Gaia.
Félicitations, votre code fait maintenant partie de Gaia et vous avez contribué à Firefox OS !

Note : Il est recommandé de n'avoir qu'un seul commit par revue.

Note : Pour plus d'informations sur la soumission de correctifs, lire le fichier contributing.md sur le dépôt principal.

Conseils pour refonder son code de Gaia

La branche master de Gaia évolue constamment (plusieurs fois par jour). Si vous avez passé deux heures à construire un correctif, il se peut que la branche ait été modifiée.

Sur votre branche liée à votre correctif (ex : mon-correctif), vous pourrez refonder (rebase en anglais et pour git) grâce aux commandes suivantes :

git checkout -b mon-correctif-r1
git pull --rebase upstream master

S'il n'y a pas de conflits, vous pouvez continuer avec :

git checkout mon-correctif
git pull --rebase upstream master
git branch -D mon-correctif-r1

Si vous avez des conflits, discutez-en avec le développeur qui a apporté les changements conflictuels puis répétez cette procédure une fois les conflits résolus.

Bugs de statut et bugs techniques

Certaines personnes chez Mozilla sont des sheriffs. Les sheriffs sont responsables de la fusion du code et de la maintenance des statuts des branches. Étant donné qu'il y a un nombre limité de sheriffs pour surveiller les échecs des tests sur Firefox OS, il est relativement difficile pour eux de détecter tous les correctifs défectueux.

C'est pourquoi, pour Firefox OS, nous préférons ouvrir un nouveau bug pour livrer de nouveaux correctifs sur un problème s'il y a des échecs lorsqu'un correctif est passé en revue. Cela entraîne quelques complications pour le suivi des statuts pour les équipes qualité et gestion de projet.

Pour cela, les bugs sont séparés entre bugs de statut et bugs techniques :

Les bugs de suivi de statut sont identifiés par le mot-clé "meta". Un bug de statut peut être réouvert s'il ne remplit pas les critères d'acceptation ou s'il a échoué au cours des étapes de reproduction.
Un bug technique ne devrait être réouvert que s'il échoue lors des tests automatisés ou que le correctif ne fonctionne pas entièrement. Si un correctif corrige partiellement le bug technique, vous devriez clôner le bug et utiliser le champ « see also » pour pointer vers le bug initial et décrire l'endroit où le premier correctif échoue.

Note : Si ce bug correspond à un scénario d'utilisation (user story en anglais), le chef de projet en charge devrait compléter le champ correspondant (user story) ainsi que les critères d'acceptation.

Réparer la situation si vous avez intégré un correctif sur un bug de suivi de statut

Si vous avez accidentellement livré un correctif sur un bug de suivi, qui ait été revu et intégré au code commun, voici ce que vous devez faire :

Utilisez le bouton « Clone this bug » situé en bas à droite de Bugzilla pour créer un nouveau bug et reproduire la plupart des champs du bug initial. Vérifiez ques les champs whiteboard, keyword, et STR/user story ont bien été copiés-collés dans le nouveau bug.
Mettez ce nouveau bug comme étant bloqué par l'ancien. Ce nouveau bug sera le nouveau bug de suivi de statut.
Utilisez le flag « needinfo » pour alerte le chef de projet concerné que le bug de statut à changé. Voici la liste des adresses e-mail des différents chefs de projets pour Firefox OS sur le wiki (en anglais).
Créez un nouveau bug technique décrivant les étapes pour reproduire et/ou les critères d'acceptations. Utilisez ce bug pour bloquer le nouveau bug de suivi de statut.
Essayez d'apporter un correctif pour ce nouveau bug. Bidouillez-bien :) !!!

Livrer des correctifs sur d'anciennes branches

Sur les bugs, vous pouvez voir les étiquettes concernant les différents versions. Si vous souhaitez soumettre un correctif pour une ancienne version de Firefox OS, vous devez vérifier que celui-ci respecte les règles d'acceptation expliquées sur la page d'intégration à B2G (en anglais).