Temurin-build: Proposition: laisser les initiateurs de PR fusionner leurs propres PR dans la mesure du possible

@sxa totalement satisfait de ce changement, je suggérerais un bot qui ajoute une étiquette ready-to-merge et envoie un ping à l'auteur

@gdams a

D'accord - cela a également du sens avec nos TZ.

Bien que je comprenne la motivation, je ne veux pas plus de bruit (GitHub me notifie déjà les approbations). De plus, nous avons besoin d'outils pour appliquer cela. Sinon, tout va s'effondrer rapidement: comment savoir (en tant qu'approbateur) si la personne peut fusionner le changement? Comment savoir quel référentiel a cette règle et lequel n'en a pas? En réduisant la propriété collective, nous décourageons en fait les nouveaux contributeurs. Si je suis responsable que tout se passe bien, je dois réserver du temps et peut-être attendre des heures jusqu'à ce que les pipelines soient passés. Bien sûr, je ne reçois pas de notification pour cela.

Donc, si certaines personnes veulent avoir le contrôle de leurs PR, elles devraient l'avoir. Créez une étiquette qui indique que l'auteur souhaite fusionner et trouvez un moyen de l'appliquer afin que personne ne fusionne par accident.

Je ne veux plus de bruit (GitHub me notifie déjà les approbations)

Quel bruit supplémentaire attendez-vous de cela? Est-ce lié au fait d'avoir un bot qui ajoute la balise ou pensez-vous à autre chose?

Si je suis responsable que tout se passe bien, je dois réserver du temps et peut-être attendre des heures

Je comprends cela, mais mon contre-argument est que c'est une bien meilleure option que les heures que j'ai passées à essayer de déboguer pourquoi quelque chose ne va pas, ce qui est un problème fréquent auquel @ andrew-m-leonard finit inévitablement par faire , c'est pourquoi je ne pense pas que l'auteur devrait avoir à prendre activement cette décision - je suis sûr que de nombreux auteurs préféreraient que quelqu'un d'autre s'occupe des retombées de leurs PR :-)

De plus, nous avons besoin d'outils pour appliquer cette

Superficiellement, cela semble légèrement en contradiction avec votre commentaire sur le fait de ne pas vouloir plus de notifications. Honnêtement, je préférerais personnellement ne pas l' appliquer à moins que nous ne puissions nous attendre à ce que les gens soient simplement sensés à ce sujet - comme je l'ai dit, il peut être nécessaire d'annuler une telle décision et je préfère ne pas avoir plus de frais généraux. Le titre de ceci dit "Laisser les créateurs de relations publiques", c'est-à-dire que je veux encourager les critiques à ne pas "fusionner par défaut" une fois qu'ils ont jeté un coup d'œil rapide sur quelque chose.

Comment savoir quel référentiel a cette règle et lequel n'en a pas?

Nous pourrions ajouter ces informations dans le modèle de relations publiques, ce qui devrait être clair - de toute façon, je ne pense pas que ce soit une raison de ne pas au moins l'essayer ici. Je suis curieux de savoir pourquoi vous pensez que cela pourrait décourager de nouveaux contributeurs? Ils ne devraient pas être affectés à moins qu'il n'y ait un cas d'utilisation auquel je ne pense pas, ou pensez-vous à de nouveaux collaborateurs qui obtiendraient les privilèges de fusion?

Je crois que ce problème est au moins en partie une tentative de résoudre le cas où les critiques n'ont pas lu attentivement les commentaires ou les demandes de l'expéditeur ("veuillez attendre que xxxx ait été vérifié ...", "ce changement doit être co -ordonné avec les changements x et y ... "," Je demande spécifiquement à Z de revoir ce changement ... "). Lorsque ces demandes sont ignorées par les réviseurs qui procèdent ensuite à la fusion, ce n'est pas une bonne chose.

Cela a également été un problème dans le dépôt openjdk-tests, où des révisions et des fusions hâtives se sont produites sans suffisamment de compréhension ou de tests. C'est très stressant pour l'équipe. Cela nous a incité à ajouter la deuxième porte requise par le réviseur, afin d'y remédier. Dans le cas du référentiel de tests, je ne veux surtout pas que l'expéditeur fusionne, car nous avons beaucoup d'expéditeurs qui n'ont pas d'accès en écriture. Si j'ai examiné quelque chose et que je veux qu'ils fusionnent (parce que je sais qu'ils ont des autorisations d'écriture, je peux demander qu'ils fusionnent lorsqu'ils sont prêts).

Je ne veux pas que quelqu'un qui ne comprend pas comment tester correctement le PR le fusionne. La plupart du temps, nous ne sommes pas dans une course au projet. Nous devrions évaluer calmement chaque PR et décider sobrement de les fusionner lorsqu'ils sont entièrement testés et selon un timing qui a du sens pour le changement (un certain nombre de possibilités, y compris mais sans s'y limiter 1. fusionner dès que possible car tout est cassé et il peut ne s'aggrave pas, ou 2. le lendemain, quand quelqu'un peut regarder une compilation, ou 3. après une prochaine version, afin de ne pas déstabiliser le projet). La façon dont nous gérons cela est vraiment ce que nous devons décider.

Si l'expéditeur a des demandes spéciales ou des commentaires concernant le PR, ceux-ci doivent être lus / compris / honorés. Nous pouvons décider d'un comportement par défaut, puis nous attendre à ce que l'expéditeur et les réviseurs communiquent via des commentaires sur le plan de fusion s'il diverge du comportement par défaut. Tout cela nécessite à la fois des examinateurs et des concepteurs d'être attentifs et de communiquer. Si tout le monde a déjà fait cela, peut-être pas besoin de cette discussion en premier lieu.

Concernant les commentaires de @sxa :

Quel bruit supplémentaire attendez-vous de cela? Est-ce lié au fait d'avoir un bot qui ajoute la balise ou pensez-vous à autre chose?

George et Morgan veulent un bot qui pète l'auteur.

Je comprends cela, mais mon contre-point est que c'est une bien meilleure option que les heures que j'ai passées à essayer de déboguer pourquoi quelque chose ne va pas.

Ce n'est pas bien. Mais la solution proposée ici est également terrible. Nous avons déjà un problème de contributeur et nous voulons maintenant l'aggraver de la même manière qu'OpenJDK l'a fait en rendant plus difficile la contribution (Skara semble essayer d'en défaire certaines parties). Le problème que vous décrivez est causé par le fait qu'openjdk-build est dans un état déplorable. Et nous empilons dessus des PR qui ne sont pas prêts. Et ils ne sont pas prêts car nous empêchons les contributeurs d'évaluer si leurs PR sont en bonne santé. Je ne suis pas nouveau ici et j'ai rarement raison.

Le titre de ceci dit "Laisser les créateurs de relations publiques", c'est-à-dire que je veux encourager les critiques à ne pas "fusionner par défaut" une fois qu'ils ont jeté un coup d'œil rapide sur quelque chose.

Ça ne marche pas. Ce que je propose, c'est une étiquette comme "auto-fusion". Si vous ajoutez cela à l'un de vos PR, certains outils m'empêcheront de frapper la fusion. Ce PR vous attendra alors. Si quelqu'un d'autre souhaite fusionner, il doit d'abord supprimer cette étiquette. Cela les fera faire une pause.

Je suis curieux de savoir pourquoi vous pensez que cela pourrait décourager de nouveaux contributeurs?

Si je suis nouveau quelque part, je veux que quelqu'un me garde grâce à mes contributions. L'idée de casser quelque chose qui touche un grand nombre de personnes est terrifiante. Donc, par défaut, ce devrait être le travail du réviseur d'intégrer mon PR dans le projet parce qu'alors "Ce n'était pas moi". Si nous pouvons obtenir cette fonction d'auto-fusion en tant que fonctionnalité optionnelle, très bien.

Concernant le commentaire de @smlambert :

Si l'expéditeur a des demandes spéciales ou des commentaires concernant le PR, ceux-ci doivent être lus / compris / honorés. Nous pouvons décider d'un comportement par défaut, puis nous attendre à ce que l'expéditeur et les réviseurs communiquent via des commentaires sur le plan de fusion s'il diverge du comportement par défaut. Tout cela nécessite à la fois des examinateurs et des concepteurs d'être attentifs et de communiquer. Si tout le monde a déjà fait cela, peut-être pas besoin de cette discussion en premier lieu.

💯 Mais: c'est difficile. Nous devrions aider les gens à faire ce qu'il faut sans avoir à parcourir manuellement des listes de contrôle (mauvais exemples: 8u-dev et 11u-dev). Le bot Skara semble aller dans la bonne direction, même s'il est très bruyant.

J'aime l'idée d'étiquette auto-fusionnée soutenue par des outils qui la mettent en œuvre. J'aime particulièrement le fait que nous discutons de diverses façons dont nous voulons nous améliorer en tant que projet et équipe mondiale. 👍

George et Morgan veulent un bot qui pète l'auteur.

Cela existe déjà . Je suggère simplement de l'étendre avec des informations plus utiles que (veuillez envoyer un ping à quelqu'un pour exécuter des tests). https://github.com/AdoptOpenJDK/ci-jenkins-pipelines/issues/59 a l' intention de le faire en rendant le bruit plus utile que le bruit. Cela pourrait également aider avec le point de garde que vous avez soulevé

Je suggère simplement de l'étendre avec des informations plus utiles que (veuillez envoyer un ping à quelqu'un pour exécuter des tests).

Bien que le bot dise ce qui doit être fait ensuite, il n'indique ni qui peut effectuer ces étapes, ni où trouver ces informations. Il ne nécessite pas non plus de révision de code initiale, ce qui est, espérons-le, le but de cet exercice (en raison de la nature avec état de nos machines, nous ne voulons pas exécuter de code non vérifié sur elles).

Petite note latérale concernant: https://github.com/AdoptOpenJDK/ci-jenkins-pipelines/issues/59. Il est peu probable qu'un nouveau venu soit en mesure de proposer lui-même des idées. Ils ont besoin d'un objectif clair et d'un guide étape par étape sur la marche à suivre ("Obtenir des informations de cette API, l'afficher, ..."). En l'état, le ticket est plutôt pour un vétéran 😉

Pouvons-nous utiliser "Brouillon" à cette fin, c'est-à-dire si l'auteur souhaite le fusionner, alors il le marque comme Brouillon, organise les révisions et quand ils sont heureux de fusionner ... comme le principe ici est pour certains cas nous voulons être sûrs qu'il est prêt pour la fusion, donc jusqu'à ce point, il est brouillon ...

Pouvons-nous utiliser "Brouillon" à cette fin, c'est-à-dire si l'auteur souhaite le fusionner, alors il le marque comme Brouillon, organise les révisions et quand ils sont heureux de fusionner ... comme le principe ici est pour certains cas nous voulons être sûrs qu'il est prêt pour la fusion, donc jusqu'à ce point, il est brouillon ...

Mon problème avec cela est comme indiqué dans la description originale: "[brouillon] peut ressembler à" pas prêt à réviser "pour les personnes qui pourraient autrement réviser." Je pense qu'il y a une différence importante entre le brouillon (je suis toujours en train de changer activement les choses) et le prêt à réviser (je recherche des commentaires mais cela ne signifie pas que je suis totalement convaincu que cela fonctionnera une fois fusionné)

(J'écris ceci assez rapidement car je suis censé être en réunion maintenant - excuses si la vue n'est pas claire)

Mais la solution proposée ici est également terrible.
rendant plus difficile la contribution

Je pense que l'appeler «terrible» est un peu dur. Cela vise à résoudre un problème que je vois régulièrement en ce moment.

Donc, par défaut, ce devrait être le travail du réviseur d'intégrer mon PR dans le projet parce qu'alors "Ce n'était pas moi".

Ce devrait certainement être le travail des critiques d'encourager la contribution et de les aider à résoudre les problèmes, et dans le cas de nouveaux contributeurs (Lire effrayés, intimidés par l'idée de casser quelque chose), cela ne changera rien (ils ne peuvent pas fusionner eux-mêmes. après tout) donc je ne sais pas quelle est la préoccupation. L'ajout d'étiquettes supplémentaires (soit self-merge ou ready-to-merge me semble un peu plus compliqué, mais je serais d'accord avec eux si c'est ce que les gens veulent. Je ne veux tout simplement pas. continuer dans une situation où les créateurs de relations publiques n'ont aucune responsabilité après la fusion (en particulier au sein des membres actuels du groupe - je vais bien si un nouveau contributeur rencontre un problème avec quelque chose qu'il a mis - dans ce cas, le critique devrait, espérons-le, aidez-les à déboguer s'il entre et échoue - cela fait partie de l'expérience d'apprentissage et se produira de toute façon)

Si je suis nouveau quelque part, je veux que quelqu'un me garde grâce à mes contributions.

Je suis tout à fait d'accord, c'est pourquoi j'ai essayé de faire pression pour une documentation améliorée, mais cela semble souvent être une cause isolée - je pense que nous avons perdu des personnes actives dans le projet plutôt que de les gagner au cours de la dernière année, et la charge de travail n'a pas disparu. vers le bas, donc ce n'est pas si facile de faire en sorte que cela se produise. Je pense cependant que c'est distinct de cette proposition, qui ne devrait pas changer ce scénario.

Je pense que l'appeler «terrible» est un peu dur. Cela vise à résoudre un problème que je vois régulièrement en ce moment.

Vous n'avez pas remarqué l'étiquette sur mon front qui dit "ATTENTION Les opinions fortes"? :sourire:

Encore une fois, nous essayons de résoudre le mauvais problème ici. Vous verriez ces problèmes beaucoup moins si les PR étaient correctement validés. Si un problème de syntaxe bash peut le rendre non détecté dans la branche principale et provoquer des ruptures de construction, le problème n'est pas la personne qui fusionne quelque chose ou que l'auteur n'est pas là pour garder le problème. Je repousse parce que ce que vous suggérez essaie de contourner le problème au lieu de le résoudre. L'état de openjdk-build est connu depuis longtemps, mais nous sommes en train de lancer la boîte parce que cela n'a pas encore fait assez mal. Nous avons de l'argent pour les gestionnaires de communauté et autres, mais nous n'avons ni argent ni personnel pour régler nos problèmes fondamentaux.

Nous avons besoin de moins de problèmes, pas plus. Dès que l'on supprime la douleur avec une victoire rapide, on a tendance à oublier qu'elle a même existé. Exemple: avec 2d9445348c70ec565874fb92f4c09971f71a5d23, le test PR sur macOS a été désactivé en le commentant. Avec a82104c77a79d707d533415163cf00dac33678d4, nous avons perdu la partie commentée. Qui se souvient maintenant que nous avons effectué des tests macOS PR, qu'il a été désactivé et que nous devrions le ramener? Il n'y a même pas de problème pour cela.

Le TSC devrait se concentrer sur ces problèmes comme l'œil de Sauron dans Le Seigneur des Anneaux.

Ce devrait certainement être le travail des critiques d'encourager la contribution et de les aider à résoudre les problèmes, et dans le cas de nouveaux contributeurs (Lire effrayés, intimidés par l'idée de casser quelque chose), cela ne changera rien (ils ne peuvent pas fusionner eux-mêmes. après tout) donc je ne sais pas quelle est la préoccupation.

