Freeze des PR sur beta-0.2 ?

Repassage sur la branche dev

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

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 ?

Édité par Talus

"Meh." Outil de diff PHP : Totem

+1 -0
Staff

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.

Auteur du sujet

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.

"Meh." Outil de diff PHP : Totem

+0 -0
Staff

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.

Staff

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 !

Auteur du sujet

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.

firm1

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)

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

Talus

"Meh." Outil de diff PHP : Totem

+0 -0
Staff

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.

Édité par victor

Je parle de JavaScript et d'autres trucs sur mon blog : https://draft.li/blog

+1 -0
Staff

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.

Auteur du sujet

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.

Alex-D

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.

"Meh." Outil de diff PHP : Totem

+0 -0
Staff

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 ?

Staff

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.

Édité par nohar

I was a llama before it was cool

+2 -0
Auteur du sujet

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 ?

"Meh." Outil de diff PHP : Totem

+0 -0
Auteur du sujet

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)

"Meh." Outil de diff PHP : Totem

+1 -0
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