implémentation des ZEPs ?

Hello,

Je me pose une question depuis l'implémentation du comportement de la désinscription et encore plus avec la mise en application de la ZEP-03 par Eskimon : est ce que le Zestflow assure bien l'existence d'une branche dédiée pour une feature de taille importante, ou pas ? Autrement posé, à quel point suis-t-on le git flow ? J'ai beau lire la documentation qui a récement été mise à jour par les bons soins de Spacefox, je ne trouve pas ma réponse.

Pourquoi créer une branche dédiée est une bonne idée ? Parce qu'au contraire d'une branche "locale" chez un dev donné, les PR apparaissent directement dans la liste des PR du dépot et on donc une meilleure visibilité pour les remarques/améliorations/QA. Le mauvais coté, étant évidement qu'à la fin, y'a forcément une étape chiante de gestion des conflits qui est associée.

Ça ne posera à mon avis pas de problème pour la ZEP-03, mais risque d'arriver pour des ZEP plus importantes (je pense par exemple à la 04, la 08 et la 12), donc je préfère poser la question avant.

Heu.. selon le git-flow, oui il faut une branche pour ça (les "feature branche"). On ne peut pas se permettre de poster directement dans dev, si c'est ce que tu propose pour éviter les conflits car on va se retrouver avec un état instable ou le code sera inutilisable tant qu'elle ne sera pas finit, avec le risque que pour une raison X ou Y ça prenne des mois ou n'arrive jamais.

Donc pour moi la question ne se pose pas. Ça doit se faire dans une branche dédié pour isoler le dev et que les autres continue a travailler dessus.

Pour les gros dev, tels que les zep, on peut par contre réfléchir à faire des lock informels. C'est à dire convenir de limiter le dev dans tel ou tel module parce qu'une zep le concernant est en court de dev. Dans un tel cas, on limiterai les dev dans ces modules aux hot-fix important pour éviter les conflits.

Reste a savoir comment organiser ça et comment rendre ça bien visible.

Pour les gros dev, tels que les zep, on peut par contre réfléchir à faire des lock informels.

Je suis particulièrement contre tout ce qui relève de l'informel (et encore plus les locks de module).

Pour moi, une ZEP reste une fonctionnalité à développer comme une autre, ce n'est pas parce qu'une fonctionnalité est en cours de développement que l'on devrait locker les modules. C'est au(x) développeur(s) de ladite fonctionnalité de s'assurer que leur branche reste toujours mergeable avec la dev (qui est la branche réceptrice de la feature).

Donc oui, je pense que créer une branche sur le dépôt principal pour les ZEP est une bonne idée, et il faut que la branche soit maintenue à jour au fil des autres merge dans la dev. Après il va y avoir forcément les conflits fonctionnels mais il parait que ce sont des cas super rares, et donc au pire j'aurai une Guinness.

Du coup ma branche pour la ZEP 3 aurait du etre faite dans le depot principal et non mon depot (ce que j'avais suspecte). Tant pis, au point ou en est le dev ce sera pas dramatique pour cette fois la je suppose (disons que c'etait le temps de lancer la machine)

Du coup ma branche pour la ZEP 3 aurait du etre faite dans le depot principal et non mon depot (ce que j'avais suspecte). Tant pis, au point ou en est le dev ce sera pas dramatique pour cette fois la je suppose (disons que c'etait le temps de lancer la machine)

Je ne vois pas ce que ça change en fait.

La fameuse guiness.

Ok, donc du coup, je pense qu'il faut rajouter deux lignes là dessus dans une doc à un endroit, parce que ça n'y apparaît pas.

Du reste, je suis également contre le lock de module pour les raisons que firm1 a évoqué, mais aussi et plus simplement pour les tiennes, Kje,

… Les hotfix éventuels doivent passer d'une manière ou d'une autre. J'espère, touchons du bois, qu'avec l'arrivée de la 1.0, le code est plus ou moins stable et que de tels hotfix seront des cas exceptionnels, mais dans tout les cas, ils doivent passer. À l'inverse, l'intégration de fonctionnalité est plus discutable, mais c'est au cas par cas.

@Eskimon: comme j'ai dit, ta ZEP est pas fondamentalement énorme, donc pour moi continue comme ça, mais je cherche surtout a éviter le cas de la désinscripton qui a mis plusieurs semaines à sortir entre autre pour cette raison.

Je ne vois pas ce que ça change en fait.

Si j’héberge la branche, alors je suis le seul maître a bord pour merger les PR dedans pour ensuite répercuter les changements dans une PR vers dev. Si la branche appartient au dépôt, le contrôle des PR est alors fait par tout les contributeurs.

D'ailleurs il pourrait être bon d'ajouter un label "Feature" ou "ZEP" pour repérer dans la liste les PR concernant les zep et celle concernant le dev normal non ?

Si j’héberge la branche, alors je suis le seul maître a bord pour merger les PR dedans pour ensuite répercuter les changements dans une PR vers dev. Si la branche appartient au dépôt, le contrôle des PR est alors fait par tout les contributeurs.

Oui enfin j'imagine que cette zep, si tu l'a prise en charge, tu en gère le dev. Si quelqu'un voulait t'aider et qu'elle était sur le dépot principal, on t'aurait demandé a toi de valider le merge. Du coup qu'elle soit physiquement sur le dépot principal ou sur un perso ne change rien.

De façon plus général, le dev d'une grosse fonctionnalité comme une ZEP, SI ELLE NE PEUT PAS ETRE FAITE EN PETIT MORCEAUX (qui reste l'idéal, faire évoluer le code au fur et à mesure), devrait avoir un responsable pour en gérer le développement.

De façon plus général, le dev d'une grosse fonctionnalité comme une ZEP, SI ELLE NE PEUT PAS ETRE FAITE EN PETIT MORCEAUX (qui reste l'idéal, faire évoluer le code au fur et à mesure), devrait avoir un responsable pour en gérer le développement.

Pour des zep comme la 08 ou la 12, ça reviendrait à d'énorme régressions que de fragmenter le dev', le but étant de réécrire une bonne partie du code, donc là, je ne pense pas que ça soit une bonne idée. Ceci dit, j'approuve l'idée du "chef de projet", ça peut toujours être utile, mais même malgré ça, je resterai sur le dépot principal pour les gros machins.

Petite question sur l'implémentation des ZEP.

La ZEP-12 est crée, elle commence à recevoir des PRs, je veux faire une passe de Code Review sur l'existant, comment je fais ?

Ma question est toujours d'actualité. Il faut trouver une solution pour faire des revues de code sur les ZEP.

Quelles sont les difficultés pour faire du code review dans le cadre des ZEP ?

Si une ZEP ne fait pas l'objet d'une PR je ne peux pas la commenter. Or si on fait des PR pour toutes les ZEP, on risque d'être un peu submergé

Je ne connais pas le process actuel des ZEPs en cours d'implémentation mais leurs PRs ne sont pas simplement en attente marqué WIP ? Si oui, une PR par ZEP me semble être une bonne solution pour du code review et pas excessif sachant qu'une ZEP n'est pas implémentée tous les jours.

De toute façon chaque zep doit avoir une branche sur le dépot, non ? Il suffit de faire le diff de cette branche, non ?

Oui, je fais le diff, pas de problème. Mais si je veux y apposer mon commentaire il faut une PR.

Donc au final on considère qu'une ZEP doit faire l'objet d'une PR sur la branche principale dev ? Je n'aime pas beaucoup cette méthode (car ça rajoute du bruit dans les PRs), mais si c'est la seule solution …