Nous allons former les réviseurs à abandonner les PR une fois qu'ils ont appuyé sur ce bouton "Approuver", car c'est la valeur par défaut. En tant que nouveau venu / personne sans privilèges, vous devez alors trouver et chasser quelqu'un pour fusionner en votre nom. C'est l'expérience OpenJDK, et je n'aime pas celle-là (ce n'est pas une fouille vers OpenJDK, les choses sont comme elles le sont pour une raison).

Vous n'avez pas remarqué l'étiquette sur mon front qui dit "ATTENTION Les opinions fortes"? sourire

J'ai manqué cela mais je n'ai pas eu d'appel vidéo avec vous récemment ;-) Bon exemple sur le testeur de relations publiques macos cependant ...

Nous allons former les réviseurs à abandonner les PR une fois qu'ils ont appuyé sur ce bouton "Approuver", car c'est la valeur par défaut. En tant que nouveau venu / personne sans privilèges, vous devez alors trouver et chasser quelqu'un pour fusionner en votre nom. C'est l'expérience OpenJDK, et je n'aime pas celle-là (ce n'est pas une fouille vers OpenJDK, les choses sont comme elles le sont pour une raison).

J'espère que ce ne sera pas le cas pour ce projet et si c'est le cas, j'espère que nous pourrons le gérer. Je suis toujours prêt à prendre le risque personnellement. Pour l'instant, avec une si petite équipe (qui fait partie du problème ... et n'est pas un problème pour openjdk) je pense que les approbateurs (c'est à peu près @gdams @karianna @ andrew-m-leonard @ M-Davies et moi qui les fais pour ce repo) savent tous qui est capable de fusionner des choses et qui ne l'est pas, j'espère donc qu'ils ne laisseront pas les non-committers dans le noir et n'auront pas trop de frais généraux. Je serais ravi si nous pouvions faire évoluer l'équipe au point où cette politique n'était plus nécessaire. Je pense vraiment que cela vaut la peine d'essayer et si nous constatons de tels problèmes, nous pouvons y revenir. Je ne veux juste pas "ne rien faire"