From gli at openjdk.java.net Mon May 2 16:09:25 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Mon, 2 May 2022 16:09:25 GMT Subject: Integrated: 1407: GitLabMergeRequest#filesUrl returns wrong result In-Reply-To: References: Message-ID: On Sat, 23 Apr 2022 21:22:34 GMT, Guoxiong Li wrote: > Hi all, > > The SKARA-744 [1][2] solved a problem about the link to the changes for just one commit. But it didn't solve the issue completely in GitLab. Please see the current issue [3] for more information. > > This patch revises `GitLabMergeRequest#filesUrl` to return a `version url` if it exists which can represent the changed files **from the first commit to the provided commit HASH**. A corresponding test is added and a previous test is polished. > > You can use the following config to run the new test `GitLabRestApiTest#testFilesUrl`: > > > gitlab.user= > gitlab.pat= > > gitlab.uri=https://gitlab.com > gitlab.repository=35596381 > gitlab.merge.request.id=1 > > gitlab.version.hash=60f39eb698e73cc2660f870667a54e7a53ee7018 > gitlab.version.url=https://gitlab.com/lgxbslgx/test/-/merge_requests/1/diffs?diff_id=379601911 > gitlab.nonversion.hash=c9b5a70790b13c3e7e182c9b83015f9f10d53df7 > gitlab.nonversion.url=https://gitlab.com/lgxbslgx/test/-/merge_requests/1/diffs?commit_id=c9b5a70790b13c3e7e182c9b83015f9f10d53df7 > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong > > [1] https://bugs.openjdk.java.net/browse/SKARA-744 > [2] https://git.openjdk.java.net/skara/commit/f16663b7 > [3] https://bugs.openjdk.java.net/browse/SKARA-1407 This pull request has now been integrated. Changeset: 3d3e4d9d Author: Guoxiong Li Committer: Erik Joelsson URL: https://git.openjdk.java.net/skara/commit/3d3e4d9dc5567652d84fea4a1cfc4aeacac63d00 Stats: 76 lines in 3 files changed: 71 ins; 0 del; 5 mod 1407: GitLabMergeRequest#filesUrl returns wrong result Reviewed-by: erikj ------------- PR: https://git.openjdk.java.net/skara/pull/1304 From gli at openjdk.java.net Mon May 2 16:10:20 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Mon, 2 May 2022 16:10:20 GMT Subject: Integrated: 1395: The "Review applies to " link is misleading In-Reply-To: <3otviio5QVDRGqEX7ott0Pa4CaTK1dml0tf1bNsabHw=.350e2297-3156-42a4-bdfb-bcddab8364c3@github.com> References: <3otviio5QVDRGqEX7ott0Pa4CaTK1dml0tf1bNsabHw=.350e2297-3156-42a4-bdfb-bcddab8364c3@github.com> Message-ID: On Sat, 23 Apr 2022 15:48:52 GMT, Guoxiong Li wrote: > Hi all, > > This trivial patch changes the `commit hash value` to a link which contains the changed files from the first commit of a PR to this `commit`. And the test case is adjusted. > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong This pull request has now been integrated. Changeset: c5459cd6 Author: Guoxiong Li Committer: Erik Joelsson URL: https://git.openjdk.java.net/skara/commit/c5459cd64fe13e20f8422e382c7ca507a5c589ea Stats: 6 lines in 2 files changed: 3 ins; 0 del; 3 mod 1395: The "Review applies to " link is misleading Reviewed-by: erikj ------------- PR: https://git.openjdk.java.net/skara/pull/1303 From erikj at openjdk.java.net Mon May 2 16:11:14 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 2 May 2022 16:11:14 GMT Subject: RFR: 282: Make the review requirements more explicit in the progress list [v5] In-Reply-To: References: Message-ID: On Fri, 29 Apr 2022 23:38:30 GMT, Guoxiong Li wrote: >> Hi all, >> >> This patch adds the explicit review requirements, such as ` (2 reviews required, with at least 1 Reviewer).`, to the progress list and adds some test cases. >> >> Thanks for taking the time to review. >> >> Best Regards, >> -- Guoxiong > > Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: > > Move space and parentheses. Marked as reviewed by erikj (Lead). ------------- PR: https://git.openjdk.java.net/skara/pull/1305 From gli at openjdk.java.net Mon May 2 16:12:30 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Mon, 2 May 2022 16:12:30 GMT Subject: Integrated: 1118: The Skara PR bot should not block on a CSR if not enabled for a repo In-Reply-To: <_2zDu99u_ja1C3hOKD2UVBRlRvXh5UPq5QdaOgGhKM4=.1c371438-821f-455d-a673-5bc6643dd321@github.com> References: <_2zDu99u_ja1C3hOKD2UVBRlRvXh5UPq5QdaOgGhKM4=.1c371438-821f-455d-a673-5bc6643dd321@github.com> Message-ID: On Tue, 26 Apr 2022 13:20:08 GMT, Guoxiong Li wrote: > Hi all, > > This patch adds a config item `enable-csr` for the PullRequestbot and then the `CSRCommand` firstly checks whether the csr is enabled. If not enabled, the `CSRCommand` will reply a message about it. > > Thanks for taking the time to review. > > Best Regards, > -- Guoxion This pull request has now been integrated. Changeset: b9e89e20 Author: Guoxiong Li Committer: Erik Joelsson URL: https://git.openjdk.java.net/skara/commit/b9e89e202deab7d7d192a61b1fd76e2510b33f64 Stats: 81 lines in 6 files changed: 62 ins; 0 del; 19 mod 1118: The Skara PR bot should not block on a CSR if not enabled for a repo Reviewed-by: erikj ------------- PR: https://git.openjdk.java.net/skara/pull/1308 From gli at openjdk.java.net Mon May 2 16:14:24 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Mon, 2 May 2022 16:14:24 GMT Subject: Integrated: 1418: Dependent pull requests: inacurrate bot comment In-Reply-To: References: Message-ID: On Fri, 29 Apr 2022 15:21:05 GMT, Guoxiong Li wrote: > Hi all, > > The patch fixes the comment when the dependent pull request was integrated and revises the corresponding test case. > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong This pull request has now been integrated. Changeset: 6d139318 Author: Guoxiong Li Committer: Erik Joelsson URL: https://git.openjdk.java.net/skara/commit/6d139318bb0d5fc1be218cd1221e3177e6a740f9 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod 1418: Dependent pull requests: inacurrate bot comment Reviewed-by: erikj ------------- PR: https://git.openjdk.java.net/skara/pull/1309 From gli at openjdk.java.net Mon May 2 16:26:05 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Mon, 2 May 2022 16:26:05 GMT Subject: RFR: 282: Make the review requirements more explicit in the progress list In-Reply-To: References: Message-ID: On Tue, 26 Apr 2022 18:12:29 GMT, Erik Joelsson wrote: >>> To do this the TooFewReviewersIssue would need to hold the requirements string from the configuration, but I think it makes enough sense for it to do that. ReviewersCheck has access to it and can provide it to the constructor. >> >> I tried this way at first when I solved this issue. But then I found the ReviewersCheck doesn?t always return the TooFewReviewersIssue which means the message may miss sometimes. And if we return the message in all the issues of the ReviewersCheck, the message may also miss when the ReviewersCheck passes without any issue. > >> I tried this way at first when I solved this issue. But then I found the ReviewersCheck doesn?t always return the TooFewReviewersIssue which means the message may miss sometimes. And if we return the message in all the issues of the ReviewersCheck, the message may also miss when the ReviewersCheck passes without any issue. > > Right, this would only work when the checkbox isn't checked. > > My biggest issue here is that you are storing mutable state in `CheckablePullRequest`. That class is currently immutable. > > Here is what I would suggest instead. Still move the logic for generating the reviewers description string to ReviewersConfiguration. Add a field to `PullRequestCheckIssueVisitor` for holding a Jcheck configuration. Set this field from `CheckablePullRequest::executeChecks`. The visitor is already a class that carries a mutable state, so this is kind of ok. Then in `PullRequestCheckIssueVisitor::get*Checks` explicitly modify the description for ReviewersCheck in the returned map. I would recommend a new private method that wraps the `Check::description` call and extracts the reviewer information from the conf field. @erikj79 Thanks for the review. ------------- PR: https://git.openjdk.java.net/skara/pull/1305 From gli at openjdk.java.net Mon May 2 16:26:16 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Mon, 2 May 2022 16:26:16 GMT Subject: RFR: 1408: GitLabMergeRequest#reviews sometimes finds the wrong commit HASH [v2] In-Reply-To: References: Message-ID: > Hi all, > > Please consider the following steps: > > - the author creates "commit 1" locally (with hash "95f2d613cf392275075d7c87285845531f5fe827" [1]) > - the author pushes it and creates a merge request in the Gitlab, then the Gitlab creates "version 1" [2] (its hash is the hash of "commit 1") which has the changed files of "commit 1" > - the author creates "commit 2" locally (with hash "99ca51edfa0063113a2236fce548ba453aee7275" [3]) > - a reviewer approves the MR with the "**version 1**" in the Gitlab. Note: the "commit 2" is not pushed now. > - the author creates "commit 3" locally (with hash "50b119c4c325053b8151ea6e761a60d1acfbb746" [4]) Note: this step seems optional > - the author pushes the commits and the gitlab create "version 2" [5] (its hash is the hash of "commit 3") which has the changed files of "commit 1-3" > > When we use the method `GitLabMergeRequest#reviews` to get the reviews list, we can see the review hash is the hash of the "commit 2" ("99ca51edfa0063113a2236fce548ba453aee7275"). But actually, the reviewer only approved "version 1" with hash of the "commit 1" ("95f2d613cf392275075d7c87285845531f5fe827"). > > This patch uses the `versions` list instead of all the `commits` list to fix the issue. And when I wrote a test case to verify it, I got a NPE and filed SKARA-1409 to record it. This patch also solves SKARA-1409 so that the reviewer can run the test locally. > > You can use the following config to run the test: > > gitlab.user= > gitlab.pat= > > gitlab.uri=https://gitlab.com > gitlab.repository=35596381 > gitlab.merge.request.id=2 > gitlab.review.hash=95f2d613cf392275075d7c87285845531f5fe827 > > > Note: this PR seems have git conflict with [SKARA-1407-PATCH](https://github.com/openjdk/skara/pull/1304). I will solve the conflict when one of them is integrated. > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong > > [1] https://gitlab.com/lgxbslgx/test/-/merge_requests/2/diffs?commit_id=95f2d613cf392275075d7c87285845531f5fe827 > [2] https://gitlab.com/lgxbslgx/test/-/merge_requests/2/diffs?diff_id=379883693 > [3] https://gitlab.com/lgxbslgx/test/-/merge_requests/2/diffs?commit_id=99ca51edfa0063113a2236fce548ba453aee7275 > [4] https://gitlab.com/lgxbslgx/test/-/merge_requests/2/diffs?commit_id=50b119c4c325053b8151ea6e761a60d1acfbb746 > [5] https://gitlab.com/lgxbslgx/test/-/merge_requests/2/diffs?diff_id=379907777 > > --- Guoxiong Li has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: - Merge branch 'master' into SKARA-1408 # Conflicts: # forge/src/test/java/org/openjdk/skara/forge/gitlab/GitLabRestApiTest.java - Disable test. - 1409: The GitLab 'list-users' api doesn't return 'email' field for normal users - 1408: GitLabMergeRequest#reviews sometimes finds the wrong commit HASH ------------- Changes: https://git.openjdk.java.net/skara/pull/1306/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1306&range=01 Stats: 20 lines in 3 files changed: 16 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/skara/pull/1306.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1306/head:pull/1306 PR: https://git.openjdk.java.net/skara/pull/1306 From gli at openjdk.java.net Mon May 2 16:26:16 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Mon, 2 May 2022 16:26:16 GMT Subject: RFR: 1408: GitLabMergeRequest#reviews sometimes finds the wrong commit HASH In-Reply-To: References: Message-ID: On Mon, 25 Apr 2022 09:37:04 GMT, Guoxiong Li wrote: > Hi all, > > Please consider the following steps: > > - the author creates "commit 1" locally (with hash "95f2d613cf392275075d7c87285845531f5fe827" [1]) > - the author pushes it and creates a merge request in the Gitlab, then the Gitlab creates "version 1" [2] (its hash is the hash of "commit 1") which has the changed files of "commit 1" > - the author creates "commit 2" locally (with hash "99ca51edfa0063113a2236fce548ba453aee7275" [3]) > - a reviewer approves the MR with the "**version 1**" in the Gitlab. Note: the "commit 2" is not pushed now. > - the author creates "commit 3" locally (with hash "50b119c4c325053b8151ea6e761a60d1acfbb746" [4]) Note: this step seems optional > - the author pushes the commits and the gitlab create "version 2" [5] (its hash is the hash of "commit 3") which has the changed files of "commit 1-3" > > When we use the method `GitLabMergeRequest#reviews` to get the reviews list, we can see the review hash is the hash of the "commit 2" ("99ca51edfa0063113a2236fce548ba453aee7275"). But actually, the reviewer only approved "version 1" with hash of the "commit 1" ("95f2d613cf392275075d7c87285845531f5fe827"). > > This patch uses the `versions` list instead of all the `commits` list to fix the issue. And when I wrote a test case to verify it, I got a NPE and filed SKARA-1409 to record it. This patch also solves SKARA-1409 so that the reviewer can run the test locally. > > You can use the following config to run the test: > > gitlab.user= > gitlab.pat= > > gitlab.uri=https://gitlab.com > gitlab.repository=35596381 > gitlab.merge.request.id=2 > gitlab.review.hash=95f2d613cf392275075d7c87285845531f5fe827 > > > Note: this PR seems have git conflict with [SKARA-1407-PATCH](https://github.com/openjdk/skara/pull/1304). I will solve the conflict when one of them is integrated. > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong > > [1] https://gitlab.com/lgxbslgx/test/-/merge_requests/2/diffs?commit_id=95f2d613cf392275075d7c87285845531f5fe827 > [2] https://gitlab.com/lgxbslgx/test/-/merge_requests/2/diffs?diff_id=379883693 > [3] https://gitlab.com/lgxbslgx/test/-/merge_requests/2/diffs?commit_id=99ca51edfa0063113a2236fce548ba453aee7275 > [4] https://gitlab.com/lgxbslgx/test/-/merge_requests/2/diffs?commit_id=50b119c4c325053b8151ea6e761a60d1acfbb746 > [5] https://gitlab.com/lgxbslgx/test/-/merge_requests/2/diffs?diff_id=379907777 > > --- I solved the git conflict just now. ------------- PR: https://git.openjdk.java.net/skara/pull/1306 From gli at openjdk.java.net Mon May 2 16:55:46 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Mon, 2 May 2022 16:55:46 GMT Subject: Integrated: 1408: GitLabMergeRequest#reviews sometimes finds the wrong commit HASH In-Reply-To: References: Message-ID: <4ZsK9FK44Tq4TKMCvHd14qhe8iWXNANCyvgLRQAtF6s=.363ef4d1-fef0-4197-be5e-0e34cd2d2e9e@github.com> On Mon, 25 Apr 2022 09:37:04 GMT, Guoxiong Li wrote: > Hi all, > > Please consider the following steps: > > - the author creates "commit 1" locally (with hash "95f2d613cf392275075d7c87285845531f5fe827" [1]) > - the author pushes it and creates a merge request in the Gitlab, then the Gitlab creates "version 1" [2] (its hash is the hash of "commit 1") which has the changed files of "commit 1" > - the author creates "commit 2" locally (with hash "99ca51edfa0063113a2236fce548ba453aee7275" [3]) > - a reviewer approves the MR with the "**version 1**" in the Gitlab. Note: the "commit 2" is not pushed now. > - the author creates "commit 3" locally (with hash "50b119c4c325053b8151ea6e761a60d1acfbb746" [4]) Note: this step seems optional > - the author pushes the commits and the gitlab create "version 2" [5] (its hash is the hash of "commit 3") which has the changed files of "commit 1-3" > > When we use the method `GitLabMergeRequest#reviews` to get the reviews list, we can see the review hash is the hash of the "commit 2" ("99ca51edfa0063113a2236fce548ba453aee7275"). But actually, the reviewer only approved "version 1" with hash of the "commit 1" ("95f2d613cf392275075d7c87285845531f5fe827"). > > This patch uses the `versions` list instead of all the `commits` list to fix the issue. And when I wrote a test case to verify it, I got a NPE and filed SKARA-1409 to record it. This patch also solves SKARA-1409 so that the reviewer can run the test locally. > > You can use the following config to run the test: > > gitlab.user= > gitlab.pat= > > gitlab.uri=https://gitlab.com > gitlab.repository=35596381 > gitlab.merge.request.id=2 > gitlab.review.hash=95f2d613cf392275075d7c87285845531f5fe827 > > > Note: this PR seems have git conflict with [SKARA-1407-PATCH](https://github.com/openjdk/skara/pull/1304). I will solve the conflict when one of them is integrated. > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong > > [1] https://gitlab.com/lgxbslgx/test/-/merge_requests/2/diffs?commit_id=95f2d613cf392275075d7c87285845531f5fe827 > [2] https://gitlab.com/lgxbslgx/test/-/merge_requests/2/diffs?diff_id=379883693 > [3] https://gitlab.com/lgxbslgx/test/-/merge_requests/2/diffs?commit_id=99ca51edfa0063113a2236fce548ba453aee7275 > [4] https://gitlab.com/lgxbslgx/test/-/merge_requests/2/diffs?commit_id=50b119c4c325053b8151ea6e761a60d1acfbb746 > [5] https://gitlab.com/lgxbslgx/test/-/merge_requests/2/diffs?diff_id=379907777 > > --- This pull request has now been integrated. Changeset: 079d2092 Author: Guoxiong Li Committer: Erik Joelsson URL: https://git.openjdk.java.net/skara/commit/079d20928990a0a1fbaf969341b7a3210a33bd18 Stats: 20 lines in 3 files changed: 16 ins; 0 del; 4 mod 1408: GitLabMergeRequest#reviews sometimes finds the wrong commit HASH 1409: The GitLab 'list-users' api doesn't return 'email' field for normal users Reviewed-by: erikj ------------- PR: https://git.openjdk.java.net/skara/pull/1306 From gli at openjdk.java.net Mon May 2 16:57:41 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Mon, 2 May 2022 16:57:41 GMT Subject: Integrated: 282: Make the review requirements more explicit in the progress list In-Reply-To: References: Message-ID: On Sun, 24 Apr 2022 15:59:42 GMT, Guoxiong Li wrote: > Hi all, > > This patch adds the explicit review requirements, such as ` (2 reviews required, with at least 1 Reviewer).`, to the progress list and adds some test cases. > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong This pull request has now been integrated. Changeset: 35d260dc Author: Guoxiong Li Committer: Erik Joelsson URL: https://git.openjdk.java.net/skara/commit/35d260dcd33a3b8d1e03c10b625e983b3a27903c Stats: 291 lines in 5 files changed: 273 ins; 1 del; 17 mod 282: Make the review requirements more explicit in the progress list Reviewed-by: erikj ------------- PR: https://git.openjdk.java.net/skara/pull/1305 From gli at openjdk.java.net Tue May 3 00:26:48 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Tue, 3 May 2022 00:26:48 GMT Subject: RFR: 1419: The Skara PR bot should not block on a JEP if not enabled for a repo Message-ID: <_m5KmF1x45XWNOi6Asvk_PIUJDbUeAWDg4DrEwmnkA4=.20d9284a-6bd3-4ea3-a4eb-38697530b9eb@github.com> Hi all, If a repository doesn't support JEP and someone issues the `/jep` command in the PR of this repo, the bot should replies a comment instead of blocking the PR. This patch adds a jep config to the PR bot and adjusts the test cases. Thanks for taking the time to review. Best Regards, -- Guoxiong ------------- Commit messages: - 1419: The Skara PR bot should not block on a JEP if not enabled for a repo Changes: https://git.openjdk.java.net/skara/pull/1310/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1310&range=00 Issue: https://bugs.openjdk.java.net/browse/SKARA-1419 Stats: 27 lines in 6 files changed: 20 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/skara/pull/1310.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1310/head:pull/1310 PR: https://git.openjdk.java.net/skara/pull/1310 From gli at openjdk.java.net Tue May 3 07:14:38 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Tue, 3 May 2022 07:14:38 GMT Subject: RFR: 1422: Remove the need to type `JEP-` or `jep-` prefix in `jep` command Message-ID: Hi all, This patch permits the strange grammer like `/jep jEP-123` and removes the need of the `JEP-` or `jep-` prefix. When the prefix (`JDK-`, `JEP-` or others) is not provided, the bot treats it as a JEP ID firstly. If the issue is not found, the bot then treats it as an issue ID. Thanks for taking the time to review. Best Regards, -- Guoxiong ------------- Commit messages: - 1422: Remove the need to type `JEP-` or `jep-` prefix in `jep` command Changes: https://git.openjdk.java.net/skara/pull/1311/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1311&range=00 Issue: https://bugs.openjdk.java.net/browse/SKARA-1422 Stats: 82 lines in 2 files changed: 58 ins; 10 del; 14 mod Patch: https://git.openjdk.java.net/skara/pull/1311.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1311/head:pull/1311 PR: https://git.openjdk.java.net/skara/pull/1311 From magnus.ihse.bursie at oracle.com Tue May 3 12:13:25 2022 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 3 May 2022 14:13:25 +0200 Subject: CFV: New Skara Committer: Guoxiong Li Message-ID: I hereby nominate Guoxiong Li to Skara Committer. Guoxiong has contributed multiple patches to the Skara project. He has been a prolific contributor at a time when other resources to Skara has been scarce, and has shown a high level of commitment to finishing the patches and upholding good code quality. Votes are due by May 18. Only current Skara Committers [1] are eligible to vote on this nomination.? Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. /Magnus [1] http://openjdk.java.net/census [2] http://openjdk.java.net/projects/#committer-vote From magnus.ihse.bursie at oracle.com Tue May 3 12:14:20 2022 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 3 May 2022 14:14:20 +0200 Subject: CFV: New Skara Committer: Guoxiong Li In-Reply-To: References: Message-ID: <093ae276-922f-5f3c-b869-4a87723843f6@oracle.com> Vote: yes /Magnus On 2022-05-03 14:13, Magnus Ihse Bursie wrote: > I hereby nominate Guoxiong Li to Skara Committer. > > Guoxiong has contributed multiple patches to the Skara project. He has > been a prolific contributor at a time when other resources to Skara > has been scarce, and has shown a high level of commitment to finishing > the patches and upholding good code quality. > > Votes are due by May 18. > > Only current Skara Committers [1] are eligible to vote > on this nomination.? Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > /Magnus > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote From erik.joelsson at oracle.com Tue May 3 12:23:36 2022 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Tue, 3 May 2022 05:23:36 -0700 Subject: CFV: New Skara Committer: Guoxiong Li In-Reply-To: References: Message-ID: <93dc7415-2dc6-f6e4-45fc-c4ff9e64a48f@oracle.com> Vote: yes /Erik On 2022-05-03 05:13, Magnus Ihse Bursie wrote: > I hereby nominate Guoxiong Li to Skara Committer. > > Guoxiong has contributed multiple patches to the Skara project. He has > been a prolific contributor at a time when other resources to Skara > has been scarce, and has shown a high level of commitment to finishing > the patches and upholding good code quality. > > Votes are due by May 18. > > Only current Skara Committers [1] are eligible to vote > on this nomination.? Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > /Magnus > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote From kevin.rushforth at oracle.com Tue May 3 12:35:07 2022 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 3 May 2022 05:35:07 -0700 Subject: CFV: New Skara Committer: Guoxiong Li In-Reply-To: References: Message-ID: <81f3a200-3b0a-ca48-fc24-0a266e86884c@oracle.com> Vote: YES On 5/3/2022 5:13 AM, Magnus Ihse Bursie wrote: > I hereby nominate Guoxiong Li to Skara Committer. From erikj at openjdk.java.net Tue May 3 12:54:26 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 3 May 2022 12:54:26 GMT Subject: RFR: 1422: Remove the need to type `JEP-` or `jep-` prefix in `jep` command In-Reply-To: References: Message-ID: On Tue, 3 May 2022 07:10:44 GMT, Guoxiong Li wrote: > Hi all, > > This patch permits the strange grammer like `/jep jEP-123` and removes the need of the `JEP-` or `jep-` prefix. > When the prefix (`JDK-`, `JEP-` or others) is not provided, the bot treats it as a JEP ID firstly. > If the issue is not found, the bot then treats it as an issue ID. > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong bots/pr/src/main/java/org/openjdk/skara/bots/pr/JEPCommand.java line 58: > 56: * `/jep jep-123` > 57: * `/jep JEP-123` > 58: * `/jep 123` I would suggest putting this example first. Also, there is an empty line after "Some examples:" but not after "Command syntax:". That looks weird. bots/pr/src/main/java/org/openjdk/skara/bots/pr/JEPCommand.java line 65: > 63: The bot firstly treats the ID without prefix as a JEP ID. > 64: If not found, the bot then treats the ID without prefix as an issue ID. > 65: The issue type in any case must be `JEP`. Suggestion: The prefix (i.e. `JDK-`, `JEP-` or `jep-`) is optional. If the argument is given without prefix, it will be tried first as a JEP ID and second as an issue ID. The issue type must be `JEP`. A text block here is good for formatting the syntax and examples, but text should not be forcibly line broken. Consider adding the text paragraph as an additional string so that it may be broken up in code, but not when posted. bots/pr/src/main/java/org/openjdk/skara/bots/pr/JEPCommand.java line 83: > 81: jbsIssue = bot.issueProject().jepIssue(args); > 82: if (jbsIssue.isEmpty()) { > 83: reply.println("The JEP issue of the JEP argument `" + args + "` was not found. " + Do we really need to print a message about this? ------------- PR: https://git.openjdk.java.net/skara/pull/1311 From erikj at openjdk.java.net Tue May 3 12:54:27 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 3 May 2022 12:54:27 GMT Subject: RFR: 1422: Remove the need to type `JEP-` or `jep-` prefix in `jep` command In-Reply-To: References: Message-ID: On Tue, 3 May 2022 12:45:50 GMT, Erik Joelsson wrote: >> Hi all, >> >> This patch permits the strange grammer like `/jep jEP-123` and removes the need of the `JEP-` or `jep-` prefix. >> When the prefix (`JDK-`, `JEP-` or others) is not provided, the bot treats it as a JEP ID firstly. >> If the issue is not found, the bot then treats it as an issue ID. >> >> Thanks for taking the time to review. >> >> Best Regards, >> -- Guoxiong > > bots/pr/src/main/java/org/openjdk/skara/bots/pr/JEPCommand.java line 83: > >> 81: jbsIssue = bot.issueProject().jepIssue(args); >> 82: if (jbsIssue.isEmpty()) { >> 83: reply.println("The JEP issue of the JEP argument `" + args + "` was not found. " + > > Do we really need to print a message about this? I also noted that on line 150 and 156, the message doesn't start with a capital letter. Could you fix that too? ------------- PR: https://git.openjdk.java.net/skara/pull/1311 From erikj at openjdk.java.net Tue May 3 12:54:56 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 3 May 2022 12:54:56 GMT Subject: RFR: 1419: The Skara PR bot should not block on a JEP if not enabled for a repo In-Reply-To: <_m5KmF1x45XWNOi6Asvk_PIUJDbUeAWDg4DrEwmnkA4=.20d9284a-6bd3-4ea3-a4eb-38697530b9eb@github.com> References: <_m5KmF1x45XWNOi6Asvk_PIUJDbUeAWDg4DrEwmnkA4=.20d9284a-6bd3-4ea3-a4eb-38697530b9eb@github.com> Message-ID: On Tue, 3 May 2022 00:22:47 GMT, Guoxiong Li wrote: > Hi all, > > If a repository doesn't support JEP and someone issues the `/jep` command in the PR of this repo, the bot should replies a comment instead of blocking the PR. This patch adds a jep config to the PR bot and adjusts the test cases. > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong bots/pr/src/main/java/org/openjdk/skara/bots/pr/JEPCommand.java line 83: > 81: List allComments, PrintWriter reply, List labelsToAdd, List labelsToRemove) { > 82: if (!bot.enableJep()) { > 83: reply.println("this repository is not allowed to use the `jep` command."); Suggestion: reply.println("This repository has not been configured to use the `jep` command."); ------------- PR: https://git.openjdk.java.net/skara/pull/1310 From gli at openjdk.java.net Tue May 3 13:06:08 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Tue, 3 May 2022 13:06:08 GMT Subject: RFR: 1419: The Skara PR bot should not block on a JEP if not enabled for a repo In-Reply-To: References: <_m5KmF1x45XWNOi6Asvk_PIUJDbUeAWDg4DrEwmnkA4=.20d9284a-6bd3-4ea3-a4eb-38697530b9eb@github.com> Message-ID: On Tue, 3 May 2022 12:52:05 GMT, Erik Joelsson wrote: >> Hi all, >> >> If a repository doesn't support JEP and someone issues the `/jep` command in the PR of this repo, the bot should replies a comment instead of blocking the PR. This patch adds a jep config to the PR bot and adjusts the test cases. >> >> Thanks for taking the time to review. >> >> Best Regards, >> -- Guoxiong > > bots/pr/src/main/java/org/openjdk/skara/bots/pr/JEPCommand.java line 83: > >> 81: List allComments, PrintWriter reply, List labelsToAdd, List labelsToRemove) { >> 82: if (!bot.enableJep()) { >> 83: reply.println("this repository is not allowed to use the `jep` command."); > > Suggestion: > > reply.println("This repository has not been configured to use the `jep` command."); Does the csr command also use the `has not been configured`. ------------- PR: https://git.openjdk.java.net/skara/pull/1310 From gli at openjdk.java.net Tue May 3 13:40:09 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Tue, 3 May 2022 13:40:09 GMT Subject: RFR: 1419: The Skara PR bot should not block on a JEP if not enabled for a repo [v2] In-Reply-To: <_m5KmF1x45XWNOi6Asvk_PIUJDbUeAWDg4DrEwmnkA4=.20d9284a-6bd3-4ea3-a4eb-38697530b9eb@github.com> References: <_m5KmF1x45XWNOi6Asvk_PIUJDbUeAWDg4DrEwmnkA4=.20d9284a-6bd3-4ea3-a4eb-38697530b9eb@github.com> Message-ID: > Hi all, > > If a repository doesn't support JEP and someone issues the `/jep` command in the PR of this repo, the bot should replies a comment instead of blocking the PR. This patch adds a jep config to the PR bot and adjusts the test cases. > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong Guoxiong Li has updated the pull request incrementally with two additional commits since the last revision: - Fix comment of the csr command. - Fix commment of the jep command and add a test case. ------------- Changes: - all: https://git.openjdk.java.net/skara/pull/1310/files - new: https://git.openjdk.java.net/skara/pull/1310/files/e2386e47..b1dfc46d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=skara&pr=1310&range=01 - incr: https://webrevs.openjdk.java.net/?repo=skara&pr=1310&range=00-01 Stats: 48 lines in 4 files changed: 45 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/skara/pull/1310.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1310/head:pull/1310 PR: https://git.openjdk.java.net/skara/pull/1310 From gli at openjdk.java.net Tue May 3 13:40:10 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Tue, 3 May 2022 13:40:10 GMT Subject: RFR: 1419: The Skara PR bot should not block on a JEP if not enabled for a repo [v2] In-Reply-To: References: <_m5KmF1x45XWNOi6Asvk_PIUJDbUeAWDg4DrEwmnkA4=.20d9284a-6bd3-4ea3-a4eb-38697530b9eb@github.com> Message-ID: On Tue, 3 May 2022 13:03:16 GMT, Guoxiong Li wrote: >> bots/pr/src/main/java/org/openjdk/skara/bots/pr/JEPCommand.java line 83: >> >>> 81: List allComments, PrintWriter reply, List labelsToAdd, List labelsToRemove) { >>> 82: if (!bot.enableJep()) { >>> 83: reply.println("this repository is not allowed to use the `jep` command."); >> >> Suggestion: >> >> reply.println("This repository has not been configured to use the `jep` command."); > > Does the csr command also use the `has not been configured`? Fixed. And the csr command is also adjusted. ------------- PR: https://git.openjdk.java.net/skara/pull/1310 From gli at openjdk.java.net Tue May 3 14:22:03 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Tue, 3 May 2022 14:22:03 GMT Subject: RFR: 1422: Remove the need to type `JEP-` or `jep-` prefix in `jep` command [v2] In-Reply-To: References: Message-ID: > Hi all, > > This patch permits the strange grammer like `/jep jEP-123` and removes the need of the `JEP-` or `jep-` prefix. > When the prefix (`JDK-`, `JEP-` or others) is not provided, the bot treats it as a JEP ID firstly. > If the issue is not found, the bot then treats it as an issue ID. > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: Fix some comments/messages. Adjust some test cases. ------------- Changes: - all: https://git.openjdk.java.net/skara/pull/1311/files - new: https://git.openjdk.java.net/skara/pull/1311/files/5f9f5203..19bbf76c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=skara&pr=1311&range=01 - incr: https://webrevs.openjdk.java.net/?repo=skara&pr=1311&range=00-01 Stats: 28 lines in 2 files changed: 6 ins; 3 del; 19 mod Patch: https://git.openjdk.java.net/skara/pull/1311.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1311/head:pull/1311 PR: https://git.openjdk.java.net/skara/pull/1311 From gli at openjdk.java.net Tue May 3 14:22:04 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Tue, 3 May 2022 14:22:04 GMT Subject: RFR: 1422: Remove the need to type `JEP-` or `jep-` prefix in `jep` command [v2] In-Reply-To: References: Message-ID: On Tue, 3 May 2022 12:32:14 GMT, Erik Joelsson wrote: >> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix some comments/messages. Adjust some test cases. > > bots/pr/src/main/java/org/openjdk/skara/bots/pr/JEPCommand.java line 58: > >> 56: * `/jep jep-123` >> 57: * `/jep JEP-123` >> 58: * `/jep 123` > > I would suggest putting this example first. > > Also, there is an empty line after "Some examples:" but not after "Command syntax:". That looks weird. Fixed. > bots/pr/src/main/java/org/openjdk/skara/bots/pr/JEPCommand.java line 65: > >> 63: The bot firstly treats the ID without prefix as a JEP ID. >> 64: If not found, the bot then treats the ID without prefix as an issue ID. >> 65: The issue type in any case must be `JEP`. > > Suggestion: > > The prefix (i.e. `JDK-`, `JEP-` or `jep-`) is optional. If the argument is given without prefix, it will be tried first as a JEP ID and second as an issue ID. The issue type must be `JEP`. > > > A text block here is good for formatting the syntax and examples, but text should not be forcibly line broken. Consider adding the text paragraph as an additional string so that it may be broken up in code, but not when posted. Fixed. ------------- PR: https://git.openjdk.java.net/skara/pull/1311 From gli at openjdk.java.net Tue May 3 14:22:04 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Tue, 3 May 2022 14:22:04 GMT Subject: RFR: 1422: Remove the need to type `JEP-` or `jep-` prefix in `jep` command [v2] In-Reply-To: References: Message-ID: <2V2hnxCmljkSZhEPdY3FWia-qaMAPZZmlXx_83PzDL0=.47852afb-737e-46a1-a3ae-8963a519f947@github.com> On Tue, 3 May 2022 12:50:14 GMT, Erik Joelsson wrote: > I also noted that on line 150 and 156, the message doesn't start with a capital letter. Could you fix that too? Fixed. > Do we really need to print a message about this? If we don't print such message, when typing `/jep 123` mistakenly (assume the right JEP id is `132` and the issue-123 exists and is not a jep issue), the bot prints `The issue 123 is not a JEP. Please make sure you have entered it correctly`. It may confused the user because the user may think the `123` is a JEP ID instead of a issue ID. And the user may asked why the document said it would firstly be tried as a JEP ID but actually not? ------------- PR: https://git.openjdk.java.net/skara/pull/1311 From tim.bell at oracle.com Tue May 3 17:20:20 2022 From: tim.bell at oracle.com (tim.bell at oracle.com) Date: Tue, 3 May 2022 10:20:20 -0700 Subject: CFV: New Skara Committer: Guoxiong Li In-Reply-To: References: Message-ID: <64e7ca57-4796-8493-7e69-3aa1be4f513b@oracle.com> Vote: yes Tim On 5/3/22 05:13, Magnus Ihse Bursie wrote: > I hereby nominate Guoxiong Li to Skara Committer. From erikj at openjdk.java.net Tue May 3 18:39:47 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 3 May 2022 18:39:47 GMT Subject: RFR: 1424: CheckRun fails to evaluate jol#24 Message-ID: CheckRun, which is part of the PullRequestBot, is currently failing to evaluate https://github.com/openjdk/jol/pull/24. The failure happens in PullRequestUtils::containsForeignMerge where we are looking for merges in the PR branch which bring in commits that aren't descendants of the main merge parent. If this test is positive, the bot adds a comment with a warning. The problem is that GitRepository::mergeBase doesn't differentiate between the git command failing with an error and when it just can't find a merge-base. For this check, a non existent merge-base should qualify for a positive test. I'm refactoring Repository::mergeBase into two methods, one that returns an Optional, which will be empty when a merge-base can't be found. I've also gone through all callers to identify when the new method should be used to properly tell this situation apart. ------------- Commit messages: - SKARA-1424 Changes: https://git.openjdk.java.net/skara/pull/1312/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1312&range=00 Issue: https://bugs.openjdk.java.net/browse/SKARA-1424 Stats: 35 lines in 3 files changed: 26 ins; 3 del; 6 mod Patch: https://git.openjdk.java.net/skara/pull/1312.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1312/head:pull/1312 PR: https://git.openjdk.java.net/skara/pull/1312 From erikj at openjdk.java.net Tue May 3 18:39:48 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 3 May 2022 18:39:48 GMT Subject: RFR: 1424: CheckRun fails to evaluate jol#24 In-Reply-To: References: Message-ID: On Tue, 3 May 2022 18:34:39 GMT, Erik Joelsson wrote: > CheckRun, which is part of the PullRequestBot, is currently failing to evaluate https://github.com/openjdk/jol/pull/24. The failure happens in PullRequestUtils::containsForeignMerge where we are looking for merges in the PR branch which bring in commits that aren't descendants of the main merge parent. If this test is positive, the bot adds a comment with a warning. > > The problem is that GitRepository::mergeBase doesn't differentiate between the git command failing with an error and when it just can't find a merge-base. For this check, a non existent merge-base should qualify for a positive test. > > I'm refactoring Repository::mergeBase into two methods, one that returns an Optional, which will be empty when a merge-base can't be found. I've also gone through all callers to identify when the new method should be used to properly tell this situation apart. forge/src/main/java/org/openjdk/skara/forge/PullRequestUtils.java line 132: > 130: // Ensure that the source and the target are related > 131: localRepo.mergeBaseOptional(targetHash(localRepo), sourceHead) > 132: .orElseThrow(() -> new CommitFailure("The target and the source branches do not share common history - cannot merge them.")); Here I think a real error should be let through so the whole WorkItem may be retried later. vcs/src/main/java/org/openjdk/skara/vcs/git/GitRepository.java line 924: > 922: public Hash mergeBase(Hash first, Hash second) throws IOException { > 923: try (var p = capture("git", "merge-base", first.hex(), second.hex())) { > 924: var res = await(p); await(p) basically does p.await() and then throws IOException if res.status() is non zero. ------------- PR: https://git.openjdk.java.net/skara/pull/1312 From erikj at openjdk.java.net Tue May 3 20:07:23 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 3 May 2022 20:07:23 GMT Subject: RFR: 1419: The Skara PR bot should not block on a JEP if not enabled for a repo [v2] In-Reply-To: References: <_m5KmF1x45XWNOi6Asvk_PIUJDbUeAWDg4DrEwmnkA4=.20d9284a-6bd3-4ea3-a4eb-38697530b9eb@github.com> Message-ID: On Tue, 3 May 2022 13:40:09 GMT, Guoxiong Li wrote: >> Hi all, >> >> If a repository doesn't support JEP and someone issues the `/jep` command in the PR of this repo, the bot should replies a comment instead of blocking the PR. This patch adds a jep config to the PR bot and adjusts the test cases. >> >> Thanks for taking the time to review. >> >> Best Regards, >> -- Guoxiong > > Guoxiong Li has updated the pull request incrementally with two additional commits since the last revision: > > - Fix comment of the csr command. > - Fix commment of the jep command and add a test case. Marked as reviewed by erikj (Lead). ------------- PR: https://git.openjdk.java.net/skara/pull/1310 From erikj at openjdk.java.net Tue May 3 20:10:17 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 3 May 2022 20:10:17 GMT Subject: RFR: 1422: Remove the need to type `JEP-` or `jep-` prefix in `jep` command [v2] In-Reply-To: <2V2hnxCmljkSZhEPdY3FWia-qaMAPZZmlXx_83PzDL0=.47852afb-737e-46a1-a3ae-8963a519f947@github.com> References: <2V2hnxCmljkSZhEPdY3FWia-qaMAPZZmlXx_83PzDL0=.47852afb-737e-46a1-a3ae-8963a519f947@github.com> Message-ID: <5Sg-M8UX-eeq9LcSOTlyC76qclNjvNGv30xsVG9y_lA=.1c70aba1-b377-4717-9560-d67fc8282bc1@github.com> On Tue, 3 May 2022 14:18:41 GMT, Guoxiong Li wrote: >> I also noted that on line 150 and 156, the message doesn't start with a capital letter. Could you fix that too? > >> I also noted that on line 150 and 156, the message doesn't start with a capital letter. Could you fix that too? > > Fixed. > >> Do we really need to print a message about this? > > If we don't print such message, when typing `/jep 123` mistakenly (assume the right JEP id is `132` and the issue-123 exists and is not a jep issue), the bot prints `The issue 123 is not a JEP. Please make sure you have entered it correctly`. It may confused the user because the user may think the `123` is a JEP ID instead of a issue ID. And the user may asked why the document said it would firstly be tried as a JEP ID but actually not? I think that will be clear enough without this extra message. ------------- PR: https://git.openjdk.java.net/skara/pull/1311 From kcr at openjdk.java.net Tue May 3 21:33:29 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 3 May 2022 21:33:29 GMT Subject: RFR: 1424: CheckRun fails to evaluate jol#24 In-Reply-To: References: Message-ID: On Tue, 3 May 2022 18:34:39 GMT, Erik Joelsson wrote: > CheckRun, which is part of the PullRequestBot, is currently failing to evaluate https://github.com/openjdk/jol/pull/24. The failure happens in PullRequestUtils::containsForeignMerge where we are looking for merges in the PR branch which bring in commits that aren't descendants of the main merge parent. If this test is positive, the bot adds a comment with a warning. > > The problem is that GitRepository::mergeBase doesn't differentiate between the git command failing with an error and when it just can't find a merge-base. For this check, a non existent merge-base should qualify for a positive test. > > I'm refactoring Repository::mergeBase into two methods, one that returns an Optional, which will be empty when a merge-base can't be found. I've also gone through all callers to identify when the new method should be used to properly tell this situation apart. Looks good. ------------- Marked as reviewed by kcr (Reviewer). PR: https://git.openjdk.java.net/skara/pull/1312 From erikj at openjdk.java.net Tue May 3 21:49:49 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 3 May 2022 21:49:49 GMT Subject: RFR: 1375: Incorrect sync labels Message-ID: This patch attempts to fix three reported issues with hgupdate-sync labels. * Backports for 6u should also be considered * "Resolved in Build": "team" should not be ignored * The b30+ is a bpr rule applies to releases up to 11.0.3 ------------- Commit messages: - SKARA-1375 Changes: https://git.openjdk.java.net/skara/pull/1313/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1313&range=00 Issue: https://bugs.openjdk.java.net/browse/SKARA-1375 Stats: 50 lines in 2 files changed: 38 ins; 2 del; 10 mod Patch: https://git.openjdk.java.net/skara/pull/1313.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1313/head:pull/1313 PR: https://git.openjdk.java.net/skara/pull/1313 From erikj at openjdk.java.net Tue May 3 21:57:02 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 3 May 2022 21:57:02 GMT Subject: Integrated: 1424: CheckRun fails to evaluate jol#24 In-Reply-To: References: Message-ID: On Tue, 3 May 2022 18:34:39 GMT, Erik Joelsson wrote: > CheckRun, which is part of the PullRequestBot, is currently failing to evaluate https://github.com/openjdk/jol/pull/24. The failure happens in PullRequestUtils::containsForeignMerge where we are looking for merges in the PR branch which bring in commits that aren't descendants of the main merge parent. If this test is positive, the bot adds a comment with a warning. > > The problem is that GitRepository::mergeBase doesn't differentiate between the git command failing with an error and when it just can't find a merge-base. For this check, a non existent merge-base should qualify for a positive test. > > I'm refactoring Repository::mergeBase into two methods, one that returns an Optional, which will be empty when a merge-base can't be found. I've also gone through all callers to identify when the new method should be used to properly tell this situation apart. This pull request has now been integrated. Changeset: 15aea104 Author: Erik Joelsson URL: https://git.openjdk.java.net/skara/commit/15aea1047876d7bd42e7fc3f421800d801075444 Stats: 35 lines in 3 files changed: 26 ins; 3 del; 6 mod 1424: CheckRun fails to evaluate jol#24 Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/skara/pull/1312 From gli at openjdk.java.net Wed May 4 05:14:02 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Wed, 4 May 2022 05:14:02 GMT Subject: RFR: 1419: The Skara PR bot should not block on a JEP if not enabled for a repo [v2] In-Reply-To: References: <_m5KmF1x45XWNOi6Asvk_PIUJDbUeAWDg4DrEwmnkA4=.20d9284a-6bd3-4ea3-a4eb-38697530b9eb@github.com> Message-ID: On Tue, 3 May 2022 20:04:42 GMT, Erik Joelsson wrote: >> Guoxiong Li has updated the pull request incrementally with two additional commits since the last revision: >> >> - Fix comment of the csr command. >> - Fix commment of the jep command and add a test case. > > Marked as reviewed by erikj (Lead). @erikj79 Thanks for the review. ------------- PR: https://git.openjdk.java.net/skara/pull/1310 From gli at openjdk.java.net Wed May 4 05:32:34 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Wed, 4 May 2022 05:32:34 GMT Subject: RFR: 1422: Remove the need to type `JEP-` or `jep-` prefix in `jep` command [v3] In-Reply-To: References: Message-ID: <8--BPPaT0z7wZ7_3yQ3-YZ3GCS184N8DQpeW5EibwuE=.77ddd3bb-e934-4fcc-844c-923817b3a455@github.com> > Hi all, > > This patch permits the strange grammer like `/jep jEP-123` and removes the need of the `JEP-` or `jep-` prefix. > When the prefix (`JDK-`, `JEP-` or others) is not provided, the bot treats it as a JEP ID firstly. > If the issue is not found, the bot then treats it as an issue ID. > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: Remove the message about JEP issue ------------- Changes: - all: https://git.openjdk.java.net/skara/pull/1311/files - new: https://git.openjdk.java.net/skara/pull/1311/files/19bbf76c..e0b416ee Webrevs: - full: https://webrevs.openjdk.java.net/?repo=skara&pr=1311&range=02 - incr: https://webrevs.openjdk.java.net/?repo=skara&pr=1311&range=01-02 Stats: 10 lines in 2 files changed: 0 ins; 8 del; 2 mod Patch: https://git.openjdk.java.net/skara/pull/1311.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1311/head:pull/1311 PR: https://git.openjdk.java.net/skara/pull/1311 From gli at openjdk.java.net Wed May 4 05:32:34 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Wed, 4 May 2022 05:32:34 GMT Subject: RFR: 1422: Remove the need to type `JEP-` or `jep-` prefix in `jep` command [v3] In-Reply-To: <5Sg-M8UX-eeq9LcSOTlyC76qclNjvNGv30xsVG9y_lA=.1c70aba1-b377-4717-9560-d67fc8282bc1@github.com> References: <2V2hnxCmljkSZhEPdY3FWia-qaMAPZZmlXx_83PzDL0=.47852afb-737e-46a1-a3ae-8963a519f947@github.com> <5Sg-M8UX-eeq9LcSOTlyC76qclNjvNGv30xsVG9y_lA=.1c70aba1-b377-4717-9560-d67fc8282bc1@github.com> Message-ID: On Tue, 3 May 2022 20:07:28 GMT, Erik Joelsson wrote: >>> I also noted that on line 150 and 156, the message doesn't start with a capital letter. Could you fix that too? >> >> Fixed. >> >>> Do we really need to print a message about this? >> >> If we don't print such message, when typing `/jep 123` mistakenly (assume the right JEP id is `132` and the issue-123 exists and is not a jep issue), the bot prints `The issue 123 is not a JEP. Please make sure you have entered it correctly`. It may confused the user because the user may think the `123` is a JEP ID instead of a issue ID. And the user may asked why the document said it would firstly be tried as a JEP ID but actually not? > > I think that will be clear enough without this extra message. Fixed. ------------- PR: https://git.openjdk.java.net/skara/pull/1311 From kcr at openjdk.java.net Wed May 4 12:21:35 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 4 May 2022 12:21:35 GMT Subject: RFR: 1375: Incorrect sync labels In-Reply-To: References: Message-ID: On Tue, 3 May 2022 21:45:51 GMT, Erik Joelsson wrote: > This patch attempts to fix three reported issues with hgupdate-sync labels. > > * Backports for 6u should also be considered > * "Resolved in Build": "team" should not be ignored > * The b30+ is a bpr rule applies to releases up to 11.0.3 The logic looks correct to me, and I see you have added tests for most of the new cases. Is it worth adding a test for resolved-in-build "team"? ------------- Marked as reviewed by kcr (Reviewer). PR: https://git.openjdk.java.net/skara/pull/1313 From erikj at openjdk.java.net Wed May 4 13:00:56 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 4 May 2022 13:00:56 GMT Subject: RFR: 1375: Incorrect sync labels In-Reply-To: References: Message-ID: <4pnj0Taj6AyAQPPpTdY0f6buqL7-Yeatx2Vl6pVX0KE=.da4f29bd-493d-432d-a17a-2fa993b67aae@github.com> On Wed, 4 May 2022 12:18:53 GMT, Kevin Rushforth wrote: > The logic looks correct to me, and I see you have added tests for most of the new cases. Is it worth adding a test for resolved-in-build "team"? There was a test verifying the old behavior which I inverted. ------------- PR: https://git.openjdk.java.net/skara/pull/1313 From kcr at openjdk.java.net Wed May 4 13:25:18 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 4 May 2022 13:25:18 GMT Subject: RFR: 1375: Incorrect sync labels In-Reply-To: <4pnj0Taj6AyAQPPpTdY0f6buqL7-Yeatx2Vl6pVX0KE=.da4f29bd-493d-432d-a17a-2fa993b67aae@github.com> References: <4pnj0Taj6AyAQPPpTdY0f6buqL7-Yeatx2Vl6pVX0KE=.da4f29bd-493d-432d-a17a-2fa993b67aae@github.com> Message-ID: On Wed, 4 May 2022 12:58:01 GMT, Erik Joelsson wrote: > There was a test verifying the old behavior which I inverted. Yes, I see that now. Thanks. ------------- PR: https://git.openjdk.java.net/skara/pull/1313 From erikj at openjdk.java.net Wed May 4 13:30:09 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 4 May 2022 13:30:09 GMT Subject: RFR: 1422: Remove the need to type `JEP-` or `jep-` prefix in `jep` command [v3] In-Reply-To: <8--BPPaT0z7wZ7_3yQ3-YZ3GCS184N8DQpeW5EibwuE=.77ddd3bb-e934-4fcc-844c-923817b3a455@github.com> References: <8--BPPaT0z7wZ7_3yQ3-YZ3GCS184N8DQpeW5EibwuE=.77ddd3bb-e934-4fcc-844c-923817b3a455@github.com> Message-ID: On Wed, 4 May 2022 05:32:34 GMT, Guoxiong Li wrote: >> Hi all, >> >> This patch permits the strange grammer like `/jep jEP-123` and removes the need of the `JEP-` or `jep-` prefix. >> When the prefix (`JDK-`, `JEP-` or others) is not provided, the bot treats it as a JEP ID firstly. >> If the issue is not found, the bot then treats it as an issue ID. >> >> Thanks for taking the time to review. >> >> Best Regards, >> -- Guoxiong > > Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: > > Remove the message about JEP issue Marked as reviewed by erikj (Lead). ------------- PR: https://git.openjdk.java.net/skara/pull/1311 From gli at openjdk.java.net Wed May 4 13:31:06 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Wed, 4 May 2022 13:31:06 GMT Subject: Integrated: 1419: The Skara PR bot should not block on a JEP if not enabled for a repo In-Reply-To: <_m5KmF1x45XWNOi6Asvk_PIUJDbUeAWDg4DrEwmnkA4=.20d9284a-6bd3-4ea3-a4eb-38697530b9eb@github.com> References: <_m5KmF1x45XWNOi6Asvk_PIUJDbUeAWDg4DrEwmnkA4=.20d9284a-6bd3-4ea3-a4eb-38697530b9eb@github.com> Message-ID: <-4U_EBxXlqABGej-hWR10wYvQDNyGDzb1dGCwnHOBck=.778dc2a5-a912-411f-89c4-ade42902f122@github.com> On Tue, 3 May 2022 00:22:47 GMT, Guoxiong Li wrote: > Hi all, > > If a repository doesn't support JEP and someone issues the `/jep` command in the PR of this repo, the bot should replies a comment instead of blocking the PR. This patch adds a jep config to the PR bot and adjusts the test cases. > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong This pull request has now been integrated. Changeset: 97f7f1a9 Author: Guoxiong Li Committer: Erik Joelsson URL: https://git.openjdk.java.net/skara/commit/97f7f1a995fc60a2a02e6bd3fa5f9804d2993de7 Stats: 74 lines in 8 files changed: 65 ins; 0 del; 9 mod 1419: The Skara PR bot should not block on a JEP if not enabled for a repo Reviewed-by: erikj ------------- PR: https://git.openjdk.java.net/skara/pull/1310 From erikj at openjdk.java.net Wed May 4 13:31:13 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 4 May 2022 13:31:13 GMT Subject: Integrated: 1375: Incorrect sync labels In-Reply-To: References: Message-ID: On Tue, 3 May 2022 21:45:51 GMT, Erik Joelsson wrote: > This patch attempts to fix three reported issues with hgupdate-sync labels. > > * Backports for 6u should also be considered > * "Resolved in Build": "team" should not be ignored > * The b30+ is a bpr rule applies to releases up to 11.0.3 This pull request has now been integrated. Changeset: 82d35bf7 Author: Erik Joelsson URL: https://git.openjdk.java.net/skara/commit/82d35bf704bcf07cc3dfb6090927535863df0ecf Stats: 50 lines in 2 files changed: 38 ins; 2 del; 10 mod 1375: Incorrect sync labels 1394: sync-bot not adding sync label to openjdk releases 1382: sync-bot removing sync label from JDK 6 backport Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/skara/pull/1313 From gli at openjdk.java.net Wed May 4 15:54:01 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Wed, 4 May 2022 15:54:01 GMT Subject: RFR: 1422: Remove the need to type `JEP-` or `jep-` prefix in `jep` command [v3] In-Reply-To: References: <8--BPPaT0z7wZ7_3yQ3-YZ3GCS184N8DQpeW5EibwuE=.77ddd3bb-e934-4fcc-844c-923817b3a455@github.com> Message-ID: On Wed, 4 May 2022 13:27:06 GMT, Erik Joelsson wrote: >> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove the message about JEP issue > > Marked as reviewed by erikj (Lead). @erikj79 Thanks for the review. ------------- PR: https://git.openjdk.java.net/skara/pull/1311 From gli at openjdk.java.net Wed May 4 19:18:59 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Wed, 4 May 2022 19:18:59 GMT Subject: Integrated: 1422: Remove the need to type `JEP-` or `jep-` prefix in `jep` command In-Reply-To: References: Message-ID: On Tue, 3 May 2022 07:10:44 GMT, Guoxiong Li wrote: > Hi all, > > This patch permits the strange grammer like `/jep jEP-123` and removes the need of the `JEP-` or `jep-` prefix. > When the prefix (`JDK-`, `JEP-` or others) is not provided, the bot treats it as a JEP ID firstly. > If the issue is not found, the bot then treats it as an issue ID. > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong This pull request has now been integrated. Changeset: a7492a5f Author: Guoxiong Li Committer: Erik Joelsson URL: https://git.openjdk.java.net/skara/commit/a7492a5f909949729703ffb17dc3ad99f380e1b8 Stats: 91 lines in 2 files changed: 54 ins; 11 del; 26 mod 1422: Remove the need to type `JEP-` or `jep-` prefix in `jep` command Reviewed-by: erikj ------------- PR: https://git.openjdk.java.net/skara/pull/1311 From erikj at openjdk.java.net Wed May 4 19:43:11 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 4 May 2022 19:43:11 GMT Subject: RFR: 1423: Clarfiy doc for /contributor command Message-ID: This patch improves the help text and the error messages for the /contributor command. ------------- Commit messages: - Remove unused import - Remove Note - Fix whitespace - SKARA-1423 Changes: https://git.openjdk.java.net/skara/pull/1314/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1314&range=00 Issue: https://bugs.openjdk.java.net/browse/SKARA-1423 Stats: 13 lines in 1 file changed: 10 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/skara/pull/1314.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1314/head:pull/1314 PR: https://git.openjdk.java.net/skara/pull/1314 From erikj at openjdk.java.net Wed May 4 21:18:05 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 4 May 2022 21:18:05 GMT Subject: RFR: 1426: IssueNotifier fails to update Resolved In Build for fixVersion with openjdk prefix Message-ID: <_mBo6gYPoxX3EWiRcwdiv8yyn6gDsowAxOlGlBmyzYc=.0781de9e-cd01-490c-8bda-bad023edd518@github.com> The IssueNotifier is supposed to update the Resolved In Build field of issues when a new build tag is added to a repo. It does this by finding all commits present in the new tag, but not present in the previous one. It also verifies that the fixversion for those issues match the tag. This latter verification fails if the fixVersion has an openjdk prefix as the tags do not. Specifically issues with fixVersion openjdk8u342 did not get updated when the tag jdk8u342-b01 was added to https://github.com/openjdk/jdk8u. This patch tries to address this. I didn't want to hard code the string "openjdk" in yet another location, so any lower case only prefix will be ignored when doing this match. Please let me know if I missed something. ------------- Commit messages: - SKARA-1426 Changes: https://git.openjdk.java.net/skara/pull/1315/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1315&range=00 Issue: https://bugs.openjdk.java.net/browse/SKARA-1426 Stats: 114 lines in 2 files changed: 111 ins; 2 del; 1 mod Patch: https://git.openjdk.java.net/skara/pull/1315.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1315/head:pull/1315 PR: https://git.openjdk.java.net/skara/pull/1315 From erikj at openjdk.java.net Wed May 4 21:59:41 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 4 May 2022 21:59:41 GMT Subject: RFR: 1427: Remove unnecessary warning log message Message-ID: The PR bot currently logs a warning about not finding a CSR for every PR. This seems unnecessary. ------------- Commit messages: - SKARA-1427 Changes: https://git.openjdk.java.net/skara/pull/1316/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1316&range=00 Issue: https://bugs.openjdk.java.net/browse/SKARA-1427 Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod Patch: https://git.openjdk.java.net/skara/pull/1316.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1316/head:pull/1316 PR: https://git.openjdk.java.net/skara/pull/1316 From erikj at openjdk.java.net Wed May 4 22:06:12 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 4 May 2022 22:06:12 GMT Subject: RFR: 1428: New reviews message always adds plural 's' Message-ID: The new message for listing review requirements in the progress list always adds a plural 's' regardless of the number of reviews required. We should change this so that it's only added when there are 2 or more reviews required. ------------- Commit messages: - SKARA-1428 Changes: https://git.openjdk.java.net/skara/pull/1317/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1317&range=00 Issue: https://bugs.openjdk.java.net/browse/SKARA-1428 Stats: 49 lines in 3 files changed: 2 ins; 0 del; 47 mod Patch: https://git.openjdk.java.net/skara/pull/1317.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1317/head:pull/1317 PR: https://git.openjdk.java.net/skara/pull/1317 From kcr at openjdk.java.net Wed May 4 22:32:35 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 4 May 2022 22:32:35 GMT Subject: RFR: 1426: IssueNotifier fails to update Resolved In Build for fixVersion with openjdk prefix In-Reply-To: <_mBo6gYPoxX3EWiRcwdiv8yyn6gDsowAxOlGlBmyzYc=.0781de9e-cd01-490c-8bda-bad023edd518@github.com> References: <_mBo6gYPoxX3EWiRcwdiv8yyn6gDsowAxOlGlBmyzYc=.0781de9e-cd01-490c-8bda-bad023edd518@github.com> Message-ID: <2NUA_22F4r7dLHqc4f5r_lzLI0p0ykCCQfNV1Kb3OqE=.2f66f674-f9b1-4de1-8193-419cc9ae974c@github.com> On Wed, 4 May 2022 21:13:47 GMT, Erik Joelsson wrote: > The IssueNotifier is supposed to update the Resolved In Build field of issues when a new build tag is added to a repo. It does this by finding all commits present in the new tag, but not present in the previous one. It also verifies that the fixversion for those issues match the tag. This latter verification fails if the fixVersion has an openjdk prefix as the tags do not. Specifically issues with fixVersion openjdk8u342 did not get updated when the tag jdk8u342-b01 was added to https://github.com/openjdk/jdk8u. > > This patch tries to address this. I didn't want to hard code the string "openjdk" in yet another location, so any lower case only prefix will be ignored when doing this match. Please let me know if I missed something. Looks good. ------------- Marked as reviewed by kcr (Reviewer). PR: https://git.openjdk.java.net/skara/pull/1315 From kcr at openjdk.java.net Wed May 4 22:33:44 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 4 May 2022 22:33:44 GMT Subject: RFR: 1427: Remove unnecessary warning log message In-Reply-To: References: Message-ID: On Wed, 4 May 2022 21:55:32 GMT, Erik Joelsson wrote: > The PR bot currently logs a warning about not finding a CSR for every PR. This seems unnecessary. Marked as reviewed by kcr (Reviewer). ------------- PR: https://git.openjdk.java.net/skara/pull/1316 From kcr at openjdk.java.net Wed May 4 22:37:39 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 4 May 2022 22:37:39 GMT Subject: RFR: 1423: Clarfiy doc for /contributor command In-Reply-To: References: Message-ID: On Wed, 4 May 2022 19:39:01 GMT, Erik Joelsson wrote: > This patch improves the help text and the error messages for the /contributor command. Looks good. I see that there are GHA test failures, but they don't seem related to this changes. ------------- Marked as reviewed by kcr (Reviewer). PR: https://git.openjdk.java.net/skara/pull/1314 From kcr at openjdk.java.net Wed May 4 22:42:45 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 4 May 2022 22:42:45 GMT Subject: RFR: 1428: New reviews message always adds plural 's' In-Reply-To: References: Message-ID: On Wed, 4 May 2022 22:02:15 GMT, Erik Joelsson wrote: > The new message for listing review requirements in the progress list always adds a plural 's' regardless of the number of reviews required. We should change this so that it's only added when there are 2 or more reviews required. Looks good. ------------- Marked as reviewed by kcr (Reviewer). PR: https://git.openjdk.java.net/skara/pull/1317 From gli at openjdk.java.net Thu May 5 02:14:47 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Thu, 5 May 2022 02:14:47 GMT Subject: RFR: 1428: New reviews message always adds plural 's' In-Reply-To: References: Message-ID: On Wed, 4 May 2022 22:02:15 GMT, Erik Joelsson wrote: > The new message for listing review requirements in the progress list always adds a plural 's' regardless of the number of reviews required. We should change this so that it's only added when there are 2 or more reviews required. LGTM ------------- Marked as reviewed by gli (Author). PR: https://git.openjdk.java.net/skara/pull/1317 From gli at openjdk.java.net Thu May 5 02:21:58 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Thu, 5 May 2022 02:21:58 GMT Subject: RFR: 1423: Clarfiy doc for /contributor command In-Reply-To: References: Message-ID: On Wed, 4 May 2022 19:39:01 GMT, Erik Joelsson wrote: > This patch improves the help text and the error messages for the /contributor command. The test case `ContributorTests::invalidContributor` failed. ------------- PR: https://git.openjdk.java.net/skara/pull/1314 From erikj at openjdk.java.net Thu May 5 13:24:21 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 5 May 2022 13:24:21 GMT Subject: RFR: 1423: Clarfiy doc for /contributor command [v2] In-Reply-To: References: Message-ID: > This patch improves the help text and the error messages for the /contributor command. Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision: Fix failing test ------------- Changes: - all: https://git.openjdk.java.net/skara/pull/1314/files - new: https://git.openjdk.java.net/skara/pull/1314/files/28f617bb..5824a75f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=skara&pr=1314&range=01 - incr: https://webrevs.openjdk.java.net/?repo=skara&pr=1314&range=00-01 Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/skara/pull/1314.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1314/head:pull/1314 PR: https://git.openjdk.java.net/skara/pull/1314 From erikj at openjdk.java.net Thu May 5 18:34:18 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 5 May 2022 18:34:18 GMT Subject: Integrated: 1426: IssueNotifier fails to update Resolved In Build for fixVersion with openjdk prefix In-Reply-To: <_mBo6gYPoxX3EWiRcwdiv8yyn6gDsowAxOlGlBmyzYc=.0781de9e-cd01-490c-8bda-bad023edd518@github.com> References: <_mBo6gYPoxX3EWiRcwdiv8yyn6gDsowAxOlGlBmyzYc=.0781de9e-cd01-490c-8bda-bad023edd518@github.com> Message-ID: On Wed, 4 May 2022 21:13:47 GMT, Erik Joelsson wrote: > The IssueNotifier is supposed to update the Resolved In Build field of issues when a new build tag is added to a repo. It does this by finding all commits present in the new tag, but not present in the previous one. It also verifies that the fixversion for those issues match the tag. This latter verification fails if the fixVersion has an openjdk prefix as the tags do not. Specifically issues with fixVersion openjdk8u342 did not get updated when the tag jdk8u342-b01 was added to https://github.com/openjdk/jdk8u. > > This patch tries to address this. I didn't want to hard code the string "openjdk" in yet another location, so any lower case only prefix will be ignored when doing this match. Please let me know if I missed something. This pull request has now been integrated. Changeset: 383283e8 Author: Erik Joelsson URL: https://git.openjdk.java.net/skara/commit/383283e85ac1b5c5b4d340ec9864f044baa34d34 Stats: 114 lines in 2 files changed: 111 ins; 2 del; 1 mod 1426: IssueNotifier fails to update Resolved In Build for fixVersion with openjdk prefix Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/skara/pull/1315 From erikj at openjdk.java.net Thu May 5 18:34:36 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 5 May 2022 18:34:36 GMT Subject: Integrated: 1427: Remove unnecessary warning log message In-Reply-To: References: Message-ID: On Wed, 4 May 2022 21:55:32 GMT, Erik Joelsson wrote: > The PR bot currently logs a warning about not finding a CSR for every PR. This seems unnecessary. This pull request has now been integrated. Changeset: 7010b622 Author: Erik Joelsson URL: https://git.openjdk.java.net/skara/commit/7010b62250863233c2f2689a1b1d313d8b967e35 Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod 1427: Remove unnecessary warning log message Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/skara/pull/1316 From erikj at openjdk.java.net Thu May 5 18:34:58 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 5 May 2022 18:34:58 GMT Subject: Integrated: 1428: New reviews message always adds plural 's' In-Reply-To: References: Message-ID: On Wed, 4 May 2022 22:02:15 GMT, Erik Joelsson wrote: > The new message for listing review requirements in the progress list always adds a plural 's' regardless of the number of reviews required. We should change this so that it's only added when there are 2 or more reviews required. This pull request has now been integrated. Changeset: 88294cb8 Author: Erik Joelsson URL: https://git.openjdk.java.net/skara/commit/88294cb8b58c2e50d9a47dea951f77a0f7d303f0 Stats: 49 lines in 3 files changed: 2 ins; 0 del; 47 mod 1428: New reviews message always adds plural 's' Reviewed-by: kcr, gli ------------- PR: https://git.openjdk.java.net/skara/pull/1317 From erikj at openjdk.java.net Thu May 5 18:35:32 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 5 May 2022 18:35:32 GMT Subject: Integrated: 1423: Clarfiy doc for /contributor command In-Reply-To: References: Message-ID: On Wed, 4 May 2022 19:39:01 GMT, Erik Joelsson wrote: > This patch improves the help text and the error messages for the /contributor command. This pull request has now been integrated. Changeset: 729ec12c Author: Erik Joelsson URL: https://git.openjdk.java.net/skara/commit/729ec12c43405c3149823bc6b2297a0a70a409f5 Stats: 18 lines in 2 files changed: 10 ins; 0 del; 8 mod 1423: Clarfiy doc for /contributor command Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/skara/pull/1314 From gli at openjdk.java.net Sun May 8 13:23:37 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Sun, 8 May 2022 13:23:37 GMT Subject: RFR: 1385: Backport MR links to the wrong CSR request Message-ID: <0aKhvarUQYxTcM9B6TGI8p5dv_t9H8cNTX-wdJAuCxI=.bcc1d50c-5b59-4b33-bc3b-b15ef169e365@github.com> Hi all, This patch solves the wrong CSR in the backport PR. It mainly has the following rules: 1. if the `version` in `.jcheck/conf` doesn't exist or the `version` is wrong, the bot think the CSR also doesn't exist. 2. else, if the `version` in `.jcheck/conf` matches the fix version of the primary CSR, the bot will use the primary CSR. (primary CSR is the CSR of the primary issue) 3. else, if these is a backport issue matches the `version`, the bot will find the CSR of the backport issue. If found, use it. If not, the bot think the CSR doesn't exist. 4. else (no backport issue matches the `version`) the bot think the CSR doesn't exist. The classes `CSRBot`, `CheckRun` and `CSRCommand` will handle the situations above respectively. Thanks for taking the time to review. Best Regards, -- Guoxiong ------------- Commit messages: - SKARA-1385 Changes: https://git.openjdk.java.net/skara/pull/1318/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1318&range=00 Issue: https://bugs.openjdk.java.net/browse/SKARA-1385 Stats: 661 lines in 11 files changed: 631 ins; 1 del; 29 mod Patch: https://git.openjdk.java.net/skara/pull/1318.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1318/head:pull/1318 PR: https://git.openjdk.java.net/skara/pull/1318 From dholmes at openjdk.java.net Sun May 8 22:18:54 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Sun, 8 May 2022 22:18:54 GMT Subject: RFR: 1385: Backport MR links to the wrong CSR request In-Reply-To: <0aKhvarUQYxTcM9B6TGI8p5dv_t9H8cNTX-wdJAuCxI=.bcc1d50c-5b59-4b33-bc3b-b15ef169e365@github.com> References: <0aKhvarUQYxTcM9B6TGI8p5dv_t9H8cNTX-wdJAuCxI=.bcc1d50c-5b59-4b33-bc3b-b15ef169e365@github.com> Message-ID: On Sun, 8 May 2022 13:19:17 GMT, Guoxiong Li wrote: > Hi all, > > This patch solves the wrong CSR in the backport PR. It mainly has the following rules: > 1. if the `version` in `.jcheck/conf` doesn't exist or the `version` is wrong, the bot think the CSR also doesn't exist. > 2. else, if the `version` in `.jcheck/conf` matches the fix version of the primary CSR, the bot will use the primary CSR. (primary CSR is the CSR of the primary issue) > 3. else, if these is a backport issue matches the `version`, the bot will find the CSR of the backport issue. If found, use it. If not, the bot think the CSR doesn't exist. > 4. else (no backport issue matches the `version`) the bot think the CSR doesn't exist. > > The classes `CSRBot`, `CheckRun` and `CSRCommand` will handle the situations above respectively. > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong Hi, There may be another case not covered by my reading of the above rules. Consider this situation: - there is a primary issue for release 17 and a corresponding CSR - there is a backport for release 11 and a corresponding CSR that is marked for multiple versions: 8-pool, 11-pool, 13-pool, 15-pool - A PR is created for a backport to 8u The search for a CSR matching the current 8u backport, has to search all of the existing backports for such a CSR request. ------------- PR: https://git.openjdk.java.net/skara/pull/1318 From gli at openjdk.java.net Mon May 9 07:10:05 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Mon, 9 May 2022 07:10:05 GMT Subject: RFR: 1385: Backport MR links to the wrong CSR request In-Reply-To: References: <0aKhvarUQYxTcM9B6TGI8p5dv_t9H8cNTX-wdJAuCxI=.bcc1d50c-5b59-4b33-bc3b-b15ef169e365@github.com> Message-ID: On Sun, 8 May 2022 22:15:41 GMT, David Holmes wrote: > There may be another case not covered by my reading of the above rules. > > Consider this situation: > > * there is a primary issue for release 17 and a corresponding CSR > * there is a backport for release 11 and a corresponding CSR that is marked for multiple versions: 8-pool, 11-pool, 13-pool, 15-pool > * A PR is created for a backport to 8u > > The search for a CSR matching the current 8u backport, has to search all of the existing backports for such a CSR request. Yes, your analysis is right. I will fix it later. ------------- PR: https://git.openjdk.java.net/skara/pull/1318 From gli at openjdk.java.net Mon May 9 11:28:29 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Mon, 9 May 2022 11:28:29 GMT Subject: RFR: 1385: Backport MR links to the wrong CSR request [v2] In-Reply-To: <0aKhvarUQYxTcM9B6TGI8p5dv_t9H8cNTX-wdJAuCxI=.bcc1d50c-5b59-4b33-bc3b-b15ef169e365@github.com> References: <0aKhvarUQYxTcM9B6TGI8p5dv_t9H8cNTX-wdJAuCxI=.bcc1d50c-5b59-4b33-bc3b-b15ef169e365@github.com> Message-ID: > Hi all, > > This patch solves the wrong CSR in the backport PR. It mainly has the following rules: > 1. if the `version` in `.jcheck/conf` doesn't exist or the `version` is wrong, the bot think the CSR also doesn't exist. > 2. else, if the `version` in `.jcheck/conf` matches the fix version of the primary CSR, the bot will use the primary CSR. (primary CSR is the CSR of the primary issue) > 3. else, if these is a backport issue matches the `version`, the bot will find the CSR of the backport issue. If found, use it. If not, the bot think the CSR doesn't exist. > 4. else (no backport issue matches the `version`) the bot think the CSR doesn't exist. > > The classes `CSRBot`, `CheckRun` and `CSRCommand` will handle the situations above respectively. > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: Fix the complex situation. ------------- Changes: - all: https://git.openjdk.java.net/skara/pull/1318/files - new: https://git.openjdk.java.net/skara/pull/1318/files/3189dc56..1a7e4853 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=skara&pr=1318&range=01 - incr: https://webrevs.openjdk.java.net/?repo=skara&pr=1318&range=00-01 Stats: 331 lines in 8 files changed: 295 ins; 6 del; 30 mod Patch: https://git.openjdk.java.net/skara/pull/1318.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1318/head:pull/1318 PR: https://git.openjdk.java.net/skara/pull/1318 From gli at openjdk.java.net Mon May 9 11:28:30 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Mon, 9 May 2022 11:28:30 GMT Subject: RFR: 1385: Backport MR links to the wrong CSR request In-Reply-To: References: <0aKhvarUQYxTcM9B6TGI8p5dv_t9H8cNTX-wdJAuCxI=.bcc1d50c-5b59-4b33-bc3b-b15ef169e365@github.com> Message-ID: On Mon, 9 May 2022 07:07:17 GMT, Guoxiong Li wrote: > Yes, your analysis is right. I will fix it later. Done. ------------- PR: https://git.openjdk.java.net/skara/pull/1318 From erikj at openjdk.java.net Mon May 9 23:15:14 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 9 May 2022 23:15:14 GMT Subject: RFR: 1385: Backport MR links to the wrong CSR request [v2] In-Reply-To: References: <0aKhvarUQYxTcM9B6TGI8p5dv_t9H8cNTX-wdJAuCxI=.bcc1d50c-5b59-4b33-bc3b-b15ef169e365@github.com> Message-ID: On Mon, 9 May 2022 11:28:29 GMT, Guoxiong Li wrote: >> Hi all, >> >> This patch solves the wrong CSR in the backport PR. It mainly has the following rules: >> 1. if the `version` in `.jcheck/conf` doesn't exist or the `version` is wrong, the bot think the CSR also doesn't exist. >> 2. else, if the `version` in `.jcheck/conf` matches the fix version of the primary CSR, the bot will use the primary CSR. (primary CSR is the CSR of the primary issue) >> 3. else, if these is a backport issue matches the `version`, the bot will find the CSR of the backport issue. If found, use it. If not, the bot think the CSR doesn't exist. >> 4. else (no backport issue matches the `version`) the bot think the CSR doesn't exist. >> >> The classes `CSRBot`, `CheckRun` and `CSRCommand` will handle the situations above respectively. >> >> Thanks for taking the time to review. >> >> Best Regards, >> -- Guoxiong > > Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: > > Fix the complex situation. I've looked through and added some comments. This can be a tricky feature to get right so please be patient. bots/csr/src/main/java/org/openjdk/skara/bots/csr/CSRBot.java line 110: > 108: var jbsIssue = jbsIssueOpt.get(); > 109: var csrOptional = csrLink(jbsIssue).flatMap(Link::issue); > 110: if (csrOptional.isEmpty()) { I don't think we can require a CSR to exist on the main bug to check for CSRs on the backport issues. bots/csr/src/main/java/org/openjdk/skara/bots/csr/CSRBot.java line 116: > 114: > 115: var csr = csrOptional.get(); > 116: if (pr.labelNames().contains("backport")) { I don't think we should only check backports when the label is set. It's currently not a requirement to create PRs as backport PRs. I think we should be more proactive and only accept CSR issues that have a matching fixVersion, and always look for them in the whole backport tree. As we are now getting smarter about fixversion in the PR bot, as a followup fix, we could consider no longer complaining about the main issue being closed, if a backport exists with the correct fixVersion. bots/csr/src/main/java/org/openjdk/skara/bots/csr/CSRBot.java line 119: > 117: csrOptional = findBackportCsr(pr, jbsIssue, csr); > 118: if (csrOptional.isEmpty()) { > 119: log.info("Not found backport CSR for " + describe(pr)); Suggestion: log.info("No backport CSR found for " + describe(pr)); bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckRun.java line 174: > 172: if (jdkVersion.isEmpty()) { > 173: return Optional.empty(); > 174: } This block of code is repeated 3 times now. I know we don't have a good place to share it between different bots, but we should be able to put it in a single location for CSRCommand and CheckRun at least. jbs/src/main/java/org/openjdk/skara/jbs/IssueUtil.java line 45: > 43: * A "scratch" fixVersion is empty, "tbd.*", or "unknown". > 44: */ > 45: public static Optional findClosestIssue(List issueList, JdkVersion fixVersion) { I think this method belongs in the Backports class, close to Backports#findIssue. They do almost the same thing, so if we are to maintain two similar implementations of the version matching order, they should reside close to each other. Could we move more of the common functionality to Backports. Something like `Backports.findCsr(Issue primary, JdkVersion jdkVersion)` that would encapsulate most of this repeated functionality? ------------- PR: https://git.openjdk.java.net/skara/pull/1318 From gli at openjdk.java.net Tue May 10 14:18:20 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Tue, 10 May 2022 14:18:20 GMT Subject: RFR: 1385: Backport MR links to the wrong CSR request [v3] In-Reply-To: <0aKhvarUQYxTcM9B6TGI8p5dv_t9H8cNTX-wdJAuCxI=.bcc1d50c-5b59-4b33-bc3b-b15ef169e365@github.com> References: <0aKhvarUQYxTcM9B6TGI8p5dv_t9H8cNTX-wdJAuCxI=.bcc1d50c-5b59-4b33-bc3b-b15ef169e365@github.com> Message-ID: > Hi all, > > This patch solves the wrong CSR in the backport PR. It mainly has the following rules: > 1. if the `version` in `.jcheck/conf` doesn't exist or the `version` is wrong, the bot think the CSR also doesn't exist. > 2. else, if the `version` in `.jcheck/conf` matches the fix version of the primary CSR, the bot will use the primary CSR. (primary CSR is the CSR of the primary issue) > 3. else, if these is a backport issue matches the `version`, the bot will find the CSR of the backport issue. If found, use it. If not, the bot think the CSR doesn't exist. > 4. else (no backport issue matches the `version`) the bot think the CSR doesn't exist. > > The classes `CSRBot`, `CheckRun` and `CSRCommand` will handle the situations above respectively. > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: Refactor code. Search CSR uniformly. Fix message. ------------- Changes: - all: https://git.openjdk.java.net/skara/pull/1318/files - new: https://git.openjdk.java.net/skara/pull/1318/files/1a7e4853..07d900ce Webrevs: - full: https://webrevs.openjdk.java.net/?repo=skara&pr=1318&range=02 - incr: https://webrevs.openjdk.java.net/?repo=skara&pr=1318&range=01-02 Stats: 172 lines in 4 files changed: 37 ins; 106 del; 29 mod Patch: https://git.openjdk.java.net/skara/pull/1318.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1318/head:pull/1318 PR: https://git.openjdk.java.net/skara/pull/1318 From gli at openjdk.java.net Tue May 10 14:29:55 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Tue, 10 May 2022 14:29:55 GMT Subject: RFR: 1385: Backport MR links to the wrong CSR request [v4] In-Reply-To: <0aKhvarUQYxTcM9B6TGI8p5dv_t9H8cNTX-wdJAuCxI=.bcc1d50c-5b59-4b33-bc3b-b15ef169e365@github.com> References: <0aKhvarUQYxTcM9B6TGI8p5dv_t9H8cNTX-wdJAuCxI=.bcc1d50c-5b59-4b33-bc3b-b15ef169e365@github.com> Message-ID: > Hi all, > > This patch solves the wrong CSR in the backport PR. It mainly has the following rules: > 1. if the `version` in `.jcheck/conf` doesn't exist or the `version` is wrong, the bot think the CSR also doesn't exist. > 2. else, if the `version` in `.jcheck/conf` matches the fix version of the primary CSR, the bot will use the primary CSR. (primary CSR is the CSR of the primary issue) > 3. else, if these is a backport issue matches the `version`, the bot will find the CSR of the backport issue. If found, use it. If not, the bot think the CSR doesn't exist. > 4. else (no backport issue matches the `version`) the bot think the CSR doesn't exist. > > The classes `CSRBot`, `CheckRun` and `CSRCommand` will handle the situations above respectively. > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: Fix test issueWithCsr. ------------- Changes: - all: https://git.openjdk.java.net/skara/pull/1318/files - new: https://git.openjdk.java.net/skara/pull/1318/files/07d900ce..d340a6cf Webrevs: - full: https://webrevs.openjdk.java.net/?repo=skara&pr=1318&range=03 - incr: https://webrevs.openjdk.java.net/?repo=skara&pr=1318&range=02-03 Stats: 9 lines in 1 file changed: 9 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/skara/pull/1318.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1318/head:pull/1318 PR: https://git.openjdk.java.net/skara/pull/1318 From gli at openjdk.java.net Tue May 10 14:29:57 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Tue, 10 May 2022 14:29:57 GMT Subject: RFR: 1385: Backport MR links to the wrong CSR request [v2] In-Reply-To: References: <0aKhvarUQYxTcM9B6TGI8p5dv_t9H8cNTX-wdJAuCxI=.bcc1d50c-5b59-4b33-bc3b-b15ef169e365@github.com> Message-ID: On Mon, 9 May 2022 13:31:17 GMT, Erik Joelsson wrote: >> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix the complex situation. > > bots/csr/src/main/java/org/openjdk/skara/bots/csr/CSRBot.java line 110: > >> 108: var jbsIssue = jbsIssueOpt.get(); >> 109: var csrOptional = csrLink(jbsIssue).flatMap(Link::issue); >> 110: if (csrOptional.isEmpty()) { > > I don't think we can require a CSR to exist on the main bug to check for CSRs on the backport issues. It is necessary. The primary CSR may has the fix versions of the backport issues. Such as this CSR: https://bugs.openjdk.java.net/browse/JDK-8285500 > I don't think we should only check backports when the label is set. It's currently not a requirement to create PRs as backport PRs. I think we should be more proactive and only accept CSR issues that have a matching fixVersion, and always look for them in the whole backport tree. I cleaned the condition and now the code always searches all the related CSRs for the right fix version. > we could consider no longer complaining about the main issue being closed I don't understand it. Could you point the related code or give more information? > bots/csr/src/main/java/org/openjdk/skara/bots/csr/CSRBot.java line 119: > >> 117: csrOptional = findBackportCsr(pr, jbsIssue, csr); >> 118: if (csrOptional.isEmpty()) { >> 119: log.info("Not found backport CSR for " + describe(pr)); > > Suggestion: > > log.info("No backport CSR found for " + describe(pr)); Fixed. > bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckRun.java line 174: > >> 172: if (jdkVersion.isEmpty()) { >> 173: return Optional.empty(); >> 174: } > > This block of code is repeated 3 times now. I know we don't have a good place to share it between different bots, but we should be able to put it in a single location for CSRCommand and CheckRun at least. I add a method `findCsr(Issue primary, JdkVersion version)` to the class `IssueUtil`. This method finds all the backport issues according to the primary issue and then gets all the CSRs and finally finds the needed CSR by using the method `findClosestIssue`. > I think this method belongs in the Backports class, close to Backports#findIssue. They do almost the same thing, so if we are to maintain two similar implementations of the version matching order, they should reside close to each other. The `Backports` class mainly handles something about backport. But this method is only about issue instead of backport. Actully, the method `Backports#findIssue` should delegate to a method such as `IssueUtil#findClosestIssue(List issueList, JdkVersion fixVersion, boolean onlySearchMainFixVersion)` after getting the backport issues to find the closest issue by using the main fix version. Such refactor is good but I don't think it should be done at this patch. So I would like to keep the utilility method about issues at a seperate class so that we can do more refactor in the future. The class name `IssueUtil` may need to be adjusted to a better name. > Could we move more of the common functionality to Backports. Something like Backports.findCsr(Issue primary, JdkVersion jdkVersion) that would encapsulate most of this repeated functionality? I moved the method `findCsr` and `csrLink` to the class `IssueUtil`. Again, the class name `Backports` is not good to place such methods. ------------- PR: https://git.openjdk.java.net/skara/pull/1318 From ihse at openjdk.java.net Wed May 11 12:31:43 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Wed, 11 May 2022 12:31:43 GMT Subject: RFR: 282: Make the review requirements more explicit in the progress list [v3] In-Reply-To: <3bKKJeWq1Hz5RzzzpTfv2UfST8_Img7FHW-MvUs35KA=.6d642e43-5446-4627-8403-61a167da8512@github.com> References: <3bKKJeWq1Hz5RzzzpTfv2UfST8_Img7FHW-MvUs35KA=.6d642e43-5446-4627-8403-61a167da8512@github.com> Message-ID: On Fri, 29 Apr 2022 23:34:56 GMT, Guoxiong Li wrote: >> That's fine, thanks! >> >> I now realize that you put the space and parentheses in the string here. I think this method should just return the requirements and let the visitor add the surrounding formatting. > > Fixed. @lgxbslgx I missed reviewing this when it was open, and am just going through the backlog of changes that has happened now. However, I think this was incorrect. The code here makes the text appears as: Change must be properly reviewed (1 review required, with at least 1 reviewer) when it should have been: Change must be properly reviewed (1 review required, with at least 1 Reviewer) (Note the capitalization of Reviewer). Traditionally, the (not very clear, I admit) distinction has been made in OpenJDK between "reviewer" (anyone who offers a review) and a "Reviewer" (a member with the official status as Reviewer for a project). This text is about the latter, so changing the "r" to a "R" in the message made a significant difference. Can you please fix this in a follow-up PR? ------------- PR: https://git.openjdk.java.net/skara/pull/1305 From gli at openjdk.java.net Wed May 11 12:43:22 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Wed, 11 May 2022 12:43:22 GMT Subject: RFR: 282: Make the review requirements more explicit in the progress list [v3] In-Reply-To: References: <3bKKJeWq1Hz5RzzzpTfv2UfST8_Img7FHW-MvUs35KA=.6d642e43-5446-4627-8403-61a167da8512@github.com> Message-ID: On Wed, 11 May 2022 12:28:43 GMT, Magnus Ihse Bursie wrote: >> Fixed. > > @lgxbslgx I missed reviewing this when it was open, and am just going through the backlog of changes that has happened now. > > However, I think this was incorrect. The code here makes the text appears as: > > Change must be properly reviewed (1 review required, with at least 1 reviewer) > > > when it should have been: > > Change must be properly reviewed (1 review required, with at least 1 Reviewer) > > > (Note the capitalization of Reviewer). > > Traditionally, the (not very clear, I admit) distinction has been made in OpenJDK between "reviewer" (anyone who offers a review) and a "Reviewer" (a member with the official status as Reviewer for a project). This text is about the latter, so changing the "r" to a "R" in the message made a significant difference. > > Can you please fix this in a follow-up PR? Do the `contributor`, `author`, `committer`, `lead` also need to be changed to `Contributor`, `Author`, `Committer`, `Lead`? ------------- PR: https://git.openjdk.java.net/skara/pull/1305 From gli at openjdk.java.net Wed May 11 12:57:36 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Wed, 11 May 2022 12:57:36 GMT Subject: RFR: 282: Make the review requirements more explicit in the progress list [v3] In-Reply-To: References: <3bKKJeWq1Hz5RzzzpTfv2UfST8_Img7FHW-MvUs35KA=.6d642e43-5446-4627-8403-61a167da8512@github.com> Message-ID: On Wed, 11 May 2022 12:40:21 GMT, Guoxiong Li wrote: >> @lgxbslgx I missed reviewing this when it was open, and am just going through the backlog of changes that has happened now. >> >> However, I think this was incorrect. The code here makes the text appears as: >> >> Change must be properly reviewed (1 review required, with at least 1 reviewer) >> >> >> when it should have been: >> >> Change must be properly reviewed (1 review required, with at least 1 Reviewer) >> >> >> (Note the capitalization of Reviewer). >> >> Traditionally, the (not very clear, I admit) distinction has been made in OpenJDK between "reviewer" (anyone who offers a review) and a "Reviewer" (a member with the official status as Reviewer for a project). This text is about the latter, so changing the "r" to a "R" in the message made a significant difference. >> >> Can you please fix this in a follow-up PR? > > Do the `contributor`, `author`, `committer`, `lead` also need to be changed to `Contributor`, `Author`, `Committer`, `Lead`? Filed https://bugs.openjdk.java.net/browse/SKARA-1437 to follow up. ------------- PR: https://git.openjdk.java.net/skara/pull/1305 From ihse at openjdk.java.net Wed May 11 13:16:37 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Wed, 11 May 2022 13:16:37 GMT Subject: RFR: 282: Make the review requirements more explicit in the progress list [v3] In-Reply-To: References: <3bKKJeWq1Hz5RzzzpTfv2UfST8_Img7FHW-MvUs35KA=.6d642e43-5446-4627-8403-61a167da8512@github.com> Message-ID: On Wed, 11 May 2022 12:54:38 GMT, Guoxiong Li wrote: >> Do the `contributor`, `author`, `committer`, `lead` also need to be changed to `Contributor`, `Author`, `Committer`, `Lead`? > > Filed https://bugs.openjdk.java.net/browse/SKARA-1437 to follow up. Yes, they should. See https://openjdk.java.net/bylaws#_7 for official roles. However, to specify any requirement other than Reviewer seems to me to be mostly an academic exercise. In practice, no-one will ever set any limitation other than the project role as Reviewer. (I'm not even sure why that code is there in the first place. Just some completionist thinking, I believe.) ------------- PR: https://git.openjdk.java.net/skara/pull/1305 From kcr at openjdk.java.net Wed May 11 13:33:04 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 11 May 2022 13:33:04 GMT Subject: RFR: 282: Make the review requirements more explicit in the progress list [v3] In-Reply-To: References: <3bKKJeWq1Hz5RzzzpTfv2UfST8_Img7FHW-MvUs35KA=.6d642e43-5446-4627-8403-61a167da8512@github.com> Message-ID: On Wed, 11 May 2022 13:13:44 GMT, Magnus Ihse Bursie wrote: >> Filed https://bugs.openjdk.java.net/browse/SKARA-1437 to follow up. > > Yes, they should. See https://openjdk.java.net/bylaws#_7 for official roles. > > However, to specify any requirement other than Reviewer seems to me to be mostly an academic exercise. In practice, no-one will ever set any limitation other than the project role as Reviewer. (I'm not even sure why that code is there in the first place. Just some completionist thinking, I believe.) Actually, it's quite common to have as a requirement 2 reviewers, at least one of which must be a Reviewer and the other an Author (i.e., any role in the Project). Both `jdk` and `jfx` are configured this way. Here is the current Progress item that Skara adds in response to the command `/reviewers 2`: - [ ] Change must be properly reviewed (2 reviews required, with at least 1 reviewer, 1 author) And here is the comment: The total number of required reviews for this PR (including the jcheck configuration and the last /reviewers command) is now set to 2 (with 1 of role reviewers, 1 of role authors). Both "Reviewer" and "Author" should be capitalized in both messages. Separately, I see that the pluralization was fixed in the Progress item, but not the comment. ------------- PR: https://git.openjdk.java.net/skara/pull/1305 From erikj at openjdk.java.net Wed May 11 13:40:52 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 11 May 2022 13:40:52 GMT Subject: RFR: 282: Make the review requirements more explicit in the progress list [v3] In-Reply-To: References: <3bKKJeWq1Hz5RzzzpTfv2UfST8_Img7FHW-MvUs35KA=.6d642e43-5446-4627-8403-61a167da8512@github.com> Message-ID: On Wed, 11 May 2022 13:30:04 GMT, Kevin Rushforth wrote: >> Yes, they should. See https://openjdk.java.net/bylaws#_7 for official roles. >> >> However, to specify any requirement other than Reviewer seems to me to be mostly an academic exercise. In practice, no-one will ever set any limitation other than the project role as Reviewer. (I'm not even sure why that code is there in the first place. Just some completionist thinking, I believe.) > > Actually, it's quite common to have as a requirement 2 reviewers, at least one of which must be a Reviewer and the other an Author (i.e., any role in the Project). Both `jdk` and `jfx` are configured this way. Here is the current Progress item that Skara adds in response to the command `/reviewers 2`: > > > - [ ] Change must be properly reviewed (2 reviews required, with at least 1 reviewer, 1 author) > > > And here is the comment: > > > The total number of required reviews for this PR (including the jcheck configuration and the last /reviewers command) is now set to 2 (with 1 of role reviewers, 1 of role authors). > > > Both "Reviewer" and "Author" should be capitalized in both messages. Separately, I see that the pluralization was fixed in the Progress item, but not the comment. There are also projects that do not have any members in the Reviewer role, so they configure their repository to only require Committers. The only role I doubt we will ever see required in reality is Lead, but that's ok. ------------- PR: https://git.openjdk.java.net/skara/pull/1305 From gli at openjdk.java.net Wed May 11 14:31:13 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Wed, 11 May 2022 14:31:13 GMT Subject: RFR: 282: Make the review requirements more explicit in the progress list [v3] In-Reply-To: References: <3bKKJeWq1Hz5RzzzpTfv2UfST8_Img7FHW-MvUs35KA=.6d642e43-5446-4627-8403-61a167da8512@github.com> Message-ID: On Wed, 11 May 2022 13:37:54 GMT, Erik Joelsson wrote: >> Actually, it's quite common to have as a requirement 2 reviewers, at least one of which must be a Reviewer and the other an Author (i.e., any role in the Project). Both `jdk` and `jfx` are configured this way. Here is the current Progress item that Skara adds in response to the command `/reviewers 2`: >> >> >> - [ ] Change must be properly reviewed (2 reviews required, with at least 1 reviewer, 1 author) >> >> >> And here is the comment: >> >> >> The total number of required reviews for this PR (including the jcheck configuration and the last /reviewers command) is now set to 2 (with 1 of role reviewers, 1 of role authors). >> >> >> Both "Reviewer" and "Author" should be capitalized in both messages. Separately, I see that the pluralization was fixed in the Progress item, but not the comment. > > There are also projects that do not have any members in the Reviewer role, so they configure their repository to only require Committers. The only role I doubt we will ever see required in reality is Lead, but that's ok. What about changing the message `(with 1 of role reviewers, 1 of role authors)` to `(with at least 1 Reviewer, 1 Author)` and obeying the same pluralization rule. The message `(with 1 of role reviewers, 1 of role authors)` may be fixed as `(with 1 of role Reviewer, 1 of role Author)`. But if there is a message `(with 2 of role reviewers)`, we don't know whether it should fixed as `(with 2 of role Reviewer)` or `(with 2 of role Reviewers)` (pluralization). It is good to unify it to `(with at least 2 Reviewers)`. ------------- PR: https://git.openjdk.java.net/skara/pull/1305 From gli at openjdk.java.net Wed May 11 15:27:10 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Wed, 11 May 2022 15:27:10 GMT Subject: RFR: 1437: Fix the OpenJDK official role name and pluralization Message-ID: Hi all, This patch mainly fixes the following message: 1. Remove the pluralization if these is 0 reviewer. `no reviews required` --> `no review required` 2. Fix the official role name. eg: `reviewer` --> `Reviewer`, `committers` --> `Committers` 3. Unify the comment and the progress message. ` (with 1 of role reviewers)` --> `(with at least 1 Reviewer)` 4. Fix the pluralization of the comment. ` (with 1 of role reviewers)` --> `(with at least 1 Reviewer)` Note the pluralization. Thanks for taking the time to review. Best Regards, -- Guoxiong ------------- Commit messages: - SKARA-1437 Changes: https://git.openjdk.java.net/skara/pull/1319/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1319&range=00 Issue: https://bugs.openjdk.java.net/browse/SKARA-1437 Stats: 98 lines in 4 files changed: 7 ins; 10 del; 81 mod Patch: https://git.openjdk.java.net/skara/pull/1319.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1319/head:pull/1319 PR: https://git.openjdk.java.net/skara/pull/1319 From gli at openjdk.java.net Wed May 11 15:27:23 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Wed, 11 May 2022 15:27:23 GMT Subject: RFR: 282: Make the review requirements more explicit in the progress list [v3] In-Reply-To: References: <3bKKJeWq1Hz5RzzzpTfv2UfST8_Img7FHW-MvUs35KA=.6d642e43-5446-4627-8403-61a167da8512@github.com> Message-ID: On Wed, 11 May 2022 14:25:46 GMT, Guoxiong Li wrote: >> There are also projects that do not have any members in the Reviewer role, so they configure their repository to only require Committers. The only role I doubt we will ever see required in reality is Lead, but that's ok. > > What about changing the message `(with 1 of role reviewers, 1 of role authors)` to `(with at least 1 Reviewer, 1 Author)` and obeying the same pluralization rule. The message `(with 1 of role reviewers, 1 of role authors)` may be fixed as `(with 1 of role Reviewer, 1 of role Author)`. But if there is a message `(with 2 of role reviewers)`, we don't know whether it should fixed as `(with 2 of role Reviewer)` or `(with 2 of role Reviewers)` (pluralization). It is good to unify it to `(with at least 2 Reviewers)`. I submitted a PR https://github.com/openjdk/skara/pull/1319. We can continue the discussion there. ------------- PR: https://git.openjdk.java.net/skara/pull/1305 From erikj at openjdk.java.net Wed May 11 17:03:17 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 11 May 2022 17:03:17 GMT Subject: RFR: 1437: Fix the OpenJDK official role name and pluralization In-Reply-To: References: Message-ID: <7UpR0JEERE24-hKFf_zBizxfuVuMrivpx1zy5hCAK0c=.bc88275f-ff8c-4220-81ec-62baae1d87ec@github.com> On Wed, 11 May 2022 15:22:58 GMT, Guoxiong Li wrote: > Hi all, > > This patch mainly fixes the following message: > > 1. Remove the pluralization if these is 0 reviewer. `no reviews required` --> `no review required` > 2. Fix the official role name. eg: `reviewer` --> `Reviewer`, `committers` --> `Committers` > 3. Unify the comment and the progress message. ` (with 1 of role reviewers)` --> `(with at least 1 Reviewer)` > 4. Fix the pluralization of the comment. ` (with 1 of role reviewers)` --> `(with at least 1 Reviewer)` Note the pluralization. > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong Marked as reviewed by erikj (Lead). ------------- PR: https://git.openjdk.java.net/skara/pull/1319 From erikj at openjdk.java.net Wed May 11 17:09:07 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 11 May 2022 17:09:07 GMT Subject: RFR: 1437: Fix the OpenJDK official role name and pluralization In-Reply-To: References: Message-ID: On Wed, 11 May 2022 15:22:58 GMT, Guoxiong Li wrote: > Hi all, > > This patch mainly fixes the following message: > > 1. Remove the pluralization if these is 0 reviewer. `no reviews required` --> `no review required` > 2. Fix the official role name. eg: `reviewer` --> `Reviewer`, `committers` --> `Committers` > 3. Unify the comment and the progress message. ` (with 1 of role reviewers)` --> `(with at least 1 Reviewer)` > 4. Fix the pluralization of the comment. ` (with 1 of role reviewers)` --> `(with at least 1 Reviewer)` Note the pluralization. > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong Reading your comment in the other PR, it got me thinking, if we really want to make it clear that we are referencing the OpenJDK roles, then perhaps we should make each instance of `Reviewer` or `Author` etc be a link to the section in the bylaws. e.g. 1 [Reviewer](http://openjdk.java.net/bylaws#reviewer), 2 [Authors](http://openjdk.java.net/bylaws#author) ------------- PR: https://git.openjdk.java.net/skara/pull/1319 From erikj at openjdk.java.net Wed May 11 17:34:35 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 11 May 2022 17:34:35 GMT Subject: RFR: 1385: Backport MR links to the wrong CSR request [v2] In-Reply-To: References: <0aKhvarUQYxTcM9B6TGI8p5dv_t9H8cNTX-wdJAuCxI=.bcc1d50c-5b59-4b33-bc3b-b15ef169e365@github.com> Message-ID: <-Yi0W5Rn562711Blo3ipTV8HAUWx_KjCBrbw7L9QjM0=.24014665-aa67-4304-8cbd-3a0a3a03dc01@github.com> On Tue, 10 May 2022 14:25:05 GMT, Guoxiong Li wrote: >> jbs/src/main/java/org/openjdk/skara/jbs/IssueUtil.java line 45: >> >>> 43: * A "scratch" fixVersion is empty, "tbd.*", or "unknown". >>> 44: */ >>> 45: public static Optional findClosestIssue(List issueList, JdkVersion fixVersion) { >> >> I think this method belongs in the Backports class, close to Backports#findIssue. They do almost the same thing, so if we are to maintain two similar implementations of the version matching order, they should reside close to each other. >> >> Could we move more of the common functionality to Backports. Something like `Backports.findCsr(Issue primary, JdkVersion jdkVersion)` that would encapsulate most of this repeated functionality? > >> I think this method belongs in the Backports class, close to Backports#findIssue. They do almost the same thing, so if we are to maintain two similar implementations of the version matching order, they should reside close to each other. > > The `Backports` class mainly handles something about backport. But this method is only about issue instead of backport. > Actully, the method `Backports#findIssue` should delegate to a method such as `IssueUtil#findClosestIssue(List issueList, JdkVersion fixVersion, boolean onlySearchMainFixVersion)` after getting the backport issues to find the closest issue by using the main fix version. Such refactor is good but I don't think it should be done at this patch. So I would like to keep the utilility method about issues at a seperate class so that we can do more refactor in the future. The class name `IssueUtil` may need to be adjusted to a better name. > >> Could we move more of the common functionality to Backports. Something like Backports.findCsr(Issue primary, JdkVersion jdkVersion) that would encapsulate most of this repeated functionality? > > I moved the method `findCsr` and `csrLink` to the class `IssueUtil`. Again, the class name `Backports` is not good to place such methods. I see your point about having a static class with utility methods for issues, similar to the java.util.Collections or java.util.Arrays classes, and following that pattern, I think the name should be `Issues`. However, The `IssueUtil#findClosestIssue` method may look like it applies generally to issues, but in reality it does not. Looking for an issue with the best matching fixVersion is inherently tied to the concept of backports as we handle them in the OpenJDK development process. This is now expanded to finding the best matching CSR in a tree of backport issues, but it's still a tree of backports, and traversing a tree of backports should be handled by the Backports class. In your current patch `IssueUtils` calls into `Backports` to get all backports. If you truly want the separation between `IssueUtils` and `Backports`, then you can't really have `IssueUtils` call into `Backports`. If you would later refactor `Backports::findIssue` to call into `IssueUtils::findClosestIssue`, we would end up with both classes calling each other. To me `Backports::findCsr` makes perfect sense, it's about finding the correct CSR in a tree of backports. `IssueUtils::findCsr` does not, as it's not clear to me that `IssueUtils` would have any knowledge about traversing backports. ------------- PR: https://git.openjdk.java.net/skara/pull/1318 From ihse at openjdk.java.net Wed May 11 22:08:25 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Wed, 11 May 2022 22:08:25 GMT Subject: RFR: 1437: Fix the OpenJDK official role name and pluralization In-Reply-To: References: Message-ID: On Wed, 11 May 2022 15:22:58 GMT, Guoxiong Li wrote: > Hi all, > > This patch mainly fixes the following message: > > 1. Remove the pluralization if these is 0 reviewer. `no reviews required` --> `no review required` > 2. Fix the official role name. eg: `reviewer` --> `Reviewer`, `committers` --> `Committers` > 3. Unify the comment and the progress message. ` (with 1 of role reviewers)` --> `(with at least 1 Reviewer)` > 4. Fix the pluralization of the comment. ` (with 1 of role reviewers)` --> `(with at least 1 Reviewer)` Note the pluralization. > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong +1 for Erik's suggestion. That would be a subtle but unambiguous way to show what we mean by those concepts. ------------- PR: https://git.openjdk.java.net/skara/pull/1319 From gli at openjdk.java.net Thu May 12 03:38:44 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Thu, 12 May 2022 03:38:44 GMT Subject: RFR: 1437: Fix the OpenJDK official role name and pluralization [v2] In-Reply-To: References: Message-ID: > Hi all, > > This patch mainly fixes the following message: > > 1. Remove the pluralization if these is 0 reviewer. `no reviews required` --> `no review required` > 2. Fix the official role name. eg: `reviewer` --> `Reviewer`, `committers` --> `Committers` > 3. Unify the comment and the progress message. ` (with 1 of role reviewers)` --> `(with at least 1 Reviewer)` > 4. Fix the pluralization of the comment. ` (with 1 of role reviewers)` --> `(with at least 1 Reviewer)` Note the pluralization. > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: Add bylaws link of the role. ------------- Changes: - all: https://git.openjdk.java.net/skara/pull/1319/files - new: https://git.openjdk.java.net/skara/pull/1319/files/c5fc2924..0042b23c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=skara&pr=1319&range=01 - incr: https://webrevs.openjdk.java.net/?repo=skara&pr=1319&range=00-01 Stats: 149 lines in 4 files changed: 33 ins; 19 del; 97 mod Patch: https://git.openjdk.java.net/skara/pull/1319.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1319/head:pull/1319 PR: https://git.openjdk.java.net/skara/pull/1319 From gli at openjdk.java.net Thu May 12 03:38:45 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Thu, 12 May 2022 03:38:45 GMT Subject: RFR: 1437: Fix the OpenJDK official role name and pluralization In-Reply-To: References: Message-ID: On Wed, 11 May 2022 15:22:58 GMT, Guoxiong Li wrote: > Hi all, > > This patch mainly fixes the following message: > > 1. Remove the pluralization if these is 0 reviewer. `no reviews required` --> `no review required` > 2. Fix the official role name. eg: `reviewer` --> `Reviewer`, `committers` --> `Committers` > 3. Unify the comment and the progress message. ` (with 1 of role reviewers)` --> `(with at least 1 Reviewer)` > 4. Fix the pluralization of the comment. ` (with 1 of role reviewers)` --> `(with at least 1 Reviewer)` Note the pluralization. > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong This link was added. And the tests were refactored to avoid some duplicated code. For convenience, I copy some messages/comments below for you to review: The total number of required reviews for this PR (including the jcheck configuration and the last /reviewers command) is now set to 5 (with at least 1 [Lead](http://openjdk.java.net/bylaws#project-lead), 1 [Reviewer](http://openjdk.java.net/bylaws#reviewer), 1 [Committer](http://openjdk.java.net/bylaws#committer), 1 [Author](http://openjdk.java.net/bylaws#author), 1 [Contributor](http://openjdk.java.net/bylaws#contributor)). The total number of required reviews for this PR (including the jcheck configuration and the last /reviewers command) is now set to 2 (with at least 1 [Reviewer](http://openjdk.java.net/bylaws#reviewer), 1 [Author](http://openjdk.java.net/bylaws#author)). The total number of required reviews for this PR (including the jcheck configuration and the last /reviewers command) is now set to 2 (with at least 2 [Reviewers](http://openjdk.java.net/bylaws#reviewer)). Change must be properly reviewed (5 reviews required, with at least 1 [Lead](http://openjdk.java.net/bylaws#project-lead), 1 [Reviewer](http://openjdk.java.net/bylaws#reviewer), 1 [Committer](http://openjdk.java.net/bylaws#committer), 1 [Author](http://openjdk.java.net/bylaws#author), 1 [Contributor](http://openjdk.java.net/bylaws#contributor)) Change must be properly reviewed (1 review required, with at least 1 [Reviewer](http://openjdk.java.net/bylaws#reviewer)) Change must be properly reviewed (2 reviews required, with at least 2 [Reviewers](http://openjdk.java.net/bylaws#reviewer)) ------------- PR: https://git.openjdk.java.net/skara/pull/1319 From gli at openjdk.java.net Thu May 12 04:14:05 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Thu, 12 May 2022 04:14:05 GMT Subject: RFR: 1385: Backport MR links to the wrong CSR request [v5] In-Reply-To: <0aKhvarUQYxTcM9B6TGI8p5dv_t9H8cNTX-wdJAuCxI=.bcc1d50c-5b59-4b33-bc3b-b15ef169e365@github.com> References: <0aKhvarUQYxTcM9B6TGI8p5dv_t9H8cNTX-wdJAuCxI=.bcc1d50c-5b59-4b33-bc3b-b15ef169e365@github.com> Message-ID: > Hi all, > > This patch solves the wrong CSR in the backport PR. It mainly has the following rules: > 1. if the `version` in `.jcheck/conf` doesn't exist or the `version` is wrong, the bot think the CSR also doesn't exist. > 2. else, if the `version` in `.jcheck/conf` matches the fix version of the primary CSR, the bot will use the primary CSR. (primary CSR is the CSR of the primary issue) > 3. else, if these is a backport issue matches the `version`, the bot will find the CSR of the backport issue. If found, use it. If not, the bot think the CSR doesn't exist. > 4. else (no backport issue matches the `version`) the bot think the CSR doesn't exist. > > The classes `CSRBot`, `CheckRun` and `CSRCommand` will handle the situations above respectively. > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: Move the methods from IssueUtil to Backports. ------------- Changes: - all: https://git.openjdk.java.net/skara/pull/1318/files - new: https://git.openjdk.java.net/skara/pull/1318/files/d340a6cf..8aa52dc5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=skara&pr=1318&range=04 - incr: https://webrevs.openjdk.java.net/?repo=skara&pr=1318&range=03-04 Stats: 324 lines in 7 files changed: 123 ins; 194 del; 7 mod Patch: https://git.openjdk.java.net/skara/pull/1318.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1318/head:pull/1318 PR: https://git.openjdk.java.net/skara/pull/1318 From gli at openjdk.java.net Thu May 12 04:16:44 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Thu, 12 May 2022 04:16:44 GMT Subject: RFR: 1385: Backport MR links to the wrong CSR request [v2] In-Reply-To: <-Yi0W5Rn562711Blo3ipTV8HAUWx_KjCBrbw7L9QjM0=.24014665-aa67-4304-8cbd-3a0a3a03dc01@github.com> References: <0aKhvarUQYxTcM9B6TGI8p5dv_t9H8cNTX-wdJAuCxI=.bcc1d50c-5b59-4b33-bc3b-b15ef169e365@github.com> <-Yi0W5Rn562711Blo3ipTV8HAUWx_KjCBrbw7L9QjM0=.24014665-aa67-4304-8cbd-3a0a3a03dc01@github.com> Message-ID: On Wed, 11 May 2022 17:31:03 GMT, Erik Joelsson wrote: >>> I think this method belongs in the Backports class, close to Backports#findIssue. They do almost the same thing, so if we are to maintain two similar implementations of the version matching order, they should reside close to each other. >> >> The `Backports` class mainly handles something about backport. But this method is only about issue instead of backport. >> Actully, the method `Backports#findIssue` should delegate to a method such as `IssueUtil#findClosestIssue(List issueList, JdkVersion fixVersion, boolean onlySearchMainFixVersion)` after getting the backport issues to find the closest issue by using the main fix version. Such refactor is good but I don't think it should be done at this patch. So I would like to keep the utilility method about issues at a seperate class so that we can do more refactor in the future. The class name `IssueUtil` may need to be adjusted to a better name. >> >>> Could we move more of the common functionality to Backports. Something like Backports.findCsr(Issue primary, JdkVersion jdkVersion) that would encapsulate most of this repeated functionality? >> >> I moved the method `findCsr` and `csrLink` to the class `IssueUtil`. Again, the class name `Backports` is not good to place such methods. > > I see your point about having a static class with utility methods for issues, similar to the java.util.Collections or java.util.Arrays classes, and following that pattern, I think the name should be `Issues`. > > However, The `IssueUtil#findClosestIssue` method may look like it applies generally to issues, but in reality it does not. Looking for an issue with the best matching fixVersion is inherently tied to the concept of backports as we handle them in the OpenJDK development process. This is now expanded to finding the best matching CSR in a tree of backport issues, but it's still a tree of backports, and traversing a tree of backports should be handled by the Backports class. > > In your current patch `IssueUtils` calls into `Backports` to get all backports. If you truly want the separation between `IssueUtils` and `Backports`, then you can't really have `IssueUtils` call into `Backports`. If you would later refactor `Backports::findIssue` to call into `IssueUtils::findClosestIssue`, we would end up with both classes calling each other. > > To me `Backports::findCsr` makes perfect sense, it's about finding the correct CSR in a tree of backports. `IssueUtils::findCsr` does not, as it's not clear to me that `IssueUtils` would have any knowledge about traversing backports. >From your description, now I think the `Backports` make sense to contain these methods. I moved them to `Backports` and removed the file `IssueUtil`. ------------- PR: https://git.openjdk.java.net/skara/pull/1318 From ihse at openjdk.java.net Thu May 12 08:49:50 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Thu, 12 May 2022 08:49:50 GMT Subject: RFR: 1437: Fix the OpenJDK official role name and pluralization [v2] In-Reply-To: References: Message-ID: On Thu, 12 May 2022 03:38:44 GMT, Guoxiong Li wrote: >> Hi all, >> >> This patch mainly fixes the following message: >> >> 1. Remove the pluralization if these is 0 reviewer. `no reviews required` --> `no review required` >> 2. Fix the official role name. eg: `reviewer` --> `Reviewer`, `committers` --> `Committers` >> 3. Unify the comment and the progress message. ` (with 1 of role reviewers)` --> `(with at least 1 Reviewer)` >> 4. Fix the pluralization of the comment. ` (with 1 of role reviewers)` --> `(with at least 1 Reviewer)` Note the pluralization. >> >> Thanks for taking the time to review. >> >> Best Regards, >> -- Guoxiong > > Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: > > Add bylaws link of the role. Marked as reviewed by ihse (Reviewer). Looks great! Thanks for doing this. ------------- PR: https://git.openjdk.java.net/skara/pull/1319 From magnus.ihse.bursie at oracle.com Thu May 12 17:20:41 2022 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 12 May 2022 19:20:41 +0200 Subject: Fwd: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v34] In-Reply-To: References: Message-ID: <34217bf3-f5a7-c8d2-40e9-b73176fa46ec@oracle.com> Seems there was some issue with the new `/jep` command. I understand why Maurizio did not want to hold up the integration to have it resolved, but we should check what happened, and fix any bugs. I think this was the very first proper test of the JEP command in a real-life scenario, and it's a bit disappointing if it blocked the integration even if everything was correct. /Magnus -------- Forwarded Message -------- Subject: Re: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v34] Date: Thu, 12 May 2022 15:51:00 GMT From: Maurizio Cimadamore To: build-dev at openjdk.java.net, core-libs-dev at openjdk.java.net, hotspot-dev at openjdk.java.net, nio-dev at openjdk.java.net, shenandoah-dev at openjdk.java.net On Fri, 29 Apr 2022 08:29:52 GMT, Guoxiong Li wrote: >>> Remind: please use the command `/jep JEP-424` [1] to mark this PR. >>> >>> [1] >>> https://wiki.openjdk.java.net/display/SKARA/Pull+Request+Commands#PullRequestCommands-/jep >> >> Question: I'm willing to try it out. If something goes wrong - would >> a `jep unneeded` be enough to "unstuck" this PR? > >> would a jep unneeded be enough to "unstuck" this PR? > > Yes if no bug. Conceptually, the `/jep unneeded` will behave as no jep > command. @lgxbslgx - JEP has been targeted, but the JEP action seems to be blocking this - what should we do? ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From lgxbslgx at gmail.com Fri May 13 04:41:01 2022 From: lgxbslgx at gmail.com (Guoxiong Li) Date: Fri, 13 May 2022 12:41:01 +0800 Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v34] In-Reply-To: <34217bf3-f5a7-c8d2-40e9-b73176fa46ec@oracle.com> References: <34217bf3-f5a7-c8d2-40e9-b73176fa46ec@oracle.com> Message-ID: >From this PR, the `jep` label was not removed by the JEP bot so that the checkbox `- [ ] Change requires a JEP request to be targeted` had not been selected by the PR bot and then the PR bot didn't mark this PR as Ready. So I confirm that this bug occurs at the class `JEPBot` instead of the PR bot. I re-read the related code but can't find any issue from the code. Maybe It needs Erik to check the running configuration and log to get more information. Best Regards, -- Guoxiong From magnus.ihse.bursie at oracle.com Fri May 13 10:10:50 2022 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 13 May 2022 12:10:50 +0200 Subject: Fwd: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v34] In-Reply-To: References: <34217bf3-f5a7-c8d2-40e9-b73176fa46ec@oracle.com> Message-ID: <84917f66-907a-7172-3e14-984a8e94c579@oracle.com> On 2022-05-12 19:29, Maurizio Cimadamore wrote: > > Hi Magnus. > > The /jep command seemed to indeed have blocked integration. I waited > around 45 mins since the JEP was targeted, and no change occurred in > the PR, which was still showing up with the JEP tag. > Didn't we have an issue with CSR labels not being updated in the PR when the CSR changed status in JBS, but no other changes were made in the PR? Could this be something similar? Maybe as Maurizio says, the polling frequency of JBS is not good enough? /Magnus > In the end, I dropped the tag using "/jep unneded", and that got me > unstuck. > > Perhaps it's just matter of polling frequency in JBS not being high > enough - in this case I wanted to integrate sooner rather than later, > given the delicate nature of the thing being integrated (the less > additional merges the better) and the timezone (better to fix > something broken now than at 2am :-) ). > > Maurizio > > On 12/05/2022 18:20, Magnus Ihse Bursie wrote: >> Seems there was some issue with the new `/jep` command. I understand >> why Maurizio did not want to hold up the integration to have it >> resolved, but we should check what happened, and fix any bugs. I >> think this was the very first proper test of the JEP command in a >> real-life scenario, and it's a bit disappointing if it blocked the >> integration even if everything was correct. >> >> /Magnus >> >> >> -------- Forwarded Message -------- >> Subject: Re: RFR: 8282191: Implementation of Foreign Function & >> Memory API (Preview) [v34] >> Date: Thu, 12 May 2022 15:51:00 GMT >> From: Maurizio Cimadamore >> To: build-dev at openjdk.java.net, core-libs-dev at openjdk.java.net, >> hotspot-dev at openjdk.java.net, nio-dev at openjdk.java.net, >> shenandoah-dev at openjdk.java.net >> >> >> >> On Fri, 29 Apr 2022 08:29:52 GMT, Guoxiong Li wrote: >> >>>>> Remind: please use the command `/jep JEP-424` [1] to mark this PR. >>>>> >>>>> [1] >>>>> https://wiki.openjdk.java.net/display/SKARA/Pull+Request+Commands#PullRequestCommands-/jep >>>> >>>> Question: I'm willing to try it out. If something goes wrong - >>>> would a `jep unneeded` be enough to "unstuck" this PR? >>> >>>> would a jep unneeded be enough to "unstuck" this PR? >>> >>> Yes if no bug. Conceptually, the `/jep unneeded` will behave as no >>> jep command. >> >> @lgxbslgx - JEP has been targeted, but the JEP action seems to be >> blocking this - what should we do? >> >> ------------- >> >> PR: https://git.openjdk.java.net/jdk/pull/7888 From gli at openjdk.java.net Sat May 14 12:17:31 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Sat, 14 May 2022 12:17:31 GMT Subject: RFR: 1437: Fix the OpenJDK official role name and pluralization In-Reply-To: References: Message-ID: On Wed, 11 May 2022 17:06:19 GMT, Erik Joelsson wrote: >> Hi all, >> >> This patch mainly fixes the following message: >> >> 1. Remove the pluralization if these is 0 reviewer. `no reviews required` --> `no review required` >> 2. Fix the official role name. eg: `reviewer` --> `Reviewer`, `committers` --> `Committers` >> 3. Unify the comment and the progress message. ` (with 1 of role reviewers)` --> `(with at least 1 Reviewer)` >> 4. Fix the pluralization of the comment. ` (with 1 of role reviewers)` --> `(with at least 1 Reviewer)` Note the pluralization. >> >> Thanks for taking the time to review. >> >> Best Regards, >> -- Guoxiong > > Reading your comment in the other PR, it got me thinking, if we really want to make it clear that we are referencing the OpenJDK roles, then perhaps we should make each instance of `Reviewer` or `Author` etc be a link to the section in the bylaws. e.g. 1 [Reviewer](http://openjdk.java.net/bylaws#reviewer), 2 [Authors](http://openjdk.java.net/bylaws#author) @erikj79 @magicus Thanks for the reviews. Maybe it is good for Erik to re-review it before sponsoring. ------------- PR: https://git.openjdk.java.net/skara/pull/1319 From kcr at openjdk.java.net Sat May 14 12:52:46 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 14 May 2022 12:52:46 GMT Subject: RFR: 1437: Fix the OpenJDK official role name and pluralization [v2] In-Reply-To: References: Message-ID: On Thu, 12 May 2022 03:38:44 GMT, Guoxiong Li wrote: >> Hi all, >> >> This patch mainly fixes the following message: >> >> 1. Remove the pluralization if these is 0 reviewer. `no reviews required` --> `no review required` >> 2. Fix the official role name. eg: `reviewer` --> `Reviewer`, `committers` --> `Committers` >> 3. Unify the comment and the progress message. ` (with 1 of role reviewers)` --> `(with at least 1 Reviewer)` >> 4. Fix the pluralization of the comment. ` (with 1 of role reviewers)` --> `(with at least 1 Reviewer)` Note the pluralization. >> >> Thanks for taking the time to review. >> >> Best Regards, >> -- Guoxiong > > Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: > > Add bylaws link of the role. This looks good to me, although we should use HTTPS (not HTTP) for `openjdk.java.net`. We could do this in a follow-up, or you could change it now before this PR is sponsored. bots/pr/src/main/java/org/openjdk/skara/bots/pr/ReviewersCommand.java line 148: > 146: var nonZeroDescriptions = formatLimits.entrySet().stream() > 147: .filter(entry -> entry.getValue() > 0) > 148: .map(entry -> entry.getValue() + " " + String.format(entry.getKey(), entry.getValue() > 1 ? "s" : "", "http://openjdk.java.net/bylaws")) This really should use "https" rather than "http". ------------- PR: https://git.openjdk.java.net/skara/pull/1319 From gli at openjdk.java.net Sat May 14 13:02:39 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Sat, 14 May 2022 13:02:39 GMT Subject: RFR: 1437: Fix the OpenJDK official role name and pluralization [v2] In-Reply-To: References: Message-ID: On Sat, 14 May 2022 12:46:19 GMT, Kevin Rushforth wrote: >> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: >> >> Add bylaws link of the role. > > bots/pr/src/main/java/org/openjdk/skara/bots/pr/ReviewersCommand.java line 148: > >> 146: var nonZeroDescriptions = formatLimits.entrySet().stream() >> 147: .filter(entry -> entry.getValue() > 0) >> 148: .map(entry -> entry.getValue() + " " + String.format(entry.getKey(), entry.getValue() > 1 ? "s" : "", "http://openjdk.java.net/bylaws")) > > This really should use "https" rather than "http". It is good to fix it at this PR. I am fixing it now. ------------- PR: https://git.openjdk.java.net/skara/pull/1319 From gli at openjdk.java.net Sat May 14 13:15:53 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Sat, 14 May 2022 13:15:53 GMT Subject: RFR: 1437: Fix the OpenJDK official role name and pluralization [v3] In-Reply-To: References: Message-ID: > Hi all, > > This patch mainly fixes the following message: > > 1. Remove the pluralization if these is 0 reviewer. `no reviews required` --> `no review required` > 2. Fix the official role name. eg: `reviewer` --> `Reviewer`, `committers` --> `Committers` > 3. Unify the comment and the progress message. ` (with 1 of role reviewers)` --> `(with at least 1 Reviewer)` > 4. Fix the pluralization of the comment. ` (with 1 of role reviewers)` --> `(with at least 1 Reviewer)` Note the pluralization. > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: Fix bylaws url. ------------- Changes: - all: https://git.openjdk.java.net/skara/pull/1319/files - new: https://git.openjdk.java.net/skara/pull/1319/files/0042b23c..fa250869 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=skara&pr=1319&range=02 - incr: https://webrevs.openjdk.java.net/?repo=skara&pr=1319&range=01-02 Stats: 10 lines in 4 files changed: 6 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/skara/pull/1319.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1319/head:pull/1319 PR: https://git.openjdk.java.net/skara/pull/1319 From gli at openjdk.java.net Sat May 14 13:15:53 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Sat, 14 May 2022 13:15:53 GMT Subject: RFR: 1437: Fix the OpenJDK official role name and pluralization [v2] In-Reply-To: References: Message-ID: On Sat, 14 May 2022 12:59:49 GMT, Guoxiong Li wrote: >> bots/pr/src/main/java/org/openjdk/skara/bots/pr/ReviewersCommand.java line 148: >> >>> 146: var nonZeroDescriptions = formatLimits.entrySet().stream() >>> 147: .filter(entry -> entry.getValue() > 0) >>> 148: .map(entry -> entry.getValue() + " " + String.format(entry.getKey(), entry.getValue() > 1 ? "s" : "", "http://openjdk.java.net/bylaws")) >> >> This really should use "https" rather than "http". > > It is good to fix it at this PR. I am fixing it now. Done. ------------- PR: https://git.openjdk.java.net/skara/pull/1319 From kcr at openjdk.java.net Sat May 14 13:28:20 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 14 May 2022 13:28:20 GMT Subject: RFR: 1437: Fix the OpenJDK official role name and pluralization [v3] In-Reply-To: References: Message-ID: <78zCUNtZwDcNVZEBLMzzj6bd0TYBxQhlC5kYVuhhqD4=.2a5976cb-046f-4616-a7ea-e70468b99183@github.com> On Sat, 14 May 2022 13:15:53 GMT, Guoxiong Li wrote: >> Hi all, >> >> This patch mainly fixes the following message: >> >> 1. Remove the pluralization if these is 0 reviewer. `no reviews required` --> `no review required` >> 2. Fix the official role name. eg: `reviewer` --> `Reviewer`, `committers` --> `Committers` >> 3. Unify the comment and the progress message. ` (with 1 of role reviewers)` --> `(with at least 1 Reviewer)` >> 4. Fix the pluralization of the comment. ` (with 1 of role reviewers)` --> `(with at least 1 Reviewer)` Note the pluralization. >> >> Thanks for taking the time to review. >> >> Best Regards, >> -- Guoxiong > > Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: > > Fix bylaws url. Marked as reviewed by kcr (Reviewer). ------------- PR: https://git.openjdk.java.net/skara/pull/1319 From kcr at openjdk.java.net Wed May 18 12:44:43 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 18 May 2022 12:44:43 GMT Subject: RFR: 1437: Fix the OpenJDK official role name and pluralization In-Reply-To: References: Message-ID: On Sat, 14 May 2022 12:14:44 GMT, Guoxiong Li wrote: >> Reading your comment in the other PR, it got me thinking, if we really want to make it clear that we are referencing the OpenJDK roles, then perhaps we should make each instance of `Reviewer` or `Author` etc be a link to the section in the bylaws. e.g. 1 [Reviewer](http://openjdk.java.net/bylaws#reviewer), 2 [Authors](http://openjdk.java.net/bylaws#author) > > @erikj79 @magicus Thanks for the reviews. Maybe it is good for Erik to re-review it before sponsoring. @lgxbslgx This is ready for you to `/integrate` again. ------------- PR: https://git.openjdk.java.net/skara/pull/1319 From gli at openjdk.java.net Wed May 18 12:52:19 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Wed, 18 May 2022 12:52:19 GMT Subject: RFR: 1437: Fix the OpenJDK official role name and pluralization [v3] In-Reply-To: References: Message-ID: On Sat, 14 May 2022 13:15:53 GMT, Guoxiong Li wrote: >> Hi all, >> >> This patch mainly fixes the following message: >> >> 1. Remove the pluralization if these is 0 reviewer. `no reviews required` --> `no review required` >> 2. Fix the official role name. eg: `reviewer` --> `Reviewer`, `committers` --> `Committers` >> 3. Unify the comment and the progress message. ` (with 1 of role reviewers)` --> `(with at least 1 Reviewer)` >> 4. Fix the pluralization of the comment. ` (with 1 of role reviewers)` --> `(with at least 1 Reviewer)` Note the pluralization. >> >> Thanks for taking the time to review. >> >> Best Regards, >> -- Guoxiong > > Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: > > Fix bylaws url. Sorry, I missed it. ------------- PR: https://git.openjdk.java.net/skara/pull/1319 From gli at openjdk.java.net Wed May 18 12:54:53 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Wed, 18 May 2022 12:54:53 GMT Subject: Integrated: 1437: Fix the OpenJDK official role name and pluralization In-Reply-To: References: Message-ID: On Wed, 11 May 2022 15:22:58 GMT, Guoxiong Li wrote: > Hi all, > > This patch mainly fixes the following message: > > 1. Remove the pluralization if these is 0 reviewer. `no reviews required` --> `no review required` > 2. Fix the official role name. eg: `reviewer` --> `Reviewer`, `committers` --> `Committers` > 3. Unify the comment and the progress message. ` (with 1 of role reviewers)` --> `(with at least 1 Reviewer)` > 4. Fix the pluralization of the comment. ` (with 1 of role reviewers)` --> `(with at least 1 Reviewer)` Note the pluralization. > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong This pull request has now been integrated. Changeset: 9261f9b6 Author: Guoxiong Li Committer: Kevin Rushforth URL: https://git.openjdk.java.net/skara/commit/9261f9b6ec9b3a83b427b19fd27c6709d0996982 Stats: 177 lines in 4 files changed: 50 ins; 33 del; 94 mod 1437: Fix the OpenJDK official role name and pluralization Reviewed-by: erikj, ihse, kcr ------------- PR: https://git.openjdk.java.net/skara/pull/1319 From magnus.ihse.bursie at oracle.com Fri May 20 08:23:33 2022 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 20 May 2022 10:23:33 +0200 Subject: Result: New Skara Committer: Guoxiong Li Message-ID: Voting for Guoxiong Li [1] is now closed. Yes: 4 Veto: 0 Abstain: 0 According to the Bylaws definition of Three-Vote Consensus, this is sufficient to approve the nomination. /Magnus [1] https://mail.openjdk.java.net/pipermail/skara-dev/2022-May/005984.html From erikj at openjdk.java.net Wed May 25 14:33:35 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 25 May 2022 14:33:35 GMT Subject: RFR: 1448: Support specialized suffix pool records for legacy releases Message-ID: This patch makes it possible to define specialized "pool" versions with suffixes for 8u in JBS, similar to how it's already possible for 11u+. For example: we could create a JBS `8-pool-foo` version that got consumed by commits with fixVersion `8u331-foo`. ------------- Commit messages: - SKARA-1448 Changes: https://git.openjdk.java.net/skara/pull/1320/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1320&range=00 Issue: https://bugs.openjdk.java.net/browse/SKARA-1448 Stats: 18 lines in 3 files changed: 16 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/skara/pull/1320.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1320/head:pull/1320 PR: https://git.openjdk.java.net/skara/pull/1320 From kcr at openjdk.java.net Wed May 25 15:22:45 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 25 May 2022 15:22:45 GMT Subject: RFR: 1448: Support specialized suffix pool records for legacy releases In-Reply-To: References: Message-ID: On Wed, 25 May 2022 14:29:11 GMT, Erik Joelsson wrote: > This patch makes it possible to define specialized "pool" versions with suffixes for 8u in JBS, similar to how it's already possible for 11u+. For example: we could create a JBS `8-pool-foo` version that got consumed by commits with fixVersion `8u331-foo`. It looks good, although I left a question about one of the if checks. jbs/src/main/java/org/openjdk/skara/jbs/JdkVersion.java line 59: > 57: finalComponents.add(legacyMatcher.group(3)); > 58: } > 59: if (legacyMatcher.groupCount() > 3 && legacyMatcher.group(4) != null) { Should that be `> 4`? if it was equal to 4 wouldn't `group(4)` be OOB? ------------- Marked as reviewed by kcr (Reviewer). PR: https://git.openjdk.java.net/skara/pull/1320 From erikj at openjdk.java.net Wed May 25 15:48:47 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 25 May 2022 15:48:47 GMT Subject: RFR: 1448: Support specialized suffix pool records for legacy releases [v2] In-Reply-To: References: Message-ID: > This patch makes it possible to define specialized "pool" versions with suffixes for 8u in JBS, similar to how it's already possible for 11u+. For example: we could create a JBS `8-pool-foo` version that got consumed by commits with fixVersion `8u331-foo`. Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision: Use >= 4 instead of > 3 ------------- Changes: - all: https://git.openjdk.java.net/skara/pull/1320/files - new: https://git.openjdk.java.net/skara/pull/1320/files/f9801c15..e18bbb3d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=skara&pr=1320&range=01 - incr: https://webrevs.openjdk.java.net/?repo=skara&pr=1320&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/skara/pull/1320.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1320/head:pull/1320 PR: https://git.openjdk.java.net/skara/pull/1320 From kcr at openjdk.java.net Wed May 25 15:48:47 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 25 May 2022 15:48:47 GMT Subject: RFR: 1448: Support specialized suffix pool records for legacy releases [v2] In-Reply-To: References: Message-ID: On Wed, 25 May 2022 15:45:11 GMT, Erik Joelsson wrote: >> This patch makes it possible to define specialized "pool" versions with suffixes for 8u in JBS, similar to how it's already possible for 11u+. For example: we could create a JBS `8-pool-foo` version that got consumed by commits with fixVersion `8u331-foo`. > > Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision: > > Use >= 4 instead of > 3 Marked as reviewed by kcr (Reviewer). ------------- PR: https://git.openjdk.java.net/skara/pull/1320 From erikj at openjdk.java.net Wed May 25 15:48:47 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 25 May 2022 15:48:47 GMT Subject: RFR: 1448: Support specialized suffix pool records for legacy releases [v2] In-Reply-To: References: Message-ID: On Wed, 25 May 2022 15:19:08 GMT, Kevin Rushforth wrote: >> Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision: >> >> Use >= 4 instead of > 3 > > jbs/src/main/java/org/openjdk/skara/jbs/JdkVersion.java line 59: > >> 57: finalComponents.add(legacyMatcher.group(3)); >> 58: } >> 59: if (legacyMatcher.groupCount() > 3 && legacyMatcher.group(4) != null) { > > Should that be `> 4`? if it was equal to 4 wouldn't `group(4)` be OOB? Group 0 is the complete expression and is not included in the count by groupCount(). Perhaps `>= 4` is more readable as the number 4 is the relevant one. ------------- PR: https://git.openjdk.java.net/skara/pull/1320 From erikj at openjdk.java.net Wed May 25 16:10:25 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 25 May 2022 16:10:25 GMT Subject: RFR: 1449: Changing the original hash in a backport PR doesn't work Message-ID: If a user tries to change the original hash for a backport PR, by changing the title to "Backport HASH", it appears to work, but in reality, several things behind the scenes do not. The logic for finding the original commit will always just return the first hash that was set and ignores any updates/changes. This affects the clean evaluation and the commit message. This patch changes the method for finding the original hash so that the last one is returned instead. A new test is added to verify this functionality, both for the clean evaluation as well as the final commit message. ------------- Commit messages: - SKARA-1449 Changes: https://git.openjdk.java.net/skara/pull/1321/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1321&range=00 Issue: https://bugs.openjdk.java.net/browse/SKARA-1449 Stats: 135 lines in 2 files changed: 132 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/skara/pull/1321.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1321/head:pull/1321 PR: https://git.openjdk.java.net/skara/pull/1321 From erikj at openjdk.java.net Wed May 25 16:22:18 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 25 May 2022 16:22:18 GMT Subject: Integrated: 1448: Support specialized suffix pool records for legacy releases In-Reply-To: References: Message-ID: <9MkWnYo9vGrPRcXtjRp4YgJbqj8hV8aX9jIEgqWbgtg=.fb2745b4-6639-4538-86bf-7352ef9a16bf@github.com> On Wed, 25 May 2022 14:29:11 GMT, Erik Joelsson wrote: > This patch makes it possible to define specialized "pool" versions with suffixes for 8u in JBS, similar to how it's already possible for 11u+. For example: we could create a JBS `8-pool-foo` version that got consumed by commits with fixVersion `8u331-foo`. This pull request has now been integrated. Changeset: f611f732 Author: Erik Joelsson URL: https://git.openjdk.java.net/skara/commit/f611f732a5605423dfad2d3fdc9f7ee1ad1ef4a0 Stats: 18 lines in 3 files changed: 16 ins; 0 del; 2 mod 1448: Support specialized suffix pool records for legacy releases Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/skara/pull/1320 From kcr at openjdk.java.net Wed May 25 16:26:49 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 25 May 2022 16:26:49 GMT Subject: RFR: 1449: Changing the original hash in a backport PR doesn't work In-Reply-To: References: Message-ID: On Wed, 25 May 2022 16:06:10 GMT, Erik Joelsson wrote: > If a user tries to change the original hash for a backport PR, by changing the title to "Backport HASH", it appears to work, but in reality, several things behind the scenes do not. The logic for finding the original commit will always just return the first hash that was set and ignores any updates/changes. This affects the clean evaluation and the commit message. > > This patch changes the method for finding the original hash so that the last one is returned instead. A new test is added to verify this functionality, both for the clean evaluation as well as the final commit message. Looks good. ------------- Marked as reviewed by kcr (Reviewer). PR: https://git.openjdk.java.net/skara/pull/1321 From erikj at openjdk.java.net Wed May 25 16:33:45 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 25 May 2022 16:33:45 GMT Subject: Integrated: 1449: Changing the original hash in a backport PR doesn't work In-Reply-To: References: Message-ID: On Wed, 25 May 2022 16:06:10 GMT, Erik Joelsson wrote: > If a user tries to change the original hash for a backport PR, by changing the title to "Backport HASH", it appears to work, but in reality, several things behind the scenes do not. The logic for finding the original commit will always just return the first hash that was set and ignores any updates/changes. This affects the clean evaluation and the commit message. > > This patch changes the method for finding the original hash so that the last one is returned instead. A new test is added to verify this functionality, both for the clean evaluation as well as the final commit message. This pull request has now been integrated. Changeset: f5261711 Author: Erik Joelsson URL: https://git.openjdk.java.net/skara/commit/f5261711acde22fc470f8a5ef29b824eb766941b Stats: 135 lines in 2 files changed: 132 ins; 0 del; 3 mod 1449: Changing the original hash in a backport PR doesn't work Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/skara/pull/1321 From erikj at openjdk.java.net Wed May 25 18:32:52 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 25 May 2022 18:32:52 GMT Subject: RFR: 1385: Backport MR links to the wrong CSR request [v5] In-Reply-To: References: <0aKhvarUQYxTcM9B6TGI8p5dv_t9H8cNTX-wdJAuCxI=.bcc1d50c-5b59-4b33-bc3b-b15ef169e365@github.com> Message-ID: <8ZGM1F4mp4ptNDMebfuBVEblixD-NTWJmcTSi-_kmA8=.4a876250-422e-44f8-aba2-e6a63f8cf7a4@github.com> On Thu, 12 May 2022 04:14:05 GMT, Guoxiong Li wrote: >> Hi all, >> >> This patch solves the wrong CSR in the backport PR. It mainly has the following rules: >> 1. if the `version` in `.jcheck/conf` doesn't exist or the `version` is wrong, the bot think the CSR also doesn't exist. >> 2. else, if the `version` in `.jcheck/conf` matches the fix version of the primary CSR, the bot will use the primary CSR. (primary CSR is the CSR of the primary issue) >> 3. else, if these is a backport issue matches the `version`, the bot will find the CSR of the backport issue. If found, use it. If not, the bot think the CSR doesn't exist. >> 4. else (no backport issue matches the `version`) the bot think the CSR doesn't exist. >> >> The classes `CSRBot`, `CheckRun` and `CSRCommand` will handle the situations above respectively. >> >> Thanks for taking the time to review. >> >> Best Regards, >> -- Guoxiong > > Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: > > Move the methods from IssueUtil to Backports. Sorry it's taken a while, I've been out sick. This is starting to look really good, thanks for hanging in there. Only a few language nits. bots/csr/src/main/java/org/openjdk/skara/bots/csr/CSRBot.java line 93: > 91: var versionOpt = getVersion(pr); > 92: if (versionOpt.isEmpty()) { > 93: log.info("No right fix version found in file `.jcheck/conf` for " + describe(pr)); Suggestion: log.info("No fix version found in `.jcheck/conf` for " + describe(pr)); bots/pr/src/main/java/org/openjdk/skara/bots/pr/CSRCommand.java line 55: > 53: private static void linkReply(PullRequest pr, Issue issue, PrintWriter writer) { > 54: writer.println("@" + pr.author().username() + " please create a [CSR](https://wiki.openjdk.java.net/display/csr/Main) request for issue " + > 55: "[" + issue.id() + "](" + issue.webUrl() + ") with the right fix version. This pull request cannot be integrated until the CSR request is approved."); Suggestion: "[" + issue.id() + "](" + issue.webUrl() + ") with the correct fix version. " + "This pull request cannot be integrated until the CSR request is approved."); bots/pr/src/main/java/org/openjdk/skara/bots/pr/CSRCommand.java line 86: > 84: if (!labels.contains(CSR_LABEL)) { > 85: // FIXME here, the PR may have an approved CSR. We should distinguishing the situations > 86: // about having no csr request and (having csr request && the CSR has been approved). Suggestion: // FIXME here, the PR may have an approved CSR. We should distinguish the situations // of having no csr request and having an approved csr request. bots/pr/src/main/java/org/openjdk/skara/bots/pr/CSRCommand.java line 102: > 100: if (jbsIssueOpt.isEmpty()) { > 101: pr.removeLabel(CSR_LABEL); > 102: reply.println("determined that a [CSR](https://wiki.openjdk.java.net/display/csr/Main) request " + This reply is repeated a lot. Perhaps we should have a method for it like some of the other replies have. ------------- PR: https://git.openjdk.java.net/skara/pull/1318 From gli at openjdk.java.net Fri May 27 07:46:00 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Fri, 27 May 2022 07:46:00 GMT Subject: RFR: 1385: Backport MR links to the wrong CSR request [v6] In-Reply-To: <0aKhvarUQYxTcM9B6TGI8p5dv_t9H8cNTX-wdJAuCxI=.bcc1d50c-5b59-4b33-bc3b-b15ef169e365@github.com> References: <0aKhvarUQYxTcM9B6TGI8p5dv_t9H8cNTX-wdJAuCxI=.bcc1d50c-5b59-4b33-bc3b-b15ef169e365@github.com> Message-ID: <_Ge7ly0vXOqBKgtdXCXNiRBIzwGdsnlFu0jqr3nBKk0=.e6961ec1-0932-482d-83c1-a9b49786a8f6@github.com> > Hi all, > > This patch solves the wrong CSR in the backport PR. It mainly has the following rules: > 1. if the `version` in `.jcheck/conf` doesn't exist or the `version` is wrong, the bot think the CSR also doesn't exist. > 2. else, if the `version` in `.jcheck/conf` matches the fix version of the primary CSR, the bot will use the primary CSR. (primary CSR is the CSR of the primary issue) > 3. else, if these is a backport issue matches the `version`, the bot will find the CSR of the backport issue. If found, use it. If not, the bot think the CSR doesn't exist. > 4. else (no backport issue matches the `version`) the bot think the CSR doesn't exist. > > The classes `CSRBot`, `CheckRun` and `CSRCommand` will handle the situations above respectively. > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: Fix log and comment. ------------- Changes: - all: https://git.openjdk.java.net/skara/pull/1318/files - new: https://git.openjdk.java.net/skara/pull/1318/files/8aa52dc5..9c7c785b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=skara&pr=1318&range=05 - incr: https://webrevs.openjdk.java.net/?repo=skara&pr=1318&range=04-05 Stats: 27 lines in 3 files changed: 6 ins; 6 del; 15 mod Patch: https://git.openjdk.java.net/skara/pull/1318.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1318/head:pull/1318 PR: https://git.openjdk.java.net/skara/pull/1318 From gli at openjdk.java.net Fri May 27 07:46:04 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Fri, 27 May 2022 07:46:04 GMT Subject: RFR: 1385: Backport MR links to the wrong CSR request [v5] In-Reply-To: <8ZGM1F4mp4ptNDMebfuBVEblixD-NTWJmcTSi-_kmA8=.4a876250-422e-44f8-aba2-e6a63f8cf7a4@github.com> References: <0aKhvarUQYxTcM9B6TGI8p5dv_t9H8cNTX-wdJAuCxI=.bcc1d50c-5b59-4b33-bc3b-b15ef169e365@github.com> <8ZGM1F4mp4ptNDMebfuBVEblixD-NTWJmcTSi-_kmA8=.4a876250-422e-44f8-aba2-e6a63f8cf7a4@github.com> Message-ID: On Wed, 25 May 2022 18:02:49 GMT, Erik Joelsson wrote: >> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: >> >> Move the methods from IssueUtil to Backports. > > bots/csr/src/main/java/org/openjdk/skara/bots/csr/CSRBot.java line 93: > >> 91: var versionOpt = getVersion(pr); >> 92: if (versionOpt.isEmpty()) { >> 93: log.info("No right fix version found in file `.jcheck/conf` for " + describe(pr)); > > Suggestion: > > log.info("No fix version found in `.jcheck/conf` for " + describe(pr)); Fixed. > bots/pr/src/main/java/org/openjdk/skara/bots/pr/CSRCommand.java line 55: > >> 53: private static void linkReply(PullRequest pr, Issue issue, PrintWriter writer) { >> 54: writer.println("@" + pr.author().username() + " please create a [CSR](https://wiki.openjdk.java.net/display/csr/Main) request for issue " + >> 55: "[" + issue.id() + "](" + issue.webUrl() + ") with the right fix version. This pull request cannot be integrated until the CSR request is approved."); > > Suggestion: > > "[" + issue.id() + "](" + issue.webUrl() + ") with the correct fix version. " + > "This pull request cannot be integrated until the CSR request is approved."); Fixed. > bots/pr/src/main/java/org/openjdk/skara/bots/pr/CSRCommand.java line 86: > >> 84: if (!labels.contains(CSR_LABEL)) { >> 85: // FIXME here, the PR may have an approved CSR. We should distinguishing the situations >> 86: // about having no csr request and (having csr request && the CSR has been approved). > > Suggestion: > > // FIXME here, the PR may have an approved CSR. We should distinguish the situations > // of having no csr request and having an approved csr request. Fixed. > bots/pr/src/main/java/org/openjdk/skara/bots/pr/CSRCommand.java line 102: > >> 100: if (jbsIssueOpt.isEmpty()) { >> 101: pr.removeLabel(CSR_LABEL); >> 102: reply.println("determined that a [CSR](https://wiki.openjdk.java.net/display/csr/Main) request " + > > This reply is repeated a lot. Perhaps we should have a method for it like some of the other replies have. Fixed. Moved to method `csrUnneededReply`. ------------- PR: https://git.openjdk.java.net/skara/pull/1318 From lgxbslgx at gmail.com Fri May 27 08:25:19 2022 From: lgxbslgx at gmail.com (Guoxiong Li) Date: Fri, 27 May 2022 16:25:19 +0800 Subject: Fwd: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v34] In-Reply-To: <84917f66-907a-7172-3e14-984a8e94c579@oracle.com> References: <34217bf3-f5a7-c8d2-40e9-b73176fa46ec@oracle.com> <84917f66-907a-7172-3e14-984a8e94c579@oracle.com> Message-ID: The issue was not recorded. I filed https://bugs.openjdk.java.net/browse/SKARA-1454 to follow up. >From the comment time of the PR, it seems that Maurizio has waited about 30 minutes. The bot should iterate its check in several minutes. So I don't think it is the business of the polling frequency. But again, it needs Erik to check the running configuration to find the polling frequency(if it exists) and check the log(if it exists) of the JEPBot to get more information. cc'ing Erik From erikj at openjdk.java.net Fri May 27 12:25:13 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 27 May 2022 12:25:13 GMT Subject: RFR: 1385: Backport MR links to the wrong CSR request [v6] In-Reply-To: <_Ge7ly0vXOqBKgtdXCXNiRBIzwGdsnlFu0jqr3nBKk0=.e6961ec1-0932-482d-83c1-a9b49786a8f6@github.com> References: <0aKhvarUQYxTcM9B6TGI8p5dv_t9H8cNTX-wdJAuCxI=.bcc1d50c-5b59-4b33-bc3b-b15ef169e365@github.com> <_Ge7ly0vXOqBKgtdXCXNiRBIzwGdsnlFu0jqr3nBKk0=.e6961ec1-0932-482d-83c1-a9b49786a8f6@github.com> Message-ID: <0zKudY4oHe7xlpY_TdU3ScHqQ5kkqz2oo7WmMn7nox8=.624304e9-b813-4a9c-8dba-56c3488d001a@github.com> On Fri, 27 May 2022 07:46:00 GMT, Guoxiong Li wrote: >> Hi all, >> >> This patch solves the wrong CSR in the backport PR. It mainly has the following rules: >> 1. if the `version` in `.jcheck/conf` doesn't exist or the `version` is wrong, the bot think the CSR also doesn't exist. >> 2. else, if the `version` in `.jcheck/conf` matches the fix version of the primary CSR, the bot will use the primary CSR. (primary CSR is the CSR of the primary issue) >> 3. else, if these is a backport issue matches the `version`, the bot will find the CSR of the backport issue. If found, use it. If not, the bot think the CSR doesn't exist. >> 4. else (no backport issue matches the `version`) the bot think the CSR doesn't exist. >> >> The classes `CSRBot`, `CheckRun` and `CSRCommand` will handle the situations above respectively. >> >> Thanks for taking the time to review. >> >> Best Regards, >> -- Guoxiong > > Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: > > Fix log and comment. Marked as reviewed by erikj (Lead). ------------- PR: https://git.openjdk.java.net/skara/pull/1318 From gli at openjdk.java.net Fri May 27 14:37:19 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Fri, 27 May 2022 14:37:19 GMT Subject: RFR: 1385: Backport MR links to the wrong CSR request [v6] In-Reply-To: <0zKudY4oHe7xlpY_TdU3ScHqQ5kkqz2oo7WmMn7nox8=.624304e9-b813-4a9c-8dba-56c3488d001a@github.com> References: <0aKhvarUQYxTcM9B6TGI8p5dv_t9H8cNTX-wdJAuCxI=.bcc1d50c-5b59-4b33-bc3b-b15ef169e365@github.com> <_Ge7ly0vXOqBKgtdXCXNiRBIzwGdsnlFu0jqr3nBKk0=.e6961ec1-0932-482d-83c1-a9b49786a8f6@github.com> <0zKudY4oHe7xlpY_TdU3ScHqQ5kkqz2oo7WmMn7nox8=.624304e9-b813-4a9c-8dba-56c3488d001a@github.com> Message-ID: On Fri, 27 May 2022 12:22:59 GMT, Erik Joelsson wrote: >> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix log and comment. > > Marked as reviewed by erikj (Lead). @erikj79 Thanks for the review. ------------- PR: https://git.openjdk.java.net/skara/pull/1318 From gli at openjdk.java.net Fri May 27 14:37:20 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Fri, 27 May 2022 14:37:20 GMT Subject: Integrated: 1385: Backport MR links to the wrong CSR request In-Reply-To: <0aKhvarUQYxTcM9B6TGI8p5dv_t9H8cNTX-wdJAuCxI=.bcc1d50c-5b59-4b33-bc3b-b15ef169e365@github.com> References: <0aKhvarUQYxTcM9B6TGI8p5dv_t9H8cNTX-wdJAuCxI=.bcc1d50c-5b59-4b33-bc3b-b15ef169e365@github.com> Message-ID: On Sun, 8 May 2022 13:19:17 GMT, Guoxiong Li wrote: > Hi all, > > This patch solves the wrong CSR in the backport PR. It mainly has the following rules: > 1. if the `version` in `.jcheck/conf` doesn't exist or the `version` is wrong, the bot think the CSR also doesn't exist. > 2. else, if the `version` in `.jcheck/conf` matches the fix version of the primary CSR, the bot will use the primary CSR. (primary CSR is the CSR of the primary issue) > 3. else, if these is a backport issue matches the `version`, the bot will find the CSR of the backport issue. If found, use it. If not, the bot think the CSR doesn't exist. > 4. else (no backport issue matches the `version`) the bot think the CSR doesn't exist. > > The classes `CSRBot`, `CheckRun` and `CSRCommand` will handle the situations above respectively. > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong This pull request has now been integrated. Changeset: 9ced76d5 Author: Guoxiong Li URL: https://git.openjdk.java.net/skara/commit/9ced76d50c6830b03b59492d426f2f5032dec828 Stats: 859 lines in 12 files changed: 800 ins; 12 del; 47 mod 1385: Backport MR links to the wrong CSR request Reviewed-by: erikj ------------- PR: https://git.openjdk.java.net/skara/pull/1318 From erikj at openjdk.java.net Fri May 27 16:36:37 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 27 May 2022 16:36:37 GMT Subject: RFR: Add toString to JEPBot Message-ID: Add a toString() method to JEPBot in line with other bots. This helps a lot when searching bot logs. ------------- Commit messages: - Add toString to JEPBot Changes: https://git.openjdk.java.net/skara/pull/1322/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1322&range=00 Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/skara/pull/1322.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1322/head:pull/1322 PR: https://git.openjdk.java.net/skara/pull/1322 From erikj at openjdk.java.net Fri May 27 17:22:50 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 27 May 2022 17:22:50 GMT Subject: RFR: 1455: Github closed action may not contain an actor Message-ID: <_3vy10UIS-29mr4dhd5YqvfVjrw5oZbU5XepNyCLFN0=.d8d138a3-9978-473b-b5c7-a8068af54d44@github.com> As described in the bug, pr.closedBy() may (consistently) return empty on Github in some cases. Rather than getting stuck retrying endlessly, I think we should just add a fallback. ------------- Commit messages: - SKARA-1455 Changes: https://git.openjdk.java.net/skara/pull/1323/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1323&range=00 Issue: https://bugs.openjdk.java.net/browse/SKARA-1455 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/skara/pull/1323.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1323/head:pull/1323 PR: https://git.openjdk.java.net/skara/pull/1323 From kcr at openjdk.java.net Fri May 27 17:39:53 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 27 May 2022 17:39:53 GMT Subject: RFR: 1455: Github closed action may not contain an actor In-Reply-To: <_3vy10UIS-29mr4dhd5YqvfVjrw5oZbU5XepNyCLFN0=.d8d138a3-9978-473b-b5c7-a8068af54d44@github.com> References: <_3vy10UIS-29mr4dhd5YqvfVjrw5oZbU5XepNyCLFN0=.d8d138a3-9978-473b-b5c7-a8068af54d44@github.com> Message-ID: On Fri, 27 May 2022 17:18:46 GMT, Erik Joelsson wrote: > As described in the bug, pr.closedBy() may (consistently) return empty on Github in some cases. Rather than getting stuck retrying endlessly, I think we should just add a fallback. Looks good. ------------- Marked as reviewed by kcr (Reviewer). PR: https://git.openjdk.java.net/skara/pull/1323 From iris at openjdk.java.net Fri May 27 17:39:53 2022 From: iris at openjdk.java.net (Iris Clark) Date: Fri, 27 May 2022 17:39:53 GMT Subject: RFR: 1455: Github closed action may not contain an actor In-Reply-To: <_3vy10UIS-29mr4dhd5YqvfVjrw5oZbU5XepNyCLFN0=.d8d138a3-9978-473b-b5c7-a8068af54d44@github.com> References: <_3vy10UIS-29mr4dhd5YqvfVjrw5oZbU5XepNyCLFN0=.d8d138a3-9978-473b-b5c7-a8068af54d44@github.com> Message-ID: On Fri, 27 May 2022 17:18:46 GMT, Erik Joelsson wrote: > As described in the bug, pr.closedBy() may (consistently) return empty on Github in some cases. Rather than getting stuck retrying endlessly, I think we should just add a fallback. It seems reasonable for the fallback to be equivalent to historical behaviour. ------------- Marked as reviewed by iris (no project role). PR: https://git.openjdk.java.net/skara/pull/1323 From kcr at openjdk.java.net Fri May 27 17:40:18 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 27 May 2022 17:40:18 GMT Subject: RFR: Add toString to JEPBot In-Reply-To: References: Message-ID: On Fri, 27 May 2022 16:32:39 GMT, Erik Joelsson wrote: > Add a toString() method to JEPBot in line with other bots. This helps a lot when searching bot logs. Marked as reviewed by kcr (Reviewer). ------------- PR: https://git.openjdk.java.net/skara/pull/1322 From iris at openjdk.java.net Fri May 27 17:43:30 2022 From: iris at openjdk.java.net (Iris Clark) Date: Fri, 27 May 2022 17:43:30 GMT Subject: RFR: Add toString to JEPBot In-Reply-To: References: Message-ID: <5U9qem0tvszt5C5J5El-qJ_iZynGVkXuz4dwDl1CArc=.8832a60d-3d3f-4576-bc91-b03c1e885a3b@github.com> On Fri, 27 May 2022 16:32:39 GMT, Erik Joelsson wrote: > Add a toString() method to JEPBot in line with other bots. This helps a lot when searching bot logs. Looks like a nice aid for debugging. ------------- Marked as reviewed by iris (no project role). PR: https://git.openjdk.java.net/skara/pull/1322 From erikj at openjdk.java.net Fri May 27 17:58:14 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 27 May 2022 17:58:14 GMT Subject: Integrated: Add toString to JEPBot In-Reply-To: References: Message-ID: On Fri, 27 May 2022 16:32:39 GMT, Erik Joelsson wrote: > Add a toString() method to JEPBot in line with other bots. This helps a lot when searching bot logs. This pull request has now been integrated. Changeset: af1f0a67 Author: Erik Joelsson URL: https://git.openjdk.java.net/skara/commit/af1f0a67d4e08de802b68a9f5f21017051e90609 Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod Add toString to JEPBot Reviewed-by: kcr, iris ------------- PR: https://git.openjdk.java.net/skara/pull/1322 From erikj at openjdk.java.net Fri May 27 17:58:50 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 27 May 2022 17:58:50 GMT Subject: Integrated: 1455: Github closed action may not contain an actor In-Reply-To: <_3vy10UIS-29mr4dhd5YqvfVjrw5oZbU5XepNyCLFN0=.d8d138a3-9978-473b-b5c7-a8068af54d44@github.com> References: <_3vy10UIS-29mr4dhd5YqvfVjrw5oZbU5XepNyCLFN0=.d8d138a3-9978-473b-b5c7-a8068af54d44@github.com> Message-ID: <87idsC9pGJKmTNbM1-3Fh5lUJZ5-dOVwVugRiVbDLxU=.ee5a6e03-4311-4f3b-b98b-f6e769e147bb@github.com> On Fri, 27 May 2022 17:18:46 GMT, Erik Joelsson wrote: > As described in the bug, pr.closedBy() may (consistently) return empty on Github in some cases. Rather than getting stuck retrying endlessly, I think we should just add a fallback. This pull request has now been integrated. Changeset: 40314e56 Author: Erik Joelsson URL: https://git.openjdk.java.net/skara/commit/40314e5614d7ab88438deaeb986b7b3df3bbd20a Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 1455: Github closed action may not contain an actor Reviewed-by: iris, kcr ------------- PR: https://git.openjdk.java.net/skara/pull/1323 From erikj at openjdk.java.net Fri May 27 21:51:17 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 27 May 2022 21:51:17 GMT Subject: RFR: 1456: hgupdate-sync labeling ignores suffix on 8u releases Message-ID: This patch adds a new concept to the hgupdate-sync label logic, which I had naively thought was already there. Any version string with an "opt" part (basically a -suffix) gets treated as a separate release stream. I think this makes sense and is easily understood, but I'm looking for more eyes and thoughts on this. While working on it, an existing test started failing. I ended up removing it as I can't see how that test is relevant or even correct. AFAIK we never accept X-pool as fixVersion when an issue is resolved, and hgupdate-sync should only be considered for resolved or closed bugs. I think this test was based on trying to mimic the old labeler and happened to find a mislabeled set of bugs. ------------- Commit messages: - Fix comment - SKARA-1456 Changes: https://git.openjdk.java.net/skara/pull/1324/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1324&range=00 Issue: https://bugs.openjdk.java.net/browse/SKARA-1456 Stats: 37 lines in 2 files changed: 23 ins; 11 del; 3 mod Patch: https://git.openjdk.java.net/skara/pull/1324.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1324/head:pull/1324 PR: https://git.openjdk.java.net/skara/pull/1324 From kcr at openjdk.java.net Fri May 27 22:03:40 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 27 May 2022 22:03:40 GMT Subject: RFR: 1456: hgupdate-sync labeling ignores suffix on 8u releases In-Reply-To: References: Message-ID: <8qwH2JmFUuxCv26EBrYIuq6psHrk5oZS6IDrRAnW2_o=.c021ce92-7c06-4680-b6d4-00ebf73c5694@github.com> On Fri, 27 May 2022 21:47:00 GMT, Erik Joelsson wrote: > This patch adds a new concept to the hgupdate-sync label logic, which I had naively thought was already there. Any version string with an "opt" part (basically a -suffix) gets treated as a separate release stream. I think this makes sense and is easily understood, but I'm looking for more eyes and thoughts on this. > > While working on it, an existing test started failing. I ended up removing it as I can't see how that test is relevant or even correct. AFAIK we never accept X-pool as fixVersion when an issue is resolved, and hgupdate-sync should only be considered for resolved or closed bugs. I think this test was based on trying to mimic the old labeler and happened to find a mislabeled set of bugs. Looks good. ------------- Marked as reviewed by kcr (Reviewer). PR: https://git.openjdk.java.net/skara/pull/1324 From iris at openjdk.java.net Fri May 27 22:15:43 2022 From: iris at openjdk.java.net (Iris Clark) Date: Fri, 27 May 2022 22:15:43 GMT Subject: RFR: 1456: hgupdate-sync labeling ignores suffix on 8u releases In-Reply-To: References: Message-ID: On Fri, 27 May 2022 21:47:00 GMT, Erik Joelsson wrote: > This patch adds a new concept to the hgupdate-sync label logic, which I had naively thought was already there. Any version string with an "opt" part (basically a -suffix) gets treated as a separate release stream. I think this makes sense and is easily understood, but I'm looking for more eyes and thoughts on this. > > While working on it, an existing test started failing. I ended up removing it as I can't see how that test is relevant or even correct. AFAIK we never accept X-pool as fixVersion when an issue is resolved, and hgupdate-sync should only be considered for resolved or closed bugs. I think this test was based on trying to mimic the old labeler and happened to find a mislabeled set of bugs. Marked as reviewed by iris (no project role). ------------- PR: https://git.openjdk.java.net/skara/pull/1324 From gli at openjdk.java.net Sat May 28 08:37:51 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Sat, 28 May 2022 08:37:51 GMT Subject: RFR: 1434: Testissue#addLink doesn't generate the right relationship for the reversed link Message-ID: Hi all, This patch fixes the reversed link type. For example, when adding a `csr for` link at `ISSUE-1` which links to `ISSUE-2`, the `ISSUE-2` should have a reversed link `csr of` instead of the same link type `csr for`. The reversed relations are shown below: - `backported by` and `backport of` - `csr for` and `csr of` - `blocks` and `is blocked by` - `clones` and `is cloned by` And the `duplicates` link type doesn't have the reversed linke type like `duplicated by` now. So we should use the link type `duplicates` instead of `duplicated by` in the test cases so that the tests can be closer to the actual situation. Thanks for taking the time to review. Best Regards, -- Guoxiong ------------- Commit messages: - SKARA-1434 Changes: https://git.openjdk.java.net/skara/pull/1325/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1325&range=00 Issue: https://bugs.openjdk.java.net/browse/SKARA-1434 Stats: 13 lines in 3 files changed: 5 ins; 0 del; 8 mod Patch: https://git.openjdk.java.net/skara/pull/1325.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1325/head:pull/1325 PR: https://git.openjdk.java.net/skara/pull/1325 From gli at openjdk.java.net Sat May 28 09:22:26 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Sat, 28 May 2022 09:22:26 GMT Subject: RFR: 1410: The reply message of the 'reviewers' command should be more accurate Message-ID: Hi all, This trivial patch fixes the reply message of the `reviewers` command. Thanks for taking the time to review. Best Regards, -- Guoxiong ------------- Commit messages: - SKARA-1410 Changes: https://git.openjdk.java.net/skara/pull/1326/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1326&range=00 Issue: https://bugs.openjdk.java.net/browse/SKARA-1410 Stats: 17 lines in 2 files changed: 14 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/skara/pull/1326.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1326/head:pull/1326 PR: https://git.openjdk.java.net/skara/pull/1326 From lgxbslgx at gmail.com Sat May 28 10:26:08 2022 From: lgxbslgx at gmail.com (Guoxiong Li) Date: Sat, 28 May 2022 18:26:08 +0800 Subject: Fwd: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v34] In-Reply-To: References: <34217bf3-f5a7-c8d2-40e9-b73176fa46ec@oracle.com> <84917f66-907a-7172-3e14-984a8e94c579@oracle.com> Message-ID: > @lgxbslgx - JEP has been targeted, but the JEP action seems to be blocking this - what should we do? This issue [1] was solved yesterday. Erik's comment in the issue states the reason. cc'ing jdk-dev to inform other developers that the jep command can be used. [1] https://bugs.openjdk.java.net/browse/SKARA-1454 From gli at openjdk.java.net Sat May 28 16:52:09 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Sat, 28 May 2022 16:52:09 GMT Subject: RFR: 1433: The change of the CSR status doesn't force the CheckWorkItem to re-run the check Message-ID: Hi all, Currently, the CheckWorkItem of the PR bot doesn't re-run the check in the following two situations so that the message of the PR body is not updated and then confuses the developers. Situation 1 steps: - The issue has no csr at first - Use command `/csr needed` (now the PR has `csr` label) - Create a csr for this issue - Then the CheckWorkItem doesn't re-run the check (Because the `csr` label is kept in the PR and no new metadata found by CheckWorkItem) - (optionally) use command `/csr needed` again - (optionally) then the CheckWorkItem also doesn't re-run the check Situation 2 steps: - The issue has no csr at first (now the PR doesn't have `csr` label) - Add the new fix version to the existing approved csr. (Now the issue has the csr issue. And because this csr issue had been approved, PR also doesn't have `csr` label.) - then the CheckWorkItem doesn't re-run the check (No new metadata found by CheckWorkItem) - (optionally) use command `/csr needed` - (optionally) then the CheckWorkItem doesn't re-run the check It is because these two situations don't add or remove the `csr` label so that the `CheckWorkItem#getMetadata` doesn't return new metadata and then `CheckWorkItem#currentCheckValid` returns true and then the check doesn't re-run. This patch adds a new tag/marker named `"; > 37: private static final String CSR_UNNEEDED_MARKER = ""; Did you intend to look for this in the CSRBot? ------------- PR: https://git.openjdk.java.net/skara/pull/1327 From erikj at openjdk.java.net Tue May 31 18:19:45 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 31 May 2022 18:19:45 GMT Subject: RFR: SKARA-1119: A bot should remind a PR author not to force push In-Reply-To: References: Message-ID: On Sun, 29 May 2022 13:30:26 GMT, Guoxiong Li wrote: > Hi all, > > This patch adds a suggestion comment to the PR when the developers force-push the branch each time. Because I can't find the related rest api of the GitLab so I only implement it for GitHub. > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong bots/notify/src/main/java/org/openjdk/skara/bots/notify/prbranch/PullRequestBranchNotifier.java line 39: > 37: Please don't rebase and force-push to your branch of this PR because it invalidates previous review comments. \ > 38: To keep track of your changes incrementally, you only need to merge the target branch (optionally), \ > 39: commit your new change and push normally. The bot can squash them as a single commit when integrating. Suggestion: Please do not rebase or force-push to an active PR as it invalidates existing review comments. \ All changes will be squashed into a single commit automatically when integrating. \ See [OpenJDK Developers? Guide](https://openjdk.java.net/guide/#working-with-pull-requests). ------------- PR: https://git.openjdk.java.net/skara/pull/1328 From erikj at openjdk.java.net Tue May 31 20:12:06 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 31 May 2022 20:12:06 GMT Subject: Integrated: 1456: hgupdate-sync labeling ignores suffix on 8u releases In-Reply-To: References: Message-ID: <7gyvhCPiXKgF9ErtID0ILWTQ7nyqqjJtRG8ViP2Q6ek=.b8e470c9-2a31-41df-80b8-a725d79de6cb@github.com> On Fri, 27 May 2022 21:47:00 GMT, Erik Joelsson wrote: > This patch adds a new concept to the hgupdate-sync label logic, which I had naively thought was already there. Any version string with an "opt" part (basically a -suffix) gets treated as a separate release stream. I think this makes sense and is easily understood, but I'm looking for more eyes and thoughts on this. > > While working on it, an existing test started failing. I ended up removing it as I can't see how that test is relevant or even correct. AFAIK we never accept X-pool as fixVersion when an issue is resolved, and hgupdate-sync should only be considered for resolved or closed bugs. I think this test was based on trying to mimic the old labeler and happened to find a mislabeled set of bugs. This pull request has now been integrated. Changeset: 81bf44d0 Author: Erik Joelsson URL: https://git.openjdk.java.net/skara/commit/81bf44d031a3c465c639d97cfd2ece1c9bbf6b21 Stats: 37 lines in 2 files changed: 23 ins; 11 del; 3 mod 1456: hgupdate-sync labeling ignores suffix on 8u releases Reviewed-by: kcr, iris ------------- PR: https://git.openjdk.java.net/skara/pull/1324