maintenant qu'on ne pousse plus à la sauvage comme des go-go-goret•te•s sur le core et les plugins dist, quel organisation est ce qu'on adopte pour la validation des PR en attente sur le core et les plugins-dist ?
Ça a peut être été discuté / décidé mais je ne retrouve pas.
Est ce qu'on attend un consensus avec quota : que n personnes aient répondu +1 pour valider ?
Est ce qu'on estime qu'une PR peut être validée après x jours sans réponse ? (moyen)
Ou bien un mix : au moins un (ou plus) commentaire avec un +1, et au bout de x jours on considère qu'elle est peut être validée ?
Autre méthode ?
PS : il faut aussi que chacun reçoive les notifications en suivant tous les répos, bien sûr...
maintenant qu'on ne pousse plus à la sauvage comme des go-go-goret•te•s sur le core et les plugins dist, quel organisation est ce qu'on adopte pour la validation des PR en attente sur le core et les plugins-dist ?
Ça a peut être été discuté / décidé mais je ne retrouve pas.
Est ce qu'on attend un consensus avec quota : que n personnes aient répondu +1 pour valider ?
Est ce qu'on estime qu'une PR peut être validée après x jours sans réponse ? (moyen)
Ou bien un mix : au moins un (ou plus) commentaire avec un +1, et au bout de x jours on considère qu'elle est peut être validée ?
Autre méthode ?
Comme je l'ai proposé plusieurs fois, amha il faut qu'on se fixe comme règle :
- PR obligatoire (sauf fix urgent de faille de sécu, et encore...)
- Application par n'importe qui (autre membre de l'équipe ou soi même) à partir du moment ou X autres membres on posté un +1 (cf le ty smiley en haut de la PR, pouce levé = oui, pouce vers le bas = non)
Pour la valeur X du nombre de +1, je propose 2, même si 3 me semble mieux je sais très bien qu'on est pas assez nombreux et réactifs pour ça.
PS : il faut aussi que chacun reçoive les notifications en suivant tous les répos, bien sûr...
Camille signalait qu'il a appliqué une modif pour que tous les membres du core suivent tous les projets de l'orga SPIP, c'est donc bon.
Comme je l'ai proposé plusieurs fois, amha il faut qu'on se fixe comme règle :
- PR obligatoire (sauf fix urgent de faille de sécu, et encore...)
Oui, c'est que je disais aussi, fini le gogogoret ^^
- Application par n'importe qui (autre membre de l'équipe ou soi même) à partir du moment ou X autres membres on posté un +1 (cf le ty smiley en haut de la PR, pouce levé = oui, pouce vers le bas = non)
Pour la valeur X du nombre de +1, je propose 2, même si 3 me semble mieux je sais très bien qu'on est pas assez nombreux et réactifs pour ça.
Pareil.
3 serait mieux, mais bon...
Et si un seul +1 et que ça bouge pas pendant plusieurs jours, relance par un commentaire ou par mail sur la liste ?
Camille signalait qu'il a appliqué une modif pour que tous les membres du core suivent tous les projets de l'orga SPIP, c'est donc bon.
Après cela demande à s'abonner à tous les plugins, et la c'est plus
compliqué
On parle bien du core uniquement hein (SPIP + plugins-dist) :
>>> Camille signalait qu'il a appliqué une modif pour que tous les
>>> membres du core suivent tous les projets de l'orga SPIP, c'est donc bon.
>>
>> Rasta disait que c'était pas le cas, à vérifier ?
2 à 3 validations à base de +1 me semble un nombre raisonnable aussi au
regard du nombre de personnes actives et des disponibilités. J'ai envie
d'ajouter quand même : sous réserve qu'il n'y ait pas discussion non
résolue en cours sur le PR en question, puisque l'idée reste d'acter un
consensus.
Et aussi que lâcher un +1 suppose dans la mesure du possible que le PR a
été testé, c'est pas juste l'équivalent de dire "ah ouais bonne idée".
Voilà sinon moi je reçois bien toutes les notifs pour l'orga spip, mais
je ne sais plus si c'est suite à l'abonnement automatisé en masse ou si
je m'étais abonné manuellement à tous les dépôts. Ce qui ne nous avance
pas sur la question j'en conviens.
Et j'en profite pour faire de la pub sur ce PR qui traine depuis 3 mois,
histoire de savoir si ça peut passer dans la 3.3 ou après ou pas du tout
: https://git.spip.net/spip/porte_plume/pulls/1
Nb : ça peut être déplacé dans une branche de dev de la dist si besoin,
à l'époque c'était pas encore bien calé tout ça.
Je n'ai strictement rien reçu, et comme dit tout à l'heure sur IRC, je n'étais PAS abonné ("suivre") au dépôt principal du noyau (spip/spip), que j'ai ajouté manuellement tout à l'heure, et pas non plus à tous les dist (pas fait du coup).
La modif de Camille à priori c'est pour les *nouveaux* dépôts, quand on en crée un alors tous les gens de l'équipe sont automatiquement ajoutés en suivi dessus. Mais par contre pour tous les dépôts déjà là, ça n'a pas été le cas (et il ne faut pas pour les contribs, mais pour noyau et dist m'est-avis qu'on devrait).
2 à 3 validations à base de +1 me semble un nombre raisonnable aussi au
regard du nombre de personnes actives et des disponibilités. J'ai envie
d'ajouter quand même : sous réserve qu'il n'y ait pas discussion non
résolue en cours sur le PR en question, puisque l'idée reste d'acter un
consensus.
Et aussi que lâcher un +1 suppose dans la mesure du possible que le PR a
été testé, c'est pas juste l'équivalent de dire "ah ouais bonne idée".
On est d'accords. Partons sur 3 +1 ?
Deux suffisent amha, je me répète mais d'expérience j'ai un paquet de patchs qui ont attendu ne serait-ce qu'un seul retour sur redmine, donc je pense qu'on est pas assez nombreux à être réactifs pour espérer 3 retours.
Et pour le mode de fusion, quelle stratégie ?
- Fusionner la demande d'ajout
- Rebase et fusionner
- Rebase et Fusion (--no-ff)
- Squash et fusionner
Je suis plutôt pour fusionner (merge) systématiquement, pour garder une trace du travail fait sur une branche parallèle.
Votre avis ?
Perso je préfère qu'on évite d'avoir des commits de merge dans la branche master, pour le reste, peu importe, ça dépend un peu du contenu de la PR. Si celle-ci est un travail de longue durée il faut garder tous ses commits, si c'est une simple patch avec plus de oups que de commits utiles un squash ne fait pas de mal, etc.
perso je dirais : il faut un commit de fusion. Après rien n'empêche de "nettoyer" la branche avant la fusion (pour reéécrire les oups), même si cela ne me semble pas indispensable.
En tout cas, il me semble plus pertinent d'avoir un commit de fusion qu'uen reprise directe de la branche, surtout si celle-ci contient des essais / erreurs
En fait le mieux serait peut être que l'auteur·e de la PR fasse soi même la fusion, en connaissance du contexte et du travail réalisé (simple correction, ticket ou travail spécifique), une fois que deux +1 ont été ajoutés et qu'il n'y a plus de discussion en cours.
Sous le premier message (celui de tcharlss), tu vois 4 pouces levés, au survol tu as la liste des gens qui les ont ajoutés, et de quoi ajouter une réaction avec le smiley bleu à côté.
Tu as aussi le smiley dans l'entête du message sur fond gris, à droite.
En fait le mieux serait peut être que l'auteur·e de la PR fasse soi même la fusion, en connaissance du contexte et du travail réalisé (simple correction, ticket ou travail spécifique), une fois que deux +1 ont été ajoutés et qu'il n'y a plus de discussion en cours
Sauf bien sûr dans le cas d'un PR fait par un non membre du core
