From erikj at openjdk.org  Fri Sep  1 14:20:08 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 1 Sep 2023 14:20:08 GMT
Subject: RFR: 1997: Allow the creator of a PR to set the commit author
In-Reply-To: <GpY2ep_iBbg14Iv1aSfJTnvU3WnD8G2P47ulYHpOzYc=.30bad807-0b20-4861-b4bc-1ec3e5518429@github.com>
References: <GpY2ep_iBbg14Iv1aSfJTnvU3WnD8G2P47ulYHpOzYc=.30bad807-0b20-4861-b4bc-1ec3e5518429@github.com>
Message-ID: <HZ82SUIigzmqH8j8TbZs5FaW3MyN14Skv0rT-cE932Y=.9eae6abe-861d-497b-83a9-5a7d709dbac9@github.com>

On Thu, 31 Aug 2023 22:42:46 GMT, Zhao Song <zsong at openjdk.org> wrote:

> In this pr, we will introduce a new pull request command `/author`.
> 
> If an author wants to contribute a change to a repository, but he doesn't have access, then someone with the access will be able to help him with this command.
> 
> Usage: `/author [set|remove] [@user | openjdk-user | Full Name <email at address>]`
> Examples: 
> `/author set @openjdk-bot`
> `/author @openjdk-bot`
> `/author set J. Duke <duke at openjdk.org>`
> `/author remove @openjdk-bot`
> `/author remove`
> 
> Note: only Committers of the repository would be allowed to issue /author command.

Looks pretty good. I have some suggestions for language to make it clearer to users and a minor optimization.

bots/pr/src/main/java/org/openjdk/skara/bots/pr/AuthorCommand.java line 55:

