Freeze des PR sur beta-0.2 ?

Hello,

Maintenant que la beta 2 est officiellement finie depuis quelques jours, il faudrait maintenant songer à repasser la branche "dev" comme étant la branche principale du dépot zds-site.

Le truc étant, c'est qu'on a 5 PR en attente. Du coup, ce que je pensais proposer, c'était donc un freeze des PR jusqu'a ce que le contenu de beta-0.2 soit mergé dans dev, et que la branche principale soit de nouveau la dev.

Si y'a vraiment besoin d'une PR en particulier, il faudra alors la diriger sur dev plutôt que beta-0.2 ; évidemment, elle ne serait pas mergée tout de suite…

edit : Que pensez-vous d'utiliser la propal de victor pour le nommage des branches ? A savoir une branche "master" pour le edge dev, et une branche "prod" pour ce qui est sur la prod. Eventuellement une autre branche "pre-prod" si on a besoin de mettre un truc en pre-prod ?

L'idée, c'était de finir ces PR, de n'en accepter aucune autre qui ne soit pas bloquante pour la sortie.

Avant la sortie, une fois qu'on a plus du tout de PR, on merge le dev actuels sur dev (qui redevient la branche principale) et sur master (puisqu'on met en prod).

J'en aurais bien profité pour renommer nos branches selon le git flow standard, pour éviter les surprises.

Je pense pas que continuer le développement sur beta-0.2 soit très pertinent, plutôt que de le faire sur le dev justement (et ce dès que possible). Ca n'a plus de sens de garder la branche beta-0.2.

Limite il faudrait carrément refuser les PR actuelles et demander à les repointer sur dev. Il ne devrait pas y avoir trop de changement (juste un changement de cible en fait), vu que dev se retrouvera alors à jour vis à vis de beta-0.2

D'ailleurs, à propos de gitflow, je suis pas non plus très sûr de la pertinence d'une branche de beta, plutôt que de développer sur dev justement. Quitte à avoir une branche beta de coté, qui fonctionne un peu comme master… Mais du coup, autant utiliser master.

Bref, vraiment adopter le gitflow au final.

Je ne vois pas pourquoi on devrait freezer quelque chose.

On peut déjà faire le merge maintenant de beta vers dev, passer dev en branche principale et editer toutes les PR actuellement qui pointent vers beta doivent être éditées pour pointer vers devs.

après repointage, on vire la branche beta et voila.

Limite il faudrait carrément refuser les PR actuelles et demander à les repointer sur dev.

En théorie oui.

En pratique, on a déjà suffisamment de retard pour éviter de jouer avec les PR. Donc on va rester comme ça.

Bref, vraiment adopter le gitflow au final.

100% d'accord !

C'est ce que je propose justement ici (on ne peut éditer la cible d'une PR : il faut la fermer, et la rouvrir vers la bonne branche)

Je suggère plutôt qu'on développe sur la branche master, branche principale, et qu'on ait une branche prod. Au moins il n'y a pas d'ambiguité, pas de mauvaise surprise possible.

Le staging tree principal c'est justement master généralement. Je vois plus facilement quelqu'un pusher par erreur sur master que pusher par erreur sur prod.

+1 pour victor.

Par contre Talus, perso je suis pour que les merges soient faits avant de rebasculer sur une quelconque autre branche. Je n'ai pas très envie de relancer mes PR alors qu'elles n'attendent que de la QA globalement.

PS : les +1/-1 qui boguent, ça vient du patch CSRF en cours, ça sera donc corrigé bientôt

Est-ce que ça change vraiment quelques chose de cloturer les PR actuelles et de les réouvrir sur une autre cible ? ça prend environ 15 secondes montre en main et ça évite de géler les PR . Une PR, c'est juste une demande de Pull d'une branche vers une autre, ça ne change donc pas grand chose.

C'est ce que firm1 & moi se tuons à te dire : ca change rien, suffit juste de fermer la PR et d'en refaire une nouvelle (même branche… destination "dev", "master", peu importe du moment que ce soit la branche principale). Ca se fait en 10 secondes, chrono en main. T'as rien à faire en git…

En gros, +1 firm1.

Juste si il y a eu des discussions vous allez les perdre…

Si on recrée la PR en linkant la précédente fermée, on garde l'historique non ?

Vus les discussions qui vont être perdues, et la latence qu'il y a en ce moment pour faire quelque chose qui prend 10 secondes, les PR en cours ne seront pas touchées.

D'autre part, vu l'état général de notre arbre, le retard actuel et le temps que j'ai perdu ces derniers jours "pour faire plus propre t'inquiètes ça va prendre 10 secondes", je suis désolé mais "pour faire propre" n'est pas un argument pour faire quelque chose.

De toutes façons il n'en reste plus que 3 : une facile à tester, une délicate et une (la #1019) qui ne sera pas mergée avant la MEP quoiqu'il arrive et donc qui devra être refaite.

En résumé

1. On n'accepte plus les PR tant que les PR #1017 et #1025 sont toujours là
2. Les PR actuelles ne sont pas modifiées (pas recréées sur une autre branche)
3. Dès qu'on a plus de PR, on merge la branche bêta dans des branches normales et on revient à un modèle de branche normal

Le "normal" restant à définir : pur git-flow ou git-flow amélioré pour éviter les push malencontreux dans master ?

Je viens d'éditer mon premier message pour proposer un vote sur la nomenclature des branches. Comme dit dans cet édit, je suis +1 pour la proposition de victor.

J'aime bien la proposition de victor, perso (et c'est comme ça que j'ai l'habitude de bosser).

Par contre, il faut relativiser : entre les deux propositions c'est presque uniquement une question de nommage des branches. Tant qu'une décision est prise et que le workflow est bien déterminé/documenté, dans la pratique ça ne changera pas non plus la face du monde.

PS : Oh, j'oubliais le plus important. +1 pour le plan de bataille proposé par SpaceFox.

Et voilà.

Il faut utiliser master pour le développement, et prod pour la prod.

Talus, si tu pouvais changer la branche principale pour master et faire sauter la branche beta-0.2 ce serait génial, je n'ai pas les droits pour. Merci !

Voilà, j'ai changé la branche principale du coup.

J'en ai profité pour virer la branche beta-0.2 ; dois-je virer la branche de dev aussi, vu qu'elle fait doublon avec master ?

faudrait a mon sens virer les branches dev, api et tests-charges qui n'ont plus rien a faire là.

J'ai mis la branche master sur la preprod pour le coup

En tout cas, vous avez les droits pour manipuler les branches comme vous voulez. Du coup, si y'en a qui ont besoin d'être supprimées, etc… Je vous laisse le faire (spécialement pour "vos" branches, telles que test-charge de SpaceFox, ou api d'andro)

Je regarde ça ce soir.

En effet on a le droit de jouer avec les branches, seul manquait le droit de gérer la branche principale.