RFR: 1079: Support ability to defer and delegate timing of an integration
kcr at openjdk.java.net
Fri Sep 17 23:11:20 UTC 2021
On Fri, 17 Sep 2021 22:00:04 GMT, Erik Joelsson <erikj at openjdk.org> wrote:
> Here is my first stab at implementing a way for a PR author to defer integration to another committer. The usecase for this is if the timing of the integration is important, but the author may not be available to issue the /integrate command at the desired time.
> Here is how it works: There are two new arguments to the /integrate command "defer" and "undefer". If the author of a PR issues "/integrate defer", the PR enters the deferred state (which is marked by the label "deferred"). This enables any committer to issue "/integrate" to actually perform the integration. When a PR is integrated by someone other than the author, then that person gets attributed in the Git committer field, just like when a change is sponsored. The author can revert this ability at any time before integration happens by issuing "/integrate undefer".
> This is similar to how sponsoring a change works, but not quite the same. When setting up for being sponsored, the /integrate command will run all the checks and record the specific hash that the author wishes to commit. I skipped this kind of rigorous book keeping here as I think it is more likely to get in the way in the desired usecase. The whole point is that timing is important and the author is not available, so better to leave things more open in my opinion.
> I'm open to informed suggestions on how this could potentially be improved on a conceptual level.
> When writing the test, I based it on the simpleMerge test already present. It took some work to properly understand what was happening in that test, and to make it clearer (at least to me), I have renamed and reorganized things a little bit. In these tests, the HostedRepository instances ("author", "integrator", "reviewer" etc) represent users and are used to create PR test instances (or views) which the test can use to interact with the PR as different users. To make this clearer, I introduced the botUser explicitly as that is also a user that sometimes issues commands and interacts with a PR, and used that for things that the bot is doing. I also changed some other users around so that they perform the role for which they are named (reviewer reviews, not the integrator).
> When composing the messages that the bot will print back in comments, I noticed that "PR" and "pull request" were used interchangeably. I decided to standardize on "pull request".
I'll do a review of the implementation when I can. Conceptually, this seems like a good approach to me.
I wonder if there would be a benefit in having the ability to defer to a specific Committer (or maybe list of Committers)? As you say, one of the use cases might be when a specific timing is needed. Another case might be a coordination with another developer so that both yours and their PR go in at roughly the same time. In both of those cases, it seems more likely that I would want a specific delegate to be able to integrate on my behalf. I don't know if this additional flexibility is worth the complexity.
More information about the skara-dev