Modèle de branches

a marqué ce sujet comme résolu.

Reprise du dernier message de la page précédente

Ce que j'aime bien, c'est que :

  • on est sur trois branches ;
  • l'idée c'est d'en changer parce que c'est pas maintenable ;
  • à chaque fois que je parle de deux branches seulement, je me prends des -1 sans explication.

Donc, quel est l'avis de ces gens qui ne s'expriment visiblement pas ? Ou plus généralement : quelle est la conclusion de ce débat ? Très sincèrement, je n'y comprends plus rien.

Auteur du sujet

Parce que ça fait des pages qu'on dit que 2 branches ça pose d'autres problèmes et que tu n'as pas apporté de nouvel argument en faveur de ton modèle ?

Personnellement ça fait 10 jours que j'ai proposé ceci, avec tous les détails pour gérer à la fois la situation courante et la situation future. Sauf que visiblement tout le monde est en vacances et/ou préfère le statu quo.

En temps normal, notre DI prend la responsabilité de trancher quand le débat n'avance plus parce que tout le monde reste sur ses positions.

J'ai cru comprendre que nous avions un second DI maintenant … ;)

+0 -0
Auteur du sujet

Là c'est différent : il n'y a pas de débat, c'est bien mon problème. Surtout vu le bazar que ça a été la dernière fois qu'on a décidé d'un truc qui ne faisait pas consensus.

Alors, si vous voulez, on peut la jouer comme ça :

  • Vous avez quelques jours pour vous exprimer (disons, la fin du WE).
  • Si personne n'a réagi avec de vraies contre-propositions d'ici là, le mode de fonctionnement que j'ai proposé est accepté.
  • À partir de là, c'est trop tard pour râler ou faire de petites piques : soit vous proposez un autre modèle complet qui résout clairement tous les problèmes que vous remontez, soit votre avis n'a aucun intérêt et donc sera ignoré.

Je trouve quand même dommage d'en arriver là, surtout sur un sujet qui semblait déchainer les passions à ce point.

Même si j'ai délibéremment choisi de ne plus m'impliquer dans le dev, je fais parti de ceux qui étaient d'accord avec le workflow de SF.

En gros, Alex, faut comprendre que ce que SF propose, c'est en gros un modèle à 2 branches… et demies. Actuellement, c'est un modèle à 3 branches, qui est fumeux, car une branche est délaissée. Avec le workflow de SF, on a en gros 2 branches (prod, dev), et une "demie" branche dans le sens où elle est éphémère… Et c'est ce que je proposais avant.

Je trouve que c'est un bon compromis.

Quantiquement votre. Extension de tests d’API via Behat (PHP) : Behapi

+1 -0

Idem. J'ai l'impression que ce débat tourne en rond depuis deux semaines parce que personne ne prend la peine de comprendre ce que proposent les autres pour déclarer "je suis d'accord avec ça".

I was a llama before it was cool

+1 -0

Merci à SpaceFox d'avoir pris le temps de rédiger ça, j'étais passé à coté de son message.

Bon, je m'en vais donner mon avis sur le workflow défini ici ainsi que le complément donné .

Version pré-v1.0

On ne merge rien sur dev tant que la v1.0 n'est pas stabilisée

SpaceFox

On a pas encore atteint la v1.0, et on annonce clairement qu'on ne merge rien dans dev, moi j'appelle ça un freeze, et donc pourquoi laisser la branche dev vivante. Je pense qu'il faut tout simplement tuer la dev maintenant et la recréer lorsqu'on aura atteint la v1.0 et qu'on ne sera donc plus en freeze.

Versions > v1.0

On peut se permettre d'utiliser une workflow de MEP à base de releases et de QA en préprod

SpaceFox

Pré-réquis à ça : Avoir une préprod fonctionnelle et iso prod. Et donc pour moi c'est une tâche (issue ?) manquante quelque part qui devrait être dans les issues de release de la V1.0

  1. Ces PR sont d'une taille raisonnable autant que possible (mieux vaut plusieurs PR compréhensibles qu'une PR géante)

SpaeFox

Ce point me semble flou, il faut un truc assez clair. Qu'appelle t-on PR géante ? plus de 10 commit ? plus de 5 fichiers modifiés ? delta (ligne ajoutées - lignes supprimée) > 100 ? Étant donné que ça me semble assez subjectif, il faudrait clairement expliciter ce point.

  1. Ces PR sont mergées dans dev (develop dans le standard), après une QA légère

SpaceFox

