Temurin-build: 建议：让PR发起人在可行的情况下合并他们自己的PR

@sxa对此更改ready-to-merge和ping的机器人

@gdams从我口中说出了赞成和机器人建议这两个词。 为此我从+1

同意-对于我们的TZ也是如此。

虽然我了解了动机，但是我不想再吵了（GitHub已经通知我批准了）。 此外，我们需要工具来强制执行此操作。 否则，整个事情将很快崩溃：我如何知道（作为批准人）此人是否可以合并更改？ 我们如何知道哪个存储库具有该规则，而哪个没有？ 通过减少集体所有权，我们实际上不鼓励新的贡献者。 如果我有责任确保一切顺利进行，那么我必须预留时间，也许要等几个小时，直到管道通过。 当然，我不会收到任何通知。

因此，如果某些人想控制自己的PR，就应该拥有它。 创建一个表明作者想要合并的标签，并找到某种方式实施该合并，以便没有人意外合并。

我不想再吵（GitHub已经通知我批准了）

您期望由此产生什么额外的噪音？ 那是与添加标签的机器人有关，还是您在考虑其他事情？

如果我有责任确保一切顺利，那么我必须预留时间，也许还要等待几个小时

我明白了，但我的反点是，这比我尝试调试突然出现问题的时间要好得多，这是我和@ andrew-m-leonard不可避免地要解决的常见问题，这就是为什么我实际上不认为作者应该主动做出决定的原因-我敢肯定，许多作者希望其他人来处理其PR带来的任何后果:-)

此外，我们需要工具来强制执行此操作

从表面上看，这与您关于不希望收到更多通知的评论有些矛盾。 老实说，我个人宁愿不执行它，除非我们不能期望人们对此有所了解-正如我说的那样，可能有必要推翻这样的裁决，而我宁愿不要这样做也需要更多的开销。 标题标题为“让PR发起人”，即我想鼓励审阅者快速浏览内容后不要“默认合并”。

我们如何知道哪个存储库具有该规则，而哪个没有？

我们可以将该信息添加到PR模板中，这应该使它变得清晰-无论哪种方式，我都不认为这是不至少在这里进行试用的原因。 我很好奇您为什么认为这可能会阻止新的贡献者？ 除非存在我不认为的用例，否则您不应该受到影响，或者您是否正在考虑将获得合并特权的新协作者？

我认为，此问题至少部分是为了解决审阅者没有仔细阅读发起人的评论或要求的情况（“请耐心等待xxxx验证...”，“此更改需要-与x和y更改相对应...”，“我特别要求Z审查此更改...”）。 如果审阅者忽略了这些请求，然后继续进行合并，那将不是一件好事。

这也是openjdk-tests回购中的一个问题，在没有足够的了解或测试的情况下，草率地进行了审核和合并。 这对团队来说压力很大。 它提示我们添加第二个审阅者所需的门，以便解决该问题。 在测试存储库的情况下，我通常不希望合并原始发布者，因为我们有许多原始发布者没有写访问权限。 如果我查看了某些内容并希望它们合并（因为我知道它们具有写权限，那么我可以要求它们在准备就绪时合并）。

我不希望有人不了解如何正确测试PR来合并它。 大多数时候，我们都没有参加这个项目。 我们应该冷静地评估每个PR，并在对它们进行充分测试之后，并在对变更有意义的时机上，清醒地决定合并它们（许多可能性，包括但不限于1.合并，因为一切都被破坏了，并且它可以不会变得更糟；或者2.第二天，当有人可以观看构建时，或者3.即将发布的版本之后，以免破坏项目的稳定性）。 我们如何决定这一点确实是我们需要决定的。

如果发起人对PR有特殊要求或评论，则应阅读/理解/尊重这些要求或评论。 我们可以决定默认行为，然后期望发起者和审阅者通过合并计划中的注释与默认行为背道而驰，进行交流。 所有这一切都需要审稿人和发起人都进行关注和交流。 如果每个人都已经这样做了，则可能不需要首先进行讨论。

关于@sxa的评论：

您期望由此产生什么额外的噪音？ 那是与添加标签的机器人有关，还是您在考虑其他事情？

