Statuons sur le process des vieilles PRs en attentes sur GitHub

Bonjour à tous,

J'ai fais un tour des PRs en attentes sur GitHub et je constate que la plupart des PRs sont, déjà, de vieilles PRs (pouvant dater de plusieurs semaines, voire mois) et sont soit à l'initiative de contributeurs casuals soit trop actifs.

C'est-à-dire que nous pouvons trouver ce genre de PRs #1372 ou #1516 où les contributeurs ne semblent pas vouloir mettre à jour les modifications demandées.

Conséquences :

• La première traine donc sur GitHub depuis le 13 Aout.
• Tout le monde attend que le contributeur revienne … un jour.

Nous pouvons retrouver aussi ce genre de PRs #1424, #1446 ou #1506 par un contributeur très actif mais qui ne maintient pas toutes ses PRs.

Conséquences :

• La première a été ouverte le 3 septembre.
• C'est un contributeur actif donc personne ne veut/peut continuer le travail.
• Les PRs deviennent des discussions interminables et il est impossible de connaitre la situation de la PR (Faut des modifications ? Faut faire de la QA ?)

Alors quoi faire ? Je pense qu'à partir d'un certain moment, nous avons deux solutions :

1. Il faut se rendre à l'évidence et refuser des PRs. Dommage si la PR était intéressante, au pire elle peut devenir une issue pour refaire une PR par un autre contributeur.
2. Un contributeur se l'assigne, le signal sur la PR et fait le nécessaire dans les plus brefs délais sinon on retombe sur le point 1.

Avez-vous un avis sur la question ? Que pensez-vous de ma proposition ?

D'un point de vue technique : est-ce qu'il existe un moyen simple de récupérer le code d'une PR faite depuis un fork ?

Exemple : X a lancé une PR et n'a pas le temps / l'envie / la motivation de la finir. La PR est cependant intéressante et utile et je veux la finir. Sauf que le code est sur le fork de X.

Est-ce que je peux récupérer ce code et MAJ la PR ? Ou éventuellement en refaire une en réutilisant le code en question ? Quid des éventuels problèmes de droits ?

D'un point de vue technique : est-ce qu'il existe un moyen simple de récupérer le code d'une PR faite depuis un fork ?

yep :

1
2
3
4
5
6
7

git remote add nomdumembre https://github.com/nomdumembre/zds-site.git
git fetch nomdumembre
git checkout -b reprise_de_la_pr nomdumembre/nom_de_la_pr
[...]#on code
git commit -am "j'ai codé"
git push origin reprise_de_la_pr
#et puis enfin une PR

Reprendre le code d'une PR (la branche du contributeur), c'est le quotidien de la QA. Tu peux même récupérer une PR, apporter des modifications, rebaser la PR et repusher. Tout est possible, simple et déjà largement utilisé au sein du projet.

Reprendre le code d'une PR (la branche du contributeur), c'est le quotidien de la QA. Tu peux même récupérer une PR, apporter des modifications, rebaser la PR et repusher. Tout est possible, simple et déjà largement utilisé au sein du projet.

OK, donc tu reprends les commits et tu les repousses depuis chez toi, donc ça marche.

Comme je n'ai jamais vu faire ça (les seules interventions que j'ai vu passer sur des PR par un tiers, c'est des PR sur la PR) j'étais pas certain que ça se fasse.

Est-ce que ça repousse dans la même PR ou est-ce que ça oblige à en créer une nouvelle ?

Ca dépend, tu peux :

• Faire une PR sur le dépôt du contributeur vers sa PR qui, une fois acceptée par le contributeur, mettra automatiquement à jour la PR originale.
• Reprendre la PR du contributeur (et donc ses commits) dans une branche que tu modifies et que tu pushs directement sur le dépôt pour faire une nouvelle PR.

Si le contributeur semble inactif, la solution 2 semble preferable.

Si le contributeur est actif mais n'a pas le temps en ce moment, la solution 1 semble plus judicieuse (le contrib' original peut garder un oeil et reprendre le travail ensuite plus facilement s'il veut continuer)

Rappel : une liste de commandes Git n'est pas une explication. Utilisez des termes fonctionnels !

git te permet de te brancher à tout un tas de dépôt distant. Un fork ce n'est qu'un dépôt distant.

Une fois le dépôt distant branché, tu peux afficher le code d'une branche de ce dépôt voir même créer une branche locale à partir de ce dépôt.