define: "QA Legere"

Eskimon

On vérifie que le truc fonctionne et qu'il n'y a pas d'énorme connerie dans le code, mais sans forcément re-tester tout le processus et tous les cas pathologiques à chaque fois.

SpaceFox

A expliciter encore mieux. Car il me semble qu'aujourd'hui les tests joue le rôle de QA légère. Et j'aurai tendance à dire, quitte à faire de la QA légère autant se concentrer sur l'écriture de test. Pour moi donc, faire de la QA légère signifierai juste valider que le développeur à écrit un test qui couvre la fonctionnalité qu'il a codé et que travis ne gueule pas.

4.3. Si on en a les ressources, les correctifs de la branche de release sont remontés sur dev. Sinon, tant pis.

SpaceFox

On ne peut pas tantpiriser ici. Pour moi, ne pas remonter une correction vers la dev, c'est la porte d'entrée aux conflits le jour du merge. On se retrouve avec des cas batards, ou tout ceux qui essayent de bosser à partir de la branche dev, doivent se manger les bugs qui sont pourtant fixés dans la branche de release, mais qui ne sont pas remontés.

Voila en gros, mes légères remarques sur le sujet.

+0 -0
Auteur du sujet

Je pense qu'il faut tout simplement tuer la dev maintenant et la recréer lorsqu'on aura atteint la v1.0 et qu'on ne sera donc plus en freeze.

A ma connaissance on ne peut pas, parce qu'on a des développements qui ont été faits sur cette dev.

Qu'appelle t-on PR géante ? plus de 10 commit ? plus de 5 fichiers modifiés ? delta (ligne ajoutées - lignes supprimée) > 100 ? Étant donné que ça me semble assez subjectif, il faudrait clairement expliciter ce point.

On ne peut pas mettre de métriques ici, c'est à voir au cas par cas. Les PR problématiques, c'est celles qui touchent plusieurs tickets qui ne sont pas forcément liés, celles qui touchent à plusieurs morceaux indépendants de l'application.

Pour faire encore plus clair : ce que je ne veux plus voir, c'est une PR qui dit "J'ai fait A, et tant que j'y étais j'ai corrigé le bug B".

A expliciter encore mieux. Car il me semble qu'aujourd'hui les tests joue le rôle de QA légère. Et j'aurai tendance à dire, quitte à faire de la QA légère autant se concentrer sur l'écriture de test. Pour moi donc, faire de la QA légère signifierai juste valider que le développeur à écrit un test qui couvre la fonctionnalité qu'il a codé et que travis ne gueule pas.

Pour tous les cas où un test est faisable, ça me paraît bien, et ça nous oblige à faire des tests (ce qu'on ne fait pas aujourd'hui).

Pour les cas non testables automatiquement, il s'agit de vérifier que ce qui a été développé fonctionne. Pour les effets de bord et autres, c'est l'objet de la vraie QA sur la préprod.

On ne peut pas tantpiriser ici. Pour moi, ne pas remonter une correction vers la dev, c'est la porte d'entrée aux conflits le jour du merge. On se retrouve avec des cas batards, ou tout ceux qui essayent de bosser à partir de la branche dev, doivent se manger les bugs qui sont pourtant fixés dans la branche de release, mais qui ne sont pas remontés.

En fait, si. Toute l'astuce qui permet le fonctionnement de ma proposition est là.

Aujourd'hui, notre problème c'est qu'on ne peut pas faire remonter les corrections au fur et à mesure parce que c'est un boulot de dingue.

Le principe ici c'est qu'on part d'une branche de dev à peu près stable et que le processus de release est court.

