Statuons sur le process des vieilles PRs en attentes sur GitHub

a marqué ce sujet comme résolu.

Mais du coup, est-ce que ça dérange quelqu'un qu'une PR trop vieille traine dans la zone de PR ?

firm1

Non, c'est pas dramatique en soi. Mon sujet est motivé par plusieurs raisons :

  • Régulièrement, il y a des plaintes sur la lenteur des merges des PRs, sur le manque de QA et/ou le nombre de PRs en cours (ne me demandez pas qui, où, comment, je ne note pas ces informations).
  • A partir d'un moment, il faut bien les résoudre les PRs. Parti comme ça, certaines PRs pourraient rester des années. Ce n'est pas plus souhaitable de perdre du travail parce que la PR est devenue obsolète que de la fermer avant et d'activer tout un processus pour ne pas perdre la PR (créer une issue si elle n'existait pas, sauvegarder la branche du contributeur, demander aux autres contributeurs de la continuer, etc.).
  • Pour des gens intéressés par faire de la QA (globalement moi pour l'instant), j'aimerais faire de la QA sur les vieux trucs pour pouvoir (enfin) les merger mais (parfois) je n'ai aucun moyen de connaître l'état de la PR pour savoir si je dois encore la tester, s'il faut améliorer la PR avant, si les QAs précédentes sont devenues obsolètes, etc.

Toutes ces petites choses me font penser qu'il faut un process d'action pour les vieilles PRs afin de limiter le "bruit" dans la liste des PRs.

Je dis ça parce que vu que la PR de gasche n'est liée a aucune issue, si on la ferme sans que personne ne la prenne on peut être sure qu'elle sera oubliée.

firm1

Normalement, c'est censé jamais arrivé une PR sans issue.

+1 -0

Normalement, c'est censé jamais arrivé une PR sans issue.

C'est toléré pour les corrections bidon (typiquement les corrections de coquilles typographiques). Mais je crois que la PR de Gasche date d'avant ce process.

Mais c'est clair qu'elle mériterait une ou plusieurs issues associées.

+0 -0

Régulièrement, il y a des plaintes sur la lenteur des merges des PRs, sur le manque de QA et/ou le nombre de PRs en cours (ne me demandez pas qui, où, comment, je ne note pas ces informations).

Andr0

Ce problème est réel et on en a déjà parlé lors du précédent Zest'Meeting. Une PR ne peut être QA que lorsqu'elle n'est pas en conflit avec la branche de merge. Sinon il faudra repasser une QA dessus après gestion des conflits ça fera donc double travail. Le fait est que entre le moment ou la PR est soumise et que la QA passe dessus, le temps passe, et si par malheur pendant ce temps une autre PR est mergée, ta PR est a revoir, car potentiellement en conflit. Le temps que l'auteur de la PR gère les conflits, et que la QA passe vraiment dessus, le temps continu de passer, et au final la PR en question reste en attente de QA pendant très longtemps.

ça a souvent été le cas de mes PRs puisque je fais souvent des PRs de types features. Mais du coup j'avoue que j'ai perdu beaucoup de motivation à faire des PRs sur ZdS à cause de ça. Mais ça reste un détail puisque mes PRs n'était (et ne sont) pas urgentes non plus.

A partir d'un moment, il faut bien les résoudre les PRs. Parti comme ça, certaines PRs pourraient rester des années. Ce n'est pas plus souhaitable de perdre du travail parce que la PR est devenue obsolète que de la fermer avant et d'activer tout un processus pour ne pas perdre la PR (créer une issue si elle n'existait pas, sauvegarder la branche du contributeur, demander aux autres contributeurs de la continuer, etc.).

Andr0

Ma question est bien là, pourquoi fermer une PRs alors que le problème qu'elle était censée réglé n'est pas corrigé ?

