et aussi un endroit quelque part pour dire « euh, j’ai 11 PRs d’améliorations fonctionnelles de TakePOS en attente de validation sur github depuis le mois de mai, qui commencent à avoir des conflits avec les versions récentes » (https://github.com/Dolibarr/dolibarr/pulls/altairis-tof)
Si on pouvait avoir la possibilité d’ajouter au moins un tag spécifique « Ready to review » (ou un truc similaire) sur les PR concernées cela permettrait de les faire ressortir sur github facilement.
Oui, un label GitHub PR ready to review serait pas mal, c’est sûr.
Après, sur GitHub, il y a désormais le statut Draft (brouillon) pour les PR pas prêtes à être mergées.
Dans les faits, je ne sais pas trop qui review les PR (à part @eldy) mais il faudrait mieux gérer le workflow GitHub (personnes et/ou équipe/groupe assignées (Assignees), personnes/groupes demandées pour la revue de code (Reviewers) sur les PR) car cela permettrait à mon avis de fluidifier les choses.
(je me suis permis d’extraire ces quelques échanges dans un nouveau sujet car c’est distinct de la discussion sur le Dolistore)
Bonjour,
Le fait de poster un PR non en brouillon (Draft comme le précise @jtraulle ) veut dire que c’est un PR à review. Pas besoin de faire un label pour quelque chose de normal.
Le problème est plutôt que si vous n’êtes pas dans les 25 derniers PRs proposés, la probabilité que vous soyez intégré s’affaiblit car @eldy ne parcours que rarement les pages suivantes et ne peut pas tout faire mais ne veut pour autant pas d’aide. Je suis moi même affecté en review pour ce qui concerne la comptabilité pour donner mon avis sur les modifications proposées.
En ce moment, je suis en train de re-poster des morceaux de code validé ou avec un léger correctif, qui était postponed mais oublié pour autant. (j’en suis à la page 9-10).
Il ne faut pas perdre espoir et bien tenir à jour vos PRs.
Bonne journée,
Un des problèmes du statut « draft » sur github, c’est que que on enlève le statut « draft » la PR ne remonte pas en début de liste. Or la mise au point d’une PR peut prendre pas mal de temps, et une fois qu’elle est terminée il est fort probable qu’elle se retrouve perdue en fin de liste des PR.
Donc si seule la première page des PR est régulièrement consultée… (je vous laisse conclure)
le problème des PR « zombies » n’est pas récent, pour ma part je ne comprend pas la logique des PR en brouillon, dans le sens ou l’on ne doit en théorie que transmettre des PR terminée, prete à être intégrée, ou alors on se fait une branche de travail?
1 « J'aime »
Une PR en brouillon peut très bien servir à présenter un projet d’évolution : si il faut par exemple implémenter du code sur une dizaines de classes, un exemple sur une classe suffit pour présenter le projet. Pas besoin de tout coder avant si le projet n’est au final pas accepté.
on a déjà du mal à ce que les PRs « normales » soient prises en compte, alors je n’ose imaginer si elles avaient un statut « brouillon »… Pull requests · Dolibarr/dolibarr · GitHub - ça c’est les miennes mais si on prend les PRs en cours triées par date… oulala novembre 2012 Pull requests · Dolibarr/dolibarr · GitHub
Le mode « brouillon » des PR est explicitement décrit sous le terme « WIP / Draft » dans le guide de contribution à Dolibarr.
If the label of PR start with « Draft » or « WIP » (Work In Progress), it will not be analyzed for merging until you change the label of the PR (but it can be analyzed for discussion).
D’autre part on y trouve aussi ceci
The majority of open PR are waiting an action of the author of the PR
Sauf qu’une fois l’action faite on a aucun moyen de le signaler correctement (un ajout de tag serait l’idéal).
Alors on a déjà du mal à se faire valider des PR qui trainent (genre sur la page 2) et là on va rajouter des PR pas terminer… comment dire???
1 « J'aime »
Petit voyage dans le temps, retour en 2018
1 « J'aime »
C’est normal qu’il n’y ai pas de « moyen » explicite car ceci se fait automatiquement par github. Un liseré bleu sur la gauche de la PR apparait (le répondant ne la voit pas, mais les acteurs de la PR, comme celui ayant fait la demande de complément mais aussi tous les autres ayant agit le voit).
Par contre dès lors qu’une demande d’action on info avait été faite, ces retours font l’objet d’un délai de traitement plus long. Comme on intègre trop de PR évol par rapport au nombre de PR fix, ce sont les PR qui ont été problématique à leur première tentative qui sont souvent le plus pénalisées par la non intégration volontaire de PR d’évols pour prioriser les PR de stabilisation qui arrivent hélas à un rythme plus lent. C’est vrai. Pour résoudre cela, il faut plus de participants aux phases de tests, débugages, aux fix qualitatifs, et aux PR de lutte contre la dette technique (on devrait avoir 2 PR ainsi pour chaque PR d’évol, mais nous sommes plutôt à 1 PR de fix par PR d’évol).
Pour plus d’info sur ce qui peut etre fait pour au dela du taux actuel de 95% de traitement des PR, voir ici:
Bonjour
commencé en Juillet,demande de feedback en aout, jamais aucun review, j’ai fini par cloturer…
Fred
