DevCamp presentation: PR to merge or not to merge: Difference between revisions

*attention : on remplace ici un "continue" (donc du code après qui n'était jamais exécuté) par du code qui sera systématiquement exécuté. Hors, la PR est sensé corrigé un défaut qui se manifest dans une certaines condition. On devrait donc s'attendre à un changement de code qui conditionne le nouveau comportement sur quelquechose. Comme ce n'est pas le cas, cela doit soulever des questions auprès du mergeur qui doit dans ce cas remonter son interrogation plutôt que valider. La PR semblant corriger un bug en en ajoutant un autre. Ceci peut se faire via des échanges avec l'auteur, en allant jusqu'à réussir à reproduire le problème lui même pour réorienter l'auteur sur la bonne solution si nécessaire.

*finalement ici, il s'agissait d'un problème de « checkbox » qui n’est pas coché qui se comporte comme si il n'y avait pas de checkbox du tout (fonctionnement de base des chackbox en HTML)

**il fallait mettre une condition en mettant un champ caché sur le formulaire avec une valeur fixe par exemple pour permettre au code serveur de faire la distinction entre checkox non coché (on modifie la base avec la valeur non), ou pas du tout de checkbox soumis dans le formulaire (on ne fait rien).

=> ceci est un cas de bug qui avait déjà été corrigé en introduisant un autre bug (bug yoyo qui corrige la cas A en cassant le cas B puis corrige le cas B en cassant le cas A...) et il fallait le corriger différemment depuis le champ "checkbox" du formulaire ainsi :