Pour des gens intéressés par faire de la QA (globalement moi pour l'instant), j'aimerais faire de la QA sur les vieux trucs pour pouvoir (enfin) les merger mais (parfois) je n'ai aucun moyen de connaître l'état de la PR pour savoir si je dois encore la tester, s'il faut améliorer la PR avant, si les QAs précédentes sont devenues obsolètes, etc.

Andr0

Pour moi c'était le rôle du Tag "validation" d'indiquer les PRs a QA.

+0 -0

Dans ce message, une "PR en attente" désigne une PR en attente depuis longtemps avec peu d'activité depuis plusieurs semaines, voire mois. Cf. les issues linkées dans le premier message de ce sujet.

Ma question est bien là, pourquoi fermer une PRs alors que le problème qu'elle était censée réglé n'est pas corrigé ?

  • Pour les PRs bug fix : une PR non mergée est souvent liée à des corrections à apporter et donc ne corrige aucun bug, voire elle en rajoute.

  • Pour les PRs feature : une PR non mergée peut avoir plusieurs raisons : la fonctionnalité n'est pas désirée, la communauté (les développeurs si ça ne passe pas par une ZEP) demande des modifications, etc. Donc une PR en attente est souvent soit pas désirée soit pas aboutie. Dans les deux cas, si le contributeur est casual et que personne ne veut continuer, c'est pas grand chose de perdue. Sinon, le contributeur est régulier et il pourra toujours refaire une PR plus tard s'il désire vraiment implémenter la fonctionnalité. Cf. le process que j'ai proposé pour les PRs en attente pour les contributeurs actifs.

Après, d'accord. Si c'est le fait de clore une PR et perdre en visibilité (puisqu'elle ne sera consultable que via l'issue associée, mais n'est-pas ce que nous voulons ?), nous pouvons toujours jouer sur les tags et donner la possibilité aux QA de filtrer sur les PRs "chaudes". Mais nous utilisons GitHub comme gestion des tickets. Ca se fait difficilement et manuellement.

Pour moi c'était le rôle du Tag "validation" d'indiquer les PRs a QA.

Je n'avais jamais compris ce tag, ne le trouve pas explicite et ne sais pas s'il est à jour dans les PRs.

+0 -0

Pour moi c'était le rôle du Tag "validation" d'indiquer les PRs a QA.

Je suis DTC et pourtant je ne sais pas ce qu'est ce tag exactement (j'en ai déjà parlé sur la discussion associée).

Les PR à QA, c'est toutes les PR par définition, sauf dans le cas où c'est explicitement dit le contraire (PR de POC etc.).

+0 -0

Donc une PR en attente est souvent soit pas désirée soit pas aboutie.

Andr0

Pas forcément. Dans mon cas par exemple, ce n'est ni l'un ni l'autre. Ce qu'on m'a dit c'est : pour QA mes PRs il fallait réserver un peu plus de temps. Donc forcément quand tu arrive dans la pile tu choisi les PRs facile a QA en priorité. Ce qui n'aide pas les autres PRs à passer (puisque les autres se prennent tout de suite des conflits)

+0 -0

Bien, prenons comme exemple tes 3 PRs citées. J'arrive sur chacune de tes PRs et je veux faire leurs QAs. Voici ce que je me suis dis et ce que je me dis toujours après cette discussion.

#1424

Il y a une discussion énorme parce que tout le monde ne voit pas les choses de la même façon (rentre déjà dans la catégorie PR non aboutie). Si je m'arrête au premier message de la PR, je n'ai aucune information pour la QA. Je prends donc mon courage à deux mains et je lis la discussion (ça me prend déjà un temps considérable). A la fin de l'issue, la discussion est au point mort. Je ne sais pas si c'est utile de faire une QA.

#1446

Si je m'arrête au premier message, je peux voir une indication pour la QA (l'indication est légère mais elle est présente). Après, je regarde un peu plus la PR et je vois qu'une autre personne fait déjà la QA. A ce niveau là, je n'avais pas été plus loin. Je m'étais dis : "Ok, quelqu'un d'autre est sur le coup". Maintenant, je lis un peu plus et ma conclusion est la suivante : "Ok, la PR semble ok pour une QA mais je me rends compte que c'est infiniment plus complexe que ta faible indication pour la QA dans le premier message de ta PR".

#1506

Le premier message semble bon. Tu expliques ce que fait ta PR, les issues donnent des indications supplémentaires et tu donnes des informations pour la QA. Mais je vois que d'autres contributeurs mentionnent des erreurs à tout va et tu n'es intervenu à aucun moment. Ta PR rendre donc dans la catégorie non aboutie.

+0 -0

1424

Il y a une discussion énorme parce que tout le monde ne voit pas les choses de la même façon (rentre déjà dans la catégorie PR non aboutie). Si je m'arrête au premier message de la PR, je n'ai aucune information pour la QA.

Andr0

Et pourtant c'est la PR avec la note de QA la plus longue de tout le projet :(

Après pour l'aspect "non aboutie" (quoique ce terme veut tout et rien dire) on peut toujours discuter de la possibilité de faire une ZEP pour chaque nouvelle fonctionnalité, mais au vu du nombre de ZEP aboutis aujourd'hui j'ai un léger doute sur l'efficacité aujourd'hui.

+0 -0

Et pourtant c'est la PR avec la note de QA la plus longue de tout le projet :(

C'est ma faute. J'ai du lire 2-3 fois le premier message et je suis passé à côté … Cela n'enlève rien sur ma conclusion de cette issue et des 3 autres.

Après pour l'aspect "non aboutie" (quoique ce terme veut tout et rien dire) on peut toujours discuter de la possibilité de faire une ZEP pour chaque nouvelle fonctionnalité, mais au vu du nombre de ZEP aboutis aujourd'hui j'ai un léger doute sur l'efficacité aujourd'hui.

Je suis tout à fait d'accord et, malheureusement, je n'ai pas de solution pour ça.

+0 -0
Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

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