Donc oui, les gens qui bossent sur dev se prennent les bugs qui sont fixés sur la release. Tant pis. Pourquoi "tant pis" et surtout pourquoi ce n'est pas gênant ?

  1. Parce que comme la branche de dev reste normalement à peu près stable (grâce à la QA légère avant d'introduire une fonctionnalité) les bugs "fixés sur la release" ne devraient pas être critiques (on a les hotfix pour les bugs critiques qui ont réussi à aller en prod).
  2. Parce que dans le pire des cas la correction sera remontée sous deux semaines, ce qui est la durée de vie maximale de la branche de release. Si elle dure trop longtemps parce qu'elle n'était pas prête et trop bugguée, il suffit de l'annuler en remontant toutes les corrections faites vers le dev, et de ne jamais la mettre en prod.

Ok dac. En fait, globalement, tout le monde est d'accord, mais personne ne voit la chose sous le même angle. Enfin pour moi c'est feu vert si c'est bien "deux branches et demi", et qu'en gros, actuellement, la branche dev dégage, et qu'on dev sur master en étant freeze (ou pas, mais en insistant très très très fortement sur les bugfix en priorité).

A noter que j'avais mis à niveau master et dev entre eux il y a 15 jours (ou un truc comme ça) et ça a été relativement rapide et simple. Donc actuellement ce qu'il faudrait faire c'est merge l'une des branche dans l'autre et virer celle qu'on veut : peu importe laquelle, le but étant d'avoir une branche prod et une branche de développement, qui dans l'état actuel des choses n'est dédié qu'à la stabilisation vers une v1.

Le principe ici c'est qu'on part d'une branche de dev à peu près stable et que le processus de release est court.

Donc oui, les gens qui bossent sur dev se prennent les bugs qui sont fixés sur la release. Tant pis. Pourquoi "tant pis" et surtout pourquoi ce n'est pas gênant ? […]

J'insiste là dessus, mais la tanpirisation ici ne peut pas faire partie d'un workflow de travail. Si on considère la branche dev, comme branche de travail, il faut qu'elle soit maintenue à jour au même titre que la branche de release. Pourquoi ?

  1. Parce que celui qui développe sur la branche de dev en cours, risque d'avoir de grosses surprises le jour ou il poussera son code, s'il ne se merge pas lui même tout le temps avec la branches de release.
  2. Parce que si je développe une fonctionnalité sur une branche instable (vu que la branche release ne m'est pas remontée) et que celle si est mergée sur la dev avant le merge de la release vers la dev, c'est la porte ouverte aux conflits. Et je précise bien qu'un conflit entre deux branches indépendantes, est la porte ouverte aux bugs "fonctionnels".
  3. Parce que, soyons honnêtes, pour que cette tanpirisation marche, il faudrait partir du principe que dès le lancement d'une release, tout le monde arrête de bosser sur la dev, et stabilise la master.

En considérant le point 3, j'ai du mal à voir l’intérêt de s'embêter à se créer des branches de release si c'est pour ne plus maintenir la dev. Il suffit de garder une branche dev et une branche prod, et de tant à autres, dire à tout le monde "On rentre en phase de release … donc freeze des features jusqu'à la MEP". Au moins ça aura le mérite d'être clair, parce que c'est ça la traduction du tant pis.

+0 -1
Auteur du sujet

Je rappelle à tout hasard que les branches de release permettent de corriger les bugs détectés pendant le test en préprod et qui nécessitent une correction immédiate. Ces bugs devraient donc être rares.

Exemples :

  • Pendant le tests de la release, on détecte un problème jamais détecté avant. Il est corrigé sur dev1 et ne fait pas partie de la release.
  • Pendant le tests de la release, on détecte un problème sur un élément qui ne fait pas partie de la release (module non impacté par les commits qu'on release). Il est corrigé sur dev et ne fait pas partie de la release.
  • Pendant le tests de la release, on détecte qu'une correction qu'on essaie de releaser ne fonctionne pas exactement comme prévu. Dans ce cas seulement, on corrige sur la branche de release.

Donc, pour que les problèmes que tu décris arrivent, il faut :

  1. Que quelqu'un merge une fonctionnalité/une correction de bug standard dans dev au moment où on a une release en prépartion
  2. et qu'on ait un bug dans cette release
  3. et que ce bug soit lié à la release (cf ci-dessus) ce qui nous oblige à le corriger pour publier
  4. et que la correction de ce bug impacte les mêmes fichiers que la fonctionnalité mergée

Dans ce cas, on a un risque de merge non trivial.

Personnellement, je pense que ce risque est tout à fait acceptable, et qu'on peut se contenter de suivre le Git Flow tel que décrit (qui, je le rappelle, n'impose pas de remonter les correctifs de la branche de release au fur et à mesure).

Il n'y a donc pas à s'inquiéter outre mesure de merges vicieux ou de geler la branche de dev pendant une release. On peut par contre imaginer de geler les devs si on détecte un problème vicieux dans la release (au cas par cas donc, et en relation avec les PR en cours).

Je n'ai aucun problème à me baser sur un workflow qui est connu pour fonctionner ; surtout face à des problématiques qui sont pour l'instant théorique et qui ont un risque faible d'arriver.


  1. Sauf s'il s'agit d'un bug critique, qui lui suit le workflow hotfix quoi qu'il arrive. 

Édité par SpaceFox

[…] Dans ce cas, on a un risque de merge non trivial.

SpaceFox

Ces cas, ne sont clairement pas triviaux. Je peux en faire une liste si tu veux.


  • X developpe une fonctionnalité d'upload d'image automatique en Ajax sur la branche dev
  • pendant ce temps en release, on se rend compte qu'on a un bug dans le nommage des galleries.
  • le bug est fixé en release et pas remonté en dev.
  • pendant ce temps X continue de développer par dessus le bug, avec 80% de chance de livrer une PR foireuse.

  • X developpe une fonctionnalité d'ajout du filtre par tag
  • Manque de bol, pendant la release on se rend compte que les autres on un problème, ils ne s'affichent pas pour les invités.
  • Le bug est fixé et n'est pas remonté en dev
  • Monsieur X à encore 80% de livrer une PR foireuse.

  • Monsieur X développe un système de navigation au clavier
  • Pendant la release on se rend compte qu'il y'a un bug du au nommage d'une classe css.
  • Le bug est fixé (changement du nom de la classe) et n'est pas remonté dans dev
  • Monsieur X a donc toutes les chances de se retrouver encore avec une PR foireuse.

Des cas qui vous semble peut-être triviaux, mais qui sont très clairement évidents. On ne les a pas encore rencontrés parce que depuis on est toujours en freeze (officiel, ouis officieux) et on s'interdit les merges dans la dev, mais dès qu'on passe en open-features, je ne vois pas comment ça peut marcher.

Après si vous considérez que le risque est acceptables, pourquoi pas, mais j'ai comme l'impression que ça fera comme la fois précédente,

  • on propose un workflow
  • tout le monde dit oui,
  • deux semaines plus tard dans la pratique on se dit, "Ah mais non, la branche tel ne sert à rien" ou encore "c'est le bordayle dans les branches on sait plus ou faire la PR", etc.
  • on perd du temps

M'enfin, j'aurais tout de même exprimé mon avis que le principe selon lequel on oblige pas la remontée des bugfix des release vers la dev, est une mauvaise pratique.

Édité par firm1

+0 -0
Auteur du sujet

Pour commencer, tes 3 cas tombent directement dans le cas que je décris à la fin : si on s'aperçoit qu'il y a un problème sur un point particulier, on ne merge pas les PR qui pourraient rentrer en conflit.

D'autre part, il faudrait vraiment un concours de circonstance extraordinaire pour que les cas que tu décris arrivent. Parce que si l'un des problèmes que tu décris est détecté pendant la release et qu'ils ne sont pas dus à une nouveautés de cette release, il ne seront pas corrigé sur la branche de release mais sur dev !

Donc pour qu'on ait des merges problématiques, en appliquant la règle du gel du merge si on détecte un problème lors des tests en préprod, il faut que toutes les conditions suivantes soient réunies :

  1. La release en cours et une PR proposée pendant la release impactent une même fonctionnalité (plus exactement les mêmes fichiers)
  2. La release a un problème sur les fichiers en question
  3. Le problème est dû aux modifications embarquées dans la release et donc doit être corrigée
  4. On a déjà mergé la PR (sinon, il suffit de la faire attendre et repartir de la nouvelle version)
  5. Le merge obtenu n'est pas trivial

M'enfin, j'aurais tout de même exprimé mon avis que le principe selon lequel on oblige pas la remontée des bugfix des release vers la dev, est une mauvaise pratique.

Je passe sur le fait que ça se discute (le Git Flow, qui encadre beaucoup de choses, ne le mentionne pas comme tel).

Mon vrai problème, c'est que c'est exactement ce qui nous a foutu dedans jusqu'ici : on a pas eu les ressources nécessaires pour le faire.

De plus, le modèle proposé fait que les corrections de release devraient être exceptionnelles.

Le modèle qui a échoué jusqu'ici l'a été parce qu'il n'a jamais été convenablement réfléchit. On ne s'était jamais posé la question de la volumétrie des commits à remonter sur la branche de dev. On s'est retrouvé avec des bugs corrigés séparément des deux côtés parce qu'il y a eu des mauvaises communications.

Le modèle que je propose échoue et devient merdique si on est mauvais et qu'on se retrouve avec des dizaines de corrections à faire sur la branche de release.

Du coup, la question du freeze ou non pendant la release se résume à une question : est-qu'on est capable de faire du boulot propre ?

PS : Si je résume donc nos positions respectives :

  • Tu sembles partir du principe qu'on va faire de la merde et donc qu'on va se retrouver avec des conflits
  • Je pars du principe qu'on peut faire un minimum confiance aux gens et tester un workflow pas trop chiant. Quitte à passer au tien s'il s'avère que j'avais tort.

Édité par SpaceFox

Si on s'inscrit dans la vision qu'on a tous souhaité pour ZdS dès le début, à savoir, un modèle de développement assez ouvert et simple pour que n'importe qui puisse y contribuer quelque soit ses compétences, on est obligé de considérer dans notre workflow l'arrivée de nouveaux contributeurs qui nous apportent le meilleur (comme toi par exemple) ou encore le pire.

+0 -0
Auteur du sujet

Bon, j'ai bien réfléchi, alors voilà :

  1. On tente ce que je propose - je met à jour la doc à ce sujet.
  2. Je prends le risque d'avoir des conflits ; si jamais un jour on se retrouve avec des merges pourris :
    1. Je me charge personnellement de les résoudre
    2. On passe au workflow de firm1 (le même mais en freezant pendant la release)
    3. Je paie une bière à firm1 (ou un fromage, un truc quoi)

Bien sûr, ça ne vaut que si le workflow est respecté.

Ne pas lire, je garde juste pour mémoire et je repost demain plus clair, plus propre

Je ne comprends pas pourquoi vous voyez prennez autant la tete et pourquoi ca semble aussi compliqué alors que vous avez un workflow tres courant (dans le sens: plusieurs versions, jamais plus de 2 versions en meme temps, toujours une version en feature freeze etc…)

Partant de la il me semble naturel que le "gitflow" doive refléter cette organisation, ce qui implique donc une branche par version (par numero de version) soit jamais plus de 2 branches actives (a la limite 3 pendant un temps limité). Ensuite il n'y a pas vraiment de version de dev/prod meme si l'une des branch des correspond effectivement a la prod.

Ensuite chaque PR est base sur la branche correspond ant au numero de version le plus faible a laquelle elle se rapporte (ex: il y a la version 1.0, deployee en prod, et la 2.0. Monsieur X resout un bug présent en prod => branche 1.0, si c'est une nouvelle feature => 2.0)

Ensuite l'essentiel se passe lors du merge : la personne qui vas merger dans la branche correspondante vas ensuite propager le patch sur les autres version en y mergeant la branche de la version.

Exemple: Monsieur Y merge une PR dans la branche 1.0 (git checkout 1.0 && git fetch upstream && git reset –hard upstream/1.0 && git merge –no-ff bug-fix/12345) vas ensuite merger la branche 1.0 dans la 2.0 (git checkout 2.0 && git reset –hard upstream/2.0 && git merge –no-ff 1.0) puis vas enfin tout push sur github (git push upstream 1.0 2.0)

(Bien évidement, comme d'habitude, il verifie que ca marche)

Enfin reste la question du changement de release : on deploie la 2.0 en prod, on cree la branche 3.0 et on clos la 2.0.

il se pose aussi la question d'un bug fix a deployer d'urgence en prod mais sans deployer toute la nouvelle version : on merge directement en prod en plus de ce qui est decrit ci-dessus)

Sachant au passage, que bien évidemment les PRs avec des merge conflicts ne sont pas acceptés (ou alors il doit être vraiment facile à résoudre) et que si jamais le merge de la 1.0 dans la 2.0 est beaucoup trop compliqué pour une PR précise (exemple: fix d'un bug présent en prod sur un système qui a été entièrement remanié en 2.0) on demande à l'auteur du patch de fournir 2 pull request : une sur la 1.0 (pr-1) et une sur la 2.0 (pr-2), la seconde pull request correspondant au merge de la 1.0 dans la 2.0 et lors du merge on merge pr-1 dans 1.0, pr-2 dans 2.0 et enfin 1.0 dans 2.0.

EDIT: au final les branches sont toujours synchrones entre elles et il n'y a jamais besoins de se taper un énorme merge conflict entre les 2 branches vue qu'on résout un petit merge conflict à chaque fois qu'une PR est merge.
EDIT2: l'utilisation de –no-ff à chaque fois permet de garder un historique propre et compréhensible
EDIT3: pour se simplifier la vie lors du merge de la PR dans la 1.0, il est possible d'utiliser hub (https://github.com/github/hub)
EDIT4: par contre ça implique de ne JAMAIS utiliser le merge bouton de github (ça force donc l'utilisation de la console ou d'un client graphique évolué)
EDIT5: aussi, si jamais une PR ne cadre sur aucune des deux branches (un truc que l'on ne veut ni dans la 1.0 ni dans la 2.0) on peut soit la laisser en attente, soit créer la branche 3.0 plus tôt.
EDIT6: Désolé de poster un nouveau pavé, j'espère que ça aura put vous aider (au passage, bon courage, c'est jamais simple de trouver un workflow simple qui s'adapte bien à la taille du projet et à ses contributeurs tout en étant suffisamment souple).

Édité par Nicofuma

Développeur de phpBB

+1 -0

Bon, tout d'abord désolé pour ceux qui ont essayé, en vain, de lire et de comprendre mes posts précédents… Maintenant je vais tenter de recommencer plus clair, plus court et plus précis :)

Donc tout d'abord j'approuve entièrement le workflow proposé par SpaceFox. C'est un très bon modèle qui a fait ses preuves sur une très grande quantité de projets ayant tous leur spécificité.

Sinon, pour revenir aux conflits entre dev et la branche de release.
Tout d'abord il faut savoir que à moins d'avoir énormément de bugs à corriger ce cas est relativement rare, sinon il y a plusieurs choses qui peuvent être tentés afin de transformer, si possible, le MAY du graph en MUST afin d'éviter au mainteneur (ou à un mainteneur suivant) d'avoir à résoudre le conflit lors de la fusion de la branche de release dans dev :

1
2
3
4
5
6
7
1. l'auteur cré son patch sous dans une branche bug-fix/10 basée sur la branche de release
2. On se rend compte que ça vas créer un conflit important lors de la fusion de la release dans dev
3. On demande à l'auteur du bug-fix si il est en mesure de résoudre le conflit lui même
4. Sinon, on peut eventuellement demander à celui qui a fournis le patch implémentant la ZEP qui est en conflit avec le bug-fix actuel si il est en mesure de résoudre le conflit
5. Sinon, on peut faire un appel à contribution pour demander si quelqu'un est en mesure de résoudre ce conflit
6. Sinon, si on peut attendre qu'un mainteneur à même de régler le conflit soit disponible (SpaceFox par exemple) et c'est donc lui qui ira fusionner le patch (la pull request)
7. Sinon, dans le pire des cas (c'est à dire quand personne ne peut résoudre le conflit et que l'on ne peut pas attendre) le mainteneur fusionne le patch dans la branche de release uniquement et on tombe sur le cas décrit par SpaceFox

Comment se passe la résolution du conflit par un tiers ?

  1. l'auteur cré son patch sous dans une branche bug-fix/10 basée sur la branche de release
  2. L'auteur, ou un autre contributeur, (on vas appeler cette personne Monsieur X) cré un nouvelle branche basée sur la branche de dev et appelée bug-fix/10-dev
  3. Monsieur X fusionne la branche bug-fix/10 dans sa branche bug-fix/10-dev et résout le conflit à ce moment là
  4. Il soumet sa branch sur github et notifie dans les commentaires du patch bug-fix/10 qu'il a résolu le conflit dans sa branche bug-fix/10-dev
  5. Le mainteneur fusionne bug-fix/10 dans la branche de release
  6. Le mainteneur fusionne bug-fix/10-dev dans la branche dev
  7. Le mainteneur fusionne la branche de release dans la branche dev (à ce moment là il n'y doit y avoir, en principe, strictement aucun conflit)

Donc voilà, c'est une petite astuce qui, assumant que la personne la mieux à même de résoudre les conflits est souvent l'auteur du patch, d'essaye d'éviter autant que possible au mainteneur d'avoir à assumer cette tâche.

J'espère que maintenant c'est plus clair.

P.S Je me permet quand même au passage de redire se que SpaceFox a dit : en pratique c'est un point qui est relativement rare. En réalité ça ne peut vraiment se présenter que dans 2 cas :

  1. La branche de realease a une durée de vie extrèmement longue (plus c'est plus plus ça a de chances d'arriver)
  2. Un patch effectuant des changement vraiment très très lourd a été fusionné dans dev après la création de la branche de release et, avant le changement de release, un bug a été découvert sur la pré-prod.
    Ca peut arriver, mais en pratique, si on sait que la durée de vie de la branche de release est faible il est parfois meilleur d'attendre sa fin de vie pour fusionner les plus gros patchs

EDIT: Finallement c'est pas plus court, désolé… mais par contre ça devrait être beaucoup plus clair.

Édité par Nicofuma

Développeur de phpBB

+2 -0
Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte