Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

1079: Support ability to defer and delegate timing of an integration #1221

Closed
wants to merge 3 commits into from

Conversation

erikj79
Copy link
Member

@erikj79 erikj79 commented Sep 17, 2021

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".


Progress

  • Change must not contain extraneous whitespace
  • Change must be properly reviewed

Issue

  • SKARA-1079: Support ability to defer and delegate timing of an integration

Reviewers

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/skara pull/1221/head:pull/1221
$ git checkout pull/1221

Update a local copy of the PR:
$ git checkout pull/1221
$ git pull https://git.openjdk.java.net/skara pull/1221/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 1221

View PR using the GUI difftool:
$ git pr show -t 1221

Using diff file

Download this PR as a diff file:
https://git.openjdk.java.net/skara/pull/1221.diff

@bridgekeeper
Copy link

@bridgekeeper bridgekeeper bot commented Sep 17, 2021

👋 Welcome back erikj! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

@openjdk openjdk bot changed the title SKARA-1079 1079: Support ability to defer and delegate timing of an integration Sep 17, 2021
@openjdk openjdk bot added the rfr label Sep 17, 2021
@mlbridge
Copy link

@mlbridge mlbridge bot commented Sep 17, 2021

Webrevs

@kevinrushforth
Copy link
Member

@kevinrushforth kevinrushforth commented Sep 17, 2021

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.

@erikj79
Copy link
Member Author

@erikj79 erikj79 commented Sep 20, 2021

I was considering maintaining a list of valid integrators, but in the end I felt like it just added complexity to solve a problem I doubt we would ever really have. I do believe we can trust committers within the OpenJDK to not go around and issue /integrate in other people's PRs.

Copy link
Member

@kevinrushforth kevinrushforth left a comment

The fix and test both look good. I added a couple minor comments on the test.

@openjdk
Copy link

@openjdk openjdk bot commented Sep 20, 2021

@erikj79 This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

🔍 One or more changes in this pull request modifies files in areas of the source code that often require two reviewers. Please consider if this is the case for this pull request, and if so, await a second reviewer to approve this pull request before you integrate it.

After integration, the commit message for the final commit will be:

1079: Support ability to defer and delegate timing of an integration

Reviewed-by: kcr, ihse

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 3 new commits pushed to the master branch:

  • 68872aa: 1194: Implement git webrev --no-comments option
  • 91be684: 1191: CommitCommentWorkItem overwhelms scheduler
  • 03e8d58: 1180: Improve logging when WorkItems run for too long

Please see this link for an up-to-date comparison between the source branch of this pull request and the master branch.
As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

@openjdk openjdk bot added the ready label Sep 20, 2021
Copy link
Member

@magicus magicus left a comment

Looks good. I think this fits well with the current model. I agree that we do not need to limit the set of eligible future integrators when deferring.

@erikj79
Copy link
Member Author

@erikj79 erikj79 commented Sep 30, 2021

/integrate

@openjdk
Copy link

@openjdk openjdk bot commented Sep 30, 2021

Going to push as commit 620f889.
Since your change was applied there have been 4 commits pushed to the master branch:

  • acda266: 1197: Label changes from java.nio.** as nio
  • 68872aa: 1194: Implement git webrev --no-comments option
  • 91be684: 1191: CommitCommentWorkItem overwhelms scheduler
  • 03e8d58: 1180: Improve logging when WorkItems run for too long

Your commit was automatically rebased without conflicts.

@openjdk openjdk bot closed this Sep 30, 2021
@openjdk openjdk bot added integrated and removed ready rfr labels Sep 30, 2021
@openjdk
Copy link

@openjdk openjdk bot commented Sep 30, 2021

@erikj79 Pushed as commit 620f889.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
3 participants