implémentation des ZEPs ?

L'auteur de ce sujet a trouvé une solution à son problème.
Auteur du sujet

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.

Doctorant et assistant en chimie à l'Université de NamurEx-dev' pour ZdS (a aidé à réaliser la ZEP-12 !) • Carniste cis (y parait que c'est une injure)

+2 -0
Staff

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.

+2 -0
Staff

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.

Staff

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.

+0 -0
Auteur du sujet

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,

[…] 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.

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.

Doctorant et assistant en chimie à l'Université de NamurEx-dev' pour ZdS (a aidé à réaliser la ZEP-12 !) • Carniste cis (y parait que c'est une injure)

+0 -0

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 ?

ZdS, le best du Zeste ! Tuto Arduino, blog, etc

+0 -0
Staff

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.

+0 -0
Auteur du sujet

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.

Doctorant et assistant en chimie à l'Université de NamurEx-dev' pour ZdS (a aidé à réaliser la ZEP-12 !) • Carniste cis (y parait que c'est une injure)

+0 -0

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.

+0 -0
Staff

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 ?

Kje

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 …

Vous devez être connecté pour pouvoir poster un message.
Connexion

Pas encore inscrit ?

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