乔治和摩根想要一个能对作者进行ping操作的机器人。

我明白了，但我要指出的是，这比我尝试调试为什么突然出错的时间要好得多。

这是不好的。 但是这里提供的解决方案也很糟糕。 我们已经遇到了贡献者问题，我们现在想使OpenJDK变得更困难，因为它使贡献更加困难（Skara似乎试图撤消其中的一部分）。 您描述的问题是由于openjdk-build的状态糟糕而引起的。 我们将尚未准备好的PR堆在上面。 他们还没有准备好，因为我们使贡献者无法评估其PR的状况是否良好。 我不是新来的人，我很少弄对它。

标题标题为“让PR发起人”，即我想鼓励审阅者快速浏览内容后不要“默认合并”。

不起作用我建议的是一个类似“自我合并”的标签。 如果将其添加到您的PR中，则某些工具将阻止我进行合并。 该公关将等待您。 如果其他人想要合并，则他们首先必须删除该标签。 那会让他们停下来。

我很好奇您为什么认为这可能会阻止新的贡献者？

如果我是某个地方的新人，我希望有人通过我的贡献来照顾我。 打破影响很多人的东西的想法令人恐惧。 因此，默认情况下，将我的PR纳入项目应该是审阅者的工作，因为那时“不是我”。 如果我们可以将该自动合并功能作为选择加入的功能，那就好了。

关于@smlambert的评论：

如果发起人对PR有特殊要求或评论，则应阅读/理解/尊重这些要求或评论。 我们可以决定默认行为，然后期望发起者和审阅者通过合并计划中的注释与默认行为背道而驰，进行交流。 所有这一切都需要审稿人和发起人都进行关注和交流。 如果每个人都已经这样做了，则可能不需要首先进行讨论。

💯但是：这很困难。 我们应该帮助人们做正确的事情，而不必手动检查清单（不好的例子：8u-dev和11u-dev）。 尽管非常嘈杂，但Skara机器人似乎朝着正确的方向发展。

我喜欢实施该工具的工具所支持的自合并标签概念。 我特别喜欢我们正在讨论要作为项目和全球团队进行改进的各种方法。 👍

乔治和摩根想要一个能对作者进行ping操作的机器人。

那已经存在了。 我只是建议使用更有用的信息来扩展它（请ping一个人以运行测试）。 https://github.com/AdoptOpenJDK/ci-jenkins-pipelines/issues/59打算通过使噪声比噪声更有用来做到这一点。 这也可能有助于您提高保姆点

我只是建议使用更有用的信息来扩展它（请ping一个人以运行测试）。

尽管该机器人说了下一步该做什么，但它没有说明谁可以执行这些步骤，也没有说明在哪里可以找到这些信息。 它也不需要进行初始代码审查，而这是本练习的重点（因为我们的计算机具有状态性质，因此我们不想在其上运行未经验证的代码）。

小附注重新： https :

我们是否可以为此目的使用“草稿”，即如果作者想将其合并，则将其标记为草稿，安排评论，并在他们乐意合并时......在某些情况下这是前提我们希望确保已准备好进行合并，因此在此之前，它是草稿...

我们是否可以为此目的使用“草稿”，即如果作者想将其合并，则将其标记为草稿，安排评论，并在他们乐意合并时......在某些情况下这是前提我们希望确保已准备好进行合并，因此在此之前，它是草稿...

我的问题已在原始说明中阐明：“ [草稿]对于可能进行复审的人来说，看起来像“尚未准备复审”。” 我认为草稿（我仍在积极地更改内容）和准备进行审核（寻找反馈，但并不意味着我完全相信合并后会起作用）之间存在重要区别。

（写这篇文章的速度很快，因为我现在应该在开会中-如果无法清楚看到情况，我深表歉意）

但是这里提供的解决方案也很糟糕。
使得贡献更加困难

我认为将其称为“可怕”有点苛刻。 这是为了解决我目前定期看到的问题。

因此，默认情况下，将我的PR纳入项目应该是审阅者的工作，因为那时“不是我”。