L'avantage, c'est que tu pars de l'historique distant et donc que non seulement tu as les modifications apportées mais que le nom de l'auteur est conservé !

Une fois cela fait, tu n'as plus qu'à pousser ta modif dans ton propre dépôt et à créer ta pull request

Donc si je pige bien, le 1er cas n'est pas applicable ici (le problème étant justement que le responsable de la PR ne réagit pas).

Donc on pourrait reprendre les PR qui nous intéressent à condition de recréer des PR. J'ai bon ?

L'avantage, c'est que tu pars de l'historique distant et donc que non seulement tu as les modifications apportées mais que le nom de l'auteur est conservé !

Ça c'est cool parce que ça évite le vol de travail.

@SpaceFox : Pas vraiment d'accord. Là, je rejoins complètement Eskimon.

Si le contributeur actif n'a plus le temps, quand est-ce qu'il aura le temps de merger le truc ?

J'ai peur qu'avec la solution 1 on se contente de rester coincés.

Il peut toujours y avoir reprise par un autre développeur. Nous pouvons imaginer le scénario suivant :

Après un temps X, rappel au contributeur actif s'il compte continuer la PR (venant d'un contributeur actif, partons de l'hypothèse qu'il répondra).

1. Oui, il compte continuer et très prochainement. On remet les compteurs à zéro et on attends à nouveau le temps X.
2. Oui, il compte continuer mais il ne sait pas trop quand. On refuse la PR et il en refera une nouvelle PR.
3. Non, il ne compte pas continuer. Nous signalons que cette PR est en attente d'un nouveau contributeur. Si après un temps Y, personne ne veut reprendre cette PR, on refuse la PR et c'est dommage.

Je vais tenter ça sur les PR actuellement en attente. On verra ce que ça donne.

Pouvons-nous imaginer un nouveau tag pour les PRs en attente d'un nouveau contributeur ? Ca augmentera leurs visibilités.

Vu que certaines de mes PRs sont concernées par ce sujet, je donne mon avis.

Déjà je ne vois aucune raison de refuser une PR, car ça veut dire qu'on perd l'historique des conversations dessus.

Pour le cas des PRs en attentes, si quelqu'un veut la reprendre (en fait on ne reprend pas une PR, mais l'issue qui lui est associée) il peut très bien forker la branche à l'origine de la PR, et proposer les modifications sur la branche de l'auteur de la PR. L'auteur de la PR n'a plus qu'a accepter les modif et ils viendront directement dans la PR concernée.

Recréer une autre PR fait perdre le fil de la discussion qui a eu lieu sur la PR.

Déjà je ne vois aucune raison de refuser une PR, car ça veut dire qu'on perd l'historique des conversations dessus.

J'y avais pensé aussi et c'est embêtant oui. Mais que proposes-tu alors ? Garder de plus en plus de PRs en stand-by ?

PS 1 : Je te mentionne dans le premier message mais ça aurait pu être quelqu'un d'autre. C'était pour dissocier les contributeurs casuals des actifs (raison pour laquelle je ne mentionne pas ton pseudo dans le premier message).

PS 2 : Je ne vois pas ton avatar. Bizarre.

Déjà je ne vois aucune raison de refuser une PR, car ça veut dire qu'on perd l'historique des conversations dessus.

Nan, ca sera visible dans les PR fermées et pourra toujours etre linke dans une nouvelle PR plus fraiche si on ne peut pas reprendre (car sur un depot d'un contributeur)

PS 2 : Je ne vois pas ton avatar. Bizarre.

Chez moi tout marche

Alors :

L'auteur de la PR n'a plus qu'a accepter les modif et ils viendront directement dans la PR concernée.

Ce n'est valable que si l'auteur d'origine est encore disponible pour faire ce merge. Ce qui ne semble pas le cas sur toutes nos PR en cours.

Dans tous les cas, on ne garde pas des PR mortes juste pour le plaisir. Si besoin, on ferme et on met le lien dans la nouvelle (une PR fermée n'est pas détruite).

PS 2 : Je ne vois pas ton avatar. Bizarre.

Il est sur un site externe bloqué par certains proxys (dont celui de mon entreprise). Firm1, ce serait super si tu le rapatriais en local.

=== END OF HS ===

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

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.

Je fais ça quand je peux

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.

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