> 53:     public void handle(PullRequestBot bot, PullRequest pr, CensusInstance censusInstance, ScratchArea scratchArea, CommandInvocation command, List<Comment> allComments, PrintWriter reply) {
> 54:         if (!command.user().equals(pr.author())) {
> 55:             reply.println("Only the author (@" + pr.author().username() + ") is allowed to issue the `author` command.");

Suggestion:

            reply.println("Only the pull request author (@" + pr.author().username() + ") is allowed to issue the `author` command.");

bots/pr/src/main/java/org/openjdk/skara/bots/pr/AuthorCommand.java line 60:

> 58: 
> 59:         if (!censusInstance.isCommitter(pr.author())) {
> 60:             reply.println("Only committers in this [project](https://openjdk.org/census#" + censusInstance.project().name() + ") are allowed to issue the `author` command.");

I think we should link to the definition of Committer instead (like we do for Reviewers in the BackportCommand). A census link would have to be conditional on which census this repository is using.
Suggestion:

            reply.println("Only [Committers](https://openjdk.org/bylaws#committer) are allowed to issue the `author` command.");

bots/pr/src/main/java/org/openjdk/skara/bots/pr/AuthorCommand.java line 91:

> 89:                 }
> 90:                 reply.println(Authors.setAuthorMarker(author.get()));
> 91:                 reply.println("Author of this pull request has been set to `" + author.get() + "` successfully.");

I think we need to change the language a bit. Claiming that the author of the pull request has changed can be confusing, because the author isn't actually changing in the forge. I think "pull request author" and "overriding author" are better terms. 
Suggestion:

                reply.println("Setting overriding author to `" + author.get() + "`. When this pull request is integrated, the overriding author will be used in the commit.");

bots/pr/src/main/java/org/openjdk/skara/bots/pr/AuthorCommand.java line 112:

> 110:                     if (currAuthor.get().equals(author.get())) {
> 111:                         reply.println(Authors.removeAuthorMarker(author.get()));
> 112:                         reply.println("Author `" + author.get() + "` successfully removed.");

Suggestion:

                        reply.println("Overriding author `" + author.get() + "` was successfully removed. When this pull request is integrated, the pull request author will be the author of the commit.");

bots/pr/src/main/java/org/openjdk/skara/bots/pr/AuthorCommand.java line 115:

> 113:                     } else {
> 114:                         reply.println("`" + author.get() + "` was not set to this pull request's author.");
> 115:                         reply.println("Current author of this pull request is set to: `" + currAuthor.get() + "`");

Suggestion:

                        reply.println("Cannot remove `" + author.get() + "`, the overriding author is currently set to: `" + currAuthor.get() + "`");

bots/pr/src/main/java/org/openjdk/skara/bots/pr/AuthorCommand.java line 125:

> 123:     @Override
> 124:     public String description() {
> 125:         return "sets or removes author for a PR";

Suggestion:

        return "sets an overriding author used in the final commit when the PR is integrated";

bots/pr/src/main/java/org/openjdk/skara/bots/pr/Authors.java line 32:

> 30: import java.util.regex.*;
> 31: 
> 32: class Authors {

I think this class should be just `Author` since we can never set more than one , or perhaps `OverridingAuthor` to make it even clearer what it is.

bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckablePullRequest.java line 181:

> 179:         }
> 180: 
> 181:         var authorSet = Authors.author(pr.repository().forge().currentUser(), pr.comments());

Calling `pr.comments()` here is a remote call so rather expensive. It's already done in `commitMessage`. We could at least make sure we only call it once. Looking a bit further, I see that in all places where a `CheckablePullRequest` is created, we already have a list of comments, so I think an even better solution here is to add a `comments` field and supply it to the constructor. 

I think the variable name can be clearer.
Suggestion:

        var overridingAuthor = Authors.author(pr.repository().forge().currentUser(), pr.comments());

-------------

PR Review: https://git.openjdk.org/skara/pull/1553#pullrequestreview-1606986111
PR Review Comment: https://git.openjdk.org/skara/pull/1553#discussion_r1313064434
PR Review Comment: https://git.openjdk.org/skara/pull/1553#discussion_r1313058552
PR Review Comment: https://git.openjdk.org/skara/pull/1553#discussion_r1313063169
PR Review Comment: https://git.openjdk.org/skara/pull/1553#discussion_r1313066662
PR Review Comment: https://git.openjdk.org/skara/pull/1553#discussion_r1313072027
PR Review Comment: https://git.openjdk.org/skara/pull/1553#discussion_r1313077939
PR Review Comment: https://git.openjdk.org/skara/pull/1553#discussion_r1313049494
PR Review Comment: https://git.openjdk.org/skara/pull/1553#discussion_r1313078472

From zsong at openjdk.org  Fri Sep  1 16:21:33 2023
From: zsong at openjdk.org (Zhao Song)
Date: Fri, 1 Sep 2023 16:21:33 GMT
Subject: RFR: 1997: Allow the creator of a PR to set the commit author [v2]
In-Reply-To: <GpY2ep_iBbg14Iv1aSfJTnvU3WnD8G2P47ulYHpOzYc=.30bad807-0b20-4861-b4bc-1ec3e5518429@github.com>
References: <GpY2ep_iBbg14Iv1aSfJTnvU3WnD8G2P47ulYHpOzYc=.30bad807-0b20-4861-b4bc-1ec3e5518429@github.com>
Message-ID: <nP0dDPhIbMgd55qOgALh4r0vxELRHDUKw2ha1DKnfsE=.5c195cfb-7c80-46af-b941-a0170b7e7f82@github.com>

> In this pr, we will introduce a new pull request command `/author`.
> 
> If an author wants to contribute a change to a repository, but he doesn't have access, then someone with the access will be able to help him with this command.
> 
> Usage: `/author [set|remove] [@user | openjdk-user | Full Name <email at address>]`
> Examples: 
> `/author set @openjdk-bot`
> `/author @openjdk-bot`
> `/author set J. Duke <duke at openjdk.org>`
> `/author remove @openjdk-bot`
> `/author remove`
> 
> Note: only Committers of the repository would be allowed to issue /author command.

Zhao Song has updated the pull request incrementally with three additional commits since the last revision:

 - Update bots/pr/src/main/java/org/openjdk/skara/bots/pr/AuthorCommand.java
   
   Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
 - Update bots/pr/src/main/java/org/openjdk/skara/bots/pr/AuthorCommand.java
   
   Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
 - Update bots/pr/src/main/java/org/openjdk/skara/bots/pr/AuthorCommand.java
   
   Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>

-------------

Changes:
  - all: https://git.openjdk.org/skara/pull/1553/files
  - new: https://git.openjdk.org/skara/pull/1553/files/67a40715..f1f3639f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=skara&pr=1553&range=01
 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1553&range=00-01

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/skara/pull/1553.diff
  Fetch: git fetch https://git.openjdk.org/skara.git pull/1553/head:pull/1553

PR: https://git.openjdk.org/skara/pull/1553

From zsong at openjdk.org  Fri Sep  1 16:21:34 2023
From: zsong at openjdk.org (Zhao Song)
Date: Fri, 1 Sep 2023 16:21:34 GMT
Subject: RFR: 1997: Allow the creator of a PR to set the commit author [v2]
In-Reply-To: <HZ82SUIigzmqH8j8TbZs5FaW3MyN14Skv0rT-cE932Y=.9eae6abe-861d-497b-83a9-5a7d709dbac9@github.com>
References: <GpY2ep_iBbg14Iv1aSfJTnvU3WnD8G2P47ulYHpOzYc=.30bad807-0b20-4861-b4bc-1ec3e5518429@github.com>
 <HZ82SUIigzmqH8j8TbZs5FaW3MyN14Skv0rT-cE932Y=.9eae6abe-861d-497b-83a9-5a7d709dbac9@github.com>
Message-ID: <vUcuxjHQpJnnnQQ2RYfErTGI7UcXHjMJDigxMka8waQ=.5f0aa5c7-332e-457a-ad3c-166ec4c7f14a@github.com>

On Fri, 1 Sep 2023 13:56:21 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Zhao Song has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Update bots/pr/src/main/java/org/openjdk/skara/bots/pr/AuthorCommand.java
>>    
>>    Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
>>  - Update bots/pr/src/main/java/org/openjdk/skara/bots/pr/AuthorCommand.java
>>    
>>    Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
>>  - Update bots/pr/src/main/java/org/openjdk/skara/bots/pr/AuthorCommand.java
>>    
>>    Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
>
> bots/pr/src/main/java/org/openjdk/skara/bots/pr/AuthorCommand.java line 91:
> 
>> 89:                 }
>> 90:                 reply.println(Authors.setAuthorMarker(author.get()));
>> 91:                 reply.println("Author of this pull request has been set to `" + author.get() + "` successfully.");
> 
> I think we need to change the language a bit. Claiming that the author of the pull request has changed can be confusing, because the author isn't actually changing in the forge. I think "pull request author" and "overriding author" are better terms. 
> Suggestion:
> 
>                 reply.println("Setting overriding author to `" + author.get() + "`. When this pull request is integrated, the overriding author will be used in the commit.");

Looks good. Thanks for the suggestion!

> bots/pr/src/main/java/org/openjdk/skara/bots/pr/Authors.java line 32:
> 
>> 30: import java.util.regex.*;
>> 31: 
>> 32: class Authors {
> 
> I think this class should be just `Author` since we can never set more than one , or perhaps `OverridingAuthor` to make it even clearer what it is.

I prefer the name OverridingAuthor because we already have a Class called Author in package vcs.

-------------

PR Review Comment: https://git.openjdk.org/skara/pull/1553#discussion_r1313242619
PR Review Comment: https://git.openjdk.org/skara/pull/1553#discussion_r1313241162

From zsong at openjdk.org  Fri Sep  1 16:27:24 2023
From: zsong at openjdk.org (Zhao Song)
Date: Fri, 1 Sep 2023 16:27:24 GMT
Subject: RFR: 1997: Allow the creator of a PR to set the commit author [v2]
In-Reply-To: <HZ82SUIigzmqH8j8TbZs5FaW3MyN14Skv0rT-cE932Y=.9eae6abe-861d-497b-83a9-5a7d709dbac9@github.com>
References: <GpY2ep_iBbg14Iv1aSfJTnvU3WnD8G2P47ulYHpOzYc=.30bad807-0b20-4861-b4bc-1ec3e5518429@github.com>
 <HZ82SUIigzmqH8j8TbZs5FaW3MyN14Skv0rT-cE932Y=.9eae6abe-861d-497b-83a9-5a7d709dbac9@github.com>
Message-ID: <pMund2dOF0mrIjDPI6Wj4-jaIxk_k9MAlsLzFSEBQwY=.820ebfeb-cfb6-4f18-b4ea-3fe751eea318@github.com>

On Fri, 1 Sep 2023 14:09:18 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Zhao Song has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Update bots/pr/src/main/java/org/openjdk/skara/bots/pr/AuthorCommand.java
>>    
>>    Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
>>  - Update bots/pr/src/main/java/org/openjdk/skara/bots/pr/AuthorCommand.java
>>    
>>    Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
>>  - Update bots/pr/src/main/java/org/openjdk/skara/bots/pr/AuthorCommand.java
>>    
>>    Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
>
> bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckablePullRequest.java line 181:
> 
>> 179:         }
>> 180: 
>> 181:         var authorSet = Authors.author(pr.repository().forge().currentUser(), pr.comments());
> 
> Calling `pr.comments()` here is a remote call so rather expensive. It's already done in `commitMessage`. We could at least make sure we only call it once. Looking a bit further, I see that in all places where a `CheckablePullRequest` is created, we already have a list of comments, so I think an even better solution here is to add a `comments` field and supply it to the constructor. 
> 
> I think the variable name can be clearer.
> Suggestion:
> 
>         var overridingAuthor = Authors.author(pr.repository().forge().currentUser(), pr.comments());

Sure, will reuse the comments

-------------

PR Review Comment: https://git.openjdk.org/skara/pull/1553#discussion_r1313250522

From zsong at openjdk.org  Fri Sep  1 20:34:38 2023
From: zsong at openjdk.org (Zhao Song)
Date: Fri, 1 Sep 2023 20:34:38 GMT
Subject: RFR: 1997: Allow the creator of a PR to set the commit author [v3]
In-Reply-To: <GpY2ep_iBbg14Iv1aSfJTnvU3WnD8G2P47ulYHpOzYc=.30bad807-0b20-4861-b4bc-1ec3e5518429@github.com>
References: <GpY2ep_iBbg14Iv1aSfJTnvU3WnD8G2P47ulYHpOzYc=.30bad807-0b20-4861-b4bc-1ec3e5518429@github.com>
Message-ID: <9tTpLHkOp9m6sw7QB7NiX3cEzmxrVRdq38jqEzX6bsE=.04acdadb-ca81-40fd-b340-188a2a05d92c@github.com>

> In this pr, we will introduce a new pull request command `/author`.
> 
> If an author wants to contribute a change to a repository, but he doesn't have access, then someone with the access will be able to help him with this command.
> 
> Usage: `/author [set|remove] [@user | openjdk-user | Full Name <email at address>]`
> Examples: 
> `/author set @openjdk-bot`
> `/author @openjdk-bot`
> `/author set J. Duke <duke at openjdk.org>`
> `/author remove @openjdk-bot`
> `/author remove`
> 
> Note: only Committers of the repository would be allowed to issue /author command.

Zhao Song has updated the pull request incrementally with 10 additional commits since the last revision:

 - fix tests
 - update
 - Update bots/pr/src/main/java/org/openjdk/skara/bots/pr/AuthorCommand.java
   
   Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
 - Update bots/pr/src/main/java/org/openjdk/skara/bots/pr/AuthorCommand.java
   
   Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
 - Update bots/pr/src/main/java/org/openjdk/skara/bots/pr/AuthorCommand.java
   
   Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
 - update
 - Update bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckablePullRequest.java
   
   Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
 - Update bots/pr/src/main/java/org/openjdk/skara/bots/pr/AuthorCommand.java
   
   Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
 - Update bots/pr/src/main/java/org/openjdk/skara/bots/pr/AuthorCommand.java
   
   Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
 - Update bots/pr/src/main/java/org/openjdk/skara/bots/pr/AuthorCommand.java
   
   Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>

-------------

Changes:
  - all: https://git.openjdk.org/skara/pull/1553/files
  - new: https://git.openjdk.org/skara/pull/1553/files/f1f3639f..f2409e82

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=skara&pr=1553&range=02
 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1553&range=01-02

  Stats: 44 lines in 8 files changed: 4 ins; 3 del; 37 mod
  Patch: https://git.openjdk.org/skara/pull/1553.diff
  Fetch: git fetch https://git.openjdk.org/skara.git pull/1553/head:pull/1553

PR: https://git.openjdk.org/skara/pull/1553

From erikj at openjdk.org  Fri Sep  1 20:34:39 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 1 Sep 2023 20:34:39 GMT
Subject: RFR: 1997: Allow the creator of a PR to set the commit author [v3]
In-Reply-To: <9tTpLHkOp9m6sw7QB7NiX3cEzmxrVRdq38jqEzX6bsE=.04acdadb-ca81-40fd-b340-188a2a05d92c@github.com>
References: <GpY2ep_iBbg14Iv1aSfJTnvU3WnD8G2P47ulYHpOzYc=.30bad807-0b20-4861-b4bc-1ec3e5518429@github.com>
 <9tTpLHkOp9m6sw7QB7NiX3cEzmxrVRdq38jqEzX6bsE=.04acdadb-ca81-40fd-b340-188a2a05d92c@github.com>
Message-ID: <0t6roTHgH15HFc5V9Ia8cZ490DcryLyeZ9OVRL4qILw=.879d5fd1-e079-45bd-96da-c7056df7d07f@github.com>

On Fri, 1 Sep 2023 20:29:24 GMT, Zhao Song <zsong at openjdk.org> wrote:

>> In this pr, we will introduce a new pull request command `/author`.
>> 
>> If an author wants to contribute a change to a repository, but he doesn't have access, then someone with the access will be able to help him with this command.
>> 
>> Usage: `/author [set|remove] [@user | openjdk-user | Full Name <email at address>]`
>> Examples: 
>> `/author set @openjdk-bot`
>> `/author @openjdk-bot`
>> `/author set J. Duke <duke at openjdk.org>`
>> `/author remove @openjdk-bot`
>> `/author remove`
>> 
>> Note: only Committers of the repository would be allowed to issue /author command.
>
> Zhao Song has updated the pull request incrementally with 10 additional commits since the last revision:
> 
>  - fix tests
>  - update
>  - Update bots/pr/src/main/java/org/openjdk/skara/bots/pr/AuthorCommand.java
>    
>    Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
>  - Update bots/pr/src/main/java/org/openjdk/skara/bots/pr/AuthorCommand.java
>    
>    Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
>  - Update bots/pr/src/main/java/org/openjdk/skara/bots/pr/AuthorCommand.java
>    
>    Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
>  - update
>  - Update bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckablePullRequest.java
>    
>    Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
>  - Update bots/pr/src/main/java/org/openjdk/skara/bots/pr/AuthorCommand.java
>    
>    Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
>  - Update bots/pr/src/main/java/org/openjdk/skara/bots/pr/AuthorCommand.java
>    
>    Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
>  - Update bots/pr/src/main/java/org/openjdk/skara/bots/pr/AuthorCommand.java
>    
>    Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>

Reading back my language suggestions again now, I found some more fine tuning could be done to make it read even better and clearer.

bots/pr/src/main/java/org/openjdk/skara/bots/pr/AuthorCommand.java line 108:

> 106:                 }
> 107:                 if (currAuthor.isEmpty()) {
> 108:                     reply.println("There is no overriding author set in this pull request.");

I think "for" reads slightly better.
Suggestion:

                    reply.println("There is no overriding author set for this pull request.");

bots/pr/src/main/java/org/openjdk/skara/bots/pr/AuthorCommand.java line 112:

> 110:                     if (currAuthor.get().equals(author.get())) {
> 111:                         reply.println(OverridingAuthor.removeAuthorMarker(author.get()));
> 112:                         reply.println("Overriding author `" + author.get() + "` was successfully removed. When this pull request is integrated, the pull request author will be the author of the commit.");

Reading this again, it can be misinterpreted.
Suggestion:

                        reply.println("Overriding author `" + author.get() + "` was successfully removed. When this pull request is integrated, the pull request author will be used as the author of the commit.");

bots/pr/src/main/java/org/openjdk/skara/bots/pr/AuthorCommand.java line 124:

> 122:     @Override
> 123:     public String description() {
> 124:         return "sets an overriding author used in the final commit when the PR is integrated";

Suggestion:

        return "sets an overriding author to be used in the commit when the PR is integrated";

bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckablePullRequest.java line 159:

> 157:     }
> 158: 
> 159:     Hash commit(Hash finalHead, Namespace namespace, String censusDomain, String sponsorId, Hash original, List<Comment> comments) throws IOException, CommitFailure {

Can you also replace the usage in `commitMessage` in this class.

-------------

PR Review: https://git.openjdk.org/skara/pull/1553#pullrequestreview-1607355482
PR Review Comment: https://git.openjdk.org/skara/pull/1553#discussion_r1313294667
PR Review Comment: https://git.openjdk.org/skara/pull/1553#discussion_r1313296087
PR Review Comment: https://git.openjdk.org/skara/pull/1553#discussion_r1313297329
PR Review Comment: https://git.openjdk.org/skara/pull/1553#discussion_r1313298631

From zsong at openjdk.org  Fri Sep  1 20:34:39 2023
From: zsong at openjdk.org (Zhao Song)
Date: Fri, 1 Sep 2023 20:34:39 GMT
Subject: RFR: 1997: Allow the creator of a PR to set the commit author [v3]
In-Reply-To: <0t6roTHgH15HFc5V9Ia8cZ490DcryLyeZ9OVRL4qILw=.879d5fd1-e079-45bd-96da-c7056df7d07f@github.com>
References: <GpY2ep_iBbg14Iv1aSfJTnvU3WnD8G2P47ulYHpOzYc=.30bad807-0b20-4861-b4bc-1ec3e5518429@github.com>
 <9tTpLHkOp9m6sw7QB7NiX3cEzmxrVRdq38jqEzX6bsE=.04acdadb-ca81-40fd-b340-188a2a05d92c@github.com>
 <0t6roTHgH15HFc5V9Ia8cZ490DcryLyeZ9OVRL4qILw=.879d5fd1-e079-45bd-96da-c7056df7d07f@github.com>
Message-ID: <Z4lqsTIuh5RImVJOhOG-svpEwzuobzi7mby5FjWclto=.61d5b0d3-17c5-4efc-91fc-c19be9cf0285@github.com>

On Fri, 1 Sep 2023 17:06:07 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Zhao Song has updated the pull request incrementally with 10 additional commits since the last revision:
>> 
>>  - fix tests
>>  - update
>>  - Update bots/pr/src/main/java/org/openjdk/skara/bots/pr/AuthorCommand.java
>>    
>>    Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
>>  - Update bots/pr/src/main/java/org/openjdk/skara/bots/pr/AuthorCommand.java
>>    
>>    Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
>>  - Update bots/pr/src/main/java/org/openjdk/skara/bots/pr/AuthorCommand.java
>>    
>>    Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
>>  - update
>>  - Update bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckablePullRequest.java
>>    
>>    Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
>>  - Update bots/pr/src/main/java/org/openjdk/skara/bots/pr/AuthorCommand.java
>>    
>>    Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
>>  - Update bots/pr/src/main/java/org/openjdk/skara/bots/pr/AuthorCommand.java
>>    
>>    Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
>>  - Update bots/pr/src/main/java/org/openjdk/skara/bots/pr/AuthorCommand.java
>>    
>>    Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
>
> bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckablePullRequest.java line 159:
> 
>> 157:     }
>> 158: 
>> 159:     Hash commit(Hash finalHead, Namespace namespace, String censusDomain, String sponsorId, Hash original, List<Comment> comments) throws IOException, CommitFailure {
> 
> Can you also replace the usage in `commitMessage` in this class.

Sure

-------------

PR Review Comment: https://git.openjdk.org/skara/pull/1553#discussion_r1313314717

From erikj at openjdk.org  Fri Sep  1 21:33:02 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 1 Sep 2023 21:33:02 GMT
Subject: RFR: 1997: Allow the creator of a PR to set the commit author [v3]
In-Reply-To: <pMund2dOF0mrIjDPI6Wj4-jaIxk_k9MAlsLzFSEBQwY=.820ebfeb-cfb6-4f18-b4ea-3fe751eea318@github.com>
References: <GpY2ep_iBbg14Iv1aSfJTnvU3WnD8G2P47ulYHpOzYc=.30bad807-0b20-4861-b4bc-1ec3e5518429@github.com>
 <HZ82SUIigzmqH8j8TbZs5FaW3MyN14Skv0rT-cE932Y=.9eae6abe-861d-497b-83a9-5a7d709dbac9@github.com>
 <pMund2dOF0mrIjDPI6Wj4-jaIxk_k9MAlsLzFSEBQwY=.820ebfeb-cfb6-4f18-b4ea-3fe751eea318@github.com>
Message-ID: <K3_Zg8cl90EeUbW54oTF4JdyoGoh0w57rPR6_wme9IA=.c60d07f0-9962-4ee8-867c-59bd85794ef8@github.com>

On Fri, 1 Sep 2023 16:25:03 GMT, Zhao Song <zsong at openjdk.org> wrote:

>> bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckablePullRequest.java line 181:
>> 
>>> 179:         }
>>> 180: 
>>> 181:         var authorSet = Authors.author(pr.repository().forge().currentUser(), pr.comments());
>> 
>> Calling `pr.comments()` here is a remote call so rather expensive. It's already done in `commitMessage`. We could at least make sure we only call it once. Looking a bit further, I see that in all places where a `CheckablePullRequest` is created, we already have a list of comments, so I think an even better solution here is to add a `comments` field and supply it to the constructor. 
>> 
>> I think the variable name can be clearer.
>> Suggestion:
>> 
>>         var overridingAuthor = Authors.author(pr.repository().forge().currentUser(), pr.comments());
>
> Sure, will reuse the comments

Was there a reason you didn't add the comments as a field in `CheckablePullRequest`? I think that would make more sense as the `PullRequest` already is a field.

-------------

PR Review Comment: https://git.openjdk.org/skara/pull/1553#discussion_r1313546162

From zsong at openjdk.org  Fri Sep  1 21:58:29 2023
From: zsong at openjdk.org (Zhao Song)
Date: Fri, 1 Sep 2023 21:58:29 GMT
Subject: RFR: 1997: Allow the creator of a PR to set the commit author [v3]
In-Reply-To: <K3_Zg8cl90EeUbW54oTF4JdyoGoh0w57rPR6_wme9IA=.c60d07f0-9962-4ee8-867c-59bd85794ef8@github.com>
References: <GpY2ep_iBbg14Iv1aSfJTnvU3WnD8G2P47ulYHpOzYc=.30bad807-0b20-4861-b4bc-1ec3e5518429@github.com>
 <HZ82SUIigzmqH8j8TbZs5FaW3MyN14Skv0rT-cE932Y=.9eae6abe-861d-497b-83a9-5a7d709dbac9@github.com>
 <pMund2dOF0mrIjDPI6Wj4-jaIxk_k9MAlsLzFSEBQwY=.820ebfeb-cfb6-4f18-b4ea-3fe751eea318@github.com>
 <K3_Zg8cl90EeUbW54oTF4JdyoGoh0w57rPR6_wme9IA=.c60d07f0-9962-4ee8-867c-59bd85794ef8@github.com>
Message-ID: <rDOILu3ryaXogfp07CdmJf3U9Eem3iVKh2ouR2kaOVI=.b3cfc281-21ce-4ca7-94a5-7dae519aff87@github.com>

On Fri, 1 Sep 2023 21:30:52 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Sure, will reuse the comments
>
> Was there a reason you didn't add the comments as a field in `CheckablePullRequest`? I think that would make more sense as the `PullRequest` already is a field.

No. I misunderstood what you mean in the morning. I will fix it soon.

-------------

PR Review Comment: https://git.openjdk.org/skara/pull/1553#discussion_r1313568664

From zsong at openjdk.org  Fri Sep  1 22:33:38 2023
From: zsong at openjdk.org (Zhao Song)
Date: Fri, 1 Sep 2023 22:33:38 GMT
Subject: RFR: 1997: Allow the creator of a PR to set the commit author [v4]
In-Reply-To: <GpY2ep_iBbg14Iv1aSfJTnvU3WnD8G2P47ulYHpOzYc=.30bad807-0b20-4861-b4bc-1ec3e5518429@github.com>
References: <GpY2ep_iBbg14Iv1aSfJTnvU3WnD8G2P47ulYHpOzYc=.30bad807-0b20-4861-b4bc-1ec3e5518429@github.com>
Message-ID: <j53FbYM3pQIGsGYLKLZsEwVQkcnzUNfcsc1WGBM4sQU=.ae79f428-082e-4699-9815-a82a99195484@github.com>

> In this pr, we will introduce a new pull request command `/author`.
> 
> If an author wants to contribute a change to a repository, but he doesn't have access, then someone with the access will be able to help him with this command.
> 
> Usage: `/author [set|remove] [@user | openjdk-user | Full Name <email at address>]`
> Examples: 
> `/author set @openjdk-bot`
> `/author @openjdk-bot`
> `/author set J. Duke <duke at openjdk.org>`
> `/author remove @openjdk-bot`
> `/author remove`
> 
> Note: only Committers of the repository would be allowed to issue /author command.

Zhao Song has updated the pull request incrementally with one additional commit since the last revision:

  update

-------------

Changes:
  - all: https://git.openjdk.org/skara/pull/1553/files
  - new: https://git.openjdk.org/skara/pull/1553/files/f2409e82..fb88a0e2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=skara&pr=1553&range=03
 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1553&range=02-03

  Stats: 31 lines in 4 files changed: 5 ins; 0 del; 26 mod
  Patch: https://git.openjdk.org/skara/pull/1553.diff
  Fetch: git fetch https://git.openjdk.org/skara.git pull/1553/head:pull/1553

PR: https://git.openjdk.org/skara/pull/1553

From erikj at openjdk.org  Fri Sep  1 22:47:54 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 1 Sep 2023 22:47:54 GMT
Subject: RFR: 1997: Allow the creator of a PR to set the commit author [v4]
In-Reply-To: <j53FbYM3pQIGsGYLKLZsEwVQkcnzUNfcsc1WGBM4sQU=.ae79f428-082e-4699-9815-a82a99195484@github.com>
References: <GpY2ep_iBbg14Iv1aSfJTnvU3WnD8G2P47ulYHpOzYc=.30bad807-0b20-4861-b4bc-1ec3e5518429@github.com>
 <j53FbYM3pQIGsGYLKLZsEwVQkcnzUNfcsc1WGBM4sQU=.ae79f428-082e-4699-9815-a82a99195484@github.com>
Message-ID: <hfP32L01G5AMPJrVC4LPLGS5A8M4xVU9__pTb677j9Y=.202448e2-53e0-4231-8e47-1dccce7f4fec@github.com>

On Fri, 1 Sep 2023 22:33:38 GMT, Zhao Song <zsong at openjdk.org> wrote:

>> In this pr, we will introduce a new pull request command `/author`.
>> 
>> If an author wants to contribute a change to a repository, but he doesn't have access, then someone with the access will be able to help him with this command.
>> 
>> Usage: `/author [set|remove] [@user | openjdk-user | Full Name <email at address>]`
>> Examples: 
>> `/author set @openjdk-bot`
>> `/author @openjdk-bot`
>> `/author set J. Duke <duke at openjdk.org>`
>> `/author remove @openjdk-bot`
>> `/author remove`
>> 
>> Note: only Committers of the repository would be allowed to issue /author command.
>
> Zhao Song has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update

Marked as reviewed by erikj (Lead).

-------------

PR Review: https://git.openjdk.org/skara/pull/1553#pullrequestreview-1607731411

From zsong at openjdk.org  Fri Sep  1 22:58:37 2023
From: zsong at openjdk.org (Zhao Song)
Date: Fri, 1 Sep 2023 22:58:37 GMT
Subject: RFR: 1997: Allow the creator of a PR to set the commit author [v4]
In-Reply-To: <j53FbYM3pQIGsGYLKLZsEwVQkcnzUNfcsc1WGBM4sQU=.ae79f428-082e-4699-9815-a82a99195484@github.com>
References: <GpY2ep_iBbg14Iv1aSfJTnvU3WnD8G2P47ulYHpOzYc=.30bad807-0b20-4861-b4bc-1ec3e5518429@github.com>
 <j53FbYM3pQIGsGYLKLZsEwVQkcnzUNfcsc1WGBM4sQU=.ae79f428-082e-4699-9815-a82a99195484@github.com>
Message-ID: <1yHVhdYakuOorA8ixDDjk3OZW3HX2hqMlOxj6deRA9c=.82039384-bbdc-4166-bf19-3c40d7ae954f@github.com>

On Fri, 1 Sep 2023 22:33:38 GMT, Zhao Song <zsong at openjdk.org> wrote:

>> In this pr, we will introduce a new pull request command `/author`.
>> 
>> If an author wants to contribute a change to a repository, but he doesn't have access, then someone with the access will be able to help him with this command.
>> 
>> Usage: `/author [set|remove] [@user | openjdk-user | Full Name <email at address>]`
>> Examples: 
>> `/author set @openjdk-bot`
>> `/author @openjdk-bot`
>> `/author set J. Duke <duke at openjdk.org>`
>> `/author remove @openjdk-bot`
>> `/author remove`
>> 
>> Note: only Committers of the repository would be allowed to issue /author command.
>
> Zhao Song has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update

Thanks for all the suggestions! This patch is much better with your suggestions.

-------------

PR Comment: https://git.openjdk.org/skara/pull/1553#issuecomment-1703417290

From zsong at openjdk.org  Fri Sep  1 22:58:37 2023
From: zsong at openjdk.org (Zhao Song)
Date: Fri, 1 Sep 2023 22:58:37 GMT
Subject: Integrated: 1997: Allow the creator of a PR to set the commit author
In-Reply-To: <GpY2ep_iBbg14Iv1aSfJTnvU3WnD8G2P47ulYHpOzYc=.30bad807-0b20-4861-b4bc-1ec3e5518429@github.com>
References: <GpY2ep_iBbg14Iv1aSfJTnvU3WnD8G2P47ulYHpOzYc=.30bad807-0b20-4861-b4bc-1ec3e5518429@github.com>
Message-ID: <f73H6hvOW-Eltbj1BaQQdO2WzQDVoqUfSDA79HFN50U=.e50dbb3f-4df3-4bae-991a-7e22c9379be2@github.com>

On Thu, 31 Aug 2023 22:42:46 GMT, Zhao Song <zsong at openjdk.org> wrote:

> In this pr, we will introduce a new pull request command `/author`.
> 
> If an author wants to contribute a change to a repository, but he doesn't have access, then someone with the access will be able to help him with this command.
> 
> Usage: `/author [set|remove] [@user | openjdk-user | Full Name <email at address>]`
> Examples: 
> `/author set @openjdk-bot`
> `/author @openjdk-bot`
> `/author set J. Duke <duke at openjdk.org>`
> `/author remove @openjdk-bot`
> `/author remove`
> 
> Note: only Committers of the repository would be allowed to issue /author command.

This pull request has now been integrated.

Changeset: ab0cdb91
Author:    Zhao Song <zsong at openjdk.org>
URL:       https://git.openjdk.org/skara/commit/ab0cdb918f38e0f9faaff57a6d2bac577e0fee50
Stats:     380 lines in 11 files changed: 362 ins; 1 del; 17 mod

1997: Allow the creator of a PR to set the commit author

Reviewed-by: erikj

-------------

PR: https://git.openjdk.org/skara/pull/1553

From duke at openjdk.org  Mon Sep  4 09:44:54 2023
From: duke at openjdk.org (altrisi)
Date: Mon, 4 Sep 2023 09:44:54 GMT
Subject: RFR: 2011: GHA: Resolve deprecation warnings
In-Reply-To: <q0LrJXo2pKnq5wqDqjRlREnevJh520NpzduZ571H8Es=.a17b1cfa-2da0-4429-8cd2-b66a68007548@github.com>
References: <q0LrJXo2pKnq5wqDqjRlREnevJh520NpzduZ571H8Es=.a17b1cfa-2da0-4429-8cd2-b66a68007548@github.com>
Message-ID: <ylCjGJ-j93P8zz9KnawvDmDzueeqkKEoHCdxCc1_290=.9f346d05-21b1-48dd-b058-5663074352fc@github.com>

On Thu, 31 Aug 2023 11:19:33 GMT, altrisi <duke at openjdk.org> wrote:

> This PR resolves deprecation warnings in the GHA workflow by updating dependencies and replacing the deprecated `set-output` with `GITHUB_OUTPUT`.
> 
> v2 to v3 major in `checkout` just updated the node version.
> 
> Github Script v3->v6 also needed a small code change (`github.repos`->`github.rest.repos`), following the documentation.
> 
> GHA workflows still pass with these changes.
> 
> Note that I don't have a JBS account to be able to make an issue for this PR.

While waiting for a sponsor, something slightly related that I've found is that if the mac part of the workflow is ran on `macos-13`, with no other changes, it finishes 30 minutes earlier (total of 1h20m -> 45m). Wondering if it'd be considered for another PR, although the `macos-13` image is marked as "[beta]" in the runner-images repo.

-------------

PR Comment: https://git.openjdk.org/skara/pull/1552#issuecomment-1704948812

From duke at openjdk.org  Tue Sep  5 12:49:23 2023
From: duke at openjdk.org (altrisi)
Date: Tue, 5 Sep 2023 12:49:23 GMT
Subject: Integrated: 2011: GHA: Resolve deprecation warnings
In-Reply-To: <q0LrJXo2pKnq5wqDqjRlREnevJh520NpzduZ571H8Es=.a17b1cfa-2da0-4429-8cd2-b66a68007548@github.com>
References: <q0LrJXo2pKnq5wqDqjRlREnevJh520NpzduZ571H8Es=.a17b1cfa-2da0-4429-8cd2-b66a68007548@github.com>
Message-ID: <Wk8h7ucNE3fAYeBVzrzxnzdjXH2vWowcOIxNW7AaARs=.99abcc6d-6e40-4fff-b0fc-61627df111f3@github.com>

On Thu, 31 Aug 2023 11:19:33 GMT, altrisi <duke at openjdk.org> wrote:

> This PR resolves deprecation warnings in the GHA workflow by updating dependencies and replacing the deprecated `set-output` with `GITHUB_OUTPUT`.
> 
> v2 to v3 major in `checkout` just updated the node version.
> 
> Github Script v3->v6 also needed a small code change (`github.repos`->`github.rest.repos`), following the documentation.
> 
> GHA workflows still pass with these changes.
> 
> Note that I don't have a JBS account to be able to make an issue for this PR.

This pull request has now been integrated.

Changeset: 6e290a82
Author:    altrisi <altrisi.trillosierra at gmail.com>
Committer: Erik Joelsson <erikj at openjdk.org>
URL:       https://git.openjdk.org/skara/commit/6e290a822c46de8c290318244212c6e0a11f9778
Stats:     12 lines in 1 file changed: 0 ins; 0 del; 12 mod

2011: GHA: Resolve deprecation warnings

Reviewed-by: erikj

-------------

PR: https://git.openjdk.org/skara/pull/1552

From zsong at openjdk.org  Wed Sep  6 18:24:25 2023
From: zsong at openjdk.org (Zhao Song)
Date: Wed, 6 Sep 2023 18:24:25 GMT
Subject: RFR: 2015: Initial run of PR IssueBot misses issue updates
Message-ID: <LJ64GotX59wc8kbx9OHncRvCqUgaw9XgLRZK7gtL5pY=.cb6a76e4-f4ee-418b-8d19-c4eb6a6b5cf0@github.com>

Currently, if pullRequestBot is down for more than 10 minutes and during that time, if users make changes to some issues, than the update activities would not trigger CheckWorkItem after the bot restarts.

To solve this problem, In this patch, after the bot restarts, in the initial run, pullRequestBot would make CheckWorkItem compare both prMetaData and issueMetaData.

-------------

Commit messages:
 - SKARA-2015

Changes: https://git.openjdk.org/skara/pull/1554/files
 Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1554&range=00
  Issue: https://bugs.openjdk.org/browse/SKARA-2015
  Stats: 42 lines in 5 files changed: 12 ins; 17 del; 13 mod
  Patch: https://git.openjdk.org/skara/pull/1554.diff
  Fetch: git fetch https://git.openjdk.org/skara.git pull/1554/head:pull/1554

PR: https://git.openjdk.org/skara/pull/1554

From zsong at openjdk.org  Wed Sep  6 21:25:18 2023
From: zsong at openjdk.org (Zhao Song)
Date: Wed, 6 Sep 2023 21:25:18 GMT
Subject: RFR: 2003: Timing out lock in RestRequestCache stops the bot
Message-ID: <KxorkWH7WxBejsNxSicd1Y3rHykHtshOvsEa8rMkMeU=.a3de5b1a-0cde-4cd7-80ce-ddc04648e748@github.com>

As Erik said in the issue description, it's better to throw an exception here.

-------------

Commit messages:
 - SKARA-2003

Changes: https://git.openjdk.org/skara/pull/1555/files
 Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1555&range=00
  Issue: https://bugs.openjdk.org/browse/SKARA-2003
  Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/skara/pull/1555.diff
  Fetch: git fetch https://git.openjdk.org/skara.git pull/1555/head:pull/1555

PR: https://git.openjdk.org/skara/pull/1555

From zsong at openjdk.org  Thu Sep  7 21:21:41 2023
From: zsong at openjdk.org (Zhao Song)
Date: Thu, 7 Sep 2023 21:21:41 GMT
Subject: RFR: 827: Copyright year differences can be regarded as a clean
 backport
Message-ID: <5ZE3i_OOIB5ReqCBjrz4Qxt2YtMAdheDogz_yKUF-HM=.74242645-8347-4fb7-9527-56ef7d0f17af@github.com>

As many user requested, when determining whether a backport is clean, our bot should ignore copyright year difference.

-------------

Commit messages:
 - SKARA-827

Changes: https://git.openjdk.org/skara/pull/1556/files
 Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1556&range=00
  Issue: https://bugs.openjdk.org/browse/SKARA-827
  Stats: 49 lines in 3 files changed: 45 ins; 2 del; 2 mod
  Patch: https://git.openjdk.org/skara/pull/1556.diff
  Fetch: git fetch https://git.openjdk.org/skara.git pull/1556/head:pull/1556

PR: https://git.openjdk.org/skara/pull/1556

From zsong at openjdk.org  Thu Sep  7 21:29:49 2023
From: zsong at openjdk.org (Zhao Song)
Date: Thu, 7 Sep 2023 21:29:49 GMT
Subject: RFR: 827: Copyright year differences can be regarded as a clean
 backport [v2]
In-Reply-To: <5ZE3i_OOIB5ReqCBjrz4Qxt2YtMAdheDogz_yKUF-HM=.74242645-8347-4fb7-9527-56ef7d0f17af@github.com>
References: <5ZE3i_OOIB5ReqCBjrz4Qxt2YtMAdheDogz_yKUF-HM=.74242645-8347-4fb7-9527-56ef7d0f17af@github.com>
Message-ID: <NzMKxdWrTcNCjxnjTTx6JdI0e-aOA40v6s-aRO3JeD0=.7323f648-640a-4711-bbac-462e69bb1329@github.com>

> As many user requested, when determining whether a backport is clean, our bot should ignore copyright year difference.

Zhao Song has updated the pull request incrementally with one additional commit since the last revision:

  update

-------------

Changes:
  - all: https://git.openjdk.org/skara/pull/1556/files
  - new: https://git.openjdk.org/skara/pull/1556/files/366b25e8..0af301eb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=skara&pr=1556&range=01
 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1556&range=00-01

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/skara/pull/1556.diff
  Fetch: git fetch https://git.openjdk.org/skara.git pull/1556/head:pull/1556

PR: https://git.openjdk.org/skara/pull/1556

From erikj at openjdk.org  Tue Sep 12 17:09:04 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 12 Sep 2023 17:09:04 GMT
Subject: RFR: 2015: Initial run of PR IssueBot misses issue updates
In-Reply-To: <LJ64GotX59wc8kbx9OHncRvCqUgaw9XgLRZK7gtL5pY=.cb6a76e4-f4ee-418b-8d19-c4eb6a6b5cf0@github.com>
References: <LJ64GotX59wc8kbx9OHncRvCqUgaw9XgLRZK7gtL5pY=.cb6a76e4-f4ee-418b-8d19-c4eb6a6b5cf0@github.com>
Message-ID: <s6U_6UB2o11pwulXCWSS1zYqIbeoeC6peRyTGRKSTTM=.9f27ea11-28cf-4667-ad51-e6243203145c@github.com>

On Wed, 6 Sep 2023 18:19:19 GMT, Zhao Song <zsong at openjdk.org> wrote:

> Currently, if pullRequestBot is down for more than 10 minutes and during that time, if users make changes to some issues, than the update activities would not trigger CheckWorkItem after the bot restarts.
> 
> To solve this problem, In this patch, after the bot restarts, in the initial run, pullRequestBot would make CheckWorkItem compare both prMetaData and issueMetaData.

bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckWorkItem.java line 73:

> 71: 
> 72:     CheckWorkItem(PullRequestBot bot, String prId, Consumer<RuntimeException> errorHandler, ZonedDateTime triggerUpdatedAt,
> 73:                   boolean needsReadyCheck, boolean forceUpdate, boolean spawnedFromIssueBot, boolean initialRun) {

Having 4 booleans in the constructor is becoming really hard to read and understand. Perhaps we should introduce factory methods instead so we only allow for valid combinations of the booleans. Something like:

fromIssue
fromPr
initialRun
forceUpdate

bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckWorkItem.java line 232:

> 230:                         }
> 231:                     }
> 232:                     // triggered by pr updates

This comment should be moved out of the block.

bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckWorkItem.java line 232:

> 230:                         if (previousIssueMetadata.equals(currIssueMetadata) && expiresAt.isAfter(Instant.now())) {
> 231:                             log.finer("[Issue]Metadata with expiration time is still valid, not checking again");
> 232:                             return true;

I think this method would be easier to read if we kept all return `true`/`false` inside the conditional blocks. If we know we have a terminal state, lets be clear about it so the reader doesn't need to check the rest of the method.

-------------

PR Review Comment: https://git.openjdk.org/skara/pull/1554#discussion_r1323334134
PR Review Comment: https://git.openjdk.org/skara/pull/1554#discussion_r1323326749
PR Review Comment: https://git.openjdk.org/skara/pull/1554#discussion_r1323328980

From erikj at openjdk.org  Tue Sep 12 17:11:53 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 12 Sep 2023 17:11:53 GMT
Subject: RFR: 2003: Timing out lock in RestRequestCache stops the bot
In-Reply-To: <KxorkWH7WxBejsNxSicd1Y3rHykHtshOvsEa8rMkMeU=.a3de5b1a-0cde-4cd7-80ce-ddc04648e748@github.com>
References: <KxorkWH7WxBejsNxSicd1Y3rHykHtshOvsEa8rMkMeU=.a3de5b1a-0cde-4cd7-80ce-ddc04648e748@github.com>
Message-ID: <PAQIvn_9DP7fomBJhc64MMZJRfW-BPRjiz2kM1pcVNA=.3969ed32-b7d7-4119-a938-624ae78becfa@github.com>

On Wed, 6 Sep 2023 21:15:28 GMT, Zhao Song <zsong at openjdk.org> wrote:

> As Erik said in the issue description, it's better to throw an exception here.

Marked as reviewed by erikj (Lead).

-------------

PR Review: https://git.openjdk.org/skara/pull/1555#pullrequestreview-1622743427

From zsong at openjdk.org  Tue Sep 12 17:19:42 2023
From: zsong at openjdk.org (Zhao Song)
Date: Tue, 12 Sep 2023 17:19:42 GMT
Subject: RFR: 2015: Initial run of PR IssueBot misses issue updates
In-Reply-To: <s6U_6UB2o11pwulXCWSS1zYqIbeoeC6peRyTGRKSTTM=.9f27ea11-28cf-4667-ad51-e6243203145c@github.com>
References: <LJ64GotX59wc8kbx9OHncRvCqUgaw9XgLRZK7gtL5pY=.cb6a76e4-f4ee-418b-8d19-c4eb6a6b5cf0@github.com>
 <s6U_6UB2o11pwulXCWSS1zYqIbeoeC6peRyTGRKSTTM=.9f27ea11-28cf-4667-ad51-e6243203145c@github.com>
Message-ID: <pSRTZwjFc-AbEdjC653vJh80RN4sGCRij7cHQxwgtO0=.aeebfdea-4377-4d91-853c-13d5ff55b762@github.com>

On Tue, 12 Sep 2023 16:58:49 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Currently, if pullRequestBot is down for more than 10 minutes and during that time, if users make changes to some issues, than the update activities would not trigger CheckWorkItem after the bot restarts.
>> 
>> To solve this problem, In this patch, after the bot restarts, in the initial run, pullRequestBot would make CheckWorkItem compare both prMetaData and issueMetaData.
>
> bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckWorkItem.java line 232:
> 
>> 230:                         }
>> 231:                     }
>> 232:                     // triggered by pr updates
> 
> This comment should be moved out of the block.

Yes, will fix it

-------------

PR Review Comment: https://git.openjdk.org/skara/pull/1554#discussion_r1323345051

From erikj at openjdk.org  Tue Sep 12 17:22:02 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 12 Sep 2023 17:22:02 GMT
Subject: RFR: 827: Copyright year differences can be regarded as a clean
 backport [v2]
In-Reply-To: <NzMKxdWrTcNCjxnjTTx6JdI0e-aOA40v6s-aRO3JeD0=.7323f648-640a-4711-bbac-462e69bb1329@github.com>
References: <5ZE3i_OOIB5ReqCBjrz4Qxt2YtMAdheDogz_yKUF-HM=.74242645-8347-4fb7-9527-56ef7d0f17af@github.com>
 <NzMKxdWrTcNCjxnjTTx6JdI0e-aOA40v6s-aRO3JeD0=.7323f648-640a-4711-bbac-462e69bb1329@github.com>
Message-ID: <BM0VfEOYc4l2oLjXwMGKLZDBdGE0VbY5EoZjWoBeMBc=.528e099e-b987-4f2f-8bbc-6fc71025fd8c@github.com>

On Thu, 7 Sep 2023 21:29:49 GMT, Zhao Song <zsong at openjdk.org> wrote:

>> As many users requested, when determining whether a backport is clean, our bot should ignore copyright year difference.
>
> Zhao Song has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update

I'm not sure about changing this code without having some kind of unit level testing for it. I'm quite surprised that we don't have any. I think we need to add basic coverage either before or with this change.

You could extract some patches from real backported commits to use for these tests.

vcs/src/main/java/org/openjdk/skara/vcs/DiffComparator.java line 70:

> 68:                 -(.)*Copyright \\(c\\) (?:\\d|\\s|,)* Oracle and/or its affiliates\\. All rights reserved\\.
> 69:                 \\+(.)*Copyright \\(c\\) (?:\\d|\\s|,)* Oracle and/or its affiliates\\. All rights reserved\\.
> 70:                 """);

This pattern should be compiled in a static variable to avoid recompiling it.

-------------

PR Review: https://git.openjdk.org/skara/pull/1556#pullrequestreview-1622754919
PR Review Comment: https://git.openjdk.org/skara/pull/1556#discussion_r1323344339

From zsong at openjdk.org  Tue Sep 12 17:24:57 2023
From: zsong at openjdk.org (Zhao Song)
Date: Tue, 12 Sep 2023 17:24:57 GMT
Subject: RFR: 2015: Initial run of PR IssueBot misses issue updates
In-Reply-To: <s6U_6UB2o11pwulXCWSS1zYqIbeoeC6peRyTGRKSTTM=.9f27ea11-28cf-4667-ad51-e6243203145c@github.com>
References: <LJ64GotX59wc8kbx9OHncRvCqUgaw9XgLRZK7gtL5pY=.cb6a76e4-f4ee-418b-8d19-c4eb6a6b5cf0@github.com>
 <s6U_6UB2o11pwulXCWSS1zYqIbeoeC6peRyTGRKSTTM=.9f27ea11-28cf-4667-ad51-e6243203145c@github.com>
Message-ID: <Pv3Gk8nLe7BQtbdVTV2K-O9s3ZOu93CqftYfNworlPA=.4fca2006-77a5-43f3-b226-1772bacb70c5@github.com>

On Tue, 12 Sep 2023 17:00:58 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Currently, if pullRequestBot is down for more than 10 minutes and during that time, if users make changes to some issues, than the update activities would not trigger CheckWorkItem after the bot restarts.
>> 
>> To solve this problem, In this patch, after the bot restarts, in the initial run, pullRequestBot would make CheckWorkItem compare both prMetaData and issueMetaData.
>
> bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckWorkItem.java line 232:
> 
>> 230:                         if (previousIssueMetadata.equals(currIssueMetadata) && expiresAt.isAfter(Instant.now())) {
>> 231:                             log.finer("[Issue]Metadata with expiration time is still valid, not checking again");
>> 232:                             return true;
> 
> I think this method would be easier to read if we kept all return `true`/`false` inside the conditional blocks. If we know we have a terminal state, lets be clear about it so the reader doesn't need to check the rest of the method.

I removed `return true` here because we couldn't return early in this block. For the initial run case, `initialRun` would be true and `spawnedFromIssueBot` would be false. We need to check both issueMetaData and PRMetaData. 

But we could add some `return true` in `if (!spawnedFromIssueBot)` block.

-------------

PR Review Comment: https://git.openjdk.org/skara/pull/1554#discussion_r1323349702

From zsong at openjdk.org  Tue Sep 12 17:40:31 2023
From: zsong at openjdk.org (Zhao Song)
Date: Tue, 12 Sep 2023 17:40:31 GMT
Subject: RFR: 827: Copyright year differences can be regarded as a clean
 backport [v2]
In-Reply-To: <BM0VfEOYc4l2oLjXwMGKLZDBdGE0VbY5EoZjWoBeMBc=.528e099e-b987-4f2f-8bbc-6fc71025fd8c@github.com>
References: <5ZE3i_OOIB5ReqCBjrz4Qxt2YtMAdheDogz_yKUF-HM=.74242645-8347-4fb7-9527-56ef7d0f17af@github.com>
 <NzMKxdWrTcNCjxnjTTx6JdI0e-aOA40v6s-aRO3JeD0=.7323f648-640a-4711-bbac-462e69bb1329@github.com>
 <BM0VfEOYc4l2oLjXwMGKLZDBdGE0VbY5EoZjWoBeMBc=.528e099e-b987-4f2f-8bbc-6fc71025fd8c@github.com>
Message-ID: <gwlkYSmqWH1UrIfRilqAp9g7VXSURlHT6ZihvRRznqU=.4d5e5428-81c9-4d3e-a6b9-15060d106ef8@github.com>

On Tue, 12 Sep 2023 17:19:53 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> I'm not sure about changing this code without having some kind of unit level testing for it. I'm quite surprised that we don't have any. I think we need to add basic coverage either before or with this change.
> 
> You could extract some patches from real backported commits to use for these tests.

Sure, I didn't add some unit tests because I tested it with some real backport cases. And I agree with you, it's good to have some unit tests.

-------------

PR Comment: https://git.openjdk.org/skara/pull/1556#issuecomment-1716157347

From zsong at openjdk.org  Tue Sep 12 17:43:07 2023
From: zsong at openjdk.org (Zhao Song)
Date: Tue, 12 Sep 2023 17:43:07 GMT
Subject: RFR: 2015: Initial run of PR IssueBot misses issue updates
In-Reply-To: <s6U_6UB2o11pwulXCWSS1zYqIbeoeC6peRyTGRKSTTM=.9f27ea11-28cf-4667-ad51-e6243203145c@github.com>
References: <LJ64GotX59wc8kbx9OHncRvCqUgaw9XgLRZK7gtL5pY=.cb6a76e4-f4ee-418b-8d19-c4eb6a6b5cf0@github.com>
 <s6U_6UB2o11pwulXCWSS1zYqIbeoeC6peRyTGRKSTTM=.9f27ea11-28cf-4667-ad51-e6243203145c@github.com>
Message-ID: <lOn0VGWDXULHVOGwO5UCsJbcYT5eAKHjFHZl3hNO8lE=.16041a2b-78e5-48ba-bd1a-75ff82dd8ebb@github.com>

On Tue, 12 Sep 2023 17:06:11 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Currently, if pullRequestBot is down for more than 10 minutes and during that time, if users make changes to some issues, than the update activities would not trigger CheckWorkItem after the bot restarts.
>> 
>> To solve this problem, In this patch, after the bot restarts, in the initial run, pullRequestBot would make CheckWorkItem compare both prMetaData and issueMetaData.
>
> bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckWorkItem.java line 73:
> 
>> 71: 
>> 72:     CheckWorkItem(PullRequestBot bot, String prId, Consumer<RuntimeException> errorHandler, ZonedDateTime triggerUpdatedAt,
>> 73:                   boolean needsReadyCheck, boolean forceUpdate, boolean spawnedFromIssueBot, boolean initialRun) {
> 
> Having 4 booleans in the constructor is becoming really hard to read and understand. Perhaps we should introduce factory methods instead so we only allow for valid combinations of the booleans. Something like:
> 
> fromIssue
> fromPr
> initialRun
> forceUpdate

I was thinking that if we fix SKARA-2016 in the future, then `forceUpdate` would be removed. So three booleans is reasonable.

-------------

PR Review Comment: https://git.openjdk.org/skara/pull/1554#discussion_r1323368188

From zsong at openjdk.org  Tue Sep 12 17:44:17 2023
From: zsong at openjdk.org (Zhao Song)
Date: Tue, 12 Sep 2023 17:44:17 GMT
Subject: RFR: 2003: Timing out lock in RestRequestCache stops the bot
In-Reply-To: <KxorkWH7WxBejsNxSicd1Y3rHykHtshOvsEa8rMkMeU=.a3de5b1a-0cde-4cd7-80ce-ddc04648e748@github.com>
References: <KxorkWH7WxBejsNxSicd1Y3rHykHtshOvsEa8rMkMeU=.a3de5b1a-0cde-4cd7-80ce-ddc04648e748@github.com>
Message-ID: <6FUyCQ2z6BnNfdjA6rhQP9Sk37i-ft9deByFjj4wzSU=.7029fe34-5e83-435a-ac0d-b810116e41b0@github.com>

On Wed, 6 Sep 2023 21:15:28 GMT, Zhao Song <zsong at openjdk.org> wrote:

> As Erik said in the issue description, it's better to throw an exception here.

Thanks for the review!

-------------

PR Comment: https://git.openjdk.org/skara/pull/1555#issuecomment-1716161662

From zsong at openjdk.org  Tue Sep 12 17:44:17 2023
From: zsong at openjdk.org (Zhao Song)
Date: Tue, 12 Sep 2023 17:44:17 GMT
Subject: Integrated: 2003: Timing out lock in RestRequestCache stops the bot
In-Reply-To: <KxorkWH7WxBejsNxSicd1Y3rHykHtshOvsEa8rMkMeU=.a3de5b1a-0cde-4cd7-80ce-ddc04648e748@github.com>
References: <KxorkWH7WxBejsNxSicd1Y3rHykHtshOvsEa8rMkMeU=.a3de5b1a-0cde-4cd7-80ce-ddc04648e748@github.com>
Message-ID: <yk_ZqvTaecXMBVlpx6Wg4K5cBDGE152OK6NJb6Pv6sw=.9f4ec38c-de88-4ff7-b01e-05b9c437088a@github.com>

On Wed, 6 Sep 2023 21:15:28 GMT, Zhao Song <zsong at openjdk.org> wrote:

> As Erik said in the issue description, it's better to throw an exception here.

This pull request has now been integrated.

Changeset: 07dde6d6
Author:    Zhao Song <zsong at openjdk.org>
URL:       https://git.openjdk.org/skara/commit/07dde6d63d49cf29b68e46135af4d27af0b8c332
Stats:     3 lines in 1 file changed: 0 ins; 1 del; 2 mod

2003: Timing out lock in RestRequestCache stops the bot

Reviewed-by: erikj

-------------

PR: https://git.openjdk.org/skara/pull/1555

From erikj at openjdk.org  Tue Sep 12 19:34:18 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 12 Sep 2023 19:34:18 GMT
Subject: RFR: 2015: Initial run of PR IssueBot misses issue updates
In-Reply-To: <lOn0VGWDXULHVOGwO5UCsJbcYT5eAKHjFHZl3hNO8lE=.16041a2b-78e5-48ba-bd1a-75ff82dd8ebb@github.com>
References: <LJ64GotX59wc8kbx9OHncRvCqUgaw9XgLRZK7gtL5pY=.cb6a76e4-f4ee-418b-8d19-c4eb6a6b5cf0@github.com>
 <s6U_6UB2o11pwulXCWSS1zYqIbeoeC6peRyTGRKSTTM=.9f27ea11-28cf-4667-ad51-e6243203145c@github.com>
 <lOn0VGWDXULHVOGwO5UCsJbcYT5eAKHjFHZl3hNO8lE=.16041a2b-78e5-48ba-bd1a-75ff82dd8ebb@github.com>
Message-ID: <qF8sHZysk0Di8blPAAZhuB_CCs0Mx6924ZyObaSQjSQ=.44766aa2-b242-4778-994c-7f5bd0045f2a@github.com>

On Tue, 12 Sep 2023 17:40:55 GMT, Zhao Song <zsong at openjdk.org> wrote:

>> bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckWorkItem.java line 73:
>> 
>>> 71: 
>>> 72:     CheckWorkItem(PullRequestBot bot, String prId, Consumer<RuntimeException> errorHandler, ZonedDateTime triggerUpdatedAt,
>>> 73:                   boolean needsReadyCheck, boolean forceUpdate, boolean spawnedFromIssueBot, boolean initialRun) {
>> 
>> Having 4 booleans in the constructor is becoming really hard to read and understand. Perhaps we should introduce factory methods instead so we only allow for valid combinations of the booleans. Something like:
>> 
>> fromIssue
>> fromPr
>> initialRun
>> forceUpdate
>
> I was thinking that if we fix SKARA-2016 in the future, then `forceUpdate` would be removed. So three booleans is reasonable.

3 is already a lot, especially if certain combinations aren't actually valid. I was already thinking this constructor was bad before this change. 

When reading the source in intellij, it shows the parameter name at each call site, which alleviates some of the problem, but that isn't happening when reviewing on GitHub, or when merging using other tools.

>> bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckWorkItem.java line 232:
>> 
>>> 230:                         if (previousIssueMetadata.equals(currIssueMetadata) && expiresAt.isAfter(Instant.now())) {
>>> 231:                             log.finer("[Issue]Metadata with expiration time is still valid, not checking again");
>>> 232:                             return true;
>> 
>> I think this method would be easier to read if we kept all return `true`/`false` inside the conditional blocks. If we know we have a terminal state, lets be clear about it so the reader doesn't need to check the rest of the method.
>
> I removed `return true` here because we couldn't return early in this block. For the initial run case, `initialRun` would be true and `spawnedFromIssueBot` would be false. We need to check both issueMetaData and PRMetaData. 
> 
> But we could add some `return true` in `if (!spawnedFromIssueBot)` block.

Oh right, I get it now. I take back my comment.

-------------

PR Review Comment: https://git.openjdk.org/skara/pull/1554#discussion_r1323472623
PR Review Comment: https://git.openjdk.org/skara/pull/1554#discussion_r1323472999

From zsong at openjdk.org  Tue Sep 12 20:47:54 2023
From: zsong at openjdk.org (Zhao Song)
Date: Tue, 12 Sep 2023 20:47:54 GMT
Subject: RFR: 827: Copyright year differences can be regarded as a clean
 backport [v3]
In-Reply-To: <5ZE3i_OOIB5ReqCBjrz4Qxt2YtMAdheDogz_yKUF-HM=.74242645-8347-4fb7-9527-56ef7d0f17af@github.com>
References: <5ZE3i_OOIB5ReqCBjrz4Qxt2YtMAdheDogz_yKUF-HM=.74242645-8347-4fb7-9527-56ef7d0f17af@github.com>
Message-ID: <sFYhOP8V0dC3QV96HKAgcg8JDsg3tQFERXEZ00NIg2U=.d78f8fe6-b74c-4b7a-ab08-6e49f243a3af@github.com>

> As many users requested, when determining whether a backport is clean, our bot should ignore copyright year difference.

Zhao Song has updated the pull request incrementally with two additional commits since the last revision:

 - fix whitespace issue
 - add unit test

-------------

Changes:
  - all: https://git.openjdk.org/skara/pull/1556/files
  - new: https://git.openjdk.org/skara/pull/1556/files/0af301eb..bff1ad28

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=skara&pr=1556&range=02
 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1556&range=01-02

  Stats: 126 lines in 2 files changed: 116 ins; 7 del; 3 mod
  Patch: https://git.openjdk.org/skara/pull/1556.diff
  Fetch: git fetch https://git.openjdk.org/skara.git pull/1556/head:pull/1556

PR: https://git.openjdk.org/skara/pull/1556

From zsong at openjdk.org  Wed Sep 13 16:57:32 2023
From: zsong at openjdk.org (Zhao Song)
Date: Wed, 13 Sep 2023 16:57:32 GMT
Subject: RFR: 2015: Initial run of PR IssueBot misses issue updates [v2]
In-Reply-To: <LJ64GotX59wc8kbx9OHncRvCqUgaw9XgLRZK7gtL5pY=.cb6a76e4-f4ee-418b-8d19-c4eb6a6b5cf0@github.com>
References: <LJ64GotX59wc8kbx9OHncRvCqUgaw9XgLRZK7gtL5pY=.cb6a76e4-f4ee-418b-8d19-c4eb6a6b5cf0@github.com>
Message-ID: <MjGzefE_GngqZ-Sh7GYHY_eInG2cQzwmCaUsZHBN6Ro=.53373fdb-291c-4240-919a-94d57463e463@github.com>

> Currently, if pullRequestBot is down for more than 10 minutes and during that time, if users make changes to some issues, than the update activities would not trigger CheckWorkItem after the bot restarts.
> 
> To solve this problem, In this patch, after the bot restarts, in the initial run, pullRequestBot would make CheckWorkItem compare both prMetaData and issueMetaData.

Zhao Song has updated the pull request incrementally with one additional commit since the last revision:

  update

-------------

Changes:
  - all: https://git.openjdk.org/skara/pull/1554/files
  - new: https://git.openjdk.org/skara/pull/1554/files/ccf99dee..7b5fa066

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=skara&pr=1554&range=01
 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1554&range=00-01

  Stats: 51 lines in 5 files changed: 40 ins; 1 del; 10 mod
  Patch: https://git.openjdk.org/skara/pull/1554.diff
  Fetch: git fetch https://git.openjdk.org/skara.git pull/1554/head:pull/1554

PR: https://git.openjdk.org/skara/pull/1554

From duke at openjdk.org  Thu Sep 14 09:38:48 2023
From: duke at openjdk.org (Andrei Rybak)
Date: Thu, 14 Sep 2023 09:38:48 GMT
Subject: RFR: build: use included build instead of buildSrc
In-Reply-To: <TuMLzk81u9XwWLskkQ2KgF0cwdip7kbYdQEtBo1g-tc=.5566deb4-e0e0-4a25-a4d0-71a90311a3a4@github.com>
References: <TuMLzk81u9XwWLskkQ2KgF0cwdip7kbYdQEtBo1g-tc=.5566deb4-e0e0-4a25-a4d0-71a90311a3a4@github.com>
Message-ID: <s5uY2xeV7KAdK1sEZ6JWNW6ZUYP_0iytCDg5FIroWLA=.3f5d1e8c-a5bd-415b-8285-b623e00235dd@github.com>

On Wed, 10 Feb 2021 10:44:44 GMT, Erik Duveblad <ehelin at openjdk.org> wrote:

> Hi all,
> 
> please review this small patch that makes the build use "included builds" for Skara's Gradle plugins instead of the "buildSrc" feature of Gradle. The "buildSrc" feature doesn't play nice with Gradle's caching mechanism - any change to a file in the `buildSrc` directory invalidates the build cache. The solution is to just include the plugins using the `includeBuild` feature (the Gradle team is even thinking of making `buildSrc` an implicitly included build, see https://github.com/gradle/gradle/issues/2531).
> 
> Testing:
> - [x] `make images` on Linux x64
> - [x] `make test` on Linux x64
> 
> Thanks,
> Erik

build.gradle line 1:

> 1: /*

I've stumbled upon an outdated reference to `buildSrc` in the root `build.gradle`:


        // Force Gradle to load the JUnit Platform Launcher from the module-path, as
        // configured in buildSrc/.../ModulePlugin.java -- see SKARA-69 for details.
        testRuntimeOnly 'org.junit.platform:junit-platform-launcher:1.6.2'


https://github.com/openjdk/skara/pull/1004/files#diff-49a96e7eea8a94af862798a45174e6ac43eb4f8b4bd40759b5da63ba31ec3ef7L49-R62

-------------

PR Review Comment: https://git.openjdk.org/skara/pull/1004#discussion_r1325680367

From erikj at openjdk.org  Mon Sep 18 22:40:01 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 18 Sep 2023 22:40:01 GMT
Subject: RFR: 2015: Initial run of PR IssueBot misses issue updates [v2]
In-Reply-To: <MjGzefE_GngqZ-Sh7GYHY_eInG2cQzwmCaUsZHBN6Ro=.53373fdb-291c-4240-919a-94d57463e463@github.com>
References: <LJ64GotX59wc8kbx9OHncRvCqUgaw9XgLRZK7gtL5pY=.cb6a76e4-f4ee-418b-8d19-c4eb6a6b5cf0@github.com>
 <MjGzefE_GngqZ-Sh7GYHY_eInG2cQzwmCaUsZHBN6Ro=.53373fdb-291c-4240-919a-94d57463e463@github.com>
Message-ID: <XKN776XxqUwCa4RDrOdD_oPkk9CYOCK67IlHdondu4Q=.7e4bcf71-ab41-42ca-8fc3-95a53ea06498@github.com>

On Wed, 13 Sep 2023 16:57:32 GMT, Zhao Song <zsong at openjdk.org> wrote:

>> Currently, if pullRequestBot is down for more than 10 minutes and during that time, if users make changes to some issues, than the update activities would not trigger CheckWorkItem after the bot restarts.
>> 
>> To solve this problem, In this patch, after the bot restarts, in the initial run, pullRequestBot would make CheckWorkItem compare both prMetaData and issueMetaData.
>
> Zhao Song has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update

bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckWorkItem.java line 111:

> 109:      * Create Normal CheckWorkItem
> 110:      */
> 111:     public static CheckWorkItem normal(PullRequestBot bot, String prId, Consumer<RuntimeException> errorHandler, ZonedDateTime triggerUpdatedAt) {

Maybe call it `fromWorkItem`.

-------------

PR Review Comment: https://git.openjdk.org/skara/pull/1554#discussion_r1329349574

From erikj at openjdk.org  Mon Sep 18 22:43:05 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 18 Sep 2023 22:43:05 GMT
Subject: RFR: 827: Copyright year differences can be regarded as a clean
 backport [v3]
In-Reply-To: <sFYhOP8V0dC3QV96HKAgcg8JDsg3tQFERXEZ00NIg2U=.d78f8fe6-b74c-4b7a-ab08-6e49f243a3af@github.com>
References: <5ZE3i_OOIB5ReqCBjrz4Qxt2YtMAdheDogz_yKUF-HM=.74242645-8347-4fb7-9527-56ef7d0f17af@github.com>
 <sFYhOP8V0dC3QV96HKAgcg8JDsg3tQFERXEZ00NIg2U=.d78f8fe6-b74c-4b7a-ab08-6e49f243a3af@github.com>
Message-ID: <fpn3S520qu_hQvdLI-xgucfKKODu85A1D8jYzh6GLB8=.8a80e876-2a83-4ce8-b9e7-f02198cc4be3@github.com>

On Tue, 12 Sep 2023 20:47:54 GMT, Zhao Song <zsong at openjdk.org> wrote:

>> As many users requested, when determining whether a backport is clean, our bot should ignore copyright year difference.
>
> Zhao Song has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - fix whitespace issue
>  - add unit test

vcs/src/main/java/org/openjdk/skara/vcs/DiffComparator.java line 32:

> 30:     private static final Pattern COPYRIGHT_PATTERN = Pattern.compile("""
> 31:             -(.)*Copyright \\(c\\) (?:\\d|\\s|,)* Oracle and/or its affiliates\\. All rights reserved\\.
> 32:             \\+(.)*Copyright \\(c\\) (?:\\d|\\s|,)* Oracle and/or its affiliates\\. All rights reserved\\.

If the only difference between these lines is the first character, we should only need one line.
Suggestion:

            [-+](.)*Copyright \(c\) (?:\\d|\\s|,)* Oracle and/or its affiliates\. All rights reserved\.

-------------

PR Review Comment: https://git.openjdk.org/skara/pull/1556#discussion_r1329351931

From goetz.lindenmaier at sap.com  Tue Sep 19 07:56:24 2023
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Tue, 19 Sep 2023 07:56:24 +0000
Subject: Distinguish changes that require review in personal pull request
 overview
Message-ID: <PAXPR02MB8245B155F9DB612591CC29C0ECFAA@PAXPR02MB8245.eurprd02.prod.outlook.com>

Hi,

I have a proposal for a small improvement of
productivity:

I am using github.com/pulls as worklist for my daily todos.
With the new added "approval" label I now can see
in this list for which pull requests I requested approval, and, with
the "ready" label, whether I got the approval.

What I can not distinguish are changes that require
a review and those that got a review.  In both cases
there is the red "rfr" label.  Thus, I daily open all the
pull requests and check whether they got a review.

Is it possible to add a label that indicates that a pull
request has been reviewed as required?
Maybe the "rfr" label could be changed in colour
(grey?) once there is a sufficient amount of reviews?

Then I can see in the list which pull request are
ready for the approval request.
Or did a miss something and this is already possible?

Best regards,
  Goetz.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/skara-dev/attachments/20230919/113a5304/attachment.htm>

From erik.joelsson at oracle.com  Tue Sep 19 13:27:03 2023
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Tue, 19 Sep 2023 06:27:03 -0700
Subject: Distinguish changes that require review in personal pull request
 overview
In-Reply-To: <PAXPR02MB8245B155F9DB612591CC29C0ECFAA@PAXPR02MB8245.eurprd02.prod.outlook.com>
References: <PAXPR02MB8245B155F9DB612591CC29C0ECFAA@PAXPR02MB8245.eurprd02.prod.outlook.com>
Message-ID: <9aafbe7f-2c04-cf94-5ec7-f033ca151c5d@oracle.com>

Hello Goetz,

I think this suggestion makes sense. Before support for the approval 
process, then the "ready" label more or less corresponded to a reviewed 
PR, but since we now have multiple steps to pass before a PR is ready, 
there isn't a clear label indication for each step. Perhaps we should 
adopt a general pattern of adding a label for each progress step as they 
get fulfilled (e.g. "reviewed", "approved")? Changing color of a label 
probably won't work. I think the colors are configured on a repo level. 
Also you can't filter on a label color.

Could you file this request as an enhancement?

/Erik

On 9/19/23 00:56, Lindenmaier, Goetz wrote:
>
> Hi,
>
> I have a proposal for a small improvement of
>
> productivity:
>
> I am using github.com/pulls as worklist for my daily todos.
>
> With the new added ?approval? label I now can see
>
> in this list for which pull requests I requested approval, and, with
>
> the ?ready? label, whether I got the approval.
>
> What I can not distinguish are changes that require
>
> a review and those that got a review.? In both cases
>
> there is the red ?rfr? label.? Thus, I daily open all the
>
> pull requests and check whether they got a review.
>
> Is it possible to add a label that indicates that a pull
>
> request has been reviewed as required?
>
> Maybe the ?rfr? label could be changed in colour
>
> (grey?) once there is a sufficient amount of reviews?
>
> Then I can see in the list which pull request are
>
> ready for the approval request.
>
> Or did a miss something and this is already possible?
>
> Best regards,
>
> ? Goetz.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/skara-dev/attachments/20230919/710b05c2/attachment-0001.htm>

From goetz.lindenmaier at sap.com  Wed Sep 20 06:48:57 2023
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Wed, 20 Sep 2023 06:48:57 +0000
Subject: Distinguish changes that require review in personal pull request
 overview
In-Reply-To: <9aafbe7f-2c04-cf94-5ec7-f033ca151c5d@oracle.com>
References: <PAXPR02MB8245B155F9DB612591CC29C0ECFAA@PAXPR02MB8245.eurprd02.prod.outlook.com>
 <9aafbe7f-2c04-cf94-5ec7-f033ca151c5d@oracle.com>
Message-ID: <PAXPR02MB8245AB55492D0B228A6E525AECF9A@PAXPR02MB8245.eurprd02.prod.outlook.com>

Hi,

I opened an issue: [SKARA-2032] Distinguish changes that require review in personal pull request overview - Java Bug System (openjdk.org)<https://bugs.openjdk.org/browse/SKARA-2032>

Thanks for considering this!
Best regards,
  Goetz.

From: erik.joelsson at oracle.com <erik.joelsson at oracle.com>
Sent: Tuesday, September 19, 2023 3:27 PM
To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; skara-dev at openjdk.org
Subject: Re: Distinguish changes that require review in personal pull request overview


Hello Goetz,

I think this suggestion makes sense. Before support for the approval process, then the "ready" label more or less corresponded to a reviewed PR, but since we now have multiple steps to pass before a PR is ready, there isn't a clear label indication for each step. Perhaps we should adopt a general pattern of adding a label for each progress step as they get fulfilled (e.g. "reviewed", "approved")? Changing color of a label probably won't work. I think the colors are configured on a repo level. Also you can't filter on a label color.

Could you file this request as an enhancement?

/Erik
On 9/19/23 00:56, Lindenmaier, Goetz wrote:
Hi,

I have a proposal for a small improvement of
productivity:

I am using github.com/pulls as worklist for my daily todos.
With the new added ?approval? label I now can see
in this list for which pull requests I requested approval, and, with
the ?ready? label, whether I got the approval.

What I can not distinguish are changes that require
a review and those that got a review.  In both cases
there is the red ?rfr? label.  Thus, I daily open all the
pull requests and check whether they got a review.

Is it possible to add a label that indicates that a pull
request has been reviewed as required?
Maybe the ?rfr? label could be changed in colour
(grey?) once there is a sufficient amount of reviews?

Then I can see in the list which pull request are
ready for the approval request.
Or did a miss something and this is already possible?

Best regards,
  Goetz.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/skara-dev/attachments/20230920/33c1b01a/attachment.htm>

From zsong at openjdk.org  Wed Sep 20 16:32:24 2023
From: zsong at openjdk.org (Zhao Song)
Date: Wed, 20 Sep 2023 16:32:24 GMT
Subject: RFR: 827: Copyright year differences can be regarded as a clean
 backport [v3]
In-Reply-To: <fpn3S520qu_hQvdLI-xgucfKKODu85A1D8jYzh6GLB8=.8a80e876-2a83-4ce8-b9e7-f02198cc4be3@github.com>
References: <5ZE3i_OOIB5ReqCBjrz4Qxt2YtMAdheDogz_yKUF-HM=.74242645-8347-4fb7-9527-56ef7d0f17af@github.com>
 <sFYhOP8V0dC3QV96HKAgcg8JDsg3tQFERXEZ00NIg2U=.d78f8fe6-b74c-4b7a-ab08-6e49f243a3af@github.com>
 <fpn3S520qu_hQvdLI-xgucfKKODu85A1D8jYzh6GLB8=.8a80e876-2a83-4ce8-b9e7-f02198cc4be3@github.com>
Message-ID: <SdG93WDAPOFl7HXyJlHLOnl3dpx1pXZu5DvvarLjfVM=.1f5875ff-c672-440c-8bde-8b724e5529b1@github.com>

On Mon, 18 Sep 2023 22:39:58 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Zhao Song has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - fix whitespace issue
>>  - add unit test
>
> vcs/src/main/java/org/openjdk/skara/vcs/DiffComparator.java line 32:
> 
>> 30:     private static final Pattern COPYRIGHT_PATTERN = Pattern.compile("""
>> 31:             -(.)*Copyright \\(c\\) (?:\\d|\\s|,)* Oracle and/or its affiliates\\. All rights reserved\\.
>> 32:             \\+(.)*Copyright \\(c\\) (?:\\d|\\s|,)* Oracle and/or its affiliates\\. All rights reserved\\.
> 
> If the only difference between these lines is the first character, we should only need one line.
> Suggestion:
> 
>             [-+](.)*Copyright \(c\) (?:\\d|\\s|,)* Oracle and/or its affiliates\. All rights reserved\.

But if we only use one line like you suggested, this will introduce a problem. In the backport PR, the user could make any change to the first line of copyright.  For example, the user could change the first line to "Random line" and the backport pr would still be considered as clean backport.  

Because the hunk will be 

@@ -2,1 +2,1 @@
- * Copyright (c) 2020, 2023, Oracle and/or its affiliates. All rights reserved.
+ * Random line.

and this hunk would match the regex pattern and be filtered out.


I think we still need two lines to make sure the user **only** changes the copyright years.

-------------

PR Review Comment: https://git.openjdk.org/skara/pull/1556#discussion_r1331905437

From zsong at openjdk.org  Wed Sep 20 16:42:37 2023
From: zsong at openjdk.org (Zhao Song)
Date: Wed, 20 Sep 2023 16:42:37 GMT
Subject: RFR: 2015: Initial run of PR IssueBot misses issue updates [v3]
In-Reply-To: <LJ64GotX59wc8kbx9OHncRvCqUgaw9XgLRZK7gtL5pY=.cb6a76e4-f4ee-418b-8d19-c4eb6a6b5cf0@github.com>
References: <LJ64GotX59wc8kbx9OHncRvCqUgaw9XgLRZK7gtL5pY=.cb6a76e4-f4ee-418b-8d19-c4eb6a6b5cf0@github.com>
Message-ID: <CfA2XQzRhCrRi2zv6EdKZ80JuDRUWjZBw66eg3xrjHw=.b3afc60b-6620-4ff2-968e-51ff6fac3b85@github.com>

> Currently, if pullRequestBot is down for more than 10 minutes and during that time, if users make changes to some issues, than the update activities would not trigger CheckWorkItem after the bot restarts.
> 
> To solve this problem, In this patch, after the bot restarts, in the initial run, pullRequestBot would make CheckWorkItem compare both prMetaData and issueMetaData.

Zhao Song has updated the pull request incrementally with one additional commit since the last revision:

  rename method

-------------

Changes:
  - all: https://git.openjdk.org/skara/pull/1554/files
  - new: https://git.openjdk.org/skara/pull/1554/files/7b5fa066..652f970d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=skara&pr=1554&range=02
 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1554&range=01-02

  Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/skara/pull/1554.diff
  Fetch: git fetch https://git.openjdk.org/skara.git pull/1554/head:pull/1554

PR: https://git.openjdk.org/skara/pull/1554

From zsong at openjdk.org  Wed Sep 20 16:42:38 2023
From: zsong at openjdk.org (Zhao Song)
Date: Wed, 20 Sep 2023 16:42:38 GMT
Subject: RFR: 2015: Initial run of PR IssueBot misses issue updates [v2]
In-Reply-To: <XKN776XxqUwCa4RDrOdD_oPkk9CYOCK67IlHdondu4Q=.7e4bcf71-ab41-42ca-8fc3-95a53ea06498@github.com>
References: <LJ64GotX59wc8kbx9OHncRvCqUgaw9XgLRZK7gtL5pY=.cb6a76e4-f4ee-418b-8d19-c4eb6a6b5cf0@github.com>
 <MjGzefE_GngqZ-Sh7GYHY_eInG2cQzwmCaUsZHBN6Ro=.53373fdb-291c-4240-919a-94d57463e463@github.com>
 <XKN776XxqUwCa4RDrOdD_oPkk9CYOCK67IlHdondu4Q=.7e4bcf71-ab41-42ca-8fc3-95a53ea06498@github.com>
Message-ID: <8qU-Hi8q6EpwSLqxVw0puTDryPo5Pchan1UZWKGSGGI=.95992546-c4a7-4680-a77b-0083a3dc82e1@github.com>

On Mon, 18 Sep 2023 22:35:28 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Zhao Song has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update
>
> bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckWorkItem.java line 111:
> 
>> 109:      * Create Normal CheckWorkItem
>> 110:      */
>> 111:     public static CheckWorkItem normal(PullRequestBot bot, String prId, Consumer<RuntimeException> errorHandler, ZonedDateTime triggerUpdatedAt) {
> 
> Maybe call it `fromWorkItem`.

Sure

-------------

PR Review Comment: https://git.openjdk.org/skara/pull/1554#discussion_r1331914206

From erikj at openjdk.org  Wed Sep 20 21:04:45 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 20 Sep 2023 21:04:45 GMT
Subject: RFR: 827: Copyright year differences can be regarded as a clean
 backport [v3]
In-Reply-To: <SdG93WDAPOFl7HXyJlHLOnl3dpx1pXZu5DvvarLjfVM=.1f5875ff-c672-440c-8bde-8b724e5529b1@github.com>
References: <5ZE3i_OOIB5ReqCBjrz4Qxt2YtMAdheDogz_yKUF-HM=.74242645-8347-4fb7-9527-56ef7d0f17af@github.com>
 <sFYhOP8V0dC3QV96HKAgcg8JDsg3tQFERXEZ00NIg2U=.d78f8fe6-b74c-4b7a-ab08-6e49f243a3af@github.com>
 <fpn3S520qu_hQvdLI-xgucfKKODu85A1D8jYzh6GLB8=.8a80e876-2a83-4ce8-b9e7-f02198cc4be3@github.com>
 <SdG93WDAPOFl7HXyJlHLOnl3dpx1pXZu5DvvarLjfVM=.1f5875ff-c672-440c-8bde-8b724e5529b1@github.com>
Message-ID: <P2ebYzgvf2iO8io1l0gviYlPJLwI-eHrIOPs0yoKNic=.40e37168-f763-4483-af12-36cc2aae069e@github.com>

On Wed, 20 Sep 2023 16:30:01 GMT, Zhao Song <zsong at openjdk.org> wrote:

>> vcs/src/main/java/org/openjdk/skara/vcs/DiffComparator.java line 32:
>> 
>>> 30:     private static final Pattern COPYRIGHT_PATTERN = Pattern.compile("""
>>> 31:             -(.)*Copyright \\(c\\) (?:\\d|\\s|,)* Oracle and/or its affiliates\\. All rights reserved\\.
>>> 32:             \\+(.)*Copyright \\(c\\) (?:\\d|\\s|,)* Oracle and/or its affiliates\\. All rights reserved\\.
>> 
>> If the only difference between these lines is the first character, we should only need one line.
>> Suggestion:
>> 
>>             [-+](.)*Copyright \(c\) (?:\\d|\\s|,)* Oracle and/or its affiliates\. All rights reserved\.
>
> But if we only use one line like you suggested, this will introduce a problem. In the backport PR, the user could make any change to the first line of copyright.  For example, the user could change the first line to "Random line" and the backport pr would still be considered as clean backport.  
> 
> Because the hunk will be 
> 
> @@ -2,1 +2,1 @@
> - * Copyright (c) 2020, 2023, Oracle and/or its affiliates. All rights reserved.
> + * Random line.
> 
> and this hunk would match the regex pattern and be filtered out.
> 
> 
> I think we still need two lines to make sure the user **only** changes the copyright years.

Ah I get it now, this is a multiline pattern, not an either this line or that line. I thought you needed to tell something in the Java regex API that it was multiline, but maybe you don't if the pattern has a newline in it?

-------------

PR Review Comment: https://git.openjdk.org/skara/pull/1556#discussion_r1332180231

From erikj at openjdk.org  Wed Sep 20 21:08:57 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 20 Sep 2023 21:08:57 GMT
Subject: RFR: 827: Copyright year differences can be regarded as a clean
 backport [v3]
In-Reply-To: <sFYhOP8V0dC3QV96HKAgcg8JDsg3tQFERXEZ00NIg2U=.d78f8fe6-b74c-4b7a-ab08-6e49f243a3af@github.com>
References: <5ZE3i_OOIB5ReqCBjrz4Qxt2YtMAdheDogz_yKUF-HM=.74242645-8347-4fb7-9527-56ef7d0f17af@github.com>
 <sFYhOP8V0dC3QV96HKAgcg8JDsg3tQFERXEZ00NIg2U=.d78f8fe6-b74c-4b7a-ab08-6e49f243a3af@github.com>
Message-ID: <hpVH99tBuWnWkdqAVWVz0zbRUAYSmGkwQtjCdOYbeV4=.7b81ae64-44ff-4b8b-a6a6-e1a8a6ba8551@github.com>

On Tue, 12 Sep 2023 20:47:54 GMT, Zhao Song <zsong at openjdk.org> wrote:

>> As many users requested, when determining whether a backport is clean, our bot should ignore copyright year difference.
>
> Zhao Song has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - fix whitespace issue
>  - add unit test

Marked as reviewed by erikj (Lead).

-------------

PR Review: https://git.openjdk.org/skara/pull/1556#pullrequestreview-1636508881

From erikj at openjdk.org  Wed Sep 20 21:08:57 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 20 Sep 2023 21:08:57 GMT
Subject: RFR: 827: Copyright year differences can be regarded as a clean
 backport [v3]
In-Reply-To: <P2ebYzgvf2iO8io1l0gviYlPJLwI-eHrIOPs0yoKNic=.40e37168-f763-4483-af12-36cc2aae069e@github.com>
References: <5ZE3i_OOIB5ReqCBjrz4Qxt2YtMAdheDogz_yKUF-HM=.74242645-8347-4fb7-9527-56ef7d0f17af@github.com>
 <sFYhOP8V0dC3QV96HKAgcg8JDsg3tQFERXEZ00NIg2U=.d78f8fe6-b74c-4b7a-ab08-6e49f243a3af@github.com>
 <fpn3S520qu_hQvdLI-xgucfKKODu85A1D8jYzh6GLB8=.8a80e876-2a83-4ce8-b9e7-f02198cc4be3@github.com>
 <SdG93WDAPOFl7HXyJlHLOnl3dpx1pXZu5DvvarLjfVM=.1f5875ff-c672-440c-8bde-8b724e5529b1@github.com>
 <P2ebYzgvf2iO8io1l0gviYlPJLwI-eHrIOPs0yoKNic=.40e37168-f763-4483-af12-36cc2aae069e@github.com>
Message-ID: <lQoon4TSy4WBRFcmonMMTurtPiltFhZvCnsGUnuLhIo=.9e73c847-2a76-4889-8d30-e46bad42c6dc@github.com>

On Wed, 20 Sep 2023 21:02:23 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> But if we only use one line like you suggested, this will introduce a problem. In the backport PR, the user could make any change to the first line of copyright.  For example, the user could change the first line to "Random line" and the backport pr would still be considered as clean backport.  
>> 
>> Because the hunk will be 
>> 
>> @@ -2,1 +2,1 @@
>> - * Copyright (c) 2020, 2023, Oracle and/or its affiliates. All rights reserved.
>> + * Random line.
>> 
>> and this hunk would match the regex pattern and be filtered out.
>> 
>> 
>> I think we still need two lines to make sure the user **only** changes the copyright years.
>
> Ah I get it now, this is a multiline pattern, not an either this line or that line. I thought you needed to tell something in the Java regex API that it was multiline, but maybe you don't if the pattern has a newline in it?

I think this should work as is. The `Pattern.MULTILINE` and `Pattern.DOTALL` are used to change the meaning of `^`, `$` and `.` respectively to work differently with newlines. I don't think that's relevant for this pattern which contains an explicit newline. Sorry for the confusion!

-------------

PR Review Comment: https://git.openjdk.org/skara/pull/1556#discussion_r1332183996

From zsong at openjdk.org  Wed Sep 20 21:08:57 2023
From: zsong at openjdk.org (Zhao Song)
Date: Wed, 20 Sep 2023 21:08:57 GMT
Subject: RFR: 827: Copyright year differences can be regarded as a clean
 backport [v3]
In-Reply-To: <lQoon4TSy4WBRFcmonMMTurtPiltFhZvCnsGUnuLhIo=.9e73c847-2a76-4889-8d30-e46bad42c6dc@github.com>
References: <5ZE3i_OOIB5ReqCBjrz4Qxt2YtMAdheDogz_yKUF-HM=.74242645-8347-4fb7-9527-56ef7d0f17af@github.com>
 <sFYhOP8V0dC3QV96HKAgcg8JDsg3tQFERXEZ00NIg2U=.d78f8fe6-b74c-4b7a-ab08-6e49f243a3af@github.com>
 <fpn3S520qu_hQvdLI-xgucfKKODu85A1D8jYzh6GLB8=.8a80e876-2a83-4ce8-b9e7-f02198cc4be3@github.com>
 <SdG93WDAPOFl7HXyJlHLOnl3dpx1pXZu5DvvarLjfVM=.1f5875ff-c672-440c-8bde-8b724e5529b1@github.com>
 <P2ebYzgvf2iO8io1l0gviYlPJLwI-eHrIOPs0yoKNic=.40e37168-f763-4483-af12-36cc2aae069e@github.com>
 <lQoon4TSy4WBRFcmonMMTurtPiltFhZvCnsGUnuLhIo=.9e73c847-2a76-4889-8d30-e46bad42c6dc@github.com>
Message-ID: <oEhnP5zQXwN2225Sv3GChP6_WkslziMqSOtn8IR-Tb8=.d8868f98-ff0e-4a68-90c6-1119e8d2e39f@github.com>

On Wed, 20 Sep 2023 21:05:50 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Ah I get it now, this is a multiline pattern, not an either this line or that line. I thought you needed to tell something in the Java regex API that it was multiline, but maybe you don't if the pattern has a newline in it?
>
> I think this should work as is. The `Pattern.MULTILINE` and `Pattern.DOTALL` are used to change the meaning of `^`, `$` and `.` respectively to work differently with newlines. I don't think that's relevant for this pattern which contains an explicit newline. Sorry for the confusion!

I think having a newline in the pattern is enough, so we don't need to tell the java regex api that it is a multiline pattern.

-------------

PR Review Comment: https://git.openjdk.org/skara/pull/1556#discussion_r1332184795

From erikj at openjdk.org  Wed Sep 20 21:09:42 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 20 Sep 2023 21:09:42 GMT
Subject: RFR: 2015: Initial run of PR IssueBot misses issue updates [v3]
In-Reply-To: <CfA2XQzRhCrRi2zv6EdKZ80JuDRUWjZBw66eg3xrjHw=.b3afc60b-6620-4ff2-968e-51ff6fac3b85@github.com>
References: <LJ64GotX59wc8kbx9OHncRvCqUgaw9XgLRZK7gtL5pY=.cb6a76e4-f4ee-418b-8d19-c4eb6a6b5cf0@github.com>
 <CfA2XQzRhCrRi2zv6EdKZ80JuDRUWjZBw66eg3xrjHw=.b3afc60b-6620-4ff2-968e-51ff6fac3b85@github.com>
Message-ID: <jW2fNBaX7HiN5PuA67BdwP8ZpukY4iQUMBdltmWj6K0=.22932d84-83e9-4df5-b8b8-3948471db836@github.com>

On Wed, 20 Sep 2023 16:42:37 GMT, Zhao Song <zsong at openjdk.org> wrote:

>> Currently, if pullRequestBot is down for more than 10 minutes and during that time, if users make changes to some issues, than the update activities would not trigger CheckWorkItem after the bot restarts.
>> 
>> To solve this problem, In this patch, after the bot restarts, in the initial run, pullRequestBot would make CheckWorkItem compare both prMetaData and issueMetaData.
>
> Zhao Song has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rename method

Marked as reviewed by erikj (Lead).

-------------

PR Review: https://git.openjdk.org/skara/pull/1554#pullrequestreview-1636510372

From zsong at openjdk.org  Wed Sep 20 21:19:29 2023
From: zsong at openjdk.org (Zhao Song)
Date: Wed, 20 Sep 2023 21:19:29 GMT
Subject: RFR: 2015: Initial run of PR IssueBot misses issue updates [v3]
In-Reply-To: <CfA2XQzRhCrRi2zv6EdKZ80JuDRUWjZBw66eg3xrjHw=.b3afc60b-6620-4ff2-968e-51ff6fac3b85@github.com>
References: <LJ64GotX59wc8kbx9OHncRvCqUgaw9XgLRZK7gtL5pY=.cb6a76e4-f4ee-418b-8d19-c4eb6a6b5cf0@github.com>
 <CfA2XQzRhCrRi2zv6EdKZ80JuDRUWjZBw66eg3xrjHw=.b3afc60b-6620-4ff2-968e-51ff6fac3b85@github.com>
Message-ID: <ipAr1t5MBQ3sNCLVfoBWMJVumCw2pLZKesTW5zgt1-I=.9c213d72-5c2e-47ed-8e69-b2ce7d109a28@github.com>

On Wed, 20 Sep 2023 16:42:37 GMT, Zhao Song <zsong at openjdk.org> wrote:

>> Currently, if pullRequestBot is down for more than 10 minutes and during that time, if users make changes to some issues, than the update activities would not trigger CheckWorkItem after the bot restarts.
>> 
>> To solve this problem, In this patch, after the bot restarts, in the initial run, pullRequestBot would make CheckWorkItem compare both prMetaData and issueMetaData.
>
> Zhao Song has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rename method

Thanks for the review!

-------------

PR Comment: https://git.openjdk.org/skara/pull/1554#issuecomment-1728438392

From zsong at openjdk.org  Wed Sep 20 21:19:29 2023
From: zsong at openjdk.org (Zhao Song)
Date: Wed, 20 Sep 2023 21:19:29 GMT
Subject: Integrated: 2015: Initial run of PR IssueBot misses issue updates
In-Reply-To: <LJ64GotX59wc8kbx9OHncRvCqUgaw9XgLRZK7gtL5pY=.cb6a76e4-f4ee-418b-8d19-c4eb6a6b5cf0@github.com>
References: <LJ64GotX59wc8kbx9OHncRvCqUgaw9XgLRZK7gtL5pY=.cb6a76e4-f4ee-418b-8d19-c4eb6a6b5cf0@github.com>
Message-ID: <MBtHvARorty3hQdLKAio8zO3cP26RdXagZKrF-FezDY=.88bdad6c-a639-431c-a50a-daf91bbf996f@github.com>

On Wed, 6 Sep 2023 18:19:19 GMT, Zhao Song <zsong at openjdk.org> wrote:

> Currently, if pullRequestBot is down for more than 10 minutes and during that time, if users make changes to some issues, than the update activities would not trigger CheckWorkItem after the bot restarts.
> 
> To solve this problem, In this patch, after the bot restarts, in the initial run, pullRequestBot would make CheckWorkItem compare both prMetaData and issueMetaData.

This pull request has now been integrated.

Changeset: ef81acbb
Author:    Zhao Song <zsong at openjdk.org>
URL:       https://git.openjdk.org/skara/commit/ef81acbbe2cf97c6d56cc0b765e4b2bb9acc75a5
Stats:     68 lines in 5 files changed: 38 ins; 4 del; 26 mod

2015: Initial run of PR IssueBot misses issue updates

Reviewed-by: erikj

-------------

PR: https://git.openjdk.org/skara/pull/1554

From zsong at openjdk.org  Wed Sep 20 21:19:51 2023
From: zsong at openjdk.org (Zhao Song)
Date: Wed, 20 Sep 2023 21:19:51 GMT
Subject: RFR: 827: Copyright year differences can be regarded as a clean
 backport [v3]
In-Reply-To: <sFYhOP8V0dC3QV96HKAgcg8JDsg3tQFERXEZ00NIg2U=.d78f8fe6-b74c-4b7a-ab08-6e49f243a3af@github.com>
References: <5ZE3i_OOIB5ReqCBjrz4Qxt2YtMAdheDogz_yKUF-HM=.74242645-8347-4fb7-9527-56ef7d0f17af@github.com>
 <sFYhOP8V0dC3QV96HKAgcg8JDsg3tQFERXEZ00NIg2U=.d78f8fe6-b74c-4b7a-ab08-6e49f243a3af@github.com>
Message-ID: <TTWcyumW3m-tZNaNQTwko3vVtrawrWeuKO0OOunSm4g=.3ed49234-08cf-4b22-992e-39179f7825ae@github.com>

On Tue, 12 Sep 2023 20:47:54 GMT, Zhao Song <zsong at openjdk.org> wrote:

>> As many users requested, when determining whether a backport is clean, our bot should ignore copyright year difference.
>
> Zhao Song has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - fix whitespace issue
>  - add unit test

Thanks for the review!

-------------

PR Comment: https://git.openjdk.org/skara/pull/1556#issuecomment-1728438813

From zsong at openjdk.org  Wed Sep 20 21:19:51 2023
From: zsong at openjdk.org (Zhao Song)
Date: Wed, 20 Sep 2023 21:19:51 GMT
Subject: Integrated: 827: Copyright year differences can be regarded as a clean
 backport
In-Reply-To: <5ZE3i_OOIB5ReqCBjrz4Qxt2YtMAdheDogz_yKUF-HM=.74242645-8347-4fb7-9527-56ef7d0f17af@github.com>
References: <5ZE3i_OOIB5ReqCBjrz4Qxt2YtMAdheDogz_yKUF-HM=.74242645-8347-4fb7-9527-56ef7d0f17af@github.com>
Message-ID: <hxzx4V4jAHrtZwEYtXhoE7Gm8VZLwGD1eBLDuPIex10=.c8d57455-386c-4461-bc5b-f0ad0b68ee6a@github.com>

On Thu, 7 Sep 2023 21:16:52 GMT, Zhao Song <zsong at openjdk.org> wrote:

> As many users requested, when determining whether a backport is clean, our bot should ignore copyright year difference.

This pull request has now been integrated.

Changeset: 3f59384a
Author:    Zhao Song <zsong at openjdk.org>
URL:       https://git.openjdk.org/skara/commit/3f59384a6e119e420e9a11fe7158b2960aa826d6
Stats:     163 lines in 4 files changed: 156 ins; 4 del; 3 mod

827: Copyright year differences can be regarded as a clean backport

Reviewed-by: erikj

-------------

PR: https://git.openjdk.org/skara/pull/1556

From erikj at openjdk.org  Thu Sep 21 14:47:29 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 21 Sep 2023 14:47:29 GMT
Subject: RFR: 2035: [GHA] Update checkout action to v4
Message-ID: <GAmh_wV7tj1m7CMRw1QNL1RDrNOBu_K4DapxWNNCyAw=.4d487df5-7b20-4cc2-a548-398d6ff1da5d@github.com>

Update the GitHub checkout action to v4 (latest). This was recently done in the JDK repositories.

-------------

Commit messages:
 - SKARA-2035

Changes: https://git.openjdk.org/skara/pull/1557/files
 Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1557&range=00
  Issue: https://bugs.openjdk.org/browse/SKARA-2035
  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/skara/pull/1557.diff
  Fetch: git fetch https://git.openjdk.org/skara.git pull/1557/head:pull/1557

PR: https://git.openjdk.org/skara/pull/1557

From ihse at openjdk.org  Thu Sep 21 15:02:57 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 21 Sep 2023 15:02:57 GMT
Subject: RFR: 2035: [GHA] Update checkout action to v4
In-Reply-To: <GAmh_wV7tj1m7CMRw1QNL1RDrNOBu_K4DapxWNNCyAw=.4d487df5-7b20-4cc2-a548-398d6ff1da5d@github.com>
References: <GAmh_wV7tj1m7CMRw1QNL1RDrNOBu_K4DapxWNNCyAw=.4d487df5-7b20-4cc2-a548-398d6ff1da5d@github.com>
Message-ID: <R_UYRbtA6GSDKOF3d2Ozc0TcySntLJVmD43EkeWWjRU=.b0421292-30f1-4b35-8d42-daa8c44eac30@github.com>

On Thu, 21 Sep 2023 14:43:11 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> Update the GitHub checkout action to v4 (latest). This was recently done in the JDK repositories.

Marked as reviewed by ihse (Reviewer).

-------------

PR Review: https://git.openjdk.org/skara/pull/1557#pullrequestreview-1638082027

From zsong at openjdk.org  Thu Sep 21 16:37:44 2023
From: zsong at openjdk.org (Zhao Song)
Date: Thu, 21 Sep 2023 16:37:44 GMT
Subject: RFR: 2035: [GHA] Update checkout action to v4
In-Reply-To: <GAmh_wV7tj1m7CMRw1QNL1RDrNOBu_K4DapxWNNCyAw=.4d487df5-7b20-4cc2-a548-398d6ff1da5d@github.com>
References: <GAmh_wV7tj1m7CMRw1QNL1RDrNOBu_K4DapxWNNCyAw=.4d487df5-7b20-4cc2-a548-398d6ff1da5d@github.com>
Message-ID: <koOmbP9vPykYw0n6b3X7805rTnlkGsmXV7UQtrrd0q8=.ead352a9-ee95-4c67-9c79-61021e1dca51@github.com>

On Thu, 21 Sep 2023 14:43:11 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> Update the GitHub checkout action to v4 (latest). This was recently done in the JDK repositories.

Marked as reviewed by zsong (Reviewer).

-------------

PR Review: https://git.openjdk.org/skara/pull/1557#pullrequestreview-1638287951

From erikj at openjdk.org  Thu Sep 21 16:56:43 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 21 Sep 2023 16:56:43 GMT
Subject: Integrated: 2035: [GHA] Update checkout action to v4
In-Reply-To: <GAmh_wV7tj1m7CMRw1QNL1RDrNOBu_K4DapxWNNCyAw=.4d487df5-7b20-4cc2-a548-398d6ff1da5d@github.com>
References: <GAmh_wV7tj1m7CMRw1QNL1RDrNOBu_K4DapxWNNCyAw=.4d487df5-7b20-4cc2-a548-398d6ff1da5d@github.com>
Message-ID: <PJzijmuMaweBRdJyJCKNctWyEN38rjLoRyGbbrwik5o=.802f248d-830f-4cf4-ac11-9270dda68e27@github.com>

On Thu, 21 Sep 2023 14:43:11 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> Update the GitHub checkout action to v4 (latest). This was recently done in the JDK repositories.

This pull request has now been integrated.

Changeset: 1f4c4ed4
Author:    Erik Joelsson <erikj at openjdk.org>
URL:       https://git.openjdk.org/skara/commit/1f4c4ed47bba333beaf2e0f49084675e6435985c
Stats:     4 lines in 1 file changed: 0 ins; 0 del; 4 mod

2035: [GHA] Update checkout action to v4

Reviewed-by: ihse, zsong

-------------

PR: https://git.openjdk.org/skara/pull/1557

From zsong at openjdk.org  Fri Sep 22 00:54:21 2023
From: zsong at openjdk.org (Zhao Song)
Date: Fri, 22 Sep 2023 00:54:21 GMT
Subject: RFR: 2037: Change the order of bots in PullRequestBotFactory
Message-ID: <Y6nTJvX2h1kF-_38RFVCVHX4_HTCwfCAxzlv6bKOs7U=.2f2ff471-e821-42a1-ba90-29636dae2e97@github.com>

Today, when restarting the bot, I found that the IssueBot was down for a long time(about 30 minutes), and then I realized that in PullRequestBotFactory, we created all pullRequestBots first, then CSRIssueBots, and IssueBots last. 

After the bot is restarted, the botRunner would run all pullRequestBots first and we have a lot of pullRequestBots, so it will take a lot of time. And if users make changes to issues in JBS during this interval, the IssueBot may not be able to get all updated issues. It's really bad. 

To solve this problem, we could to reverse the order of bots in PullRequestBotFactory, therefore we could make sure IssueBot will be run firstly.

-------------

Commit messages:
 - override replaces
 - SKARA-2037

Changes: https://git.openjdk.org/skara/pull/1558/files
 Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1558&range=00
  Issue: https://bugs.openjdk.org/browse/SKARA-2037
  Stats: 14 lines in 2 files changed: 14 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/skara/pull/1558.diff
  Fetch: git fetch https://git.openjdk.org/skara.git pull/1558/head:pull/1558

PR: https://git.openjdk.org/skara/pull/1558

From ihse at openjdk.org  Fri Sep 22 07:50:21 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 22 Sep 2023 07:50:21 GMT
Subject: RFR: 2037: Change the order of bots in PullRequestBotFactory
In-Reply-To: <Y6nTJvX2h1kF-_38RFVCVHX4_HTCwfCAxzlv6bKOs7U=.2f2ff471-e821-42a1-ba90-29636dae2e97@github.com>
References: <Y6nTJvX2h1kF-_38RFVCVHX4_HTCwfCAxzlv6bKOs7U=.2f2ff471-e821-42a1-ba90-29636dae2e97@github.com>
Message-ID: <IudW7Jc8M48OwVzLWCfAV2hFj8iLU0Dq6d4Kq6dp1TI=.630277a1-8fd3-4c98-aff1-61c9a8547530@github.com>

On Thu, 21 Sep 2023 21:16:17 GMT, Zhao Song <zsong at openjdk.org> wrote:

> Today, when restarting the bot, I found that the IssueBot was down for a long time(about 30 minutes), and then I realized that in PullRequestBotFactory, we created all pullRequestBots first, then CSRIssueBots, and IssueBots last. 
> 
> After the bot is restarted, the botRunner would run all pullRequestBots first and we have a lot of pullRequestBots, so it will take a lot of time. And if users make changes to issues in JBS during this interval, the IssueBot may not be able to get all updated issues. It's really bad. 
> 
> To solve this problem, we could to reverse the order of bots in PullRequestBotFactory, therefore we could make sure IssueBot will be run firstly.

So how long does it typically take for the IssueBots to finish running? (So we're not just turning this into the problem "PullRequestBots is waiting too long on IssueBots")

-------------

PR Comment: https://git.openjdk.org/skara/pull/1558#issuecomment-1730963007

From christoph.langer at sap.com  Fri Sep 22 07:58:14 2023
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 22 Sep 2023 07:58:14 +0000
Subject: Suggestion regarding Skara /approval command
Message-ID: <DB6PR0202MB2694521CB74CBD0BC51DBCDD8AFFA@DB6PR0202MB2694.eurprd02.prod.outlook.com>

Hi,

I have a small suggestion for the great new approval feature in Skara.

Currently, when a PR refers to multiple JBS issues, I have to request approval for each of them with a distinct ?/approval request JDK-<nnn>? command. However, since the approval text that I?d add to each of the items in such a case would often be the same, I?d like to suggest that in such cases an ?/approval request? without bug ids adds the label and text to all of the referred bugs. Do you think this makes sense? If yes, I can create an issue for that.

Thanks
Christoph

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/skara-dev/attachments/20230922/f82a4a56/attachment-0001.htm>

From goetz.lindenmaier at sap.com  Fri Sep 22 08:01:35 2023
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Fri, 22 Sep 2023 08:01:35 +0000
Subject: Suggestion regarding Skara /approval command
In-Reply-To: <DB6PR0202MB2694521CB74CBD0BC51DBCDD8AFFA@DB6PR0202MB2694.eurprd02.prod.outlook.com>
References: <DB6PR0202MB2694521CB74CBD0BC51DBCDD8AFFA@DB6PR0202MB2694.eurprd02.prod.outlook.com>
Message-ID: <PAXPR02MB82457B78C771147C735551EEECFFA@PAXPR02MB8245.eurprd02.prod.outlook.com>

Hi,

I had thought about the same issue.
/approval all request
would be another nice solution to this.
And similarly /approve all yes.

Best regards,
  Goetz.


From: skara-dev <skara-dev-retn at openjdk.org> On Behalf Of Langer, Christoph
Sent: Friday, September 22, 2023 9:58 AM
To: skara-dev at openjdk.org
Subject: Suggestion regarding Skara /approval command

Hi,

I have a small suggestion for the great new approval feature in Skara.

Currently, when a PR refers to multiple JBS issues, I have to request approval for each of them with a distinct ?/approval request JDK-<nnn>? command. However, since the approval text that I?d add to each of the items in such a case would often be the same, I?d like to suggest that in such cases an ?/approval request? without bug ids adds the label and text to all of the referred bugs. Do you think this makes sense? If yes, I can create an issue for that.

Thanks
Christoph

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/skara-dev/attachments/20230922/090b675e/attachment.htm>

From kevin.rushforth at oracle.com  Fri Sep 22 12:13:07 2023
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Fri, 22 Sep 2023 05:13:07 -0700
Subject: Suggestion regarding Skara /approval command
In-Reply-To: <PAXPR02MB82457B78C771147C735551EEECFFA@PAXPR02MB8245.eurprd02.prod.outlook.com>
References: <DB6PR0202MB2694521CB74CBD0BC51DBCDD8AFFA@DB6PR0202MB2694.eurprd02.prod.outlook.com>
 <PAXPR02MB82457B78C771147C735551EEECFFA@PAXPR02MB8245.eurprd02.prod.outlook.com>
Message-ID: <3624649a-946b-694a-451d-7276a85797b3@oracle.com>

+1 for this suggestion.

-- Kevin

On 9/22/2023 1:01 AM, Lindenmaier, Goetz wrote:
>
> Hi,
>
> I had thought about the same issue.
>
> /approval all request
>
> would be another nice solution to this.
>
> And similarly /approve all yes.
>
> Best regards,
>
> Goetz.
>
> *From:*skara-dev <skara-dev-retn at openjdk.org> *On Behalf Of *Langer, 
> Christoph
> *Sent:* Friday, September 22, 2023 9:58 AM
> *To:* skara-dev at openjdk.org
> *Subject:* Suggestion regarding Skara /approval command
>
> Hi,
>
> I have a small suggestion for the great new approval feature in Skara.
>
> Currently, when a PR refers to multiple JBS issues, I have to request 
> approval for each of them with a distinct ?/approval request 
> JDK-<nnn>? command. However, since the approval text that I?d add to 
> each of the items in such a case would often be the same, I?d like to 
> suggest that in such cases an ?/approval request? without bug ids adds 
> the label and text to all of the referred bugs. Do you think this 
> makes sense? If yes, I can create an issue for that.
>
> Thanks
>
> Christoph
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/skara-dev/attachments/20230922/d2c1db88/attachment-0001.htm>

From erikj at openjdk.org  Fri Sep 22 13:01:57 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 22 Sep 2023 13:01:57 GMT
Subject: RFR: 2037: Change the order of bots in PullRequestBotFactory
In-Reply-To: <Y6nTJvX2h1kF-_38RFVCVHX4_HTCwfCAxzlv6bKOs7U=.2f2ff471-e821-42a1-ba90-29636dae2e97@github.com>
References: <Y6nTJvX2h1kF-_38RFVCVHX4_HTCwfCAxzlv6bKOs7U=.2f2ff471-e821-42a1-ba90-29636dae2e97@github.com>
Message-ID: <IDugjMyEfF2DaQPgsIP6ZrjWCSUmg0layB45BmlEOZA=.78544488-587a-4e68-82d6-598d15ed176d@github.com>

On Thu, 21 Sep 2023 21:16:17 GMT, Zhao Song <zsong at openjdk.org> wrote:

> Today, when restarting the bot, I found that the IssueBot was down for a long time(about 30 minutes), and then I realized that in PullRequestBotFactory, we created all pullRequestBots first, then CSRIssueBots, and IssueBots last. 
> 
> After the bot is restarted, the botRunner would run all pullRequestBots first and we have a lot of pullRequestBots, so it will take a lot of time. And if users make changes to issues in JBS during this interval, the IssueBot may not be able to get all updated issues. It's really bad. 
> 
> To solve this problem, we could to reverse the order of bots in PullRequestBotFactory, therefore we could make sure IssueBot will be run firstly.

Marked as reviewed by erikj (Lead).

I approved too quickly. I think instead of reversing, we should preserve the order from the config file and just put *IssueBots first. We can collect them in separate lists and then compose the final list at the end of the factory.

-------------

PR Review: https://git.openjdk.org/skara/pull/1558#pullrequestreview-1639904335
Changes requested by erikj (Lead).

PR Review: https://git.openjdk.org/skara/pull/1558#pullrequestreview-1639907376

From erikj at openjdk.org  Fri Sep 22 13:01:57 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 22 Sep 2023 13:01:57 GMT
Subject: RFR: 2037: Change the order of bots in PullRequestBotFactory
In-Reply-To: <IudW7Jc8M48OwVzLWCfAV2hFj8iLU0Dq6d4Kq6dp1TI=.630277a1-8fd3-4c98-aff1-61c9a8547530@github.com>
References: <Y6nTJvX2h1kF-_38RFVCVHX4_HTCwfCAxzlv6bKOs7U=.2f2ff471-e821-42a1-ba90-29636dae2e97@github.com>
 <IudW7Jc8M48OwVzLWCfAV2hFj8iLU0Dq6d4Kq6dp1TI=.630277a1-8fd3-4c98-aff1-61c9a8547530@github.com>
Message-ID: <XTL4GtfPbNOrX55Z66AoP6_CzoEOQxFNtgwsz_PNXWo=.e19fe520-5962-4b95-bded-e5d887e66d5f@github.com>

On Fri, 22 Sep 2023 07:48:11 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> So how long does it typically take for the IssueBots to finish running? (So we're not just turning this into the problem "PullRequestBots is waiting too long on IssueBots")

The PullRequestBot fetches all open PRs and all other PRs that were touched in the last 7 days at startup. This is to ensure we didn't miss anything while we were down. The *IssueBot only starts polling for updates going 10 minutes time back in the first run. That's a rather arbitrarily picked time interval that's basically just meant to be longer than the possible time difference between the Skara bot and the remote server. I think this is the right change to make.

-------------

PR Comment: https://git.openjdk.org/skara/pull/1558#issuecomment-1731371350

From erik.joelsson at oracle.com  Fri Sep 22 13:08:35 2023
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Fri, 22 Sep 2023 06:08:35 -0700
Subject: Suggestion regarding Skara /approval command
In-Reply-To: <3624649a-946b-694a-451d-7276a85797b3@oracle.com>
References: <DB6PR0202MB2694521CB74CBD0BC51DBCDD8AFFA@DB6PR0202MB2694.eurprd02.prod.outlook.com>
 <PAXPR02MB82457B78C771147C735551EEECFFA@PAXPR02MB8245.eurprd02.prod.outlook.com>
 <3624649a-946b-694a-451d-7276a85797b3@oracle.com>
Message-ID: <5422b6a4-1a2e-b9d4-41a5-5cccf98f395a@oracle.com>

Hello,

If you as maintainers would prefer it that way, we can certainly change 
it. I wasn't sure which way to go with that. My assumption was that it 
would encourage people to be lazy and just add the same text to multiple 
bugs, when each of them were likely to require individual motivations.

Note that for the maintainer, the /approve command already approves all 
associated bugs if no bugid is given.

/Erik

On 9/22/23 05:13, Kevin Rushforth wrote:
> +1 for this suggestion.
>
> -- Kevin
>
> On 9/22/2023 1:01 AM, Lindenmaier, Goetz wrote:
>>
>> Hi,
>>
>> I had thought about the same issue.
>>
>> /approval all request
>>
>> would be another nice solution to this.
>>
>> And similarly /approve all yes.
>>
>> Best regards,
>>
>> Goetz.
>>
>> *From:*skara-dev <skara-dev-retn at openjdk.org> *On Behalf Of *Langer, 
>> Christoph
>> *Sent:* Friday, September 22, 2023 9:58 AM
>> *To:* skara-dev at openjdk.org
>> *Subject:* Suggestion regarding Skara /approval command
>>
>> Hi,
>>
>> I have a small suggestion for the great new approval feature in Skara.
>>
>> Currently, when a PR refers to multiple JBS issues, I have to request 
>> approval for each of them with a distinct ?/approval request 
>> JDK-<nnn>? command. However, since the approval text that I?d add to 
>> each of the items in such a case would often be the same, I?d like to 
>> suggest that in such cases an ?/approval request? without bug ids 
>> adds the label and text to all of the referred bugs. Do you think 
>> this makes sense? If yes, I can create an issue for that.
>>
>> Thanks
>>
>> Christoph
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/skara-dev/attachments/20230922/228faa76/attachment-0001.htm>

From christoph.langer at sap.com  Fri Sep 22 13:12:50 2023
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 22 Sep 2023 13:12:50 +0000
Subject: Suggestion regarding Skara /approval command
In-Reply-To: <5422b6a4-1a2e-b9d4-41a5-5cccf98f395a@oracle.com>
References: <DB6PR0202MB2694521CB74CBD0BC51DBCDD8AFFA@DB6PR0202MB2694.eurprd02.prod.outlook.com>
 <PAXPR02MB82457B78C771147C735551EEECFFA@PAXPR02MB8245.eurprd02.prod.outlook.com>
 <3624649a-946b-694a-451d-7276a85797b3@oracle.com>
 <5422b6a4-1a2e-b9d4-41a5-5cccf98f395a@oracle.com>
Message-ID: <DB6PR0202MB26943F3E8E876C198EE6C39F8AFFA@DB6PR0202MB2694.eurprd02.prod.outlook.com>

Hi Erik,

thanks for these insights. Regarding the laziness of requestors, I think we can handle it. If a comment is too short of content we?ll anyway ask the submitter for more info. But in most cases of multiple issues, I guess it?s possible/ok/desirable to have one text to explain them all.

So I?ll open a ticket for this.

Cheers
Christoph

From: erik.joelsson at oracle.com <erik.joelsson at oracle.com>
Sent: Freitag, 22. September 2023 15:09
To: Kevin Rushforth <kevin.rushforth at oracle.com>; Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; Langer, Christoph <christoph.langer at sap.com>; skara-dev at openjdk.org
Subject: Re: Suggestion regarding Skara /approval command


Hello,

If you as maintainers would prefer it that way, we can certainly change it. I wasn't sure which way to go with that. My assumption was that it would encourage people to be lazy and just add the same text to multiple bugs, when each of them were likely to require individual motivations.

Note that for the maintainer, the /approve command already approves all associated bugs if no bugid is given.

/Erik
On 9/22/23 05:13, Kevin Rushforth wrote:
+1 for this suggestion.

-- Kevin
On 9/22/2023 1:01 AM, Lindenmaier, Goetz wrote:
Hi,

I had thought about the same issue.
/approval all request
would be another nice solution to this.
And similarly /approve all yes.

Best regards,
  Goetz.


From: skara-dev <skara-dev-retn at openjdk.org><mailto:skara-dev-retn at openjdk.org> On Behalf Of Langer, Christoph
Sent: Friday, September 22, 2023 9:58 AM
To: skara-dev at openjdk.org<mailto:skara-dev at openjdk.org>
Subject: Suggestion regarding Skara /approval command

Hi,

I have a small suggestion for the great new approval feature in Skara.

Currently, when a PR refers to multiple JBS issues, I have to request approval for each of them with a distinct ?/approval request JDK-<nnn>? command. However, since the approval text that I?d add to each of the items in such a case would often be the same, I?d like to suggest that in such cases an ?/approval request? without bug ids adds the label and text to all of the referred bugs. Do you think this makes sense? If yes, I can create an issue for that.

Thanks
Christoph


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/skara-dev/attachments/20230922/42b450af/attachment.htm>

From zsong at openjdk.org  Fri Sep 22 16:50:01 2023
From: zsong at openjdk.org (Zhao Song)
Date: Fri, 22 Sep 2023 16:50:01 GMT
Subject: RFR: 2037: Change the order of bots in PullRequestBotFactory
In-Reply-To: <IDugjMyEfF2DaQPgsIP6ZrjWCSUmg0layB45BmlEOZA=.78544488-587a-4e68-82d6-598d15ed176d@github.com>
References: <Y6nTJvX2h1kF-_38RFVCVHX4_HTCwfCAxzlv6bKOs7U=.2f2ff471-e821-42a1-ba90-29636dae2e97@github.com>
 <IDugjMyEfF2DaQPgsIP6ZrjWCSUmg0layB45BmlEOZA=.78544488-587a-4e68-82d6-598d15ed176d@github.com>
Message-ID: <kbmQsHQXpj0HXqY_cSKz_TcOIDirp6rHA9Gsf1Qu6dA=.9d6dd9ac-e575-4686-ae01-fb49220840f6@github.com>

On Fri, 22 Sep 2023 12:59:42 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> I approved too quickly. I think instead of reversing, we should preserve the order from the config file and just put *IssueBots first. We can collect them in separate lists and then compose the final list at the end of the factory.

Sure. Will do it.

-------------

PR Comment: https://git.openjdk.org/skara/pull/1558#issuecomment-1731733083

From zsong at openjdk.org  Fri Sep 22 17:01:08 2023
From: zsong at openjdk.org (Zhao Song)
Date: Fri, 22 Sep 2023 17:01:08 GMT
Subject: RFR: 2037: Change the order of bots in PullRequestBotFactory [v2]
In-Reply-To: <Y6nTJvX2h1kF-_38RFVCVHX4_HTCwfCAxzlv6bKOs7U=.2f2ff471-e821-42a1-ba90-29636dae2e97@github.com>
References: <Y6nTJvX2h1kF-_38RFVCVHX4_HTCwfCAxzlv6bKOs7U=.2f2ff471-e821-42a1-ba90-29636dae2e97@github.com>
Message-ID: <180OJS8Zfs-qYvDHUdx8_VXOnFnTBCPqLSjILHZJ5F4=.05405f37-5d5a-427c-a09e-6122475fd12a@github.com>

> Today, when restarting the bot, I found that the IssueBot was down for a long time(about 30 minutes), and then I realized that in PullRequestBotFactory, we created all pullRequestBots first, then CSRIssueBots, and IssueBots last. 
> 
> After the bot is restarted, the botRunner would run all pullRequestBots first and we have a lot of pullRequestBots, so it will take a lot of time. And if users make changes to issues in JBS during this interval, the IssueBot may not be able to get all updated issues. It's really bad. 
> 
> To solve this problem, we could to reverse the order of bots in PullRequestBotFactory, therefore we could make sure IssueBot will be run firstly.

Zhao Song has updated the pull request incrementally with one additional commit since the last revision:

  review comment

-------------

Changes:
  - all: https://git.openjdk.org/skara/pull/1558/files
  - new: https://git.openjdk.org/skara/pull/1558/files/97ce00d1..65f93747

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=skara&pr=1558&range=01
 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1558&range=00-01

  Stats: 5 lines in 1 file changed: 0 ins; 3 del; 2 mod
  Patch: https://git.openjdk.org/skara/pull/1558.diff
  Fetch: git fetch https://git.openjdk.org/skara.git pull/1558/head:pull/1558

PR: https://git.openjdk.org/skara/pull/1558

From erikj at openjdk.org  Fri Sep 22 17:51:32 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 22 Sep 2023 17:51:32 GMT
Subject: RFR: 2037: Change the order of bots in PullRequestBotFactory [v2]
In-Reply-To: <180OJS8Zfs-qYvDHUdx8_VXOnFnTBCPqLSjILHZJ5F4=.05405f37-5d5a-427c-a09e-6122475fd12a@github.com>
References: <Y6nTJvX2h1kF-_38RFVCVHX4_HTCwfCAxzlv6bKOs7U=.2f2ff471-e821-42a1-ba90-29636dae2e97@github.com>
 <180OJS8Zfs-qYvDHUdx8_VXOnFnTBCPqLSjILHZJ5F4=.05405f37-5d5a-427c-a09e-6122475fd12a@github.com>
Message-ID: <CZHWESink-3L_CWGXLFReFyTdZ3DI3nBLwDqHdc5F7Y=.329e9a73-13e6-4e74-be31-60fff3ae762c@github.com>

On Fri, 22 Sep 2023 17:01:08 GMT, Zhao Song <zsong at openjdk.org> wrote:

>> Today, when restarting the bot, I found that the IssueBot was down for a long time(about 30 minutes), and then I realized that in PullRequestBotFactory, we created all pullRequestBots first, then CSRIssueBots, and IssueBots last. 
>> 
>> After the bot is restarted, the botRunner would run all pullRequestBots first and we have a lot of pullRequestBots, so it will take a lot of time. And if users make changes to issues in JBS during this interval, the IssueBot may not be able to get all updated issues. It's really bad. 
>> 
>> To solve this problem, we could to reverse the order of bots in PullRequestBotFactory, therefore we could make sure IssueBot will be run firstly.
>
> Zhao Song has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comment

Marked as reviewed by erikj (Lead).

-------------

PR Review: https://git.openjdk.org/skara/pull/1558#pullrequestreview-1640411103

From zsong at openjdk.org  Fri Sep 22 18:33:03 2023
From: zsong at openjdk.org (Zhao Song)
Date: Fri, 22 Sep 2023 18:33:03 GMT
Subject: RFR: 2037: Change the order of bots in PullRequestBotFactory [v2]
In-Reply-To: <180OJS8Zfs-qYvDHUdx8_VXOnFnTBCPqLSjILHZJ5F4=.05405f37-5d5a-427c-a09e-6122475fd12a@github.com>
References: <Y6nTJvX2h1kF-_38RFVCVHX4_HTCwfCAxzlv6bKOs7U=.2f2ff471-e821-42a1-ba90-29636dae2e97@github.com>
 <180OJS8Zfs-qYvDHUdx8_VXOnFnTBCPqLSjILHZJ5F4=.05405f37-5d5a-427c-a09e-6122475fd12a@github.com>
Message-ID: <94D7CshajH8MKY3D9hj88QIYpUl_PWmEqa1gqyIoXWI=.b2836b81-d266-4bc7-b6cd-b31e4c35041d@github.com>

On Fri, 22 Sep 2023 17:01:08 GMT, Zhao Song <zsong at openjdk.org> wrote:

>> Today, when restarting the bot, I found that the IssueBot was down for a long time(about 30 minutes), and then I realized that in PullRequestBotFactory, we created all pullRequestBots first, then CSRIssueBots, and IssueBots last. 
>> 
>> After the bot is restarted, the botRunner would run all pullRequestBots first and we have a lot of pullRequestBots, so it will take a lot of time. And if users make changes to issues in JBS during this interval, the IssueBot may not be able to get all updated issues. It's really bad. 
>> 
>> To solve this problem, we could to reverse the order of bots in PullRequestBotFactory, therefore we could make sure IssueBot will be run firstly.
>
> Zhao Song has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comment

Thanks!

-------------

PR Comment: https://git.openjdk.org/skara/pull/1558#issuecomment-1731875969

From zsong at openjdk.org  Fri Sep 22 18:33:03 2023
From: zsong at openjdk.org (Zhao Song)
Date: Fri, 22 Sep 2023 18:33:03 GMT
Subject: Integrated: 2037: Change the order of bots in PullRequestBotFactory
In-Reply-To: <Y6nTJvX2h1kF-_38RFVCVHX4_HTCwfCAxzlv6bKOs7U=.2f2ff471-e821-42a1-ba90-29636dae2e97@github.com>
References: <Y6nTJvX2h1kF-_38RFVCVHX4_HTCwfCAxzlv6bKOs7U=.2f2ff471-e821-42a1-ba90-29636dae2e97@github.com>
Message-ID: <i-Tdx6yHxfKE3TtpH-wJR4jo8U-kCXK4vuCLH1z3Jc8=.afba6719-9e7a-4e28-8e49-48b4ef64ad3a@github.com>

On Thu, 21 Sep 2023 21:16:17 GMT, Zhao Song <zsong at openjdk.org> wrote:

> Today, when restarting the bot, I found that the IssueBot was down for a long time(about 30 minutes), and then I realized that in PullRequestBotFactory, we created all pullRequestBots first, then CSRIssueBots, and IssueBots last. 
> 
> After the bot is restarted, the botRunner would run all pullRequestBots first and we have a lot of pullRequestBots, so it will take a lot of time. And if users make changes to issues in JBS during this interval, the IssueBot may not be able to get all updated issues. It's really bad. 
> 
> To solve this problem, we could to reverse the order of bots in PullRequestBotFactory, therefore we could make sure IssueBot will be run firstly.

This pull request has now been integrated.

Changeset: 1da0b82b
Author:    Zhao Song <zsong at openjdk.org>
URL:       https://git.openjdk.org/skara/commit/1da0b82b91d6ab3ba810b40a201d0f4dd41bb7b4
Stats:     13 lines in 2 files changed: 11 ins; 0 del; 2 mod

2037: Change the order of bots in PullRequestBotFactory

Reviewed-by: erikj

-------------

PR: https://git.openjdk.org/skara/pull/1558

From zsong at openjdk.org  Fri Sep 22 20:01:57 2023
From: zsong at openjdk.org (Zhao Song)
Date: Fri, 22 Sep 2023 20:01:57 GMT
Subject: RFR: 2038: Don't post error message of invalid jcheck configuration
 when encountering UncheckedIOException
Message-ID: <bJpiZZ4_ACYOh08xb6F58CTyFzDPv5Gn8Vm3VU05-A8=.47d62470-ee7d-4336-8a1c-0f76c31e0a1a@github.com>

In CheckWorkItem, the bot would check whether this pull request has a valid jcheck configuration and if not, the bot would post an error message of invalid jcheck configuration in the pull request. 

Today, a user reported that he saw this error message in his pull request and he couldn't determine whether the pull request is good. After reading the log, I found that it's just a temporary glitch. The bot was trying to read jcheck configuration in GitHub but got HttpTimeoutException, so the bot posted the error message. But it recovers in the next try. 
https://github.com/openjdk/panama-foreign/pull/893 

To sum, in the cases of some temporary glitches, we shouldn't post error message to pull request to confuse users.

-------------

Commit messages:
 - SKARA-2038

Changes: https://git.openjdk.org/skara/pull/1559/files
 Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1559&range=00
  Issue: https://bugs.openjdk.org/browse/SKARA-2038
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/skara/pull/1559.diff
  Fetch: git fetch https://git.openjdk.org/skara.git pull/1559/head:pull/1559

PR: https://git.openjdk.org/skara/pull/1559

From erikj at openjdk.org  Fri Sep 22 20:31:43 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 22 Sep 2023 20:31:43 GMT
Subject: RFR: 2038: Don't post error message of invalid jcheck
 configuration when encountering UncheckedIOException
In-Reply-To: <bJpiZZ4_ACYOh08xb6F58CTyFzDPv5Gn8Vm3VU05-A8=.47d62470-ee7d-4336-8a1c-0f76c31e0a1a@github.com>
References: <bJpiZZ4_ACYOh08xb6F58CTyFzDPv5Gn8Vm3VU05-A8=.47d62470-ee7d-4336-8a1c-0f76c31e0a1a@github.com>
Message-ID: <ozR4O-dBE0xFYDgjXUze2HNYd_eVsjCtxiSYhGG7p1I=.9d3bc7a0-c8d1-4aa2-9c30-1c7f0362ba44@github.com>

On Fri, 22 Sep 2023 18:30:04 GMT, Zhao Song <zsong at openjdk.org> wrote:

> In CheckWorkItem, the bot would check whether this pull request has a valid jcheck configuration and if not, the bot would post an error message of invalid jcheck configuration in the pull request. 
> 
> Today, a user reported that he saw this error message in his pull request and he couldn't determine whether the pull request is good. After reading the log, I found that it's just a temporary glitch. The bot was trying to read jcheck configuration in GitHub but got HttpTimeoutException, so the bot posted the error message. But it recovers in the next try. 
> https://github.com/openjdk/panama-foreign/pull/893 
> 
> To sum, in the cases of some temporary glitches, we shouldn't post error message to pull request to confuse users.

Marked as reviewed by erikj (Lead).

-------------

PR Review: https://git.openjdk.org/skara/pull/1559#pullrequestreview-1640603915

From zsong at openjdk.org  Fri Sep 22 21:33:51 2023
From: zsong at openjdk.org (Zhao Song)
Date: Fri, 22 Sep 2023 21:33:51 GMT
Subject: Integrated: 2038: Don't post error message of invalid jcheck
 configuration when encountering UncheckedIOException
In-Reply-To: <bJpiZZ4_ACYOh08xb6F58CTyFzDPv5Gn8Vm3VU05-A8=.47d62470-ee7d-4336-8a1c-0f76c31e0a1a@github.com>
References: <bJpiZZ4_ACYOh08xb6F58CTyFzDPv5Gn8Vm3VU05-A8=.47d62470-ee7d-4336-8a1c-0f76c31e0a1a@github.com>
Message-ID: <3ufGVJiSMJy9izwIKZExDl7JAXlsZojkwJ7ghgUn3lU=.d57067ae-f7d2-4e6f-a766-e7f2061cc386@github.com>

On Fri, 22 Sep 2023 18:30:04 GMT, Zhao Song <zsong at openjdk.org> wrote:

> In CheckWorkItem, the bot would check whether this pull request has a valid jcheck configuration and if not, the bot would post an error message of invalid jcheck configuration in the pull request. 
> 
> Today, a user reported that he saw this error message in his pull request and he couldn't determine whether the pull request is good. After reading the log, I found that it's just a temporary glitch. The bot was trying to read jcheck configuration in GitHub but got HttpTimeoutException, so the bot posted the error message. But it recovers in the next try. 
> https://github.com/openjdk/panama-foreign/pull/893 
> 
> To sum, in the cases of some temporary glitches, we shouldn't post error message to pull request to confuse users.

This pull request has now been integrated.

Changeset: f59da95a
Author:    Zhao Song <zsong at openjdk.org>
URL:       https://git.openjdk.org/skara/commit/f59da95aa040dd02edd363686bacd0d66b19a0d5
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

2038: Don't post error message of invalid jcheck configuration when encountering UncheckedIOException

Reviewed-by: erikj

-------------

PR: https://git.openjdk.org/skara/pull/1559

From zsong at openjdk.org  Mon Sep 25 17:09:23 2023
From: zsong at openjdk.org (Zhao Song)
Date: Mon, 25 Sep 2023 17:09:23 GMT
Subject: RFR: 2033: Require all bugs to be accessible before marking PR 'rfr'
Message-ID: <WJ-4xl138rCLZctEpOkbGAx8doAG6qEevSwgxUd2Pcs=.e52e41c1-042c-4478-9eed-a006967b014d@github.com>

If one or more issues associated with the pull request is not accessible, then the pull request should be considered as invalid. Also, no 'rft' label will be added to this pull request and this could help prevent emails from being sent out while the pull request is associated with invalid issues.

-------------

Commit messages:
 - SKARA-2033

Changes: https://git.openjdk.org/skara/pull/1560/files
 Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1560&range=00
  Issue: https://bugs.openjdk.org/browse/SKARA-2033
  Stats: 7 lines in 1 file changed: 7 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/skara/pull/1560.diff
  Fetch: git fetch https://git.openjdk.org/skara.git pull/1560/head:pull/1560

PR: https://git.openjdk.org/skara/pull/1560

From erikj at openjdk.org  Mon Sep 25 20:27:02 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 25 Sep 2023 20:27:02 GMT
Subject: RFR: 2033: Require all bugs to be accessible before marking PR
 'rfr'
In-Reply-To: <WJ-4xl138rCLZctEpOkbGAx8doAG6qEevSwgxUd2Pcs=.e52e41c1-042c-4478-9eed-a006967b014d@github.com>
References: <WJ-4xl138rCLZctEpOkbGAx8doAG6qEevSwgxUd2Pcs=.e52e41c1-042c-4478-9eed-a006967b014d@github.com>
Message-ID: <NbuT5AtWlLyY64BfzRvKx3AkNcOgcGtxRVd-_SA5lr4=.d4889af5-c800-4fc0-a43a-817a057d465a@github.com>

On Fri, 22 Sep 2023 22:00:41 GMT, Zhao Song <zsong at openjdk.org> wrote:

> If one or more issues associated with the pull request is not accessible, then the pull request should be considered as invalid. Also, no 'rft' label will be added to this pull request and this could help prevent emails from being sent out while the pull request is associated with invalid issues.

bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckRun.java line 415:

> 413:     private boolean updateReadyForReview(PullRequestCheckIssueVisitor visitor, List<String> additionalErrors) {
> 414:         // All the issues must be accessible
> 415:         if (!allIssuesAccessible) {

I would like to avoid having a boolean field that gets modified at some arbitrary point during a run. We can just send the `regularIssuesMap` to this method and we can check if any of the values is an empty Optional.

-------------

PR Review Comment: https://git.openjdk.org/skara/pull/1560#discussion_r1336352932

From zsong at openjdk.org  Mon Sep 25 21:21:08 2023
From: zsong at openjdk.org (Zhao Song)
Date: Mon, 25 Sep 2023 21:21:08 GMT
Subject: RFR: 2033: Require all bugs to be accessible before marking PR
 'rfr'
In-Reply-To: <NbuT5AtWlLyY64BfzRvKx3AkNcOgcGtxRVd-_SA5lr4=.d4889af5-c800-4fc0-a43a-817a057d465a@github.com>
References: <WJ-4xl138rCLZctEpOkbGAx8doAG6qEevSwgxUd2Pcs=.e52e41c1-042c-4478-9eed-a006967b014d@github.com>
 <NbuT5AtWlLyY64BfzRvKx3AkNcOgcGtxRVd-_SA5lr4=.d4889af5-c800-4fc0-a43a-817a057d465a@github.com>
Message-ID: <98dNV3bhZlTGR-SEO7KD25C35vtUYQg0oYaGIZTGsvA=.56b5cc44-1ff9-404d-a1e7-f6ced99750c1@github.com>

On Mon, 25 Sep 2023 20:23:56 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> If one or more issues associated with the pull request is not accessible, then the pull request should be considered as invalid. Also, no 'rft' label will be added to this pull request and this could help prevent emails from being sent out while the pull request is associated with invalid issues.
>
> bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckRun.java line 415:
> 
>> 413:     private boolean updateReadyForReview(PullRequestCheckIssueVisitor visitor, List<String> additionalErrors) {
>> 414:         // All the issues must be accessible
>> 415:         if (!allIssuesAccessible) {
> 
> I would like to avoid having a boolean field that gets modified at some arbitrary point during a run. We can just send the `regularIssuesMap` to this method and we can check if any of the values is an empty Optional.

Sure

-------------

PR Review Comment: https://git.openjdk.org/skara/pull/1560#discussion_r1336398752

From zsong at openjdk.org  Mon Sep 25 21:28:48 2023
From: zsong at openjdk.org (Zhao Song)
Date: Mon, 25 Sep 2023 21:28:48 GMT
Subject: RFR: 2033: Require all bugs to be accessible before marking PR
 'rfr' [v2]
In-Reply-To: <WJ-4xl138rCLZctEpOkbGAx8doAG6qEevSwgxUd2Pcs=.e52e41c1-042c-4478-9eed-a006967b014d@github.com>
References: <WJ-4xl138rCLZctEpOkbGAx8doAG6qEevSwgxUd2Pcs=.e52e41c1-042c-4478-9eed-a006967b014d@github.com>
Message-ID: <csiaOqjM2Gqb9wpxyWMd-fET7VlppuuuJT1ya0FHpYE=.1e550720-afda-4dad-8be2-cbe2dd5c3809@github.com>

> If one or more issues associated with the pull request is not accessible, then the pull request should be considered as invalid. Also, no 'rft' label will be added to this pull request and this could help prevent emails from being sent out while the pull request is associated with invalid issues.

Zhao Song has updated the pull request incrementally with one additional commit since the last revision:

  review comment

-------------

Changes:
  - all: https://git.openjdk.org/skara/pull/1560/files
  - new: https://git.openjdk.org/skara/pull/1560/files/3dbe7a6c..cff9ba14

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=skara&pr=1560&range=01
 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1560&range=00-01

  Stats: 5 lines in 1 file changed: 0 ins; 2 del; 3 mod
  Patch: https://git.openjdk.org/skara/pull/1560.diff
  Fetch: git fetch https://git.openjdk.org/skara.git pull/1560/head:pull/1560

PR: https://git.openjdk.org/skara/pull/1560

From erikj at openjdk.org  Mon Sep 25 21:36:00 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 25 Sep 2023 21:36:00 GMT
Subject: RFR: 2033: Require all bugs to be accessible before marking PR
 'rfr' [v2]
In-Reply-To: <csiaOqjM2Gqb9wpxyWMd-fET7VlppuuuJT1ya0FHpYE=.1e550720-afda-4dad-8be2-cbe2dd5c3809@github.com>
References: <WJ-4xl138rCLZctEpOkbGAx8doAG6qEevSwgxUd2Pcs=.e52e41c1-042c-4478-9eed-a006967b014d@github.com>
 <csiaOqjM2Gqb9wpxyWMd-fET7VlppuuuJT1ya0FHpYE=.1e550720-afda-4dad-8be2-cbe2dd5c3809@github.com>
Message-ID: <EA30zswlQgrD6eLzVRR5uYVRw8J1cTH27EjT4lLRtig=.8acb4335-cc5f-4ac1-ad6f-c6d050505349@github.com>

On Mon, 25 Sep 2023 21:28:48 GMT, Zhao Song <zsong at openjdk.org> wrote:

>> If one or more issues associated with the pull request is not accessible, then the pull request should be considered as invalid. Also, no 'rft' label will be added to this pull request and this could help prevent emails from being sent out while the pull request is associated with invalid issues.
>
> Zhao Song has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comment

If I understand this correctly, this will only prevent PRs not yet ready for review from being marked `rfr`, but will not remove `rfr` if an issue is suddenly unreachable. I think that is what we want for this.

-------------

Marked as reviewed by erikj (Lead).

PR Review: https://git.openjdk.org/skara/pull/1560#pullrequestreview-1643020894

From zsong at openjdk.org  Mon Sep 25 21:43:51 2023
From: zsong at openjdk.org (Zhao Song)
Date: Mon, 25 Sep 2023 21:43:51 GMT
Subject: RFR: 2033: Require all bugs to be accessible before marking PR
 'rfr' [v2]
In-Reply-To: <csiaOqjM2Gqb9wpxyWMd-fET7VlppuuuJT1ya0FHpYE=.1e550720-afda-4dad-8be2-cbe2dd5c3809@github.com>
References: <WJ-4xl138rCLZctEpOkbGAx8doAG6qEevSwgxUd2Pcs=.e52e41c1-042c-4478-9eed-a006967b014d@github.com>
 <csiaOqjM2Gqb9wpxyWMd-fET7VlppuuuJT1ya0FHpYE=.1e550720-afda-4dad-8be2-cbe2dd5c3809@github.com>
Message-ID: <xbK4qq_2alzwmx_7SOi9QUL5bSv3AKCERlD0FGfoZqE=.ef1e9984-66f1-4e2a-b10d-2f26813be2f8@github.com>

On Mon, 25 Sep 2023 21:28:48 GMT, Zhao Song <zsong at openjdk.org> wrote:

>> If one or more issues associated with the pull request is not accessible, then the pull request should be considered as invalid. Also, no 'rft' label will be added to this pull request and this could help prevent emails from being sent out while the pull request is associated with invalid issues.
>
> Zhao Song has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comment

Thanks for the review!

-------------

PR Comment: https://git.openjdk.org/skara/pull/1560#issuecomment-1734502821

From zsong at openjdk.org  Mon Sep 25 21:43:51 2023
From: zsong at openjdk.org (Zhao Song)
Date: Mon, 25 Sep 2023 21:43:51 GMT
Subject: Integrated: 2033: Require all bugs to be accessible before marking PR
 'rfr'
In-Reply-To: <WJ-4xl138rCLZctEpOkbGAx8doAG6qEevSwgxUd2Pcs=.e52e41c1-042c-4478-9eed-a006967b014d@github.com>
References: <WJ-4xl138rCLZctEpOkbGAx8doAG6qEevSwgxUd2Pcs=.e52e41c1-042c-4478-9eed-a006967b014d@github.com>
Message-ID: <UpfUY4aG4IcpIn7mTOpzKW_TXv3WmtErIS9JZ4yYYwg=.b3abbd77-b293-4e5c-a04d-bd9bc658c849@github.com>

On Fri, 22 Sep 2023 22:00:41 GMT, Zhao Song <zsong at openjdk.org> wrote:

> If one or more issues associated with the pull request is not accessible, then the pull request should be considered as invalid. Also, no 'rft' label will be added to this pull request and this could help prevent emails from being sent out while the pull request is associated with invalid issues.

This pull request has now been integrated.

Changeset: 776497ee
Author:    Zhao Song <zsong at openjdk.org>
URL:       https://git.openjdk.org/skara/commit/776497ee3f63a9dfae514528e18e30682e13c32b
Stats:     7 lines in 1 file changed: 5 ins; 0 del; 2 mod

2033: Require all bugs to be accessible before marking PR 'rfr'

Reviewed-by: erikj

-------------

PR: https://git.openjdk.org/skara/pull/1560

From zsong at openjdk.org  Tue Sep 26 22:32:49 2023
From: zsong at openjdk.org (Zhao Song)
Date: Tue, 26 Sep 2023 22:32:49 GMT
Subject: RFR: 2040: Temporary workaround of SKARA-2025
Message-ID: <EhmgjR8sL3u9TiPUs2O76q0Ea0F3Lfxc4xQNeB-45Mk=.7340a72e-a624-46ad-88c6-ad18a622b585@github.com>

The final solution for [SKARA-2025](https://bugs.openjdk.org/browse/SKARA-2025) should be for us to optimize the HostedRepositoryPool#materializeClone method, but this will take some time. 

And some users would use /tag command every week, to make their experiences better, we should fix it with the temporary workaround as soon as possible. 

As Erik said in [SKARA-2025](https://bugs.openjdk.org/browse/SKARA-2025), we only need to fetch from the remote repo into local repo and the problem could be solved.

-------------

Commit messages:
 - SKARA-2040
 - SKARA-2040

Changes: https://git.openjdk.org/skara/pull/1561/files
 Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1561&range=00
  Issue: https://bugs.openjdk.org/browse/SKARA-2040
  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/skara/pull/1561.diff
  Fetch: git fetch https://git.openjdk.org/skara.git pull/1561/head:pull/1561

PR: https://git.openjdk.org/skara/pull/1561

From zsong at openjdk.org  Tue Sep 26 22:32:49 2023
From: zsong at openjdk.org (Zhao Song)
Date: Tue, 26 Sep 2023 22:32:49 GMT
Subject: RFR: 2040: Temporary workaround of SKARA-2025
In-Reply-To: <EhmgjR8sL3u9TiPUs2O76q0Ea0F3Lfxc4xQNeB-45Mk=.7340a72e-a624-46ad-88c6-ad18a622b585@github.com>
References: <EhmgjR8sL3u9TiPUs2O76q0Ea0F3Lfxc4xQNeB-45Mk=.7340a72e-a624-46ad-88c6-ad18a622b585@github.com>
Message-ID: <WtTd9eJA6Kc2Uf_TYJQFnruft1w2fuzFM1s3wVf5AkQ=.3a69e457-ede7-40fb-8ae3-0faa354e1157@github.com>

On Mon, 25 Sep 2023 18:30:21 GMT, Zhao Song <zsong at openjdk.org> wrote:

> The final solution for [SKARA-2025](https://bugs.openjdk.org/browse/SKARA-2025) should be for us to optimize the HostedRepositoryPool#materializeClone method, but this will take some time. 
> 
> And some users would use /tag command every week, to make their experiences better, we should fix it with the temporary workaround as soon as possible. 
> 
> As Erik said in [SKARA-2025](https://bugs.openjdk.org/browse/SKARA-2025), we only need to fetch from the remote repo into local repo and the problem could be solved.

Repository#fetchAll doesn't work in this case because when cloning the repository, `git clone` typically only clones the default branch by default. However, in the fetchAll method, the `git fetch ` command includes the parameter '+refs/heads/:refs/heads/,' which will make the `git fetch` command fails.

-------------

PR Comment: https://git.openjdk.org/skara/pull/1561#issuecomment-1736389442

From christoph.langer at sap.com  Wed Sep 27 08:16:15 2023
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 27 Sep 2023 08:16:15 +0000
Subject: Suggestion regarding Skara /approval command
In-Reply-To: <DB6PR0202MB26943F3E8E876C198EE6C39F8AFFA@DB6PR0202MB2694.eurprd02.prod.outlook.com>
References: <DB6PR0202MB2694521CB74CBD0BC51DBCDD8AFFA@DB6PR0202MB2694.eurprd02.prod.outlook.com>
 <PAXPR02MB82457B78C771147C735551EEECFFA@PAXPR02MB8245.eurprd02.prod.outlook.com>
 <3624649a-946b-694a-451d-7276a85797b3@oracle.com>
 <5422b6a4-1a2e-b9d4-41a5-5cccf98f395a@oracle.com>
 <DB6PR0202MB26943F3E8E876C198EE6C39F8AFFA@DB6PR0202MB2694.eurprd02.prod.outlook.com>
Message-ID: <DB6PR0202MB26943665F952AC112828735C8AC2A@DB6PR0202MB2694.eurprd02.prod.outlook.com>

Hi,

RFE created: https://bugs.openjdk.org/browse/SKARA-2042

Thanks
Christoph

From: Langer, Christoph <christoph.langer at sap.com>
Sent: Freitag, 22. September 2023 15:13
To: erik.joelsson at oracle.com; Kevin Rushforth <kevin.rushforth at oracle.com>; Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; skara-dev at openjdk.org
Subject: RE: Suggestion regarding Skara /approval command

Hi Erik,

thanks for these insights. Regarding the laziness of requestors, I think we can handle it. If a comment is too short of content we?ll anyway ask the submitter for more info. But in most cases of multiple issues, I guess it?s possible/ok/desirable to have one text to explain them all.

So I?ll open a ticket for this.

Cheers
Christoph

From: erik.joelsson at oracle.com<mailto:erik.joelsson at oracle.com> <erik.joelsson at oracle.com<mailto:erik.joelsson at oracle.com>>
Sent: Freitag, 22. September 2023 15:09
To: Kevin Rushforth <kevin.rushforth at oracle.com<mailto:kevin.rushforth at oracle.com>>; Lindenmaier, Goetz <goetz.lindenmaier at sap.com<mailto:goetz.lindenmaier at sap.com>>; Langer, Christoph <christoph.langer at sap.com<mailto:christoph.langer at sap.com>>; skara-dev at openjdk.org<mailto:skara-dev at openjdk.org>
Subject: Re: Suggestion regarding Skara /approval command


Hello,

If you as maintainers would prefer it that way, we can certainly change it. I wasn't sure which way to go with that. My assumption was that it would encourage people to be lazy and just add the same text to multiple bugs, when each of them were likely to require individual motivations.

Note that for the maintainer, the /approve command already approves all associated bugs if no bugid is given.

/Erik
On 9/22/23 05:13, Kevin Rushforth wrote:
+1 for this suggestion.

-- Kevin
On 9/22/2023 1:01 AM, Lindenmaier, Goetz wrote:
Hi,

I had thought about the same issue.
/approval all request
would be another nice solution to this.
And similarly /approve all yes.

Best regards,
  Goetz.


From: skara-dev <skara-dev-retn at openjdk.org><mailto:skara-dev-retn at openjdk.org> On Behalf Of Langer, Christoph
Sent: Friday, September 22, 2023 9:58 AM
To: skara-dev at openjdk.org<mailto:skara-dev at openjdk.org>
Subject: Suggestion regarding Skara /approval command

Hi,

I have a small suggestion for the great new approval feature in Skara.

Currently, when a PR refers to multiple JBS issues, I have to request approval for each of them with a distinct ?/approval request JDK-<nnn>? command. However, since the approval text that I?d add to each of the items in such a case would often be the same, I?d like to suggest that in such cases an ?/approval request? without bug ids adds the label and text to all of the referred bugs. Do you think this makes sense? If yes, I can create an issue for that.

Thanks
Christoph


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/skara-dev/attachments/20230927/112b2017/attachment.htm>

From goetz.lindenmaier at sap.com  Wed Sep 27 15:20:53 2023
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Wed, 27 Sep 2023 15:20:53 +0000
Subject: SKARA-2019 and dependent pull requests
Message-ID: <PAXPR02MB82457A3D6DB62E7A60AC6D49ECC2A@PAXPR02MB8245.eurprd02.prod.outlook.com>

Hi Erik and Kevin,

How does SKARA-2019/21 handle dependent pull requests?
https://github.com/openjdk/jdk21u/pull/200

The change is not marked for approval.
Is this on purpose or just not yet implemented?

If there is a needed follow up fix, I as a maintainer only approve the
underlying change after approving the follow up to make
sure they can both be pushed at the same time.
So I would have expected the above PR to be marked
as ready for approval.

Best regards,
  Goetz.





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/skara-dev/attachments/20230927/1b063552/attachment-0001.htm>

From zhao.song at oracle.com  Wed Sep 27 16:44:42 2023
From: zhao.song at oracle.com (Zhao Song)
Date: Wed, 27 Sep 2023 16:44:42 +0000
Subject: SKARA-2019 and dependent pull requests
In-Reply-To: <PAXPR02MB82457A3D6DB62E7A60AC6D49ECC2A@PAXPR02MB8245.eurprd02.prod.outlook.com>
References: <PAXPR02MB82457A3D6DB62E7A60AC6D49ECC2A@PAXPR02MB8245.eurprd02.prod.outlook.com>
Message-ID: <DS7PR10MB49732453FEC349034C438A9484C2A@DS7PR10MB4973.namprd10.prod.outlook.com>

Hi Goetz,

Maybe it?s a bug in the maintainer approval feature.

The skara bot would determine whether this pr needs maintainer approval by checking whether merging into the target branch needs maintainer approval.

In this case, we only configured that merging into master branch of jdk21u needs maintainer approval, however, for dependent pull requests, the target branch is pr/XXX.

I will try to fix it.

Thank you,
Zhao

From: skara-dev <skara-dev-retn at openjdk.org> on behalf of Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
Date: Wednesday, September 27, 2023 at 08:21
To: skara-dev at openjdk.org <skara-dev at openjdk.org>, Erik Joelsson <erik.joelsson at oracle.com>, Kevin Rushforth <kevin.rushforth at oracle.com>
Subject: SKARA-2019 and dependent pull requests
Hi Erik and Kevin,

How does SKARA-2019/21 handle dependent pull requests?
https://github.com/openjdk/jdk21u/pull/200

The change is not marked for approval.
Is this on purpose or just not yet implemented?

If there is a needed follow up fix, I as a maintainer only approve the
underlying change after approving the follow up to make
sure they can both be pushed at the same time.
So I would have expected the above PR to be marked
as ready for approval.

Best regards,
  Goetz.





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/skara-dev/attachments/20230927/ec71e706/attachment.htm>

From erik.joelsson at oracle.com  Wed Sep 27 20:50:55 2023
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Wed, 27 Sep 2023 13:50:55 -0700
Subject: SKARA-2019 and dependent pull requests
In-Reply-To: <DS7PR10MB49732453FEC349034C438A9484C2A@DS7PR10MB4973.namprd10.prod.outlook.com>
References: <PAXPR02MB82457A3D6DB62E7A60AC6D49ECC2A@PAXPR02MB8245.eurprd02.prod.outlook.com>
 <DS7PR10MB49732453FEC349034C438A9484C2A@DS7PR10MB4973.namprd10.prod.outlook.com>
Message-ID: <bea7e3d5-9283-2843-60fb-ac58e340e7d4@oracle.com>

Hello,

Dependent pull requests weren't considered with this feature. The way it 
works now, the approval logic won't be triggered until the PR targets a 
branch that is configured for approval. A quick and dirty workaround 
would be to configure 'pr/.*' as a set of branches that need approval 
for the repo. A more correct solution would be to implement proper 
support for pr/X branches by haing the bot extract the PR from the 
target branch name and follow that dependency chain until we find a non 
pr/X branch, and if that branch requires approval, activate the approval 
logic.

/Erik

On 9/27/23 09:44, Zhao Song wrote:
>
> Hi Goetz,
>
> Maybe it?s a bug in the maintainer approval feature.
>
> The skara bot would determine whether this pr needs maintainer 
> approval by checking whether merging into the target branch needs 
> maintainer approval.
>
> In this case, we only configured that merging into master branch of 
> jdk21u needs maintainer approval, however, for dependent pull 
> requests, the target branch is pr/XXX.
>
> I will try to fix it.
>
> Thank you,
>
> Zhao
>
> *From: *skara-dev <skara-dev-retn at openjdk.org> on behalf of 
> Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> *Date: *Wednesday, September 27, 2023 at 08:21
> *To: *skara-dev at openjdk.org <skara-dev at openjdk.org>, Erik Joelsson 
> <erik.joelsson at oracle.com>, Kevin Rushforth <kevin.rushforth at oracle.com>
> *Subject: *SKARA-2019 and dependent pull requests
>
> Hi Erik and Kevin,
>
> How does SKARA-2019/21 handle dependent pull requests?
>
> https://github.com/openjdk/jdk21u/pull/200
>
> The change is not marked for approval.
>
> Is this on purpose or just not yet implemented?
>
> If there is a needed follow up fix, I as a maintainer only approve the
>
> underlying change after approving the follow up to make
>
> sure they can both be pushed at the same time.
>
> So I would have expected the above PR to be marked
>
> as ready for approval.
>
> Best regards,
>
> ? Goetz.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/skara-dev/attachments/20230927/9a79f74a/attachment-0001.htm>

From erikj at openjdk.org  Wed Sep 27 20:58:12 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 27 Sep 2023 20:58:12 GMT
Subject: RFR: 2040: Temporary workaround of SKARA-2025
In-Reply-To: <WtTd9eJA6Kc2Uf_TYJQFnruft1w2fuzFM1s3wVf5AkQ=.3a69e457-ede7-40fb-8ae3-0faa354e1157@github.com>
References: <EhmgjR8sL3u9TiPUs2O76q0Ea0F3Lfxc4xQNeB-45Mk=.7340a72e-a624-46ad-88c6-ad18a622b585@github.com>
 <WtTd9eJA6Kc2Uf_TYJQFnruft1w2fuzFM1s3wVf5AkQ=.3a69e457-ede7-40fb-8ae3-0faa354e1157@github.com>
Message-ID: <OvVrV7pXD3E5YiOpU9vIjkAiTKZl5IEA-1CpvdP7Uic=.8baccaa6-b34f-4832-a50a-9be65df0c420@github.com>

On Tue, 26 Sep 2023 22:28:18 GMT, Zhao Song <zsong at openjdk.org> wrote:

> Repository#fetchAll doesn't work in this case because when cloning the repository, `git clone` typically only clones the default branch by default. However, in the fetchAll method, the `git fetch ` command includes the parameter '+refs/heads/:refs/heads/,' which will make the `git fetch` command fails.

Fetching just the commit will fix the reported problem, but it will not fix the issue of checking if the tag already exists. Maybe rewriting that check to use the remote repository instead of the local is a better solution for that.

-------------

PR Comment: https://git.openjdk.org/skara/pull/1561#issuecomment-1738066129

From zsong at openjdk.org  Wed Sep 27 20:58:29 2023
From: zsong at openjdk.org (Zhao Song)
Date: Wed, 27 Sep 2023 20:58:29 GMT
Subject: RFR: 2045: Make maintainer approval feature compatible with dependent
 pr feature.
Message-ID: <QOz0O7vPtxJ84ifFPpK4Z-SXN6wwdCausq2ZJ_kibQQ=.9675e64a-9f39-45fa-b703-887acdcfaa23@github.com>

A user reported that a dependent pr in a repo which configured with maintainer approval feature is not marked for approval. 

After investigation, I realized that the skara bot would determine whether this pr needs maintainer approval by checking whether merging into the target branch needs maintainer approval. 
  
In this case, we only configured that merging into master branch of jdk21u needs maintainer approval, however, for dependent pull requests, the target branch is pr/XXX. 

To fix this issue, we should let the skara bot be able to find the real target ref.

-------------

Commit messages:
 - fix an issue
 - add test
 - SKARA-2045

Changes: https://git.openjdk.org/skara/pull/1562/files
 Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1562&range=00
  Issue: https://bugs.openjdk.org/browse/SKARA-2045
  Stats: 84 lines in 4 files changed: 75 ins; 1 del; 8 mod
  Patch: https://git.openjdk.org/skara/pull/1562.diff
  Fetch: git fetch https://git.openjdk.org/skara.git pull/1562/head:pull/1562

PR: https://git.openjdk.org/skara/pull/1562

From erikj at openjdk.org  Wed Sep 27 21:20:52 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 27 Sep 2023 21:20:52 GMT
Subject: RFR: 2040: Temporary workaround of SKARA-2025
In-Reply-To: <EhmgjR8sL3u9TiPUs2O76q0Ea0F3Lfxc4xQNeB-45Mk=.7340a72e-a624-46ad-88c6-ad18a622b585@github.com>
References: <EhmgjR8sL3u9TiPUs2O76q0Ea0F3Lfxc4xQNeB-45Mk=.7340a72e-a624-46ad-88c6-ad18a622b585@github.com>
Message-ID: <sBPFGgPkYat7_twXn_UkqiRsOGMyG1I3UBwzvQqwnBk=.ccc3e853-2e80-4ed7-8a3e-154bed3b76b4@github.com>

On Mon, 25 Sep 2023 18:30:21 GMT, Zhao Song <zsong at openjdk.org> wrote:

> The final solution for [SKARA-2025](https://bugs.openjdk.org/browse/SKARA-2025) should be for us to optimize the HostedRepositoryPool#materializeClone method, but this will take some time. 
> 
> And some users would use /tag command every week, to make their experiences better, we should fix it with the temporary workaround as soon as possible. 
> 
> As Erik said in [SKARA-2025](https://bugs.openjdk.org/browse/SKARA-2025), we only need to fetch from the remote repo into local repo and the problem could be solved.

Marked as reviewed by erikj (Lead).

-------------

PR Review: https://git.openjdk.org/skara/pull/1561#pullrequestreview-1647581929

From erikj at openjdk.org  Wed Sep 27 21:20:52 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 27 Sep 2023 21:20:52 GMT
Subject: RFR: 2040: Temporary workaround of SKARA-2025
In-Reply-To: <OvVrV7pXD3E5YiOpU9vIjkAiTKZl5IEA-1CpvdP7Uic=.8baccaa6-b34f-4832-a50a-9be65df0c420@github.com>
References: <EhmgjR8sL3u9TiPUs2O76q0Ea0F3Lfxc4xQNeB-45Mk=.7340a72e-a624-46ad-88c6-ad18a622b585@github.com>
 <WtTd9eJA6Kc2Uf_TYJQFnruft1w2fuzFM1s3wVf5AkQ=.3a69e457-ede7-40fb-8ae3-0faa354e1157@github.com>
 <OvVrV7pXD3E5YiOpU9vIjkAiTKZl5IEA-1CpvdP7Uic=.8baccaa6-b34f-4832-a50a-9be65df0c420@github.com>
Message-ID: <WWntN986jgGE5_Jebm0EthZrq7DX5BRjFyp2C6wqKSs=.951f6c4e-8f5a-457e-ae91-fbba4b6a68b0@github.com>

On Wed, 27 Sep 2023 20:56:00 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> > Repository#fetchAll doesn't work in this case because when cloning the repository, `git clone` typically only clones the default branch by default. However, in the fetchAll method, the `git fetch ` command includes the parameter '+refs/heads/:refs/heads/,' which will make the `git fetch` command fails.
> 
> Fetching just the commit will fix the reported problem, but it will not fix the issue of checking if the tag already exists. Maybe rewriting that check to use the remote repository instead of the local is a better solution for that.

I was wrong. Fetching with includeTags=true will get all tags, so this should be fine.

-------------

PR Comment: https://git.openjdk.org/skara/pull/1561#issuecomment-1738092269

From zsong at openjdk.org  Wed Sep 27 21:32:16 2023
From: zsong at openjdk.org (Zhao Song)
Date: Wed, 27 Sep 2023 21:32:16 GMT
Subject: RFR: 2040: Temporary workaround of SKARA-2025
In-Reply-To: <EhmgjR8sL3u9TiPUs2O76q0Ea0F3Lfxc4xQNeB-45Mk=.7340a72e-a624-46ad-88c6-ad18a622b585@github.com>
References: <EhmgjR8sL3u9TiPUs2O76q0Ea0F3Lfxc4xQNeB-45Mk=.7340a72e-a624-46ad-88c6-ad18a622b585@github.com>
Message-ID: <ERvA7PSWJkIKu81m56_V-_E9CNTUIC5du8USsOlmjdE=.ea982cc8-fa62-4ca1-8a9d-c5e34a7a9f73@github.com>

On Mon, 25 Sep 2023 18:30:21 GMT, Zhao Song <zsong at openjdk.org> wrote:

> The final solution for [SKARA-2025](https://bugs.openjdk.org/browse/SKARA-2025) should be for us to optimize the HostedRepositoryPool#materializeClone method, but this will take some time. 
> 
> And some users would use /tag command every week, to make their experiences better, we should fix it with the temporary workaround as soon as possible. 
> 
> As Erik said in [SKARA-2025](https://bugs.openjdk.org/browse/SKARA-2025), we only need to fetch from the remote repo into local repo and the problem could be solved.

Thanks for the review!

-------------

PR Comment: https://git.openjdk.org/skara/pull/1561#issuecomment-1738103729

From zsong at openjdk.org  Wed Sep 27 21:32:16 2023
From: zsong at openjdk.org (Zhao Song)
Date: Wed, 27 Sep 2023 21:32:16 GMT
Subject: Integrated: 2040: Temporary workaround of SKARA-2025
In-Reply-To: <EhmgjR8sL3u9TiPUs2O76q0Ea0F3Lfxc4xQNeB-45Mk=.7340a72e-a624-46ad-88c6-ad18a622b585@github.com>
References: <EhmgjR8sL3u9TiPUs2O76q0Ea0F3Lfxc4xQNeB-45Mk=.7340a72e-a624-46ad-88c6-ad18a622b585@github.com>
Message-ID: <0im3iQLn6piUotKx55jLECYrQE04_ZbFaXB20VFbpDw=.36f0ab8a-c5fa-4e49-9bcc-ef8b2e6a98d4@github.com>

On Mon, 25 Sep 2023 18:30:21 GMT, Zhao Song <zsong at openjdk.org> wrote:

> The final solution for [SKARA-2025](https://bugs.openjdk.org/browse/SKARA-2025) should be for us to optimize the HostedRepositoryPool#materializeClone method, but this will take some time. 
> 
> And some users would use /tag command every week, to make their experiences better, we should fix it with the temporary workaround as soon as possible. 
> 
> As Erik said in [SKARA-2025](https://bugs.openjdk.org/browse/SKARA-2025), we only need to fetch from the remote repo into local repo and the problem could be solved.

This pull request has now been integrated.

Changeset: 063408a5
Author:    Zhao Song <zsong at openjdk.org>
URL:       https://git.openjdk.org/skara/commit/063408a565075af3de6c43324cb2e71f25b4b728
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

2040: Temporary workaround of SKARA-2025

Reviewed-by: erikj

-------------

PR: https://git.openjdk.org/skara/pull/1561

From erikj at openjdk.org  Wed Sep 27 21:37:14 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 27 Sep 2023 21:37:14 GMT
Subject: RFR: 2045: Make maintainer approval feature compatible with
 dependent pr feature.
In-Reply-To: <QOz0O7vPtxJ84ifFPpK4Z-SXN6wwdCausq2ZJ_kibQQ=.9675e64a-9f39-45fa-b703-887acdcfaa23@github.com>
References: <QOz0O7vPtxJ84ifFPpK4Z-SXN6wwdCausq2ZJ_kibQQ=.9675e64a-9f39-45fa-b703-887acdcfaa23@github.com>
Message-ID: <-03wHGVVWVRpeba4MFfZHhzCbHRmU9OmMrhUrYzQACE=.bb88a810-87a9-4984-b4a7-4a5484fdf200@github.com>

On Wed, 27 Sep 2023 19:50:25 GMT, Zhao Song <zsong at openjdk.org> wrote:

> A user reported that a dependent pr in a repo which configured with maintainer approval feature is not marked for approval. 
> 
> After investigation, I realized that the skara bot would determine whether this pr needs maintainer approval by checking whether merging into the target branch needs maintainer approval. 
>   
> In this case, we only configured that merging into master branch of jdk21u needs maintainer approval, however, for dependent pull requests, the target branch is pr/XXX. 
> 
> To fix this issue, we should let the skara bot be able to find the real target ref.

bots/pr/src/main/java/org/openjdk/skara/bots/pr/ApprovalCommand.java line 185:

> 183:         var dependentPR = pr.repository().pullRequest(id);
> 184:         return realTargetRef(dependentPR);
> 185:     }

There is a class `org.openjdk.skara.forge.PreIntegrations` that handles these things. I think this method should be added there (and be integrated with existing methods).

bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckRun.java line 108:

> 106:                 workItem.bot.confOverrideRef(),
> 107:                 comments);
> 108:         realTargetRef = ApprovalCommand.realTargetRef(pr);

I would like to avoid calculating this for every pr targeting a pr/X branch. We could make this field lazy initialized in the `needsApproval` method. Something like:


if (approval != null) {
    if (realTargetRef == null) {
         realTargetRef = PreIntegration.realTargetRef(pr);
    }
    return approval.needsApproval(realTargetRef);
}
return false;


I would also add a comment on the field with something like

// Only set if approval is configured for the repo

-------------

PR Review Comment: https://git.openjdk.org/skara/pull/1562#discussion_r1339232687
PR Review Comment: https://git.openjdk.org/skara/pull/1562#discussion_r1339244487

From zsong at openjdk.org  Wed Sep 27 21:50:53 2023
From: zsong at openjdk.org (Zhao Song)
Date: Wed, 27 Sep 2023 21:50:53 GMT
Subject: RFR: 2045: Make maintainer approval feature compatible with
 dependent pr feature.
In-Reply-To: <-03wHGVVWVRpeba4MFfZHhzCbHRmU9OmMrhUrYzQACE=.bb88a810-87a9-4984-b4a7-4a5484fdf200@github.com>
References: <QOz0O7vPtxJ84ifFPpK4Z-SXN6wwdCausq2ZJ_kibQQ=.9675e64a-9f39-45fa-b703-887acdcfaa23@github.com>
 <-03wHGVVWVRpeba4MFfZHhzCbHRmU9OmMrhUrYzQACE=.bb88a810-87a9-4984-b4a7-4a5484fdf200@github.com>
Message-ID: <aSwW5D7qOXjO2bwGvzxHk5D1qoznw6lisSVmjbHfccc=.33d30be4-3c6f-4231-b4de-be65477c81c1@github.com>

On Wed, 27 Sep 2023 21:33:33 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> A user reported that a dependent pr in a repo which configured with maintainer approval feature is not marked for approval. 
>> 
>> After investigation, I realized that the skara bot would determine whether this pr needs maintainer approval by checking whether merging into the target branch needs maintainer approval. 
>>   
>> In this case, we only configured that merging into master branch of jdk21u needs maintainer approval, however, for dependent pull requests, the target branch is pr/XXX. 
>> 
>> To fix this issue, we should let the skara bot be able to find the real target ref.
>
> bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckRun.java line 108:
> 
>> 106:                 workItem.bot.confOverrideRef(),
>> 107:                 comments);
>> 108:         realTargetRef = ApprovalCommand.realTargetRef(pr);
> 
> I would like to avoid calculating this for every pr targeting a pr/X branch. We could make this field lazy initialized in the `needsApproval` method. Something like:
> 
> 
> if (approval != null) {
>     if (realTargetRef == null) {
>          realTargetRef = PreIntegration.realTargetRef(pr);
>     }
>     return approval.needsApproval(realTargetRef);
> }
> return false;
> 
> 
> I would also add a comment on the field with something like
> 
> // Only set if approval is configured for the repo

Thanks for the suggestion. It will make this patch much better!

-------------

PR Review Comment: https://git.openjdk.org/skara/pull/1562#discussion_r1339258901

From zsong at openjdk.org  Wed Sep 27 22:22:14 2023
From: zsong at openjdk.org (Zhao Song)
Date: Wed, 27 Sep 2023 22:22:14 GMT
Subject: RFR: 2045: Make maintainer approval feature compatible with
 dependent pr feature. [v2]
In-Reply-To: <QOz0O7vPtxJ84ifFPpK4Z-SXN6wwdCausq2ZJ_kibQQ=.9675e64a-9f39-45fa-b703-887acdcfaa23@github.com>
References: <QOz0O7vPtxJ84ifFPpK4Z-SXN6wwdCausq2ZJ_kibQQ=.9675e64a-9f39-45fa-b703-887acdcfaa23@github.com>
Message-ID: <TbODRqC4gxsvtzGkfFNWTmvu3JpMYkNfhjfXihpg7Lo=.14a723fa-28f9-447d-85ee-5660a7be2c7d@github.com>

> A user reported that a dependent pr in a repo which configured with maintainer approval feature is not marked for approval. 
> 
> After investigation, I realized that the skara bot would determine whether this pr needs maintainer approval by checking whether merging into the target branch needs maintainer approval. 
>   
> In this case, we only configured that merging into master branch of jdk21u needs maintainer approval, however, for dependent pull requests, the target branch is pr/XXX. 
> 
> To fix this issue, we should let the skara bot be able to find the real target ref.

Zhao Song has updated the pull request incrementally with three additional commits since the last revision:

 - update
 - update
 - review comment

-------------

Changes:
  - all: https://git.openjdk.org/skara/pull/1562/files
  - new: https://git.openjdk.org/skara/pull/1562/files/b0f7a491..cda5c577

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=skara&pr=1562&range=01
 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1562&range=00-01

  Stats: 35 lines in 4 files changed: 15 ins; 16 del; 4 mod
  Patch: https://git.openjdk.org/skara/pull/1562.diff
  Fetch: git fetch https://git.openjdk.org/skara.git pull/1562/head:pull/1562

PR: https://git.openjdk.org/skara/pull/1562

From zsong at openjdk.org  Thu Sep 28 18:07:31 2023
From: zsong at openjdk.org (Zhao Song)
Date: Thu, 28 Sep 2023 18:07:31 GMT
Subject: RFR: 2049: After enabled maintainer approval in a repo,
 some pull requests are not updated
Message-ID: <dC0h1Ywb4jYQJGwwIpN7VDakcoD8akUaSr3-GVTNFs4=.91ab1c8f-0f3f-466d-bb1f-86a688722e32@github.com>

Today, I enabled maintainer approval feature in openjdk/jdk8u-dev. 

After I enabled this feature, I expect to see the progress like "JDK-XXXXXXX needs maintainer approval" in the body of all open prs. 

However, this pr(https://github.com/openjdk/jdk8u-dev/pull/368) is not updated. 

The reason is that although after we enabled the maintainer approval feature, the issue labels will be calculated in the issueMetaData, there still exists some issues that doesn't contain any label. 

To solve this, I think we could add a string "approval" to issueMetaData after we enabled the maintainer approval.

-------------

Commit messages:
 - SKARA-2049

Changes: https://git.openjdk.org/skara/pull/1563/files
 Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1563&range=00
  Issue: https://bugs.openjdk.org/browse/SKARA-2049
  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/skara/pull/1563.diff
  Fetch: git fetch https://git.openjdk.org/skara.git pull/1563/head:pull/1563

PR: https://git.openjdk.org/skara/pull/1563

From erikj at openjdk.org  Thu Sep 28 18:21:33 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 28 Sep 2023 18:21:33 GMT
Subject: RFR: 2043: Skara mistakenly tagged the wrong commit when processing a
 /tag command
Message-ID: <FwrA0EpCsBGQiwYaDIMOR5piTm7HQL06OIKNVIYHZas=.f7354c4f-a2ff-47d0-9cb0-55022a9faa15@github.com>

The method `GitLabRepository::recentCommitComments` may sometimes return a comment associated with the wrong commit. We have seen it happen, which caused a tag to be set on the wrong commit. My theory is that this was caused by a race, which was probably made more potent due to GitLab sometimes being slow in returning up to date data. See bug for more details.

The main fix is to always verify that an event note about a recent commit comment actually matches a comment found on the commit in question. The current implementation has a quick return when only one potential commit is found.

In addition to that, I'm also reworking the implementation to be a bit more robust. @zhaosongzs found that there is an alternate API for retrieving commit comments called "discussions" and that gives us more data, notably the same ID field as an event has. This makes it possible to match an event note with a commit comment note by ID instead of by the combination of author and created_at. From this further simplifications naturally fell out.

A CommitComment returned from `GitLabRepository::addCommitComment` no longer contains a value for ID. I think this is more correct than making up a value. I verified that no code seems to be using the returned object currently, so this shouldn't impact anything.

The two new tests were run and inspected manually.

-------------

Commit messages:
 - SKARA-2043

Changes: https://git.openjdk.org/skara/pull/1564/files
 Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1564&range=00
  Issue: https://bugs.openjdk.org/browse/SKARA-2043
  Stats: 136 lines in 2 files changed: 76 ins; 20 del; 40 mod
  Patch: https://git.openjdk.org/skara/pull/1564.diff
  Fetch: git fetch https://git.openjdk.org/skara.git pull/1564/head:pull/1564

PR: https://git.openjdk.org/skara/pull/1564

From erikj at openjdk.org  Thu Sep 28 18:40:22 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 28 Sep 2023 18:40:22 GMT
Subject: RFR: 2049: After enabled maintainer approval in a repo,
 some pull requests are not updated
In-Reply-To: <dC0h1Ywb4jYQJGwwIpN7VDakcoD8akUaSr3-GVTNFs4=.91ab1c8f-0f3f-466d-bb1f-86a688722e32@github.com>
References: <dC0h1Ywb4jYQJGwwIpN7VDakcoD8akUaSr3-GVTNFs4=.91ab1c8f-0f3f-466d-bb1f-86a688722e32@github.com>
Message-ID: <AIZlHCBZz6cI0s3XuJkudqlLm9xevgVxm7nPX-9BxFg=.68c40681-0e13-4412-b279-ada4a25be126@github.com>

On Thu, 28 Sep 2023 17:58:34 GMT, Zhao Song <zsong at openjdk.org> wrote:

> Today, I enabled maintainer approval feature in openjdk/jdk8u-dev. 
> 
> After I enabled this feature, I expect to see the progress like "JDK-XXXXXXX needs maintainer approval" in the body of all open prs. 
> 
> However, this pr(https://github.com/openjdk/jdk8u-dev/pull/368) is not updated. 
> 
> The reason is that although after we enabled the maintainer approval feature, the issue labels will be calculated in the issueMetaData, there still exists some issues that doesn't contain any label. 
> 
> To solve this, I think we could add a string "approval" to issueMetaData after we enabled the maintainer approval.

Looks good, but I would like a comment explaining why. Added suggestion.

bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckWorkItem.java line 217:

> 215:                         }
> 216:                         if (bot.approval() != null && bot.approval().needsApproval(pr.targetRef())) {
> 217:                             issueData.append("approval");

Suggestion:

                            // Add a static sting to the metadata if the PR needs approval to force
                            // update if this configuration has changed for the target branch.
                            issueData.append("approval");

-------------

PR Review: https://git.openjdk.org/skara/pull/1563#pullrequestreview-1649498164
PR Review Comment: https://git.openjdk.org/skara/pull/1563#discussion_r1340539063

From zsong at openjdk.org  Thu Sep 28 18:51:20 2023
From: zsong at openjdk.org (Zhao Song)
Date: Thu, 28 Sep 2023 18:51:20 GMT
Subject: RFR: 2049: After enabled maintainer approval in a repo,
 some pull requests are not updated [v2]
In-Reply-To: <dC0h1Ywb4jYQJGwwIpN7VDakcoD8akUaSr3-GVTNFs4=.91ab1c8f-0f3f-466d-bb1f-86a688722e32@github.com>
References: <dC0h1Ywb4jYQJGwwIpN7VDakcoD8akUaSr3-GVTNFs4=.91ab1c8f-0f3f-466d-bb1f-86a688722e32@github.com>
Message-ID: <YM9nU87RG0RXUKFFHx43AuvrlJSeU8zdG4iPUHAtmtI=.d5920199-177e-4fa3-abb6-ae43b1bc4178@github.com>

> Today, I enabled maintainer approval feature in openjdk/jdk8u-dev. 
> 
> After I enabled this feature, I expect to see the progress like "JDK-XXXXXXX needs maintainer approval" in the body of all open prs. 
> 
> However, this pr(https://github.com/openjdk/jdk8u-dev/pull/368) is not updated. 
> 
> The reason is that although after we enabled the maintainer approval feature, the issue labels will be calculated in the issueMetaData, there still exists some issues that doesn't contain any label. 
> 
> To solve this, I think we could add a string "approval" to issueMetaData after we enabled the maintainer approval.

Zhao Song has updated the pull request incrementally with one additional commit since the last revision:

  Update bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckWorkItem.java
  
  Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>

-------------

Changes:
  - all: https://git.openjdk.org/skara/pull/1563/files
  - new: https://git.openjdk.org/skara/pull/1563/files/39e68913..6694d79e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=skara&pr=1563&range=01
 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1563&range=00-01

  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/skara/pull/1563.diff
  Fetch: git fetch https://git.openjdk.org/skara.git pull/1563/head:pull/1563

PR: https://git.openjdk.org/skara/pull/1563

From zsong at openjdk.org  Thu Sep 28 21:23:18 2023
From: zsong at openjdk.org (Zhao Song)
Date: Thu, 28 Sep 2023 21:23:18 GMT
Subject: RFR: 2043: Skara mistakenly tagged the wrong commit when
 processing a /tag command
In-Reply-To: <FwrA0EpCsBGQiwYaDIMOR5piTm7HQL06OIKNVIYHZas=.f7354c4f-a2ff-47d0-9cb0-55022a9faa15@github.com>
References: <FwrA0EpCsBGQiwYaDIMOR5piTm7HQL06OIKNVIYHZas=.f7354c4f-a2ff-47d0-9cb0-55022a9faa15@github.com>
Message-ID: <w1XIO-8iODXEShww2lxvybVeD0_U_3lEoMmK0heiY6Q=.1be18027-69df-4503-9579-82743a551f62@github.com>

On Thu, 28 Sep 2023 18:17:29 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> The method `GitLabRepository::recentCommitComments` may sometimes return a comment associated with the wrong commit. We have seen it happen, which caused a tag to be set on the wrong commit. My theory is that this was caused by a race, which was probably made more potent due to GitLab sometimes being slow in returning up to date data. See bug for more details.
> 
> The main fix is to always verify that an event note about a recent commit comment actually matches a comment found on the commit in question. The current implementation has a quick return when only one potential commit is found.
> 
> In addition to that, I'm also reworking the implementation to be a bit more robust. @zhaosongzs found that there is an alternate API for retrieving commit comments called "discussions" and that gives us more data, notably the same ID field as an event has. This makes it possible to match an event note with a commit comment note by ID instead of by the combination of author and created_at. From this further simplifications naturally fell out.
> 
> A CommitComment returned from `GitLabRepository::addCommitComment` no longer contains a value for ID. I think this is more correct than making up a value. I verified that no code seems to be using the returned object currently, so this shouldn't impact anything.
> 
> The two new tests were run and inspected manually.

Looks good.

forge/src/main/java/org/openjdk/skara/forge/gitlab/GitLabRepository.java line 557:

> 555:             log.warning("Did not find commit with title " + commitTitle + " for repository " + projectName);
> 556:         }
> 557:         return found;

Just want to confirm that if we stop throwing exceptions here, the commitComment will be handled again in the next CommitCommentsWorkItem.

-------------

Marked as reviewed by zsong (Reviewer).

PR Review: https://git.openjdk.org/skara/pull/1564#pullrequestreview-1649728141
PR Review Comment: https://git.openjdk.org/skara/pull/1564#discussion_r1340678580

From erikj at openjdk.org  Thu Sep 28 21:24:25 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 28 Sep 2023 21:24:25 GMT
Subject: RFR: 2049: After enabled maintainer approval in a repo,
 some pull requests are not updated [v2]
In-Reply-To: <YM9nU87RG0RXUKFFHx43AuvrlJSeU8zdG4iPUHAtmtI=.d5920199-177e-4fa3-abb6-ae43b1bc4178@github.com>
References: <dC0h1Ywb4jYQJGwwIpN7VDakcoD8akUaSr3-GVTNFs4=.91ab1c8f-0f3f-466d-bb1f-86a688722e32@github.com>
 <YM9nU87RG0RXUKFFHx43AuvrlJSeU8zdG4iPUHAtmtI=.d5920199-177e-4fa3-abb6-ae43b1bc4178@github.com>
Message-ID: <yYQhAYra2CpHDOPVWTpaZNm_RJootgIEw59ztmmnfQA=.2907014e-8bbc-4a83-adce-aac08bd57643@github.com>

On Thu, 28 Sep 2023 18:51:20 GMT, Zhao Song <zsong at openjdk.org> wrote:

>> Today, I enabled maintainer approval feature in openjdk/jdk8u-dev. 
>> 
>> After I enabled this feature, I expect to see the progress like "JDK-XXXXXXX needs maintainer approval" in the body of all open prs. 
>> 
>> However, this pr(https://github.com/openjdk/jdk8u-dev/pull/368) is not updated. 
>> 
>> The reason is that although after we enabled the maintainer approval feature, the issue labels will be calculated in the issueMetaData, there still exists some issues that doesn't contain any label. 
>> 
>> To solve this, I think we could add a string "approval" to issueMetaData after we enabled the maintainer approval.
>
> Zhao Song has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckWorkItem.java
>   
>   Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>

Marked as reviewed by erikj (Lead).

-------------

PR Review: https://git.openjdk.org/skara/pull/1563#pullrequestreview-1649727277

From zsong at openjdk.org  Thu Sep 28 21:24:25 2023
From: zsong at openjdk.org (Zhao Song)
Date: Thu, 28 Sep 2023 21:24:25 GMT
Subject: Integrated: 2049: After enabled maintainer approval in a repo,
 some pull requests are not updated
In-Reply-To: <dC0h1Ywb4jYQJGwwIpN7VDakcoD8akUaSr3-GVTNFs4=.91ab1c8f-0f3f-466d-bb1f-86a688722e32@github.com>
References: <dC0h1Ywb4jYQJGwwIpN7VDakcoD8akUaSr3-GVTNFs4=.91ab1c8f-0f3f-466d-bb1f-86a688722e32@github.com>
Message-ID: <2qMMaJPf-NmP9Qbm--xKHDOJZ51DEQlDP_phgF5djU0=.d926b5ec-43bf-4047-93e1-7247f21f1d9f@github.com>

On Thu, 28 Sep 2023 17:58:34 GMT, Zhao Song <zsong at openjdk.org> wrote:

> Today, I enabled maintainer approval feature in openjdk/jdk8u-dev. 
> 
> After I enabled this feature, I expect to see the progress like "JDK-XXXXXXX needs maintainer approval" in the body of all open prs. 
> 
> However, this pr(https://github.com/openjdk/jdk8u-dev/pull/368) is not updated. 
> 
> The reason is that although after we enabled the maintainer approval feature, the issue labels will be calculated in the issueMetaData, there still exists some issues that doesn't contain any label. 
> 
> To solve this, I think we could add a string "approval" to issueMetaData after we enabled the maintainer approval.

This pull request has now been integrated.

Changeset: be89a78a
Author:    Zhao Song <zsong at openjdk.org>
URL:       https://git.openjdk.org/skara/commit/be89a78a5ca9d5922021b67387894d7fd8a62fbb
Stats:     3 lines in 1 file changed: 3 ins; 0 del; 0 mod

2049: After enabled maintainer approval in a repo, some pull requests are not updated

Reviewed-by: erikj

-------------

PR: https://git.openjdk.org/skara/pull/1563

From zsong at openjdk.org  Fri Sep 29 00:17:46 2023
From: zsong at openjdk.org (Zhao Song)
Date: Fri, 29 Sep 2023 00:17:46 GMT
Subject: RFR: 2042: Allow bulk requests with /approval request command
Message-ID: <ZzhupeX9huoabSJqoyzFa1M-x7IMmtBXW6_PYd2lfPM=.80706dad-fdf7-4ca3-b39e-69469af44a32@github.com>

As some users requested, we will allow bulk requests with `/approval` request command.

If an id is not specified in the `/approval` command, the bot will generate a maintainer approval request for all associated bugs.

This also applies to the `/approval cancel` command, which will cancel the maintainer approval request for all associated bugs.

-------------

Commit messages:
 - SKARA-2042

Changes: https://git.openjdk.org/skara/pull/1565/files
 Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1565&range=00
  Issue: https://bugs.openjdk.org/browse/SKARA-2042
  Stats: 129 lines in 3 files changed: 43 ins; 56 del; 30 mod
  Patch: https://git.openjdk.org/skara/pull/1565.diff
  Fetch: git fetch https://git.openjdk.org/skara.git pull/1565/head:pull/1565

PR: https://git.openjdk.org/skara/pull/1565

From erikj at openjdk.org  Fri Sep 29 12:53:51 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 29 Sep 2023 12:53:51 GMT
Subject: RFR: 2043: Skara mistakenly tagged the wrong commit when
 processing a /tag command
In-Reply-To: <w1XIO-8iODXEShww2lxvybVeD0_U_3lEoMmK0heiY6Q=.1be18027-69df-4503-9579-82743a551f62@github.com>
References: <FwrA0EpCsBGQiwYaDIMOR5piTm7HQL06OIKNVIYHZas=.f7354c4f-a2ff-47d0-9cb0-55022a9faa15@github.com>
 <w1XIO-8iODXEShww2lxvybVeD0_U_3lEoMmK0heiY6Q=.1be18027-69df-4503-9579-82743a551f62@github.com>
Message-ID: <toPLH809dO8FePNK8mwRjhXrk1GwVUnd8euw97tMUqc=.4e0e99ae-471e-4990-88bf-e3d0e06e8d2d@github.com>

On Thu, 28 Sep 2023 21:19:50 GMT, Zhao Song <zsong at openjdk.org> wrote:

>> The method `GitLabRepository::recentCommitComments` may sometimes return a comment associated with the wrong commit. We have seen it happen, which caused a tag to be set on the wrong commit. My theory is that this was caused by a race, which was probably made more potent due to GitLab sometimes being slow in returning up to date data. See bug for more details.
>> 
>> The main fix is to always verify that an event note about a recent commit comment actually matches a comment found on the commit in question. The current implementation has a quick return when only one potential commit is found.
>> 
>> In addition to that, I'm also reworking the implementation to be a bit more robust. @zhaosongzs found that there is an alternate API for retrieving commit comments called "discussions" and that gives us more data, notably the same ID field as an event has. This makes it possible to match an event note with a commit comment note by ID instead of by the combination of author and created_at. From this further simplifications naturally fell out.
>> 
>> A CommitComment returned from `GitLabRepository::addCommitComment` no longer contains a value for ID. I think this is more correct than making up a value. I verified that no code seems to be using the returned object currently, so this shouldn't impact anything.
>> 
>> The two new tests were run and inspected manually.
>
> forge/src/main/java/org/openjdk/skara/forge/gitlab/GitLabRepository.java line 557:
> 
>> 555:             log.warning("Did not find commit with title " + commitTitle + " for repository " + projectName);
>> 556:         }
>> 557:         return found;
> 
> Just want to confirm that if we stop throwing exceptions here, the commitComment will be handled again in the next CommitCommentsWorkItem.

The way it's currently implemented, yes it will. The drawback of throwing an exception is that it's treated as an error and we get notified about it. But since this is something that can happen, and if it happens it's likely benign, I would like to avoid that.

The `CommitCommentsWorkItem` always queries for recent comments from the last 4 days. All processed comments are stored in a map to avoid processing again. If we never return a comment, it will be retried for 4 days, regardless of if we throw the exception or not.

-------------

PR Review Comment: https://git.openjdk.org/skara/pull/1564#discussion_r1341326483

From erikj at openjdk.org  Fri Sep 29 13:05:46 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 29 Sep 2023 13:05:46 GMT
Subject: RFR: 2042: Allow bulk requests with /approval request command
In-Reply-To: <ZzhupeX9huoabSJqoyzFa1M-x7IMmtBXW6_PYd2lfPM=.80706dad-fdf7-4ca3-b39e-69469af44a32@github.com>
References: <ZzhupeX9huoabSJqoyzFa1M-x7IMmtBXW6_PYd2lfPM=.80706dad-fdf7-4ca3-b39e-69469af44a32@github.com>
Message-ID: <sYYwgc-_nnQdxtNsJXfW8LfSM1Q-wUrLUJxDxgpeupE=.c7c51f37-04c7-42be-bc2b-6d171dd1b3c0@github.com>

On Thu, 28 Sep 2023 23:07:06 GMT, Zhao Song <zsong at openjdk.org> wrote:

> As some users requested, we will allow bulk requests with `/approval` request command.
> 
> If an id is not specified in the `/approval` command, the bot will generate a maintainer approval request for all associated bugs.
> 
> This also applies to the `/approval cancel` command, which will cancel the maintainer approval request for all associated bugs.

bots/pr/src/main/java/org/openjdk/skara/bots/pr/ApprovalCommand.java line 89:

> 87:             var issueTrackerIssueOpt = issueProject.issue(issue.shortId());
> 88:             if (issueTrackerIssueOpt.isEmpty()) {
> 89:                 reply.println("Can not find " + issue.id() + " in the " + issueProject.name() + " project.");

The ID is already printed, so this error message doesn't need to include it. Maybe something like

Suggestion:

                reply.println("Can not be found in the " + issueProject.name() + " project.");

bots/pr/src/main/java/org/openjdk/skara/bots/pr/ApproveCommand.java line 120:

> 118:     }
> 119: 
> 120:     public static List<Issue> getIssues(String issueId, PullRequest pr, List<Comment> allComments, PrintWriter reply) {

This can be package private instead of public (don't set either `public` or `private`).

-------------

PR Review Comment: https://git.openjdk.org/skara/pull/1565#discussion_r1341335332
PR Review Comment: https://git.openjdk.org/skara/pull/1565#discussion_r1341330989

From zsong at openjdk.org  Fri Sep 29 16:22:52 2023
From: zsong at openjdk.org (Zhao Song)
Date: Fri, 29 Sep 2023 16:22:52 GMT
Subject: RFR: 2042: Allow bulk requests with /approval request command [v2]
In-Reply-To: <ZzhupeX9huoabSJqoyzFa1M-x7IMmtBXW6_PYd2lfPM=.80706dad-fdf7-4ca3-b39e-69469af44a32@github.com>
References: <ZzhupeX9huoabSJqoyzFa1M-x7IMmtBXW6_PYd2lfPM=.80706dad-fdf7-4ca3-b39e-69469af44a32@github.com>
Message-ID: <kssQQdYWTCO_guGzP2Tr1FCewYAPN6o9AKLSquhI5tY=.993c89e0-9615-46c7-93ce-bbfc60c5d13d@github.com>

> As some users requested, we will allow bulk requests with `/approval` request command.
> 
> If an id is not specified in the `/approval` command, the bot will generate a maintainer approval request for all associated bugs.
> 
> This also applies to the `/approval cancel` command, which will cancel the maintainer approval request for all associated bugs.

Zhao Song has updated the pull request incrementally with one additional commit since the last revision:

  Update bots/pr/src/main/java/org/openjdk/skara/bots/pr/ApprovalCommand.java
  
  Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>

-------------

Changes:
  - all: https://git.openjdk.org/skara/pull/1565/files
  - new: https://git.openjdk.org/skara/pull/1565/files/6c63bd02..29ad3fee

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=skara&pr=1565&range=01
 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1565&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/skara/pull/1565.diff
  Fetch: git fetch https://git.openjdk.org/skara.git pull/1565/head:pull/1565

PR: https://git.openjdk.org/skara/pull/1565

From zsong at openjdk.org  Fri Sep 29 16:36:08 2023
From: zsong at openjdk.org (Zhao Song)
Date: Fri, 29 Sep 2023 16:36:08 GMT
Subject: RFR: 2042: Allow bulk requests with /approval request command [v3]
In-Reply-To: <ZzhupeX9huoabSJqoyzFa1M-x7IMmtBXW6_PYd2lfPM=.80706dad-fdf7-4ca3-b39e-69469af44a32@github.com>
References: <ZzhupeX9huoabSJqoyzFa1M-x7IMmtBXW6_PYd2lfPM=.80706dad-fdf7-4ca3-b39e-69469af44a32@github.com>
Message-ID: <mcE4LsmSBI28dxxzNgllXyPghSpzze9b-Rcb8hlZd3M=.550fbd37-320f-49c6-9ca6-ec1ab7a281bc@github.com>

> As some users requested, we will allow bulk requests with `/approval` request command.
> 
> If an id is not specified in the `/approval` command, the bot will generate a maintainer approval request for all associated bugs.
> 
> This also applies to the `/approval cancel` command, which will cancel the maintainer approval request for all associated bugs.

Zhao Song has updated the pull request incrementally with one additional commit since the last revision:

  review comment

-------------

Changes:
  - all: https://git.openjdk.org/skara/pull/1565/files
  - new: https://git.openjdk.org/skara/pull/1565/files/29ad3fee..cec12170

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=skara&pr=1565&range=02
 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1565&range=01-02

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/skara/pull/1565.diff
  Fetch: git fetch https://git.openjdk.org/skara.git pull/1565/head:pull/1565

PR: https://git.openjdk.org/skara/pull/1565

From erikj at openjdk.org  Fri Sep 29 16:59:27 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 29 Sep 2023 16:59:27 GMT
Subject: RFR: 2042: Allow bulk requests with /approval request command [v3]
In-Reply-To: <mcE4LsmSBI28dxxzNgllXyPghSpzze9b-Rcb8hlZd3M=.550fbd37-320f-49c6-9ca6-ec1ab7a281bc@github.com>
References: <ZzhupeX9huoabSJqoyzFa1M-x7IMmtBXW6_PYd2lfPM=.80706dad-fdf7-4ca3-b39e-69469af44a32@github.com>
 <mcE4LsmSBI28dxxzNgllXyPghSpzze9b-Rcb8hlZd3M=.550fbd37-320f-49c6-9ca6-ec1ab7a281bc@github.com>
Message-ID: <Xv70_3cMTEWK3vVC7kahBbUFHUv5sRgJCiDh8MJrM5E=.9907eac9-a330-4035-acc9-90a7aa6f5edc@github.com>

On Fri, 29 Sep 2023 16:36:08 GMT, Zhao Song <zsong at openjdk.org> wrote:

>> As some users requested, we will allow bulk requests with `/approval` request command.
>> 
>> If an id is not specified in the `/approval` command, the bot will generate a maintainer approval request for all associated bugs.
>> 
>> This also applies to the `/approval cancel` command, which will cancel the maintainer approval request for all associated bugs.
>
> Zhao Song has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comment

Marked as reviewed by erikj (Lead).

-------------

PR Review: https://git.openjdk.org/skara/pull/1565#pullrequestreview-1651168386

From zsong at openjdk.org  Fri Sep 29 17:22:37 2023
From: zsong at openjdk.org (Zhao Song)
Date: Fri, 29 Sep 2023 17:22:37 GMT
Subject: RFR: 2042: Allow bulk requests with /approval request command [v3]
In-Reply-To: <mcE4LsmSBI28dxxzNgllXyPghSpzze9b-Rcb8hlZd3M=.550fbd37-320f-49c6-9ca6-ec1ab7a281bc@github.com>
References: <ZzhupeX9huoabSJqoyzFa1M-x7IMmtBXW6_PYd2lfPM=.80706dad-fdf7-4ca3-b39e-69469af44a32@github.com>
 <mcE4LsmSBI28dxxzNgllXyPghSpzze9b-Rcb8hlZd3M=.550fbd37-320f-49c6-9ca6-ec1ab7a281bc@github.com>
Message-ID: <h5qccO-FrS7GJAcnfHVbYx_CpSUZCEwhZbf2IhRbVeo=.b8e14f37-a46c-4bfe-acd2-462575985860@github.com>

On Fri, 29 Sep 2023 16:36:08 GMT, Zhao Song <zsong at openjdk.org> wrote:

>> As some users requested, we will allow bulk requests with `/approval` request command.
>> 
>> If an id is not specified in the `/approval` command, the bot will generate a maintainer approval request for all associated bugs.
>> 
>> This also applies to the `/approval cancel` command, which will cancel the maintainer approval request for all associated bugs.
>
> Zhao Song has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comment

Thanks for the review!

-------------

PR Comment: https://git.openjdk.org/skara/pull/1565#issuecomment-1741246186

From zsong at openjdk.org  Fri Sep 29 17:24:24 2023
From: zsong at openjdk.org (Zhao Song)
Date: Fri, 29 Sep 2023 17:24:24 GMT
Subject: Integrated: 2042: Allow bulk requests with /approval request command
In-Reply-To: <ZzhupeX9huoabSJqoyzFa1M-x7IMmtBXW6_PYd2lfPM=.80706dad-fdf7-4ca3-b39e-69469af44a32@github.com>
References: <ZzhupeX9huoabSJqoyzFa1M-x7IMmtBXW6_PYd2lfPM=.80706dad-fdf7-4ca3-b39e-69469af44a32@github.com>
Message-ID: <4E_EU-vp7u1KDF1W66ib58Js40ZbR8gKiCcKguv1C7E=.22cae59f-7c4e-4eb2-82bf-73693d145ccb@github.com>

On Thu, 28 Sep 2023 23:07:06 GMT, Zhao Song <zsong at openjdk.org> wrote:

> As some users requested, we will allow bulk requests with `/approval` request command.
> 
> If an id is not specified in the `/approval` command, the bot will generate a maintainer approval request for all associated bugs.
> 
> This also applies to the `/approval cancel` command, which will cancel the maintainer approval request for all associated bugs.

This pull request has now been integrated.

Changeset: ab9a2e70
Author:    Zhao Song <zsong at openjdk.org>
URL:       https://git.openjdk.org/skara/commit/ab9a2e70f600ac3ff85ccad33f4de0a1ca7dd106
Stats:     129 lines in 3 files changed: 43 ins; 56 del; 30 mod

2042: Allow bulk requests with /approval request command

Reviewed-by: erikj

-------------

PR: https://git.openjdk.org/skara/pull/1565

From erikj at openjdk.org  Fri Sep 29 17:34:37 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 29 Sep 2023 17:34:37 GMT
Subject: Integrated: 2043: Skara mistakenly tagged the wrong commit when
 processing a /tag command
In-Reply-To: <FwrA0EpCsBGQiwYaDIMOR5piTm7HQL06OIKNVIYHZas=.f7354c4f-a2ff-47d0-9cb0-55022a9faa15@github.com>
References: <FwrA0EpCsBGQiwYaDIMOR5piTm7HQL06OIKNVIYHZas=.f7354c4f-a2ff-47d0-9cb0-55022a9faa15@github.com>
Message-ID: <LJ4t2EAcHJdkgaeif4-43oEcIPWAfbWRshX5A3kcsNc=.6507a19b-5033-43bd-b5be-033207debba2@github.com>

On Thu, 28 Sep 2023 18:17:29 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> The method `GitLabRepository::recentCommitComments` may sometimes return a comment associated with the wrong commit. We have seen it happen, which caused a tag to be set on the wrong commit. My theory is that this was caused by a race, which was probably made more potent due to GitLab sometimes being slow in returning up to date data. See bug for more details.
> 
> The main fix is to always verify that an event note about a recent commit comment actually matches a comment found on the commit in question. The current implementation has a quick return when only one potential commit is found.
> 
> In addition to that, I'm also reworking the implementation to be a bit more robust. @zhaosongzs found that there is an alternate API for retrieving commit comments called "discussions" and that gives us more data, notably the same ID field as an event has. This makes it possible to match an event note with a commit comment note by ID instead of by the combination of author and created_at. From this further simplifications naturally fell out.
> 
> A CommitComment returned from `GitLabRepository::addCommitComment` no longer contains a value for ID. I think this is more correct than making up a value. I verified that no code seems to be using the returned object currently, so this shouldn't impact anything.
> 
> The two new tests were run and inspected manually.

This pull request has now been integrated.

Changeset: 439d2662
Author:    Erik Joelsson <erikj at openjdk.org>
URL:       https://git.openjdk.org/skara/commit/439d26621820896e247803f59e388976b9e4b957
Stats:     136 lines in 2 files changed: 76 ins; 20 del; 40 mod

2043: Skara mistakenly tagged the wrong commit when processing a /tag command

Reviewed-by: zsong

-------------

PR: https://git.openjdk.org/skara/pull/1564

From zsong at openjdk.org  Fri Sep 29 18:47:15 2023
From: zsong at openjdk.org (Zhao Song)
Date: Fri, 29 Sep 2023 18:47:15 GMT
Subject: RFR: 2045: Make maintainer approval feature compatible with
 dependent pr feature. [v3]
In-Reply-To: <QOz0O7vPtxJ84ifFPpK4Z-SXN6wwdCausq2ZJ_kibQQ=.9675e64a-9f39-45fa-b703-887acdcfaa23@github.com>
References: <QOz0O7vPtxJ84ifFPpK4Z-SXN6wwdCausq2ZJ_kibQQ=.9675e64a-9f39-45fa-b703-887acdcfaa23@github.com>
Message-ID: <FQqXIM93DUXvw4tQolF1YlaJdtuvRPV8HJIzFCKLs28=.8c486382-c628-4ce1-afae-0538f78227ea@github.com>

> A user reported that a dependent pr in a repo which configured with maintainer approval feature is not marked for approval. 
> 
> After investigation, I realized that the skara bot would determine whether this pr needs maintainer approval by checking whether merging into the target branch needs maintainer approval. 
>   
> In this case, we only configured that merging into master branch of jdk21u needs maintainer approval, however, for dependent pull requests, the target branch is pr/XXX. 
> 
> To fix this issue, we should let the skara bot be able to find the real target ref.

Zhao Song has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:

 - Merge branch 'master' into SKARA-2045
   
   # Conflicts:
   #	bots/pr/src/main/java/org/openjdk/skara/bots/pr/ApprovalCommand.java
 - update
 - update
 - review comment
 - fix an issue
 - add test
 - SKARA-2045

-------------

Changes: https://git.openjdk.org/skara/pull/1562/files
 Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1562&range=02
  Stats: 85 lines in 5 files changed: 75 ins; 1 del; 9 mod
  Patch: https://git.openjdk.org/skara/pull/1562.diff
  Fetch: git fetch https://git.openjdk.org/skara.git pull/1562/head:pull/1562

PR: https://git.openjdk.org/skara/pull/1562

From erikj at openjdk.org  Fri Sep 29 19:00:13 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 29 Sep 2023 19:00:13 GMT
Subject: RFR: 2045: Make maintainer approval feature compatible with
 dependent pr feature. [v3]
In-Reply-To: <FQqXIM93DUXvw4tQolF1YlaJdtuvRPV8HJIzFCKLs28=.8c486382-c628-4ce1-afae-0538f78227ea@github.com>
References: <QOz0O7vPtxJ84ifFPpK4Z-SXN6wwdCausq2ZJ_kibQQ=.9675e64a-9f39-45fa-b703-887acdcfaa23@github.com>
 <FQqXIM93DUXvw4tQolF1YlaJdtuvRPV8HJIzFCKLs28=.8c486382-c628-4ce1-afae-0538f78227ea@github.com>
Message-ID: <SLMtk46l7yVsuzEo8EL5Lgv2K1WP_N7uglhsymbqNro=.3331eeec-6205-4a72-87f9-2affd220a8f6@github.com>

On Fri, 29 Sep 2023 18:47:15 GMT, Zhao Song <zsong at openjdk.org> wrote:

>> A user reported that a dependent pr in a repo which configured with maintainer approval feature is not marked for approval. 
>> 
>> After investigation, I realized that the skara bot would determine whether this pr needs maintainer approval by checking whether merging into the target branch needs maintainer approval. 
>>   
>> In this case, we only configured that merging into master branch of jdk21u needs maintainer approval, however, for dependent pull requests, the target branch is pr/XXX. 
>> 
>> To fix this issue, we should let the skara bot be able to find the real target ref.
>
> Zhao Song has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
> 
>  - Merge branch 'master' into SKARA-2045
>    
>    # Conflicts:
>    #	bots/pr/src/main/java/org/openjdk/skara/bots/pr/ApprovalCommand.java
>  - update
>  - update
>  - review comment
>  - fix an issue
>  - add test
>  - SKARA-2045

Marked as reviewed by erikj (Lead).

-------------

PR Review: https://git.openjdk.org/skara/pull/1562#pullrequestreview-1651334112

From zsong at openjdk.org  Fri Sep 29 19:16:26 2023
From: zsong at openjdk.org (Zhao Song)
Date: Fri, 29 Sep 2023 19:16:26 GMT
Subject: Integrated: 2045: Make maintainer approval feature compatible with
 dependent pr feature.
In-Reply-To: <QOz0O7vPtxJ84ifFPpK4Z-SXN6wwdCausq2ZJ_kibQQ=.9675e64a-9f39-45fa-b703-887acdcfaa23@github.com>
References: <QOz0O7vPtxJ84ifFPpK4Z-SXN6wwdCausq2ZJ_kibQQ=.9675e64a-9f39-45fa-b703-887acdcfaa23@github.com>
Message-ID: <XxttuW8CBAcIIkR8kcDWCwlfWgwjHUgVm3Wglx7kUhI=.c4867acb-f7f9-45ac-a5b9-edd48f628b81@github.com>

On Wed, 27 Sep 2023 19:50:25 GMT, Zhao Song <zsong at openjdk.org> wrote:

> A user reported that a dependent pr in a repo which configured with maintainer approval feature is not marked for approval. 
> 
> After investigation, I realized that the skara bot would determine whether this pr needs maintainer approval by checking whether merging into the target branch needs maintainer approval. 
>   
> In this case, we only configured that merging into master branch of jdk21u needs maintainer approval, however, for dependent pull requests, the target branch is pr/XXX. 
> 
> To fix this issue, we should let the skara bot be able to find the real target ref.

This pull request has now been integrated.

Changeset: ba26745a
Author:    Zhao Song <zsong at openjdk.org>
URL:       https://git.openjdk.org/skara/commit/ba26745a5e73aa6e15671d81704f53d5774299dd
Stats:     85 lines in 5 files changed: 75 ins; 1 del; 9 mod

2045: Make maintainer approval feature compatible with dependent pr feature.

Reviewed-by: erikj

-------------

PR: https://git.openjdk.org/skara/pull/1562

From zsong at openjdk.org  Fri Sep 29 19:16:26 2023
From: zsong at openjdk.org (Zhao Song)
Date: Fri, 29 Sep 2023 19:16:26 GMT
Subject: RFR: 2045: Make maintainer approval feature compatible with
 dependent pr feature. [v3]
In-Reply-To: <FQqXIM93DUXvw4tQolF1YlaJdtuvRPV8HJIzFCKLs28=.8c486382-c628-4ce1-afae-0538f78227ea@github.com>
References: <QOz0O7vPtxJ84ifFPpK4Z-SXN6wwdCausq2ZJ_kibQQ=.9675e64a-9f39-45fa-b703-887acdcfaa23@github.com>
 <FQqXIM93DUXvw4tQolF1YlaJdtuvRPV8HJIzFCKLs28=.8c486382-c628-4ce1-afae-0538f78227ea@github.com>
Message-ID: <xWtbGkgfzSsSnwgG_lrmAWXS3xAXzIeR3q8-TP5mnSs=.34257928-a743-498b-af32-25d9694ad1a0@github.com>

On Fri, 29 Sep 2023 18:47:15 GMT, Zhao Song <zsong at openjdk.org> wrote:

>> A user reported that a dependent pr in a repo which configured with maintainer approval feature is not marked for approval. 
>> 
>> After investigation, I realized that the skara bot would determine whether this pr needs maintainer approval by checking whether merging into the target branch needs maintainer approval. 
>>   
>> In this case, we only configured that merging into master branch of jdk21u needs maintainer approval, however, for dependent pull requests, the target branch is pr/XXX. 
>> 
>> To fix this issue, we should let the skara bot be able to find the real target ref.
>
> Zhao Song has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
> 
>  - Merge branch 'master' into SKARA-2045
>    
>    # Conflicts:
>    #	bots/pr/src/main/java/org/openjdk/skara/bots/pr/ApprovalCommand.java
>  - update
>  - update
>  - review comment
>  - fix an issue
>  - add test
>  - SKARA-2045

Thanks!

-------------

PR Comment: https://git.openjdk.org/skara/pull/1562#issuecomment-1741369345