鼓励作者贡献自己的力量，并帮助他们解决任何问题，这当然应该是审稿人的工作。在新的（害怕阅读，被打破某些东西的想法吓到）贡献者的情况下，这不会改变任何事情（他们无法合并自己）毕竟），所以我不清楚所关注的是什么。 添加额外的标签（ self-merge或ready-to-merge似乎对我个人来说有点额外的开销，但是如果这是人们想要的，我会同意的。我只是不想在PR发起者在合并后没有任何责任的情况下继续进行（特别是在当前组成员中-如果新贡献者遇到他们提出的问题，我可以-在这种情况下，审阅者应该希望帮助他们调试是否失败-这是学习经验的一部分，并且无论如何都会发生）

如果我是某个地方的新人，我希望有人通过我的贡献来照顾我。

我完全同意，这就是为什么我一直努力争取改进文档的原因，但是通常感觉这是一个孤独的原因-我认为我们在项目中失去了积极的人，而不是在去年增加了他们，而且工作量没有消失下来，要实现这一目标并非易事。 我确实认为这与该提议是分开的，这不应改变这种情况。

我认为将其称为“可怕”有点苛刻。 这是为了解决我目前定期看到的问题。

您没有注意到我额头上的标签上写着“注意强烈的意见”吗？ ：咧嘴笑：

同样，我们正在尝试在此处解决错误的问题。 如果正确地验证了PR，您所看到的那些问题将少得多。 如果bash语法问题使它无法被发现到主分支中并导致构建中断，那么问题就不在于合并什么东西的人，或者不是作者在现场照顾问题。 我后退，因为您的建议是尝试解决此问题而不是解决它。 openjdk-build的状态早已为人所知，但我们仍在努力，因为它尚未受到足够的伤害。 我们有钱给社区经理，而没有钱，但我们没有钱或人来解决我们的核心问题。

我们需要更少的问题，而不是更多。 一旦我们以快速的胜利消除了痛苦，我们就有忘记它甚至存在的趋势。 示例：对于2d9445348c70ec565874fb92f4c09971f71a5d23，通过注释掉macOS的PR测试被禁用。 使用a82104c77a79d707d533415163cf00dac33678d4，我们丢失了被注释掉的部分。 谁还记得我们曾经进行过macOS PR测试，已被禁用并且应该将其带回来？ 甚至没有问题。

TSC应该将重点放在诸如《指环王》中的索伦之眼之类的问题上。

鼓励作者贡献自己的力量，并帮助他们解决任何问题，这当然应该是审稿人的工作。在新的（害怕阅读，被打破某些东西的想法吓到）贡献者的情况下，这不会改变任何事情（他们无法合并自己）毕竟），所以我不清楚所关注的是什么。

一旦PR按下“批准”按钮，我们将训练他们放弃PR，因为这是默认设置。 作为没有特权的新人/新人，您必须找到并追赶代表您合并的人。 那是OpenJDK的经验，我对此并不满意（这不是对OpenJDK的深入了解，因为它们是有原因的）。

您没有注意到我额头上的标签上写着“注意强烈的意见”吗？ 咧嘴笑

错过了，但是最近我还没有和您进行视频通话;-)虽然在macos PR测试仪上有很好的例子...

一旦PR按下“批准”按钮，我们将训练他们放弃PR，因为这是默认设置。 作为没有特权的新人/新人，您必须找到并追赶代表您合并的人。 那是OpenJDK的经验，我对此并不满意（这不是对OpenJDK的深入了解，因为它们是有原因的）。

我希望这个项目不会出现这种情况，如果确实如此，那么我希望我们能够处理。 我仍然愿意亲自冒险。 目前，在这样一个小团队的情况下（这是问题的一部分……对于openjdk来说不是问题），我认为批准者（几乎是@gdams @karianna @ andrew-m-leonard @ M-Davies和我自己是为此仓库执行任务的人）都知道谁有能力合并事物，谁没有能力，所以我希望他们不会将非提交者置于黑暗之中，并且不会有太多的开销。 如果我们能够将团队规模扩大到不再需要此政策，我将感到非常高兴。 我真的认为值得尝试，如果遇到此类问题，我们可以重新访问。 我只是不想“什么也不做”