From erikj at openjdk.org Mon Jul 1 06:27:33 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 1 Jul 2024 06:27:33 GMT Subject: RFR: 2311: Use getLast and removeLast methods for lists [v3] In-Reply-To: References:

Message-ID: <0PdVSNIt07EbMHX2RB9R63rl6SCHZdsyiIIMCDvk0CM=.68f19da4-652a-4244-95ab-b63e2b968610@github.com> On Fri, 28 Jun 2024 23:05:30 GMT, Pavel Rappo wrote: >> Please review this simple refactoring to change most if not all occurrences of `list.get(x.size() - 1)` to `list.getLast()`. >> >> `getLast` was introduced in JDK 21, as part of JEP 431: Sequenced Collections, which also introduced a counterpart method, `getFirst()`. While there are also a lot of occurrences of `list.get(0)` in Skara codebase, changing them to `list.getFirst()` might be of insufficient benefit and, hence, is not proposed in this PR. I don't think that coinciding `get(0)` and `getLast()` would look inconsistent. >> >> The copyright years will be updated after this PR has been reviewed. > > Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright years > > Note: any commit hashes below might be outdated due to subsequent > history rewriting (e.g. git rebase). > > + update args/src/main/java/org/openjdk/skara/args/ArgumentParser.java due to ceace51a > + update bots/bridgekeeper/src/main/java/org/openjdk/skara/bots/bridgekeeper/PullRequestPrunerBot.java due to ceace51a > + update bots/bridgekeeper/src/test/java/org/openjdk/skara/bots/bridgekeeper/PullRequestPrunerBotTests.java due to ceace51a > + update bots/cli/src/test/java/org/openjdk/skara/bots/cli/BotSlackHandlerTests.java due to ceace51a > + update bots/mlbridge/src/main/java/org/openjdk/skara/bots/mlbridge/ArchiveItem.java due to ceace51a > + update bots/notify/src/main/java/org/openjdk/skara/bots/notify/mailinglist/MailingListNotifier.java due to ceace51a > + update bots/notify/src/test/java/org/openjdk/skara/bots/notify/issue/IssueNotifierTests.java due to ceace51a > + update bots/notify/src/test/java/org/openjdk/skara/bots/notify/prbranch/PullRequestBranchNotifierTests.java due to ceace51a > + update bots/pr/src/main/java/org/openjdk/skara/bots/pr/ReviewersTracker.java due to ceace51a > + update bots/pr/src/test/java/org/openjdk/skara/bots/pr/CSRBotTests.java due to ceace51a > + update bots/pr/src/test/java/org/openjdk/skara/bots/pr/CommitCommandAsserts.java due to ceace51a > + update bots/pr/src/test/java/org/openjdk/skara/bots/pr/IntegrateTests.java due to ceace51a > + update bots/pr/src/test/java/org/openjdk/skara/bots/pr/SponsorTests.java due to ceace51a > + update forge/src/main/java/org/openjdk/skara/forge/PullRequest.java due to ceace51a > + update test/src/main/java/org/openjdk/skara/test/HostCredentials.java due to ceace51a > + update vcs/src/test/java/org/openjdk/skara/vcs/openjdk/converter/GitToHgConverterTests.java due to ceace51a > + update webrev/src/main/java/org/openjdk/skara/webrev/HunkCoalescer.java due to ceace51a Nice! ------------- Marked as reviewed by erikj (Lead). PR Review: https://git.openjdk.org/skara/pull/1665#pullrequestreview-2150521079 From duke at openjdk.org Mon Jul 1 09:14:04 2024 From: duke at openjdk.org (duke) Date: Mon, 1 Jul 2024 09:14:04 GMT Subject: RFR: 2311: Use getLast and removeLast methods for lists [v3] In-Reply-To: References:

Message-ID: On Fri, 28 Jun 2024 23:05:30 GMT, Pavel Rappo wrote: >> Please review this simple refactoring to change most if not all occurrences of `list.get(x.size() - 1)` to `list.getLast()`. >> >> `getLast` was introduced in JDK 21, as part of JEP 431: Sequenced Collections, which also introduced a counterpart method, `getFirst()`. While there are also a lot of occurrences of `list.get(0)` in Skara codebase, changing them to `list.getFirst()` might be of insufficient benefit and, hence, is not proposed in this PR. I don't think that coinciding `get(0)` and `getLast()` would look inconsistent. >> >> The copyright years will be updated after this PR has been reviewed. > > Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright years > > Note: any commit hashes below might be outdated due to subsequent > history rewriting (e.g. git rebase). > > + update args/src/main/java/org/openjdk/skara/args/ArgumentParser.java due to ceace51a > + update bots/bridgekeeper/src/main/java/org/openjdk/skara/bots/bridgekeeper/PullRequestPrunerBot.java due to ceace51a > + update bots/bridgekeeper/src/test/java/org/openjdk/skara/bots/bridgekeeper/PullRequestPrunerBotTests.java due to ceace51a > + update bots/cli/src/test/java/org/openjdk/skara/bots/cli/BotSlackHandlerTests.java due to ceace51a > + update bots/mlbridge/src/main/java/org/openjdk/skara/bots/mlbridge/ArchiveItem.java due to ceace51a > + update bots/notify/src/main/java/org/openjdk/skara/bots/notify/mailinglist/MailingListNotifier.java due to ceace51a > + update bots/notify/src/test/java/org/openjdk/skara/bots/notify/issue/IssueNotifierTests.java due to ceace51a > + update bots/notify/src/test/java/org/openjdk/skara/bots/notify/prbranch/PullRequestBranchNotifierTests.java due to ceace51a > + update bots/pr/src/main/java/org/openjdk/skara/bots/pr/ReviewersTracker.java due to ceace51a > + update bots/pr/src/test/java/org/openjdk/skara/bots/pr/CSRBotTests.java due to ceace51a > + update bots/pr/src/test/java/org/openjdk/skara/bots/pr/CommitCommandAsserts.java due to ceace51a > + update bots/pr/src/test/java/org/openjdk/skara/bots/pr/IntegrateTests.java due to ceace51a > + update bots/pr/src/test/java/org/openjdk/skara/bots/pr/SponsorTests.java due to ceace51a > + update forge/src/main/java/org/openjdk/skara/forge/PullRequest.java due to ceace51a > + update test/src/main/java/org/openjdk/skara/test/HostCredentials.java due to ceace51a > + update vcs/src/test/java/org/openjdk/skara/vcs/openjdk/converter/GitToHgConverterTests.java due to ceace51a > + update webrev/src/main/java/org/openjdk/skara/webrev/HunkCoalescer.java due to ceace51a @pavelrappo Your change (at version 6e17f33c68babb9a4c27f962f269ce9d2511d89b) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/skara/pull/1665#issuecomment-2199635593 From prappo at openjdk.org Mon Jul 1 09:36:00 2024 From: prappo at openjdk.org (Pavel Rappo) Date: Mon, 1 Jul 2024 09:36:00 GMT Subject: Integrated: 2311: Use getLast and removeLast methods for lists In-Reply-To: References: Message-ID: On Fri, 28 Jun 2024 17:28:13 GMT, Pavel Rappo wrote: > Please review this simple refactoring to change most if not all occurrences of `list.get(x.size() - 1)` to `list.getLast()`. > > `getLast` was introduced in JDK 21, as part of JEP 431: Sequenced Collections, which also introduced a counterpart method, `getFirst()`. While there are also a lot of occurrences of `list.get(0)` in Skara codebase, changing them to `list.getFirst()` might be of insufficient benefit and, hence, is not proposed in this PR. I don't think that coinciding `get(0)` and `getLast()` would look inconsistent. > > The copyright years will be updated after this PR has been reviewed. This pull request has now been integrated. Changeset: a510583d Author: Pavel Rappo Committer: Erik Joelsson URL: https://git.openjdk.org/skara/commit/a510583db9715e8091891b6cd0bbfa13380cf17a Stats: 68 lines in 22 files changed: 0 ins; 0 del; 68 mod 2311: Use getLast and removeLast methods for lists Reviewed-by: zsong, erikj ------------- PR: https://git.openjdk.org/skara/pull/1665 From yzheng at openjdk.org Tue Jul 2 10:15:05 2024 From: yzheng at openjdk.org (Yudi Zheng) Date: Tue, 2 Jul 2024 10:15:05 GMT Subject: RFR: 2313: Notify graal mailing list for intrinsic related PRs Message-ID: This allows Graal to act fast on intrinsic related changes. ------------- Commit messages: - 2313: Notify graal mailing list for intrinsic related PRs Changes: https://git.openjdk.org/skara/pull/1666/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1666&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-2313 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/skara/pull/1666.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1666/head:pull/1666 PR: https://git.openjdk.org/skara/pull/1666 From erikj at openjdk.org Tue Jul 2 13:32:50 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 2 Jul 2024 13:32:50 GMT Subject: RFR: 2313: Notify graal mailing list for intrinsic related PRs In-Reply-To: References: Message-ID: On Tue, 2 Jul 2024 10:11:47 GMT, Yudi Zheng wrote: > This allows Graal to act fast on intrinsic related changes. Marked as reviewed by erikj (Lead). ------------- PR Review: https://git.openjdk.org/skara/pull/1666#pullrequestreview-2153830259 From duke at openjdk.org Tue Jul 2 13:37:04 2024 From: duke at openjdk.org (duke) Date: Tue, 2 Jul 2024 13:37:04 GMT Subject: RFR: 2313: Notify graal mailing list for intrinsic related PRs In-Reply-To: References: Message-ID: On Tue, 2 Jul 2024 10:11:47 GMT, Yudi Zheng wrote: > This allows Graal to act fast on intrinsic related changes. @mur47x111 Your change (at version ddf8c38be63b2882d50834419393be24c2ecb4d7) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/skara/pull/1666#issuecomment-2203183292 From yzheng at openjdk.org Tue Jul 2 13:37:04 2024 From: yzheng at openjdk.org (Yudi Zheng) Date: Tue, 2 Jul 2024 13:37:04 GMT Subject: RFR: 2313: Notify graal mailing list for intrinsic related PRs In-Reply-To: References: Message-ID: On Tue, 2 Jul 2024 10:11:47 GMT, Yudi Zheng wrote: > This allows Graal to act fast on intrinsic related changes. Thanks for the review! ------------- PR Comment: https://git.openjdk.org/skara/pull/1666#issuecomment-2203182757 From yzheng at openjdk.org Tue Jul 2 13:41:34 2024 From: yzheng at openjdk.org (Yudi Zheng) Date: Tue, 2 Jul 2024 13:41:34 GMT Subject: Integrated: 2313: Notify graal mailing list for intrinsic related PRs In-Reply-To: References: Message-ID: On Tue, 2 Jul 2024 10:11:47 GMT, Yudi Zheng wrote: > This allows Graal to act fast on intrinsic related changes. This pull request has now been integrated. Changeset: 9817010c Author: Yudi Zheng Committer: Erik Joelsson URL: https://git.openjdk.org/skara/commit/9817010c4fe57fd5e54b30653df6c43b9b481b2b Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 2313: Notify graal mailing list for intrinsic related PRs Reviewed-by: erikj ------------- PR: https://git.openjdk.org/skara/pull/1666 From zsong at openjdk.org Tue Jul 2 20:27:31 2024 From: zsong at openjdk.org (Zhao Song) Date: Tue, 2 Jul 2024 20:27:31 GMT Subject: RFR: 2304: /backport jdk23 should provide a more helpful message Message-ID: This patch is trying to improve the bot's replies of backport command. 1. If the user issued `/backport jdkX`, the bot would check if there is a `jdkX` branch in current repo, if so, the bot would tell the user that to target a backport to `jdkX` branch in current repo, he should issue `/backport :jdkX`. 2. When user specified branch name in the command but the branch doesn't exist, the bot will list 10 branch names in the target repo, the branch names are just sorted in reverse alphabetical order, so we can't guarantee they are the most relevant ones. ------------- Commit messages: - Fix tests - SKARA-2304 Changes: https://git.openjdk.org/skara/pull/1667/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1667&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-2304 Stats: 46 lines in 2 files changed: 42 ins; 0 del; 4 mod Patch: https://git.openjdk.org/skara/pull/1667.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1667/head:pull/1667 PR: https://git.openjdk.org/skara/pull/1667 From erikj at openjdk.org Wed Jul 3 06:57:12 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 3 Jul 2024 06:57:12 GMT Subject: RFR: 2304: /backport jdk23 should provide a more helpful message In-Reply-To: References: Message-ID: On Tue, 2 Jul 2024 18:15:21 GMT, Zhao Song wrote: > This patch is trying to improve the bot's replies of backport command. > > 1. If the user issued `/backport jdkX`, the bot would check if there is a `jdkX` branch in current repo, if so, the bot would tell the user that to target a backport to `jdkX` branch in current repo, he should issue `/backport :jdkX`. > > 2. When user specified branch name in the command but the branch doesn't exist, the bot will list 10 branch names in the target repo, the branch names are just sorted in reverse alphabetical order, so we can't guarantee they are the most relevant ones. bots/pr/src/main/java/org/openjdk/skara/bots/pr/BackportCommand.java line 205: > 203: reply.println("There is a branch `" + repoName + "` in current repository `" + bot.repo().name() + "`."); > 204: reply.println("To target a backport to this branch in current repository:"); > 205: reply.println("`/backport :" + repoName + "`"); Suggestion: reply.println("There is a branch `" + repoName + "` in the current repository `" + bot.repo().name() + "`."); reply.println("To target a backport to this branch in the current repository use:"); reply.println("`/backport :" + repoName + "`"); bots/pr/src/main/java/org/openjdk/skara/bots/pr/BackportCommand.java line 208: > 206: reply.println(); > 207: } > 208: reply.println("The target repository `" + repoNameArg + "` is not a valid target for backports. "); I think this line should be first in the message, then followed by the branch message if there is a branch match. bots/pr/src/main/java/org/openjdk/skara/bots/pr/BackportCommand.java line 225: > 223: if (targetBranchHash.isEmpty()) { > 224: reply.println("The target branch `" + targetBranchName + "` does not exist"); > 225: reply.print("List of target branches: "); Suggestion: reply.print("List of valid branches: "); ------------- PR Review Comment: https://git.openjdk.org/skara/pull/1667#discussion_r1663609011 PR Review Comment: https://git.openjdk.org/skara/pull/1667#discussion_r1663607601 PR Review Comment: https://git.openjdk.org/skara/pull/1667#discussion_r1663614230 From zsong at openjdk.org Wed Jul 3 17:20:10 2024 From: zsong at openjdk.org (Zhao Song) Date: Wed, 3 Jul 2024 17:20:10 GMT Subject: RFR: 2304: /backport jdk23 should provide a more helpful message [v2] In-Reply-To: References: Message-ID: <31jEjBapkyoQ36rbRMvKn0WpQNAStNJx68ESdBu7AgI=.819ec6a9-aee8-4d5f-ad30-1a1ef2e7b2ad@github.com> > This patch is trying to improve the bot's replies of backport command. > > 1. If the user issued `/backport jdkX`, the bot would check if there is a `jdkX` branch in current repo, if so, the bot would tell the user that to target a backport to `jdkX` branch in current repo, he should issue `/backport :jdkX`. > > 2. When user specified branch name in the command but the branch doesn't exist, the bot will list 10 branch names in the target repo, the branch names are just sorted in reverse alphabetical order, so we can't guarantee they are the most relevant ones. Zhao Song has updated the pull request incrementally with two additional commits since the last revision: - Update bots/pr/src/main/java/org/openjdk/skara/bots/pr/BackportCommand.java Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com> - Update bots/pr/src/main/java/org/openjdk/skara/bots/pr/BackportCommand.java Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com> ------------- Changes: - all: https://git.openjdk.org/skara/pull/1667/files - new: https://git.openjdk.org/skara/pull/1667/files/66d367d7..3788e4c6 Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1667&range=01 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1667&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/skara/pull/1667.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1667/head:pull/1667 PR: https://git.openjdk.org/skara/pull/1667 From zsong at openjdk.org Wed Jul 3 17:20:10 2024 From: zsong at openjdk.org (Zhao Song) Date: Wed, 3 Jul 2024 17:20:10 GMT Subject: RFR: 2304: /backport jdk23 should provide a more helpful message [v2] In-Reply-To: References:

Message-ID: On Wed, 3 Jul 2024 06:50:20 GMT, Erik Joelsson wrote: >> Zhao Song has updated the pull request incrementally with two additional commits since the last revision: >> >> - Update bots/pr/src/main/java/org/openjdk/skara/bots/pr/BackportCommand.java >> >> Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com> >> - Update bots/pr/src/main/java/org/openjdk/skara/bots/pr/BackportCommand.java >> >> Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com> > > bots/pr/src/main/java/org/openjdk/skara/bots/pr/BackportCommand.java line 208: > >> 206: reply.println(); >> 207: } >> 208: reply.println("The target repository `" + repoNameArg + "` is not a valid target for backports. "); > > I think this line should be first in the message, then followed by the branch message if there is a branch match. Sure, will fix it ------------- PR Review Comment: https://git.openjdk.org/skara/pull/1667#discussion_r1664520914 From zsong at openjdk.org Wed Jul 3 17:28:07 2024 From: zsong at openjdk.org (Zhao Song) Date: Wed, 3 Jul 2024 17:28:07 GMT Subject: RFR: 2304: /backport jdk23 should provide a more helpful message [v3] In-Reply-To: References: Message-ID: > This patch is trying to improve the bot's replies of backport command. > > 1. If the user issued `/backport jdkX`, the bot would check if there is a `jdkX` branch in current repo, if so, the bot would tell the user that to target a backport to `jdkX` branch in current repo, he should issue `/backport :jdkX`. > > 2. When user specified branch name in the command but the branch doesn't exist, the bot will list 10 branch names in the target repo, the branch names are just sorted in reverse alphabetical order, so we can't guarantee they are the most relevant ones. Zhao Song has updated the pull request incrementally with one additional commit since the last revision: review comment ------------- Changes: - all: https://git.openjdk.org/skara/pull/1667/files - new: https://git.openjdk.org/skara/pull/1667/files/3788e4c6..d2733005 Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1667&range=02 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1667&range=01-02 Stats: 17 lines in 2 files changed: 7 ins; 8 del; 2 mod Patch: https://git.openjdk.org/skara/pull/1667.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1667/head:pull/1667 PR: https://git.openjdk.org/skara/pull/1667 From erikj at openjdk.org Wed Jul 3 17:35:11 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 3 Jul 2024 17:35:11 GMT Subject: RFR: 2304: /backport jdk23 should provide a more helpful message [v3] In-Reply-To: References:

Message-ID: On Wed, 3 Jul 2024 17:28:07 GMT, Zhao Song wrote: >> This patch is trying to improve the bot's replies of backport command. >> >> 1. If the user issued `/backport jdkX`, the bot would check if there is a `jdkX` branch in current repo, if so, the bot would tell the user that to target a backport to `jdkX` branch in current repo, he should issue `/backport :jdkX`. >> >> 2. When user specified branch name in the command but the branch doesn't exist, the bot will list 10 branch names in the target repo, the branch names are just sorted in reverse alphabetical order, so we can't guarantee they are the most relevant ones. > > Zhao Song has updated the pull request incrementally with one additional commit since the last revision: > > review comment Thanks for the review! ------------- PR Comment: https://git.openjdk.org/skara/pull/1667#issuecomment-2206933919 From zsong at openjdk.org Wed Jul 3 18:17:43 2024 From: zsong at openjdk.org (Zhao Song) Date: Wed, 3 Jul 2024 18:17:43 GMT Subject: Integrated: 2304: /backport jdk23 should provide a more helpful message In-Reply-To: References: Message-ID: <2ocm1v17TM3sI6P58n6ixym-6wFLRA1BYHKMvU609CI=.10f3259e-aa63-4a05-9cf6-ef2747b86e12@github.com> On Tue, 2 Jul 2024 18:15:21 GMT, Zhao Song wrote: > This patch is trying to improve the bot's replies of backport command. > > 1. If the user issued `/backport jdkX`, the bot would check if there is a `jdkX` branch in current repo, if so, the bot would tell the user that to target a backport to `jdkX` branch in current repo, he should issue `/backport :jdkX`. > > 2. When user specified branch name in the command but the branch doesn't exist, the bot will list 10 branch names in the target repo, the branch names are just sorted in reverse alphabetical order, so we can't guarantee they are the most relevant ones. This pull request has now been integrated. Changeset: 273c362a Author: Zhao Song URL: https://git.openjdk.org/skara/commit/273c362ab262134584830fc99adfd23f6f7ee0f7 Stats: 45 lines in 2 files changed: 41 ins; 0 del; 4 mod 2304: /backport jdk23 should provide a more helpful message Reviewed-by: erikj ------------- PR: https://git.openjdk.org/skara/pull/1667 From prappo at openjdk.org Fri Jul 5 09:35:52 2024 From: prappo at openjdk.org (Pavel Rappo) Date: Fri, 5 Jul 2024 09:35:52 GMT Subject: RFR: 2316: Prefer not to specify UTF-8 if it's used by default Message-ID: Please review this clean-up. It's about not specifying UTF-8 encoding when it's the default, such as in `Files.{readString, writeString}`. The change is very uniform, except for two cases, where specifying the encoding was avoided by slightly more involved refactoring: * `JsonWriter:44` * `XML:42` ------------- Commit messages: - Initial commit Changes: https://git.openjdk.org/skara/pull/1668/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1668&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-2316 Stats: 194 lines in 31 files changed: 0 ins; 36 del; 158 mod Patch: https://git.openjdk.org/skara/pull/1668.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1668/head:pull/1668 PR: https://git.openjdk.org/skara/pull/1668 From prappo at openjdk.org Fri Jul 5 10:11:18 2024 From: prappo at openjdk.org (Pavel Rappo) Date: Fri, 5 Jul 2024 10:11:18 GMT Subject: RFR: 2317: Avoid use of deprecated Thread.getId() Message-ID: `Thread.getId()` was deprecated in JDK 19, as part of [JDK-8284161]. Skara build now produces warnings because of that method: Task :bot:compileTestJava Note: skara/bot/src/test/java/org/openjdk/skara/bot/BotTaskAggregationHandlerTests.java uses or overrides a deprecated API. [JDK-8284161]: https://bugs.openjdk.org/browse/JDK-8284161 ------------- Commit messages: - Initial commit Changes: https://git.openjdk.org/skara/pull/1669/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1669&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-2317 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/skara/pull/1669.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1669/head:pull/1669 PR: https://git.openjdk.org/skara/pull/1669 From prappo at openjdk.org Fri Jul 5 10:32:12 2024 From: prappo at openjdk.org (Pavel Rappo) Date: Fri, 5 Jul 2024 10:32:12 GMT Subject: RFR: 2318: Prefer Thread.sleep(Duration) Message-ID: `Thread.sleep(java.time.Duration)` was introduced in JDK 19, as part of [JDK-8284161], and standardised in JDK 21, as part of [JDK-8304919]. [JDK-8284161]: https://bugs.openjdk.org/browse/JDK-8284161 [JDK-8304919]: https://bugs.openjdk.org/browse/JDK-8304919 ------------- Commit messages: - Initial commit Changes: https://git.openjdk.org/skara/pull/1670/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1670&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-2318 Stats: 22 lines in 11 files changed: 0 ins; 2 del; 20 mod Patch: https://git.openjdk.org/skara/pull/1670.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1670/head:pull/1670 PR: https://git.openjdk.org/skara/pull/1670 From prappo at openjdk.org Fri Jul 5 10:37:30 2024 From: prappo at openjdk.org (Pavel Rappo) Date: Fri, 5 Jul 2024 10:37:30 GMT Subject: RFR: 2317: Avoid use of deprecated Thread.getId() In-Reply-To: References: Message-ID: On Fri, 5 Jul 2024 10:07:11 GMT, Pavel Rappo wrote: > `Thread.getId()` was deprecated in JDK 19, as part of [JDK-8284161]. Skara build now produces warnings because of that method: > > Task :bot:compileTestJava > Note: skara/bot/src/test/java/org/openjdk/skara/bot/BotTaskAggregationHandlerTests.java uses or overrides a deprecated API. > > [JDK-8284161]: https://bugs.openjdk.org/browse/JDK-8284161 I should've made it clear that while `Thread.getId()` was deprecated in JDK 19, as part of [JDK-8284161] as preview, the deprecation was standardised in JDK 21, as part of [JDK-8304919]. [JDK-8284161]: https://bugs.openjdk.org/browse/JDK-8284161 [JDK-8304919]: https://bugs.openjdk.org/browse/JDK-8304919 ------------- PR Comment: https://git.openjdk.org/skara/pull/1669#issuecomment-2210637032 From erikj at openjdk.org Fri Jul 5 12:07:51 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 5 Jul 2024 12:07:51 GMT Subject: RFR: 2316: Prefer not to specify UTF-8 if it's used by default In-Reply-To: References: Message-ID: On Fri, 5 Jul 2024 09:31:39 GMT, Pavel Rappo wrote: > Please review this clean-up. It's about not specifying UTF-8 encoding when it's the default, such as in `Files.{readString, writeString}`. > > The change is very uniform, except for two cases, where specifying the encoding was avoided by slightly more involved refactoring: > > * `JsonWriter:44` > * `XML:42` Looks good now that I understand the proposed change. Avoiding being explicit with UTF8 when it's actually the default is good. Then we only need to be explicit when using older APIs where the platform default is the default encoding. ------------- Marked as reviewed by erikj (Lead). PR Review: https://git.openjdk.org/skara/pull/1668#pullrequestreview-2160588567 From erikj at openjdk.org Fri Jul 5 12:09:22 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 5 Jul 2024 12:09:22 GMT Subject: RFR: 2318: Prefer Thread.sleep(Duration) In-Reply-To: References: Message-ID: On Fri, 5 Jul 2024 10:29:32 GMT, Pavel Rappo wrote: > `Thread.sleep(java.time.Duration)` was introduced in JDK 19, as part of [JDK-8284161], and standardised in JDK 21, as part of [JDK-8304919]. > > [JDK-8284161]: https://bugs.openjdk.org/browse/JDK-8284161 > [JDK-8304919]: https://bugs.openjdk.org/browse/JDK-8304919 Nice ------------- Marked as reviewed by erikj (Lead). PR Review: https://git.openjdk.org/skara/pull/1670#pullrequestreview-2160591228 From erikj at openjdk.org Fri Jul 5 12:10:23 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 5 Jul 2024 12:10:23 GMT Subject: RFR: 2317: Avoid use of deprecated Thread.getId() In-Reply-To: References: Message-ID: On Fri, 5 Jul 2024 10:07:11 GMT, Pavel Rappo wrote: > `Thread.getId()` was deprecated in JDK 19, as part of [JDK-8284161]. Skara build now produces warnings because of that method: > > Task :bot:compileTestJava > Note: skara/bot/src/test/java/org/openjdk/skara/bot/BotTaskAggregationHandlerTests.java uses or overrides a deprecated API. > > [JDK-8284161]: https://bugs.openjdk.org/browse/JDK-8284161 Marked as reviewed by erikj (Lead). ------------- PR Review: https://git.openjdk.org/skara/pull/1669#pullrequestreview-2160592725 From zsong at openjdk.org Fri Jul 5 15:52:26 2024 From: zsong at openjdk.org (Zhao Song) Date: Fri, 5 Jul 2024 15:52:26 GMT Subject: RFR: 2318: Prefer Thread.sleep(Duration) In-Reply-To: References: Message-ID: <3a7zENjCjFnu1Gl07bAL7M_ACEvbHT8weH7N8wVwlx4=.8ea1b75c-1fe6-4e24-9c3d-a48a8c93f630@github.com> On Fri, 5 Jul 2024 10:29:32 GMT, Pavel Rappo wrote: > `Thread.sleep(java.time.Duration)` was introduced in JDK 19, as part of [JDK-8284161], and standardised in JDK 21, as part of [JDK-8304919]. > > [JDK-8284161]: https://bugs.openjdk.org/browse/JDK-8284161 > [JDK-8304919]: https://bugs.openjdk.org/browse/JDK-8304919 Looks good! ------------- Marked as reviewed by zsong (Reviewer). PR Review: https://git.openjdk.org/skara/pull/1670#pullrequestreview-2160962497 From zsong at openjdk.org Fri Jul 5 15:53:21 2024 From: zsong at openjdk.org (Zhao Song) Date: Fri, 5 Jul 2024 15:53:21 GMT Subject: RFR: 2317: Avoid use of deprecated Thread.getId() In-Reply-To: References: Message-ID: On Fri, 5 Jul 2024 10:07:11 GMT, Pavel Rappo wrote: > `Thread.getId()` was deprecated in JDK 19, as part of [JDK-8284161]. Skara build now produces warnings because of that method: > > Task :bot:compileTestJava > Note: skara/bot/src/test/java/org/openjdk/skara/bot/BotTaskAggregationHandlerTests.java uses or overrides a deprecated API. > > [JDK-8284161]: https://bugs.openjdk.org/browse/JDK-8284161 Marked as reviewed by zsong (Reviewer). ------------- PR Review: https://git.openjdk.org/skara/pull/1669#pullrequestreview-2160963499 From zsong at openjdk.org Fri Jul 5 16:02:06 2024 From: zsong at openjdk.org (Zhao Song) Date: Fri, 5 Jul 2024 16:02:06 GMT Subject: RFR: 2316: Prefer not to specify UTF-8 if it's used by default In-Reply-To: References: Message-ID: On Fri, 5 Jul 2024 09:31:39 GMT, Pavel Rappo wrote: > Please review this clean-up. It's about not specifying UTF-8 encoding when it's the default, such as in `Files.{readString, writeString}`. > > The change is very uniform, except for two cases, where specifying the encoding was avoided by slightly more involved refactoring: > > * `JsonWriter:44` > * `XML:42` Good to know UTF-8 encoding is default in most cases! ------------- Marked as reviewed by zsong (Reviewer). PR Review: https://git.openjdk.org/skara/pull/1668#pullrequestreview-2160974194 From duke at openjdk.org Fri Jul 5 18:47:24 2024 From: duke at openjdk.org (duke) Date: Fri, 5 Jul 2024 18:47:24 GMT Subject: RFR: 2318: Prefer Thread.sleep(Duration) In-Reply-To: References: Message-ID: On Fri, 5 Jul 2024 10:29:32 GMT, Pavel Rappo wrote: > `Thread.sleep(java.time.Duration)` was introduced in JDK 19, as part of [JDK-8284161], and standardised in JDK 21, as part of [JDK-8304919]. > > [JDK-8284161]: https://bugs.openjdk.org/browse/JDK-8284161 > [JDK-8304919]: https://bugs.openjdk.org/browse/JDK-8304919 @pavelrappo Your change (at version 31abafce18963016b70b872ff7e7d075619b4739) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/skara/pull/1670#issuecomment-2211281125 From duke at openjdk.org Fri Jul 5 18:47:50 2024 From: duke at openjdk.org (duke) Date: Fri, 5 Jul 2024 18:47:50 GMT Subject: RFR: 2317: Avoid use of deprecated Thread.getId() In-Reply-To: References: Message-ID: On Fri, 5 Jul 2024 10:07:11 GMT, Pavel Rappo wrote: > `Thread.getId()` was deprecated in JDK 19, as part of [JDK-8284161]. Skara build now produces warnings because of that method: > > Task :bot:compileTestJava > Note: skara/bot/src/test/java/org/openjdk/skara/bot/BotTaskAggregationHandlerTests.java uses or overrides a deprecated API. > > [JDK-8284161]: https://bugs.openjdk.org/browse/JDK-8284161 @pavelrappo Your change (at version e9dbda1106ee4835aa8eec771c9a9178c8877afb) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/skara/pull/1669#issuecomment-2211281466 From duke at openjdk.org Fri Jul 5 18:48:05 2024 From: duke at openjdk.org (duke) Date: Fri, 5 Jul 2024 18:48:05 GMT Subject: RFR: 2316: Prefer not to specify UTF-8 if it's used by default In-Reply-To: References: Message-ID: <8HNgPwu1tdW0Hu86De4Evsx6Z2muHG6QpqlEpHKNBTM=.d2b29625-1cdd-4d20-ab01-65305eb85b36@github.com> On Fri, 5 Jul 2024 09:31:39 GMT, Pavel Rappo wrote: > Please review this clean-up. It's about not specifying UTF-8 encoding when it's the default, such as in `Files.{readString, writeString}`. > > The change is very uniform, except for two cases, where specifying the encoding was avoided by slightly more involved refactoring: > > * `JsonWriter:44` > * `XML:42` @pavelrappo Your change (at version 2a137497170f7113a84b9f31e54d3427ccab14aa) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/skara/pull/1668#issuecomment-2211281800 From prappo at openjdk.org Fri Jul 5 19:21:36 2024 From: prappo at openjdk.org (Pavel Rappo) Date: Fri, 5 Jul 2024 19:21:36 GMT Subject: Integrated: 2318: Prefer Thread.sleep(Duration) In-Reply-To: References: Message-ID: On Fri, 5 Jul 2024 10:29:32 GMT, Pavel Rappo wrote: > `Thread.sleep(java.time.Duration)` was introduced in JDK 19, as part of [JDK-8284161], and standardised in JDK 21, as part of [JDK-8304919]. > > [JDK-8284161]: https://bugs.openjdk.org/browse/JDK-8284161 > [JDK-8304919]: https://bugs.openjdk.org/browse/JDK-8304919 This pull request has now been integrated. Changeset: b99b663a Author: Pavel Rappo Committer: Zhao Song URL: https://git.openjdk.org/skara/commit/b99b663a7a0a7e2f53ea14ec085789d53dce1a32 Stats: 22 lines in 11 files changed: 0 ins; 2 del; 20 mod 2318: Prefer Thread.sleep(Duration) Reviewed-by: erikj, zsong ------------- PR: https://git.openjdk.org/skara/pull/1670 From prappo at openjdk.org Fri Jul 5 19:21:36 2024 From: prappo at openjdk.org (Pavel Rappo) Date: Fri, 5 Jul 2024 19:21:36 GMT Subject: Integrated: 2317: Avoid use of deprecated Thread.getId() In-Reply-To: References: Message-ID: On Fri, 5 Jul 2024 10:07:11 GMT, Pavel Rappo wrote: > `Thread.getId()` was deprecated in JDK 19, as part of [JDK-8284161]. Skara build now produces warnings because of that method: > > Task :bot:compileTestJava > Note: skara/bot/src/test/java/org/openjdk/skara/bot/BotTaskAggregationHandlerTests.java uses or overrides a deprecated API. > > [JDK-8284161]: https://bugs.openjdk.org/browse/JDK-8284161 This pull request has now been integrated. Changeset: d1ad1865 Author: Pavel Rappo Committer: Zhao Song URL: https://git.openjdk.org/skara/commit/d1ad1865a4ba04b3b629592a80fd5a186aa8b6e9 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod 2317: Avoid use of deprecated Thread.getId() Reviewed-by: erikj, zsong ------------- PR: https://git.openjdk.org/skara/pull/1669 From prappo at openjdk.org Fri Jul 5 19:21:55 2024 From: prappo at openjdk.org (Pavel Rappo) Date: Fri, 5 Jul 2024 19:21:55 GMT Subject: Integrated: 2316: Prefer not to specify UTF-8 if it's used by default In-Reply-To: References: Message-ID: On Fri, 5 Jul 2024 09:31:39 GMT, Pavel Rappo wrote: > Please review this clean-up. It's about not specifying UTF-8 encoding when it's the default, such as in `Files.{readString, writeString}`. > > The change is very uniform, except for two cases, where specifying the encoding was avoided by slightly more involved refactoring: > > * `JsonWriter:44` > * `XML:42` This pull request has now been integrated. Changeset: bafcd5e1 Author: Pavel Rappo Committer: Zhao Song URL: https://git.openjdk.org/skara/commit/bafcd5e134fd0b827f8fa474fc4d17555a75028d Stats: 194 lines in 31 files changed: 0 ins; 36 del; 158 mod 2316: Prefer not to specify UTF-8 if it's used by default Reviewed-by: erikj, zsong ------------- PR: https://git.openjdk.org/skara/pull/1668 From zsong at openjdk.org Fri Jul 5 22:38:56 2024 From: zsong at openjdk.org (Zhao Song) Date: Fri, 5 Jul 2024 22:38:56 GMT Subject: RFR: 2292: Improve the labels of Review/Commit links for backport branches In-Reply-To: References: Message-ID: On Fri, 5 Jul 2024 22:23:48 GMT, Zhao Song wrote: > The patch is trying to add a branch name to the commit link, review link, commit comment, review comment in JBS. > > Adding a branch name for commit link and comment is feasible and easy, but adding a branch name for review link and review comment is not that easy because people can retarget pull request. Therefore, the bot needs to save the target branch name in the storage. > > I believe my patch will be compatible with the existing storage files. bots/notify/src/main/java/org/openjdk/skara/bots/notify/PullRequestWorkItem.java line 140: > 138: if (pr.targetBranch() != null) { > 139: ret.put("targetBranch", JSON.of(pr.targetBranch())); > 140: } We have two options for handling non-replaced entries: 1: Do not add a null JSON for targetBranch 2: Add a null JSON for targetBranch Currently, I chose option 1 ------------- PR Review Comment: https://git.openjdk.org/skara/pull/1671#discussion_r1667191910 From zsong at openjdk.org Fri Jul 5 22:38:56 2024 From: zsong at openjdk.org (Zhao Song) Date: Fri, 5 Jul 2024 22:38:56 GMT Subject: RFR: 2292: Improve the labels of Review/Commit links for backport branches Message-ID: The patch is trying to add a branch name to the commit link, review link, commit comment, review comment in JBS. Adding a branch name for commit link and comment is feasible and easy, but adding a branch name for review link and review comment is not that easy because people can retarget pull request. Therefore, the bot needs to save the target branch name in the storage. I believe my patch will be compatible with the existing storage files. ------------- Commit messages: - copyright - SKARA-2292 Changes: https://git.openjdk.org/skara/pull/1671/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1671&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-2292 Stats: 186 lines in 8 files changed: 143 ins; 10 del; 33 mod Patch: https://git.openjdk.org/skara/pull/1671.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1671/head:pull/1671 PR: https://git.openjdk.org/skara/pull/1671 From erikj at openjdk.org Mon Jul 8 09:19:24 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 8 Jul 2024 09:19:24 GMT Subject: RFR: 2292: Improve the labels of Review/Commit links for backport branches In-Reply-To: References: Message-ID: On Fri, 5 Jul 2024 22:23:48 GMT, Zhao Song wrote: > The patch is trying to add a branch name to the commit link, review link, commit comment, review comment in JBS. > > Adding a branch name for commit link and comment is feasible and easy, but adding a branch name for review link and review comment is not that easy because people can retarget pull request. Therefore, the bot needs to save the target branch name in the storage. > > I believe my patch will be compatible with the existing storage files. Looks good! ------------- Marked as reviewed by erikj (Lead). PR Review: https://git.openjdk.org/skara/pull/1671#pullrequestreview-2162750644 From erikj at openjdk.org Mon Jul 8 09:43:32 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 8 Jul 2024 09:43:32 GMT Subject: RFR: 2292: Improve the labels of Review/Commit links for backport branches In-Reply-To: References: Message-ID: On Fri, 5 Jul 2024 22:23:48 GMT, Zhao Song wrote: > The patch is trying to add a branch name to the commit link, review link, commit comment, review comment in JBS. > > Adding a branch name for commit link and comment is feasible and easy, but adding a branch name for review link and review comment is not that easy because people can retarget pull request. Therefore, the bot needs to save the target branch name in the storage. > > I believe my patch will be compatible with the existing storage files. bots/notify/src/main/java/org/openjdk/skara/bots/notify/PullRequestWorkItem.java line 290: > 288: } > 289: var storedTargetBranch = storedState.get().targetBranch(); > 290: if (storedTargetBranch == null || !storedTargetBranch.equals(state.targetBranch())) { I think we need to flip this check. If `storedTargetBranch` is null and we for some reason get a null from `state.targetBranch()`, then this will keep notifying even though there is no change. If we instead flip it to state.targetBranch() != null && !state.targetBranch().equals(storedTargetBranch) then we will only notify if the updated branch is not null. It may never be needed, but it's a bit more defensive against unexpected data being returned from the forge. ------------- PR Review Comment: https://git.openjdk.org/skara/pull/1671#discussion_r1668321842 From prappo at openjdk.org Mon Jul 8 14:58:41 2024 From: prappo at openjdk.org (Pavel Rappo) Date: Mon, 8 Jul 2024 14:58:41 GMT Subject: RFR: 2312: Do not require re-review for a simple merge Message-ID: If a repository is configured to ignore stale reviews, every commit to a PR made against that repo means that the PR needs to be re-reviewed. Re-reviewing is costly, and not all commits are worth that cost. One example of such a commit is a simple merge. During a PR's lifetime, the PR's target branch (typically, repo's `master`) might be merged into the PR multiple times. Usually, such merges are trivial and would effectively be performed by Skara automatically if the PR didn't have them in the first place [^*]. For such commits, it makes sense to not require review. This is my first contribution to Skara domain logic, which I've just started learning about. Also, while I tried to code this change according to Skara customs and idioms, I might have missed something. I guess what I'm saying is **take extra care** reviewing this PR. Thanks. [^*]: This is the main assumption of this PR. Any simple merges present in a PR change the end result of that PR insignificantly, if at all. ------------- Commit messages: - Initial commit Changes: https://git.openjdk.org/skara/pull/1672/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1672&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-2312 Stats: 436 lines in 11 files changed: 413 ins; 7 del; 16 mod Patch: https://git.openjdk.org/skara/pull/1672.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1672/head:pull/1672 PR: https://git.openjdk.org/skara/pull/1672 From prappo at openjdk.org Mon Jul 8 17:08:04 2024 From: prappo at openjdk.org (Pavel Rappo) Date: Mon, 8 Jul 2024 17:08:04 GMT Subject: RFR: 2321: Prefer pattern matching for instanceof Message-ID: Pattern matching for `instanceof` was introduced in JDK 16, by JEP 394. It's already been used by new code in Skara, but the older code can benefit from it too. ------------- Commit messages: - Initial commit Changes: https://git.openjdk.org/skara/pull/1673/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1673&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-2321 Stats: 156 lines in 52 files changed: 0 ins; 50 del; 106 mod Patch: https://git.openjdk.org/skara/pull/1673.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1673/head:pull/1673 PR: https://git.openjdk.org/skara/pull/1673 From zsong at openjdk.org Mon Jul 8 17:25:06 2024 From: zsong at openjdk.org (Zhao Song) Date: Mon, 8 Jul 2024 17:25:06 GMT Subject: RFR: 2292: Improve the labels of Review/Commit links for backport branches [v2] In-Reply-To: References: Message-ID: > The patch is trying to add a branch name to the commit link, review link, commit comment, review comment in JBS. > > Adding a branch name for commit link and comment is feasible and easy, but adding a branch name for review link and review comment is not that easy because people can retarget pull request. Therefore, the bot needs to save the target branch name in the storage. > > I believe my patch will be compatible with the existing storage files. Zhao Song has updated the pull request incrementally with one additional commit since the last revision: review comment ------------- Changes: - all: https://git.openjdk.org/skara/pull/1671/files - new: https://git.openjdk.org/skara/pull/1671/files/7a17d262..7fb136e3 Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1671&range=01 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1671&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/skara/pull/1671.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1671/head:pull/1671 PR: https://git.openjdk.org/skara/pull/1671 From zsong at openjdk.org Mon Jul 8 17:25:06 2024 From: zsong at openjdk.org (Zhao Song) Date: Mon, 8 Jul 2024 17:25:06 GMT Subject: RFR: 2292: Improve the labels of Review/Commit links for backport branches [v2] In-Reply-To: References:

Message-ID: <1q5MdDOLMuNPnLJEGOGPUE7nRyOFA23rDrrKIdrjd3I=.e9f57f3e-7679-40e7-b40c-67bc716588f8@github.com> On Mon, 8 Jul 2024 09:40:38 GMT, Erik Joelsson wrote: >> Zhao Song has updated the pull request incrementally with one additional commit since the last revision: >> >> review comment > > bots/notify/src/main/java/org/openjdk/skara/bots/notify/PullRequestWorkItem.java line 290: > >> 288: } >> 289: var storedTargetBranch = storedState.get().targetBranch(); >> 290: if (storedTargetBranch == null || !storedTargetBranch.equals(state.targetBranch())) { > > I think we need to flip this check. If `storedTargetBranch` is null and we for some reason get a null from `state.targetBranch()`, then this will keep notifying even though there is no change. If we instead flip it to > > state.targetBranch() != null && !state.targetBranch().equals(storedTargetBranch) > > then we will only notify if the updated branch is not null. It may never be needed, but it's a bit more defensive against unexpected data being returned from the forge. Yes, it's a good point. Thanks! ------------- PR Review Comment: https://git.openjdk.org/skara/pull/1671#discussion_r1669012822 From zsong at openjdk.org Mon Jul 8 20:02:50 2024 From: zsong at openjdk.org (Zhao Song) Date: Mon, 8 Jul 2024 20:02:50 GMT Subject: RFR: 2292: Improve the labels of Review/Commit links for backport branches [v2] In-Reply-To: References:

Message-ID: On Mon, 8 Jul 2024 17:25:06 GMT, Zhao Song wrote: >> The patch is trying to add a branch name to the commit link, review link, commit comment, review comment in JBS. >> >> Adding a branch name for commit link and comment is feasible and easy, but adding a branch name for review link and review comment is not that easy because people can retarget pull request. Therefore, the bot needs to save the target branch name in the storage. >> >> I believe my patch will be compatible with the existing storage files. > > Zhao Song has updated the pull request incrementally with one additional commit since the last revision: > > review comment Thanks for the review! ------------- PR Comment: https://git.openjdk.org/skara/pull/1671#issuecomment-2215108253 From zsong at openjdk.org Mon Jul 8 20:02:50 2024 From: zsong at openjdk.org (Zhao Song) Date: Mon, 8 Jul 2024 20:02:50 GMT Subject: Integrated: 2292: Improve the labels of Review/Commit links for backport branches In-Reply-To: References: Message-ID: On Fri, 5 Jul 2024 22:23:48 GMT, Zhao Song wrote: > The patch is trying to add a branch name to the commit link, review link, commit comment, review comment in JBS. > > Adding a branch name for commit link and comment is feasible and easy, but adding a branch name for review link and review comment is not that easy because people can retarget pull request. Therefore, the bot needs to save the target branch name in the storage. > > I believe my patch will be compatible with the existing storage files. This pull request has now been integrated. Changeset: 9743137f Author: Zhao Song URL: https://git.openjdk.org/skara/commit/9743137f37e26a21f8e3c42c56c428bcafa5c894 Stats: 186 lines in 8 files changed: 143 ins; 10 del; 33 mod 2292: Improve the labels of Review/Commit links for backport branches 2309: Include branch name in IssueTracker notification comments Reviewed-by: erikj ------------- PR: https://git.openjdk.org/skara/pull/1671 From zsong at openjdk.org Mon Jul 8 21:13:58 2024 From: zsong at openjdk.org (Zhao Song) Date: Mon, 8 Jul 2024 21:13:58 GMT Subject: RFR: 2321: Prefer pattern matching for instanceof In-Reply-To: References: Message-ID: On Mon, 8 Jul 2024 17:04:03 GMT, Pavel Rappo wrote: > Pattern matching for `instanceof` was introduced in JDK 16, by JEP 394. It's already been used by new code in Skara, but the older code can benefit from it too. Looks good! ------------- Marked as reviewed by zsong (Reviewer). PR Review: https://git.openjdk.org/skara/pull/1673#pullrequestreview-2164434204 From zsong at openjdk.org Mon Jul 8 22:40:21 2024 From: zsong at openjdk.org (Zhao Song) Date: Mon, 8 Jul 2024 22:40:21 GMT Subject: RFR: 2312: Do not require re-review for a simple merge In-Reply-To: References: Message-ID: On Mon, 8 Jul 2024 14:55:44 GMT, Pavel Rappo wrote: > If a repository is configured to ignore stale reviews, every commit to a PR made against that repo means that the PR needs to be re-reviewed. Re-reviewing is costly, and not all commits are worth that cost. > > One example of such a commit is a simple merge. During a PR's lifetime, the PR's target branch (typically, repo's `master`) might be merged into the PR multiple times. Usually, such merges are trivial and would effectively be performed by Skara automatically if the PR didn't have them in the first place [^*]. For such commits, it makes sense to not require review. > > This is my first contribution to Skara domain logic, which I've just started learning about. Also, while I tried to code this change according to Skara customs and idioms, I might have missed something. I guess what I'm saying is **take extra care** reviewing this PR. Thanks. > > > [^*]: This is the main assumption of this PR. Any simple merges present in a PR change the end result of that PR insignificantly, if at all. The functionality seems good to me, just have some minor suggestions. bots/pr/src/main/java/org/openjdk/skara/bots/pr/PullRequestBotBuilder.java line 47: > 45: private IssueProject issueProject = null; > 46: private boolean ignoreStaleReviews = false; > 47: private boolean includeSimpleMerges = false; I am not sure if `includeSimpleMerges` is a good name. To me, if `includeSimpleMerges` is true, I think it means the bot **should** check the simple merges. But actually, it means the bot should ignore simple merges? bots/pr/src/main/java/org/openjdk/skara/bots/pr/ReviewCoverage.java line 59: > 57: return true; > 58: if (!includeSimpleMerges) > 59: return false; I think it's better to add `{}` after an if statement, even for single statements vcs/src/main/java/org/openjdk/skara/vcs/git/GitCommits.java line 68: > 66: this.num = -1; > 67: from = reachableFrom; > 68: notFrom = unreachableFrom; Add `this` before `from` and `notFrom` to align with surrounding code? vcs/src/main/java/org/openjdk/skara/vcs/git/GitRepository.java line 1012: > 1010: } > 1011: } > 1012: Maybe it's better to add an interface in `ReadOnlyRepository` ------------- PR Review: https://git.openjdk.org/skara/pull/1672#pullrequestreview-2164487843 PR Review Comment: https://git.openjdk.org/skara/pull/1672#discussion_r1669369874 PR Review Comment: https://git.openjdk.org/skara/pull/1672#discussion_r1669387128 PR Review Comment: https://git.openjdk.org/skara/pull/1672#discussion_r1669405474 PR Review Comment: https://git.openjdk.org/skara/pull/1672#discussion_r1669403150 From prappo at openjdk.org Mon Jul 8 23:10:30 2024 From: prappo at openjdk.org (Pavel Rappo) Date: Mon, 8 Jul 2024 23:10:30 GMT Subject: RFR: 2312: Do not require re-review for a simple merge In-Reply-To: References:

Message-ID: On Mon, 8 Jul 2024 21:46:31 GMT, Zhao Song wrote: >> If a repository is configured to ignore stale reviews, every commit to a PR made against that repo means that the PR needs to be re-reviewed. Re-reviewing is costly, and not all commits are worth that cost. >> >> One example of such a commit is a simple merge. During a PR's lifetime, the PR's target branch (typically, repo's `master`) might be merged into the PR multiple times. Usually, such merges are trivial and would effectively be performed by Skara automatically if the PR didn't have them in the first place [^*]. For such commits, it makes sense to not require review. >> >> This is my first contribution to Skara domain logic, which I've just started learning about. Also, while I tried to code this change according to Skara customs and idioms, I might have missed something. I guess what I'm saying is **take extra care** reviewing this PR. Thanks. >> >> >> [^*]: This is the main assumption of this PR. Any simple merges present in a PR change the end result of that PR insignificantly, if at all. > > bots/pr/src/main/java/org/openjdk/skara/bots/pr/PullRequestBotBuilder.java line 47: > >> 45: private IssueProject issueProject = null; >> 46: private boolean ignoreStaleReviews = false; >> 47: private boolean includeSimpleMerges = false; > > I am not sure if `includeSimpleMerges` is a good name. > To me, if `includeSimpleMerges` is true, I think it means the bot **should** check the simple merges. > But actually, it means the bot should ignore simple merges? Naming is hard. Consistent naming in an established project is harder still. `includeSimpleMerges` (or whatever it ends up being named) is supposed to work in pair with `ignoreStaleReviews`. In that pair, "include" is the opposite to "ignore": do not ignore reviews for simple merges. That said, I'm open to better naming. ------------- PR Review Comment: https://git.openjdk.org/skara/pull/1672#discussion_r1669426440 From zsong at openjdk.org Mon Jul 8 23:12:09 2024 From: zsong at openjdk.org (Zhao Song) Date: Mon, 8 Jul 2024 23:12:09 GMT Subject: RFR: 2322: Notify when PR is ready for sponsor in GitLab Message-ID: In [SKARA-2302](https://bugs.openjdk.org/browse/SKARA-2302), I tried to let the bot send an email notification about the "pr is ready for sponsor" comment. But today, I noticed that it only works in GitHub not works in GitLab. ------------- Commit messages: - SKARA-2322 Changes: https://git.openjdk.org/skara/pull/1674/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1674&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-2322 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/skara/pull/1674.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1674/head:pull/1674 PR: https://git.openjdk.org/skara/pull/1674 From prappo at openjdk.org Mon Jul 8 23:28:30 2024 From: prappo at openjdk.org (Pavel Rappo) Date: Mon, 8 Jul 2024 23:28:30 GMT Subject: RFR: 2312: Do not require re-review for a simple merge [v2] In-Reply-To: References: Message-ID: > If a repository is configured to ignore stale reviews, every commit to a PR made against that repo means that the PR needs to be re-reviewed. Re-reviewing is costly, and not all commits are worth that cost. > > One example of such a commit is a simple merge. During a PR's lifetime, the PR's target branch (typically, repo's `master`) might be merged into the PR multiple times. Usually, such merges are trivial and would effectively be performed by Skara automatically if the PR didn't have them in the first place [^*]. For such commits, it makes sense to not require review. > > This is my first contribution to Skara domain logic, which I've just started learning about. Also, while I tried to code this change according to Skara customs and idioms, I might have missed something. I guess what I'm saying is **take extra care** reviewing this PR. Thanks. > > > [^*]: This is the main assumption of this PR. Any simple merges present in a PR change the end result of that PR insignificantly, if at all. Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: Respond to feedback ------------- Changes: - all: https://git.openjdk.org/skara/pull/1672/files - new: https://git.openjdk.org/skara/pull/1672/files/1e771a28..68e4dffc Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1672&range=01 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1672&range=00-01 Stats: 10 lines in 2 files changed: 3 ins; 0 del; 7 mod Patch: https://git.openjdk.org/skara/pull/1672.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1672/head:pull/1672 PR: https://git.openjdk.org/skara/pull/1672 From prappo at openjdk.org Mon Jul 8 23:21:11 2024 From: prappo at openjdk.org (Pavel Rappo) Date: Mon, 8 Jul 2024 23:21:11 GMT Subject: RFR: 2312: Do not require re-review for a simple merge In-Reply-To: References:

Message-ID: On Mon, 8 Jul 2024 22:32:38 GMT, Zhao Song wrote: >> If a repository is configured to ignore stale reviews, every commit to a PR made against that repo means that the PR needs to be re-reviewed. Re-reviewing is costly, and not all commits are worth that cost. >> >> One example of such a commit is a simple merge. During a PR's lifetime, the PR's target branch (typically, repo's `master`) might be merged into the PR multiple times. Usually, such merges are trivial and would effectively be performed by Skara automatically if the PR didn't have them in the first place [^*]. For such commits, it makes sense to not require review. >> >> This is my first contribution to Skara domain logic, which I've just started learning about. Also, while I tried to code this change according to Skara customs and idioms, I might have missed something. I guess what I'm saying is **take extra care** reviewing this PR. Thanks. >> >> >> [^*]: This is the main assumption of this PR. Any simple merges present in a PR change the end result of that PR insignificantly, if at all. > > vcs/src/main/java/org/openjdk/skara/vcs/git/GitRepository.java line 1012: > >> 1010: } >> 1011: } >> 1012: > > Maybe it's better to add an interface in `ReadOnlyRepository` If we add this method to `ReadOnlyRepository`, then we'll need to provide some implementation of it for `HgRepository`, which is a subclass of `ReadOnlyRepository`. Not only does `HgRepository` need no such functionality (AFAIK, PRs are not modelled to work in Mercurial repos), a Mercurial implementation will likely be more involved than that of Git. ------------- PR Review Comment: https://git.openjdk.org/skara/pull/1672#discussion_r1669433795 From zsong at openjdk.org Tue Jul 9 00:10:21 2024 From: zsong at openjdk.org (Zhao Song) Date: Tue, 9 Jul 2024 00:10:21 GMT Subject: RFR: 2312: Do not require re-review for a simple merge [v2] In-Reply-To: References:

Message-ID: On Mon, 8 Jul 2024 23:19:08 GMT, Pavel Rappo wrote: >> vcs/src/main/java/org/openjdk/skara/vcs/git/GitRepository.java line 1012: >> >>> 1010: } >>> 1011: } >>> 1012: >> >> Maybe it's better to add an interface in `ReadOnlyRepository` > > If we add this method to `ReadOnlyRepository`, then we'll need to provide some implementation of it for `HgRepository`, which is a subclass of `ReadOnlyRepository`. Not only does `HgRepository` need no such functionality (AFAIK, PRs are not modelled to work in Mercurial repos), a Mercurial implementation will likely be more involved than that of Git. Yes, for `HgRepository`, you just need to put `throw new UnsupportedOperationException();` in the implementation ------------- PR Review Comment: https://git.openjdk.org/skara/pull/1672#discussion_r1669465951 From zsong at openjdk.org Tue Jul 9 00:25:38 2024 From: zsong at openjdk.org (Zhao Song) Date: Tue, 9 Jul 2024 00:25:38 GMT Subject: RFR: 2312: Do not require re-review for a simple merge [v2] In-Reply-To: References:

Message-ID: On Mon, 8 Jul 2024 23:08:20 GMT, Pavel Rappo wrote: >> bots/pr/src/main/java/org/openjdk/skara/bots/pr/PullRequestBotBuilder.java line 47: >> >>> 45: private IssueProject issueProject = null; >>> 46: private boolean ignoreStaleReviews = false; >>> 47: private boolean includeSimpleMerges = false; >> >> I am not sure if `includeSimpleMerges` is a good name. >> To me, if `includeSimpleMerges` is true, I think it means the bot **should** check the simple merges. >> But actually, it means the bot should ignore simple merges? > > Naming is hard. Consistent naming in an established project is harder still. > > `includeSimpleMerges` (or whatever it ends up being named) is supposed to work in pair with `ignoreStaleReviews`. In that pair, "include" is the opposite to "ignore": do not ignore reviews for simple merges. > > That said, I'm open to better naming. So you said `includeSimpleMerges` means "do not ignore reviews for simple merges."? ------------- PR Review Comment: https://git.openjdk.org/skara/pull/1672#discussion_r1669475383 From prappo at openjdk.org Tue Jul 9 00:34:20 2024 From: prappo at openjdk.org (Pavel Rappo) Date: Tue, 9 Jul 2024 00:34:20 GMT Subject: RFR: 2312: Do not require re-review for a simple merge [v2] In-Reply-To: References:

Message-ID: On Tue, 9 Jul 2024 00:23:34 GMT, Zhao Song wrote: >> Naming is hard. Consistent naming in an established project is harder still. >> >> `includeSimpleMerges` (or whatever it ends up being named) is supposed to work in pair with `ignoreStaleReviews`. In that pair, "include" is the opposite to "ignore": do not ignore reviews for simple merges. >> >> That said, I'm open to better naming. > > So you said `includeSimpleMerges` means "do not ignore reviews for simple merges."? Yes. ------------- PR Review Comment: https://git.openjdk.org/skara/pull/1672#discussion_r1669481103 From zsong at openjdk.org Tue Jul 9 02:03:40 2024 From: zsong at openjdk.org (Zhao Song) Date: Tue, 9 Jul 2024 02:03:40 GMT Subject: RFR: 2312: Do not require re-review for a simple merge [v2] In-Reply-To: References:

Message-ID: <4vfWkgI8dPncdVzlLtkTr3e8MfvwhlKCx1uSKNcT3Us=.931e6211-a9eb-40b7-86c2-cd72011e306a@github.com> On Tue, 9 Jul 2024 00:08:12 GMT, Zhao Song wrote: >> If we add this method to `ReadOnlyRepository`, then we'll need to provide some implementation of it for `HgRepository`, which is a subclass of `ReadOnlyRepository`. Not only does `HgRepository` need no such functionality (AFAIK, PRs are not modelled to work in Mercurial repos), a Mercurial implementation will likely be more involved than that of Git. > > Yes, for `HgRepository`, you just need to put `throw new UnsupportedOperationException();` in the implementation Here's what I'm going to do: - pull up new `Commits commits(List reachableFrom, List unreachableFrom)` to `ReadOnlyRepository`, - pull up `boolean isRemergeDiffEmpty(Hash mergeCommitHash)` to `Repository`. `isRemergeDiffEmpty` is not a good fit for `ReadOnlyRepository` as far as I understand it. Additionally, if in the future we decide to implement `--remerge-diff` manually, for whatever reason, it'll be even less fit. ------------- PR Review Comment: https://git.openjdk.org/skara/pull/1672#discussion_r1670140743 From prappo at openjdk.org Tue Jul 9 10:20:21 2024 From: prappo at openjdk.org (Pavel Rappo) Date: Tue, 9 Jul 2024 10:20:21 GMT Subject: RFR: 2312: Do not require re-review for a simple merge [v3] In-Reply-To: References: Message-ID: > If a repository is configured to ignore stale reviews, every commit to a PR made against that repo means that the PR needs to be re-reviewed. Re-reviewing is costly, and not all commits are worth that cost. > > One example of such a commit is a simple merge. During a PR's lifetime, the PR's target branch (typically, repo's `master`) might be merged into the PR multiple times. Usually, such merges are trivial and would effectively be performed by Skara automatically if the PR didn't have them in the first place [^*]. For such commits, it makes sense to not require review. > > This is my first contribution to Skara domain logic, which I've just started learning about. Also, while I tried to code this change according to Skara customs and idioms, I might have missed something. I guess what I'm saying is **take extra care** reviewing this PR. Thanks. > > > [^*]: This is the main assumption of this PR. Any simple merges present in a PR change the end result of that PR insignificantly, if at all. Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: Respond to feedback Pulls up new methods from GitRepository. ------------- Changes: - all: https://git.openjdk.org/skara/pull/1672/files - new: https://git.openjdk.org/skara/pull/1672/files/68e4dffc..555b826e Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1672&range=02 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1672&range=01-02 Stats: 35 lines in 6 files changed: 20 ins; 5 del; 10 mod Patch: https://git.openjdk.org/skara/pull/1672.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1672/head:pull/1672 PR: https://git.openjdk.org/skara/pull/1672 From erikj at openjdk.org Tue Jul 9 10:24:04 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 9 Jul 2024 10:24:04 GMT Subject: RFR: 2312: Do not require re-review for a simple merge [v3] In-Reply-To: References:

Message-ID: On Tue, 9 Jul 2024 10:20:21 GMT, Pavel Rappo wrote: >> If a repository is configured to ignore stale reviews, every commit to a PR made against that repo means that the PR needs to be re-reviewed. Re-reviewing is costly, and not all commits are worth that cost. >> >> One example of such a commit is a simple merge. During a PR's lifetime, the PR's target branch (typically, repo's `master`) might be merged into the PR multiple times. Usually, such merges are trivial and would effectively be performed by Skara automatically if the PR didn't have them in the first place [^*]. For such commits, it makes sense to not require review. >> >> This is my first contribution to Skara domain logic, which I've just started learning about. Also, while I tried to code this change according to Skara customs and idioms, I might have missed something. I guess what I'm saying is **take extra care** reviewing this PR. Thanks. >> >> >> [^*]: This is the main assumption of this PR. Any simple merges present in a PR change the end result of that PR insignificantly, if at all. > > Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: > > Respond to feedback > > Pulls up new methods from GitRepository. I like that you are abstracting out the logic for review coverage into a separate class. See inline for comments and thoughts. ------------- PR Review: https://git.openjdk.org/skara/pull/1672#pullrequestreview-2165659932 From erikj at openjdk.org Tue Jul 9 10:24:04 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 9 Jul 2024 10:24:04 GMT Subject: RFR: 2312: Do not require re-review for a simple merge [v3] In-Reply-To: References:

Message-ID: On Tue, 9 Jul 2024 00:32:12 GMT, Pavel Rappo wrote: >> So you said `includeSimpleMerges` means "do not ignore reviews for simple merges."? > > Yes. I agree with Zhao's concern about the naming being confusing. I understand the motivation given the existing `ignoreStaleReviews`, which is almost equally bad. Just the other day, we reflected over that config option when we enabled it for the mainline jdk repository as it could be interpreted both ways, but we agreed that the opposite interpretation was our instinctive assumption. Perhaps we should just fix both names while we are at it? Can do the existing one in a separate fix if you prefer, but either way works for me. When deploying it, we will need to take care to update the bot configuration files. This kind of change isn't without precedent and something we can do. In that case I would suggest the following, but open for suggestions: - `useStaleReviews` - `acceptSimpleMerges` >> Yes, for `HgRepository`, you just need to put `throw new UnsupportedOperationException();` in the implementation > > Here's what I'm going to do: > > - pull up new `Commits commits(List reachableFrom, List unreachableFrom)` to `ReadOnlyRepository`, > - pull up `boolean isRemergeDiffEmpty(Hash mergeCommitHash)` to `Repository`. > > `isRemergeDiffEmpty` is not a good fit for `ReadOnlyRepository` as far as I understand it. Additionally, if in the future we decide to implement `--remerge-diff` manually, for whatever reason, it'll be even less fit. I agree with Zhao, the API should be on the interface. It's fine to just throw unsupported from HG. ------------- PR Review Comment: https://git.openjdk.org/skara/pull/1672#discussion_r1670121053 PR Review Comment: https://git.openjdk.org/skara/pull/1672#discussion_r1670159713 From erikj at openjdk.org Tue Jul 9 10:24:04 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 9 Jul 2024 10:24:04 GMT Subject: RFR: 2312: Do not require re-review for a simple merge [v2] In-Reply-To: References:

Message-ID: On Mon, 8 Jul 2024 23:28:30 GMT, Pavel Rappo wrote: >> If a repository is configured to ignore stale reviews, every commit to a PR made against that repo means that the PR needs to be re-reviewed. Re-reviewing is costly, and not all commits are worth that cost. >> >> One example of such a commit is a simple merge. During a PR's lifetime, the PR's target branch (typically, repo's `master`) might be merged into the PR multiple times. Usually, such merges are trivial and would effectively be performed by Skara automatically if the PR didn't have them in the first place [^*]. For such commits, it makes sense to not require review. >> >> This is my first contribution to Skara domain logic, which I've just started learning about. Also, while I tried to code this change according to Skara customs and idioms, I might have missed something. I guess what I'm saying is **take extra care** reviewing this PR. Thanks. >> >> >> [^*]: This is the main assumption of this PR. Any simple merges present in a PR change the end result of that PR insignificantly, if at all. > > Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: > > Respond to feedback bots/pr/src/main/java/org/openjdk/skara/bots/pr/PullRequestBotFactory.java line 167: > 165: botBuilder.ignoreStaleReviews(repo.value().get("ignorestale").asBoolean()); > 166: } > 167: if (repo.value().contains("includemerge")) { In newer Skara code we have already moved towards using camel case in the config options and having them match the boolean in the code, so I think we should do that here too, for both this new option and the old `ignorestale` if we agree to fix both. bots/pr/src/main/java/org/openjdk/skara/bots/pr/ReviewCoverage.java line 49: > 47: } > 48: > 49: public boolean covers(Review review, PullRequest pr) { >From what I can tell, this method is called twice for each Review in a CheckRun, once when generating the commit and once when generating the body. It makes several invocations of `git` in each call, some of which are clearly repeating between calls. We need to look at how we can cache the results to avoid bloating CheckRuns too much. Since the class is instantiated once for each CheckRun (and command), it should be fine to implement caching in the class itself for most of these calls, or rather for the result of a particular review hash. The pr head and target hash won't change during one WorkItem, so the only input value that differs between calls to one instance is the review hash. With that in mind, the pr should be a field rather than a method parameter. I would really like to solve such performance issues up front for new features and avoid adding more unnecessary bloat that will need cleanup later. bots/pr/src/main/java/org/openjdk/skara/bots/pr/ReviewCoverage.java line 69: > 67: boolean seenAtLeastOneCommit = false; > 68: try { > 69: var targetHash = PullRequestUtils.targetHash(gitRepo); `PullRequestUtils::targetHash` is not caching the result, so will invoke `git` every time. There is a wrapper for this in CheckablePullRequest that does caching, which is used most of the time from the work items. Not sure how to best utilize that though. We could cache here, but that would still add one additional `git` invocation. bots/pr/src/main/java/org/openjdk/skara/bots/pr/ReviewCoverage.java line 74: > 72: seenAtLeastOneCommit = true; > 73: if (!c.isMerge() || c.numParents() != 2) > 74: return false; Nit: Please surround the if block with braces. ------------- PR Review Comment: https://git.openjdk.org/skara/pull/1672#discussion_r1670150653 PR Review Comment: https://git.openjdk.org/skara/pull/1672#discussion_r1670193124 PR Review Comment: https://git.openjdk.org/skara/pull/1672#discussion_r1670184200 PR Review Comment: https://git.openjdk.org/skara/pull/1672#discussion_r1670173107 From prappo at openjdk.org Tue Jul 9 10:28:12 2024 From: prappo at openjdk.org (Pavel Rappo) Date: Tue, 9 Jul 2024 10:28:12 GMT Subject: Integrated: 2321: Prefer pattern matching for instanceof In-Reply-To: References: Message-ID: On Mon, 8 Jul 2024 17:04:03 GMT, Pavel Rappo wrote: > Pattern matching for `instanceof` was introduced in JDK 16, by JEP 394. It's already been used by new code in Skara, but the older code can benefit from it too. This pull request has now been integrated. Changeset: 14560732 Author: Pavel Rappo Committer: Erik Joelsson URL: https://git.openjdk.org/skara/commit/14560732b4c7985b07d61b15eab35006132a19bc Stats: 155 lines in 52 files changed: 0 ins; 50 del; 105 mod 2321: Prefer pattern matching for instanceof Reviewed-by: zsong, erikj ------------- PR: https://git.openjdk.org/skara/pull/1673 From zsong at openjdk.org Tue Jul 9 16:20:52 2024 From: zsong at openjdk.org (Zhao Song) Date: Tue, 9 Jul 2024 16:20:52 GMT Subject: RFR: 2322: Notify when PR is ready for sponsor in GitLab In-Reply-To: References: Message-ID: On Mon, 8 Jul 2024 23:07:20 GMT, Zhao Song wrote: > In [SKARA-2302](https://bugs.openjdk.org/browse/SKARA-2302), I tried to let the bot send an email notification about the "pr is ready for sponsor" comment. > But today, I noticed that it only works in GitHub not works in GitLab. Thanks for the review! ------------- PR Comment: https://git.openjdk.org/skara/pull/1674#issuecomment-2218123469 From zsong at openjdk.org Tue Jul 9 16:20:52 2024 From: zsong at openjdk.org (Zhao Song) Date: Tue, 9 Jul 2024 16:20:52 GMT Subject: Integrated: 2322: Notify when PR is ready for sponsor in GitLab In-Reply-To: References: Message-ID: On Mon, 8 Jul 2024 23:07:20 GMT, Zhao Song wrote: > In [SKARA-2302](https://bugs.openjdk.org/browse/SKARA-2302), I tried to let the bot send an email notification about the "pr is ready for sponsor" comment. > But today, I noticed that it only works in GitHub not works in GitLab. This pull request has now been integrated. Changeset: 0c71b9d4 Author: Zhao Song URL: https://git.openjdk.org/skara/commit/0c71b9d402b042c08608763ef390f1b04ffd7b21 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 2322: Notify when PR is ready for sponsor in GitLab Reviewed-by: erikj ------------- PR: https://git.openjdk.org/skara/pull/1674 From prappo at openjdk.org Wed Jul 10 08:51:50 2024 From: prappo at openjdk.org (Pavel Rappo) Date: Wed, 10 Jul 2024 08:51:50 GMT Subject: RFR: 2323: Use stream-bearing methods of java.nio.file.Files correctly Message-ID: Streams returned from methods of `java.nio.file.Files` should be closed. A typical documentation note reads as follows: > This method must be used within a try-with-resources statement or similar control structure to ensure that the stream's is closed promptly after the stream's operations have completed. In a few occasions, code was additionally lightly simplified: - LinkTask.java#L131 - LinkTask.java#L179 - VersionPlugin.java#L55-L60 ------------- Commit messages: - Initial commit Changes: https://git.openjdk.org/skara/pull/1675/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1675&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-2323 Stats: 159 lines in 20 files changed: 26 ins; 7 del; 126 mod Patch: https://git.openjdk.org/skara/pull/1675.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1675/head:pull/1675 PR: https://git.openjdk.org/skara/pull/1675 From erikj at openjdk.org Wed Jul 10 11:29:51 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 10 Jul 2024 11:29:51 GMT Subject: RFR: 2323: Use stream-bearing methods of java.nio.file.Files correctly In-Reply-To: References: Message-ID: <4Xj5vGGIBDCLUkun1IqiLhBraLVsn5ctHzUYTBrk_i0=.e44bad20-8c94-4a8e-a657-459771a78d44@github.com> On Wed, 10 Jul 2024 08:47:49 GMT, Pavel Rappo wrote: > Streams returned from methods of `java.nio.file.Files` should be closed. A typical documentation note reads as follows: > >> This method must be used within a try-with-resources statement or similar control structure to ensure that the stream's is closed promptly after the stream's operations have completed. > > In a few occasions, code was additionally lightly simplified: > > - LinkTask.java#L131 > - LinkTask.java#L179 > - VersionPlugin.java#L55-L60 Looks good. For the gradle plugins, did you verify building the targets using them? ------------- Marked as reviewed by erikj (Lead). PR Review: https://git.openjdk.org/skara/pull/1675#pullrequestreview-2168717050 From prappo at openjdk.org Wed Jul 10 11:31:42 2024 From: prappo at openjdk.org (Pavel Rappo) Date: Wed, 10 Jul 2024 11:31:42 GMT Subject: RFR: 2312: Do not require re-review for a simple merge [v4] In-Reply-To: References: Message-ID: > If a repository is configured to ignore stale reviews, every commit to a PR made against that repo means that the PR needs to be re-reviewed. Re-reviewing is costly, and not all commits are worth that cost. > > One example of such a commit is a simple merge. During a PR's lifetime, the PR's target branch (typically, repo's `master`) might be merged into the PR multiple times. Usually, such merges are trivial and would effectively be performed by Skara automatically if the PR didn't have them in the first place [^*]. For such commits, it makes sense to not require review. > > This is my first contribution to Skara domain logic, which I've just started learning about. Also, while I tried to code this change according to Skara customs and idioms, I might have missed something. I guess what I'm saying is **take extra care** reviewing this PR. Thanks. > > > [^*]: This is the main assumption of this PR. Any simple merges present in a PR change the end result of that PR insignificantly, if at all. Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: Respond to feedback ------------- Changes: - all: https://git.openjdk.org/skara/pull/1672/files - new: https://git.openjdk.org/skara/pull/1672/files/555b826e..0c295858 Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1672&range=03 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1672&range=02-03 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/skara/pull/1672.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1672/head:pull/1672 PR: https://git.openjdk.org/skara/pull/1672 From prappo at openjdk.org Wed Jul 10 11:31:42 2024 From: prappo at openjdk.org (Pavel Rappo) Date: Wed, 10 Jul 2024 11:31:42 GMT Subject: RFR: 2312: Do not require re-review for a simple merge [v4] In-Reply-To: References:

Message-ID: On Tue, 9 Jul 2024 09:27:06 GMT, Erik Joelsson wrote: > Just the other day, we reflected over that config option when we enabled it for the mainline jdk repository as it could be interpreted both ways, but we agreed that the opposite interpretation was our instinctive assumption. When I started this work, I was surprised to realise that `ignoreStaleReviews` is true means that outdated reviews are **not** included in the total count of reviews. Like you said, it's counterintuitive. But I didn't propose to change it because it's an established property that some repos already use. So, like you said, if we change it, we should be prepared to change the configuration of the affected repos too. Those names you suggested, are they both for JSON configuration and Java code? In other words, should I change code like this? if (repo.value().contains("useStaleReviews")) { botBuilder.useStaleReviews(repo.value().get("useStaleReviews").asBoolean()); } if (repo.value().contains("acceptSimpleMerges")) { botBuilder.acceptSimpleMerges(repo.value().get("acceptSimpleMerges").asBoolean()); } ------------- PR Review Comment: https://git.openjdk.org/skara/pull/1672#discussion_r1672005706 From prappo at openjdk.org Wed Jul 10 11:31:43 2024 From: prappo at openjdk.org (Pavel Rappo) Date: Wed, 10 Jul 2024 11:31:43 GMT Subject: RFR: 2312: Do not require re-review for a simple merge [v2] In-Reply-To: References:

Message-ID: On Tue, 9 Jul 2024 09:44:37 GMT, Erik Joelsson wrote: >> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: >> >> Respond to feedback > > bots/pr/src/main/java/org/openjdk/skara/bots/pr/PullRequestBotFactory.java line 167: > >> 165: botBuilder.ignoreStaleReviews(repo.value().get("ignorestale").asBoolean()); >> 166: } >> 167: if (repo.value().contains("includemerge")) { > > In newer Skara code we have already moved towards using camel case in the config options and having them match the boolean in the code, so I think we should do that here too, for both this new option and the old `ignorestale` if we agree to fix both. I see, that answers my earlier question: https://github.com/openjdk/skara/pull/1672#discussion_r1672005706 ------------- PR Review Comment: https://git.openjdk.org/skara/pull/1672#discussion_r1672008592 From prappo at openjdk.org Wed Jul 10 11:53:50 2024 From: prappo at openjdk.org (Pavel Rappo) Date: Wed, 10 Jul 2024 11:53:50 GMT Subject: RFR: 2323: Use stream-bearing methods of java.nio.file.Files correctly In-Reply-To: <4Xj5vGGIBDCLUkun1IqiLhBraLVsn5ctHzUYTBrk_i0=.e44bad20-8c94-4a8e-a657-459771a78d44@github.com> References: <4Xj5vGGIBDCLUkun1IqiLhBraLVsn5ctHzUYTBrk_i0=.e44bad20-8c94-4a8e-a657-459771a78d44@github.com> Message-ID: On Wed, 10 Jul 2024 10:39:41 GMT, Erik Joelsson wrote: > For the gradle plugins, did you verify building the targets using them? I'll do all the extra testing I can, but according to my earlier code coverage for the `test` target, the following classes, not all of which are related to Gradle (*), were **insufficiently** covered on the affected lines. - org.openjdk.skara.bots.hgbridge.Exporter - org.openjdk.skara.bots.merge.MergeBot - org.openjdk.skara.cli.debug.GitMlRules - org.openjdk.skara.cli.debug.GitVerifyImport - org.openjdk.skara.cli.GitTrees - org.openjdk.skara.cli.GitWebrev - org.openjdk.skara.gradle.images.DownloadJDKTask * - org.openjdk.skara.gradle.images.LaunchersTask * - org.openjdk.skara.gradle.images.LinkTask * - org.openjdk.skara.gradle.version.VersionPlugin * - org.openjdk.skara.vcs.git.GitRepository - org.openjdk.skara.vcs.hg.HgRepository - org.openjdk.skara.vcs.openjdk.convert.HgToGitConverter Any suggestions for the extra testing? ------------- PR Comment: https://git.openjdk.org/skara/pull/1675#issuecomment-2220314407 From erikj at openjdk.org Wed Jul 10 12:41:48 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 10 Jul 2024 12:41:48 GMT Subject: RFR: 2323: Use stream-bearing methods of java.nio.file.Files correctly In-Reply-To: References: <4Xj5vGGIBDCLUkun1IqiLhBraLVsn5ctHzUYTBrk_i0=.e44bad20-8c94-4a8e-a657-459771a78d44@github.com> Message-ID: On Wed, 10 Jul 2024 11:51:45 GMT, Pavel Rappo wrote: > Any suggestions for the extra testing? The plugins are used when building the bots cli image bash gradlew :bots:cli:images I pulled your branch and tested this (also with the Oracle internal custom additions). I don't think there is more we can reasonably do. ------------- PR Comment: https://git.openjdk.org/skara/pull/1675#issuecomment-2220409071 From erikj at openjdk.org Wed Jul 10 12:46:01 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 10 Jul 2024 12:46:01 GMT Subject: RFR: 2312: Do not require re-review for a simple merge [v4] In-Reply-To: References:

Message-ID: <0X-bdw9HGz1BSJXOmN0zdORd-dKg5zbjThw7NWoH9pc=.a28ac993-fd11-4656-8238-ee6e8fa4111c@github.com> On Wed, 10 Jul 2024 10:15:19 GMT, Pavel Rappo wrote: >> I agree with Zhao's concern about the naming being confusing. I understand the motivation given the existing `ignoreStaleReviews`, which is almost equally bad. Just the other day, we reflected over that config option when we enabled it for the mainline jdk repository as it could be interpreted both ways, but we agreed that the opposite interpretation was our instinctive assumption. >> >> Perhaps we should just fix both names while we are at it? Can do the existing one in a separate fix if you prefer, but either way works for me. When deploying it, we will need to take care to update the bot configuration files. This kind of change isn't without precedent and something we can do. >> >> In that case I would suggest the following, but open for suggestions: >> >> - `useStaleReviews` >> - `acceptSimpleMerges` > >> Just the other day, we reflected over that config option when we enabled it for the mainline jdk repository as it could be interpreted both ways, but we agreed that the opposite interpretation was our instinctive assumption. > > When I started this work, I was surprised to realise that `ignoreStaleReviews` is true means that outdated reviews are **not** included in the total count of reviews. Like you said, it's counterintuitive. > > But I didn't propose to change it because it's an established property that some repos already use. So, like you said, if we change it, we should be prepared to change the configuration of the affected repos too. > > Those names you suggested, are they both for JSON configuration and Java code? In other words, should I change code like this? > > if (repo.value().contains("useStaleReviews")) { > botBuilder.useStaleReviews(repo.value().get("useStaleReviews").asBoolean()); > } > if (repo.value().contains("acceptSimpleMerges")) { > botBuilder.acceptSimpleMerges(repo.value().get("acceptSimpleMerges").asBoolean()); > } Yes, I would like it to be consistent. ------------- PR Review Comment: https://git.openjdk.org/skara/pull/1672#discussion_r1672198351 From prappo at openjdk.org Wed Jul 10 13:35:54 2024 From: prappo at openjdk.org (Pavel Rappo) Date: Wed, 10 Jul 2024 13:35:54 GMT Subject: RFR: 2312: Do not require re-review for a simple merge [v5] In-Reply-To: References: Message-ID: > If a repository is configured to ignore stale reviews, every commit to a PR made against that repo means that the PR needs to be re-reviewed. Re-reviewing is costly, and not all commits are worth that cost. > > One example of such a commit is a simple merge. During a PR's lifetime, the PR's target branch (typically, repo's `master`) might be merged into the PR multiple times. Usually, such merges are trivial and would effectively be performed by Skara automatically if the PR didn't have them in the first place [^*]. For such commits, it makes sense to not require review. > > This is my first contribution to Skara domain logic, which I've just started learning about. Also, while I tried to code this change according to Skara customs and idioms, I might have missed something. I guess what I'm saying is **take extra care** reviewing this PR. Thanks. > > > [^*]: This is the main assumption of this PR. Any simple merges present in a PR change the end result of that PR insignificantly, if at all. Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: - Rename properties as suggested IMPORTANT --------- The ignoreStale JSON property is now called useStaleReviews. The semantics of useStaleReviews is the opposite (negated) that of ignoreStale. That means that all repos that are configured with ignoreStale set to true should instead be configured with useStaleReviews set to false or useStaleReviews absent. And the repositories whose configuration doesn't contain ignoreStale or whose ignoreStale is set to false should instead be configured with useStaleReviews set to true. In any case, if present, ignoreStale should be removed from a repo configuration as that property is now unrecognised. - Merge branch 'master' into 2312 - Respond to feedback - Respond to feedback Pulls up new methods from GitRepository. - Respond to feedback - Initial commit ------------- Changes: - all: https://git.openjdk.org/skara/pull/1672/files - new: https://git.openjdk.org/skara/pull/1672/files/0c295858..18ecf690 Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1672&range=04 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1672&range=03-04 Stats: 391 lines in 70 files changed: 143 ins; 60 del; 188 mod Patch: https://git.openjdk.org/skara/pull/1672.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1672/head:pull/1672 PR: https://git.openjdk.org/skara/pull/1672 From prappo at openjdk.org Wed Jul 10 13:52:43 2024 From: prappo at openjdk.org (Pavel Rappo) Date: Wed, 10 Jul 2024 13:52:43 GMT Subject: RFR: 2312: Do not require re-review for a simple merge [v5] In-Reply-To: References:

Message-ID: On Wed, 10 Jul 2024 13:35:54 GMT, Pavel Rappo wrote: >> If a repository is configured to ignore stale reviews, every commit to a PR made against that repo means that the PR needs to be re-reviewed. Re-reviewing is costly, and not all commits are worth that cost. >> >> One example of such a commit is a simple merge. During a PR's lifetime, the PR's target branch (typically, repo's `master`) might be merged into the PR multiple times. Usually, such merges are trivial and would effectively be performed by Skara automatically if the PR didn't have them in the first place [^*]. For such commits, it makes sense to not require review. >> >> This is my first contribution to Skara domain logic, which I've just started learning about. Also, while I tried to code this change according to Skara customs and idioms, I might have missed something. I guess what I'm saying is **take extra care** reviewing this PR. Thanks. >> >> >> [^*]: This is the main assumption of this PR. Any simple merges present in a PR change the end result of that PR insignificantly, if at all. > > Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: > > - Rename properties as suggested > > IMPORTANT > --------- > > The ignoreStale JSON property is now called useStaleReviews. The > semantics of useStaleReviews is the opposite (negated) that of > ignoreStale. > > That means that all repos that are configured with ignoreStale set to > true should instead be configured with useStaleReviews set to false or > useStaleReviews absent. And the repositories whose configuration doesn't > contain ignoreStale or whose ignoreStale is set to false should instead > be configured with useStaleReviews set to true. > > In any case, if present, ignoreStale should be removed from a repo > configuration as that property is now unrecognised. > - Merge branch 'master' into 2312 > - Respond to feedback > - Respond to feedback > > Pulls up new methods from GitRepository. > - Respond to feedback > - Initial commit Correction to the commit message of https://github.com/openjdk/skara/pull/1672/commits/18ecf690e3a404993ac6c8b3d27aa5a0051abdb8. It should read as follows: IMPORTANT --------- The ignoreStale JSON property is now called useStaleReviews. The semantics of useStaleReviews is the opposite (negated) of that of ignoreStale. The default value of useStaleReviews is true. That means that all repos that are configured with ignoreStale set to true should instead be configured with useStaleReviews set to false. And all repos that are configured with ignoreStale implicitly set to false should instead be configured to useStaleReviews set to true, or ignoreStale removed from a repo configuration. ------------- PR Comment: https://git.openjdk.org/skara/pull/1672#issuecomment-2220563043 From prappo at openjdk.org Wed Jul 10 13:59:11 2024 From: prappo at openjdk.org (Pavel Rappo) Date: Wed, 10 Jul 2024 13:59:11 GMT Subject: RFR: 2323: Use stream-bearing methods of java.nio.file.Files correctly In-Reply-To: References: <4Xj5vGGIBDCLUkun1IqiLhBraLVsn5ctHzUYTBrk_i0=.e44bad20-8c94-4a8e-a657-459771a78d44@github.com>

Message-ID: On Wed, 10 Jul 2024 12:39:38 GMT, Erik Joelsson wrote: > I pulled your branch and tested this (also with the Oracle internal custom additions). I don't think there is more we can reasonably do. Thanks, Erik. ------------- PR Comment: https://git.openjdk.org/skara/pull/1675#issuecomment-2220578883 From erikj at openjdk.org Wed Jul 10 14:11:16 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 10 Jul 2024 14:11:16 GMT Subject: RFR: 2312: Do not require re-review for a simple merge [v5] In-Reply-To: References:

Message-ID: On Wed, 10 Jul 2024 13:35:54 GMT, Pavel Rappo wrote: >> If a repository is configured to ignore stale reviews, every commit to a PR made against that repo means that the PR needs to be re-reviewed. Re-reviewing is costly, and not all commits are worth that cost. >> >> One example of such a commit is a simple merge. During a PR's lifetime, the PR's target branch (typically, repo's `master`) might be merged into the PR multiple times. Usually, such merges are trivial and would effectively be performed by Skara automatically if the PR didn't have them in the first place [^*]. For such commits, it makes sense to not require review. >> >> This is my first contribution to Skara domain logic, which I've just started learning about. Also, while I tried to code this change according to Skara customs and idioms, I might have missed something. I guess what I'm saying is **take extra care** reviewing this PR. Thanks. >> >> >> [^*]: This is the main assumption of this PR. Any simple merges present in a PR change the end result of that PR insignificantly, if at all. > > Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: > > - Rename properties as suggested > > IMPORTANT > --------- > > The ignoreStale JSON property is now called useStaleReviews. The > semantics of useStaleReviews is the opposite (negated) that of > ignoreStale. > > That means that all repos that are configured with ignoreStale set to > true should instead be configured with useStaleReviews set to false or > useStaleReviews absent. And the repositories whose configuration doesn't > contain ignoreStale or whose ignoreStale is set to false should instead > be configured with useStaleReviews set to true. > > In any case, if present, ignoreStale should be removed from a repo > configuration as that property is now unrecognised. > - Merge branch 'master' into 2312 > - Respond to feedback > - Respond to feedback > > Pulls up new methods from GitRepository. > - Respond to feedback > - Initial commit > Correction to the commit message of [18ecf69](https://github.com/openjdk/skara/commit/18ecf690e3a404993ac6c8b3d27aa5a0051abdb8). It should read as follows: > > ## IMPORTANT > The ignoreStale JSON property is now called useStaleReviews. The semantics of useStaleReviews is the opposite (negated) of that of ignoreStale. The default value of useStaleReviews is true. > > That means that all repos that are configured with ignoreStale set to true should instead be configured with useStaleReviews set to false. And all repos that are configured with ignoreStale implicitly set to false should instead be configured to useStaleReviews set to true, or ignoreStale removed from a repo configuration. Thanks for renaming the properties. This should be straightforward enough to update for. I like the new property names much better already when reading the code. ------------- PR Comment: https://git.openjdk.org/skara/pull/1672#issuecomment-2220616011 From prappo at openjdk.org Wed Jul 10 18:41:22 2024 From: prappo at openjdk.org (Pavel Rappo) Date: Wed, 10 Jul 2024 18:41:22 GMT Subject: RFR: 2312: Do not require re-review for a simple merge [v2] In-Reply-To: References:

Message-ID: <4wpZ-db2uOLuTvl24abW_soYDRKlzrgn5Zgfr1wvbyA=.ec02de63-3757-410b-a1ab-46f2c6ee45ad@github.com> On Tue, 9 Jul 2024 10:07:23 GMT, Erik Joelsson wrote: >> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: >> >> Respond to feedback > > bots/pr/src/main/java/org/openjdk/skara/bots/pr/ReviewCoverage.java line 49: > >> 47: } >> 48: >> 49: public boolean covers(Review review, PullRequest pr) { > > From what I can tell, this method is called twice for each Review in a CheckRun, once when generating the commit and once when generating the body. It makes several invocations of `git` in each call, some of which are clearly repeating between calls. We need to look at how we can cache the results to avoid bloating CheckRuns too much. Since the class is instantiated once for each CheckRun (and command), it should be fine to implement caching in the class itself for most of these calls, or rather for the result of a particular review hash. The pr head and target hash won't change during one WorkItem, so the only input value that differs between calls to one instance is the review hash. With that in mind, the pr should be a field rather than a method parameter. > > I would really like to solve such performance issues up front for new features and avoid adding more unnecessary bloat that will need cleanup later. In fact, during a single invocation of `CheckRun.checkStatus`, `ReviewCoverage.covers` is called **four** times for the same review and PR. The first time to identify if a reviewer should be added to the "Reviewed-by" list in a commit message. The second time to identify if a review should be labelled with "Re-review required" or "Review applies to ..." in the "Reviewers" bulleted list in the PR body. The third and fourth times to decide whether the "Reviewed-by" list in the commit message should be amended: 1. CheckRun:1329 2. CheckRun:1411 3. CheckRun:1416 (x 2) FYI, when I introduced trivial caching, the savings in my test scenario were very modest. Without any cache, on my machine, `org.openjdk.skara.bots.pr.CheckTests#acceptSimpleMerges` on average took 18,166 ms to complete. With the cache, on the same machine, that same test took 17,784 ms. This is 2% improvement. I haven't tried to address your other concern for `PullRequestUtils::targetHash` yet. ------------- PR Review Comment: https://git.openjdk.org/skara/pull/1672#discussion_r1672778521 From prappo at openjdk.org Wed Jul 10 22:46:14 2024 From: prappo at openjdk.org (Pavel Rappo) Date: Wed, 10 Jul 2024 22:46:14 GMT Subject: RFR: 2312: Do not require re-review for a simple merge [v2] In-Reply-To: <4wpZ-db2uOLuTvl24abW_soYDRKlzrgn5Zgfr1wvbyA=.ec02de63-3757-410b-a1ab-46f2c6ee45ad@github.com> References:

<4wpZ-db2uOLuTvl24abW_soYDRKlzrgn5Zgfr1wvbyA=.ec02de63-3757-410b-a1ab-46f2c6ee45ad@github.com> Message-ID: On Wed, 10 Jul 2024 18:39:13 GMT, Pavel Rappo wrote: >> bots/pr/src/main/java/org/openjdk/skara/bots/pr/ReviewCoverage.java line 49: >> >>> 47: } >>> 48: >>> 49: public boolean covers(Review review, PullRequest pr) { >> >> From what I can tell, this method is called twice for each Review in a CheckRun, once when generating the commit and once when generating the body. It makes several invocations of `git` in each call, some of which are clearly repeating between calls. We need to look at how we can cache the results to avoid bloating CheckRuns too much. Since the class is instantiated once for each CheckRun (and command), it should be fine to implement caching in the class itself for most of these calls, or rather for the result of a particular review hash. The pr head and target hash won't change during one WorkItem, so the only input value that differs between calls to one instance is the review hash. With that in mind, the pr should be a field rather than a method parameter. >> >> I would really like to solve such performance issues up front for new features and avoid adding more unnecessary bloat that will need cleanup later. > > In fact, during a single invocation of `CheckRun.checkStatus`, `ReviewCoverage.covers` is called **four** times for the same review and PR. The first time to identify if a reviewer should be added to the "Reviewed-by" list in a commit message. The second time to identify if a review should be labelled with "Re-review required" or "Review applies to ..." in the "Reviewers" bulleted list in the PR body. The third and fourth times to decide whether the "Reviewed-by" list in the commit message should be amended: > > 1. CheckRun:1329 > 2. CheckRun:1411 > 3. CheckRun:1416 (x 2) > > FYI, when I introduced trivial caching, the savings in my test scenario were very modest. Without any cache, on my machine, `org.openjdk.skara.bots.pr.CheckTests#acceptSimpleMerges` on average took 18,166 ms to complete. With the cache, on the same machine, that same test took 17,784 ms. This is 2% improvement. > > I haven't tried to address your other concern for `PullRequestUtils::targetHash` yet. I tried to cache `targetHash`. The average time went down a bit more: now it's 17,627 ms. I'll push what I have, and you can see for yourself if you like it or not. ------------- PR Review Comment: https://git.openjdk.org/skara/pull/1672#discussion_r1673137796 From prappo at openjdk.org Wed Jul 10 23:08:02 2024 From: prappo at openjdk.org (Pavel Rappo) Date: Wed, 10 Jul 2024 23:08:02 GMT Subject: RFR: 2312: Do not require re-review for a simple merge [v6] In-Reply-To: References: Message-ID: > If a repository is configured to ignore stale reviews, every commit to a PR made against that repo means that the PR needs to be re-reviewed. Re-reviewing is costly, and not all commits are worth that cost. > > One example of such a commit is a simple merge. During a PR's lifetime, the PR's target branch (typically, repo's `master`) might be merged into the PR multiple times. Usually, such merges are trivial and would effectively be performed by Skara automatically if the PR didn't have them in the first place [^*]. For such commits, it makes sense to not require review. > > This is my first contribution to Skara domain logic, which I've just started learning about. Also, while I tried to code this change according to Skara customs and idioms, I might have missed something. I guess what I'm saying is **take extra care** reviewing this PR. Thanks. > > > [^*]: This is the main assumption of this PR. Any simple merges present in a PR change the end result of that PR insignificantly, if at all. Pavel Rappo has updated the pull request incrementally with four additional commits since the last revision: - Clean up - Cache targetHash as suggested - Cache Review coverage as suggested - Make PullRequest a ctor parameter as suggested ------------- Changes: - all: https://git.openjdk.org/skara/pull/1672/files - new: https://git.openjdk.org/skara/pull/1672/files/18ecf690..739c1191 Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1672&range=05 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1672&range=04-05 Stats: 39 lines in 5 files changed: 28 ins; 1 del; 10 mod Patch: https://git.openjdk.org/skara/pull/1672.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1672/head:pull/1672 PR: https://git.openjdk.org/skara/pull/1672 From erikj at openjdk.org Thu Jul 11 07:01:51 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 11 Jul 2024 07:01:51 GMT Subject: RFR: 2312: Do not require re-review for a simple merge [v6] In-Reply-To: References:

Message-ID: On Wed, 10 Jul 2024 23:08:02 GMT, Pavel Rappo wrote: >> If a repository is configured to ignore stale reviews, every commit to a PR made against that repo means that the PR needs to be re-reviewed. Re-reviewing is costly, and not all commits are worth that cost. >> >> One example of such a commit is a simple merge. During a PR's lifetime, the PR's target branch (typically, repo's `master`) might be merged into the PR multiple times. Usually, such merges are trivial and would effectively be performed by Skara automatically if the PR didn't have them in the first place [^*]. For such commits, it makes sense to not require review. >> >> This is my first contribution to Skara domain logic, which I've just started learning about. Also, while I tried to code this change according to Skara customs and idioms, I might have missed something. I guess what I'm saying is **take extra care** reviewing this PR. Thanks. >> >> >> [^*]: This is the main assumption of this PR. Any simple merges present in a PR change the end result of that PR insignificantly, if at all. > > Pavel Rappo has updated the pull request incrementally with four additional commits since the last revision: > > - Clean up > - Cache targetHash as suggested > - Cache Review coverage as suggested > - Make PullRequest a ctor parameter as suggested I think this looks good now. Thank you for working on this and seeing it through! ------------- Marked as reviewed by erikj (Lead). PR Review: https://git.openjdk.org/skara/pull/1672#pullrequestreview-2171075312 From erikj at openjdk.org Thu Jul 11 07:06:30 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 11 Jul 2024 07:06:30 GMT Subject: RFR: 2312: Do not require re-review for a simple merge [v2] In-Reply-To: References:

<4wpZ-db2uOLuTvl24abW_soYDRKlzrgn5Zgfr1wvbyA=.ec02de63-3757-410b-a1ab-46f2c6ee45ad@github.com> Message-ID: On Wed, 10 Jul 2024 22:44:08 GMT, Pavel Rappo wrote: >> In fact, during a single invocation of `CheckRun.checkStatus`, `ReviewCoverage.covers` is called **four** times for the same review and PR. The first time to identify if a reviewer should be added to the "Reviewed-by" list in a commit message. The second time to identify if a review should be labelled with "Re-review required" or "Review applies to ..." in the "Reviewers" bulleted list in the PR body. The third and fourth times to decide whether the "Reviewed-by" list in the commit message should be amended: >> >> 1. CheckRun:1329 >> 2. CheckRun:1411 >> 3. CheckRun:1416 (x 2) >> >> FYI, when I introduced trivial caching, the savings in my test scenario were very modest. Without any cache, on my machine, `org.openjdk.skara.bots.pr.CheckTests#acceptSimpleMerges` on average took 18,166 ms to complete. With the cache, on the same machine, that same test took 17,784 ms. This is 2% improvement. >> >> I haven't tried to address your other concern for `PullRequestUtils::targetHash` yet. > > I tried to cache `targetHash`. The average time went down a bit more: now it's 17,627 ms. I'll push what I have, and you can see for yourself if you like it or not. I agree that it may not amount to much, especially not in a local test where the Git repository is minimal. I would expect some of these operations to be noticeably more expensive in properly sized repositories like the JDK. It's also about not suffering from the death of a thousand cuts. It's very easy for improvements like this to grow resource usage over time. So I appreciate you making the effort to implement caching. At least this way we know we aren't adding an unreasonable amount of extra work to a CheckRun. ------------- PR Review Comment: https://git.openjdk.org/skara/pull/1672#discussion_r1673512593 From duke at openjdk.org Thu Jul 11 15:56:20 2024 From: duke at openjdk.org (duke) Date: Thu, 11 Jul 2024 15:56:20 GMT Subject: RFR: 2323: Use stream-bearing methods of java.nio.file.Files correctly In-Reply-To: References: Message-ID: On Wed, 10 Jul 2024 08:47:49 GMT, Pavel Rappo wrote: > Streams returned from methods of `java.nio.file.Files` should be closed. A typical documentation note reads as follows: > >> This method must be used within a try-with-resources statement or similar control structure to ensure that the stream's is closed promptly after the stream's operations have completed. > > In a few occasions, code was additionally lightly simplified: > > - LinkTask.java#L131 > - LinkTask.java#L179 > - VersionPlugin.java#L55-L60 @pavelrappo Your change (at version e11ccf49d7308f32e9c7b5f5201de9f4f6504eb7) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/skara/pull/1675#issuecomment-2223305061 From prappo at openjdk.org Thu Jul 11 16:05:21 2024 From: prappo at openjdk.org (Pavel Rappo) Date: Thu, 11 Jul 2024 16:05:21 GMT Subject: Integrated: 2323: Use stream-bearing methods of java.nio.file.Files correctly In-Reply-To: References: Message-ID: On Wed, 10 Jul 2024 08:47:49 GMT, Pavel Rappo wrote: > Streams returned from methods of `java.nio.file.Files` should be closed. A typical documentation note reads as follows: > >> This method must be used within a try-with-resources statement or similar control structure to ensure that the stream's is closed promptly after the stream's operations have completed. > > In a few occasions, code was additionally lightly simplified: > > - LinkTask.java#L131 > - LinkTask.java#L179 > - VersionPlugin.java#L55-L60 This pull request has now been integrated. Changeset: b5f6e6dc Author: Pavel Rappo Committer: Erik Joelsson URL: https://git.openjdk.org/skara/commit/b5f6e6dc262ab11dfb34e9c51c4a623f191b9df4 Stats: 159 lines in 20 files changed: 26 ins; 7 del; 126 mod 2323: Use stream-bearing methods of java.nio.file.Files correctly Reviewed-by: erikj ------------- PR: https://git.openjdk.org/skara/pull/1675 From zsong at openjdk.org Thu Jul 11 16:07:00 2024 From: zsong at openjdk.org (Zhao Song) Date: Thu, 11 Jul 2024 16:07:00 GMT Subject: RFR: 2312: Do not require re-review for a simple merge [v6] In-Reply-To: References:

Message-ID: On Wed, 10 Jul 2024 23:08:02 GMT, Pavel Rappo wrote: >> If a repository is configured to ignore stale reviews, every commit to a PR made against that repo means that the PR needs to be re-reviewed. Re-reviewing is costly, and not all commits are worth that cost. >> >> One example of such a commit is a simple merge. During a PR's lifetime, the PR's target branch (typically, repo's `master`) might be merged into the PR multiple times. Usually, such merges are trivial and would effectively be performed by Skara automatically if the PR didn't have them in the first place [^*]. For such commits, it makes sense to not require review. >> >> This is my first contribution to Skara domain logic, which I've just started learning about. Also, while I tried to code this change according to Skara customs and idioms, I might have missed something. I guess what I'm saying is **take extra care** reviewing this PR. Thanks. >> >> >> [^*]: This is the main assumption of this PR. Any simple merges present in a PR change the end result of that PR insignificantly, if at all. > > Pavel Rappo has updated the pull request incrementally with four additional commits since the last revision: > > - Clean up > - Cache targetHash as suggested > - Cache Review coverage as suggested > - Make PullRequest a ctor parameter as suggested Looks good! ------------- Marked as reviewed by zsong (Reviewer). PR Review: https://git.openjdk.org/skara/pull/1672#pullrequestreview-2172379746 From duke at openjdk.org Thu Jul 11 16:13:36 2024 From: duke at openjdk.org (duke) Date: Thu, 11 Jul 2024 16:13:36 GMT Subject: RFR: 2312: Do not require re-review for a simple merge [v6] In-Reply-To: References:

Message-ID: <1zaFvEcH_qpi5TsNgO42ZnqKxzDpWNX5Era3-l2Nq_o=.5f668ca1-b319-4401-b771-146aba55c8b9@github.com> On Wed, 10 Jul 2024 23:08:02 GMT, Pavel Rappo wrote: >> If a repository is configured to ignore stale reviews, every commit to a PR made against that repo means that the PR needs to be re-reviewed. Re-reviewing is costly, and not all commits are worth that cost. >> >> One example of such a commit is a simple merge. During a PR's lifetime, the PR's target branch (typically, repo's `master`) might be merged into the PR multiple times. Usually, such merges are trivial and would effectively be performed by Skara automatically if the PR didn't have them in the first place [^*]. For such commits, it makes sense to not require review. >> >> This is my first contribution to Skara domain logic, which I've just started learning about. Also, while I tried to code this change according to Skara customs and idioms, I might have missed something. I guess what I'm saying is **take extra care** reviewing this PR. Thanks. >> >> >> [^*]: This is the main assumption of this PR. Any simple merges present in a PR change the end result of that PR insignificantly, if at all. > > Pavel Rappo has updated the pull request incrementally with four additional commits since the last revision: > > - Clean up > - Cache targetHash as suggested > - Cache Review coverage as suggested > - Make PullRequest a ctor parameter as suggested @pavelrappo Your change (at version 739c119120aac05ec3c2c0ea0f365988018aa02f) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/skara/pull/1672#issuecomment-2223340275 From prappo at openjdk.org Thu Jul 11 16:17:41 2024 From: prappo at openjdk.org (Pavel Rappo) Date: Thu, 11 Jul 2024 16:17:41 GMT Subject: Integrated: 2312: Do not require re-review for a simple merge In-Reply-To: References: Message-ID: On Mon, 8 Jul 2024 14:55:44 GMT, Pavel Rappo wrote: > If a repository is configured to ignore stale reviews, every commit to a PR made against that repo means that the PR needs to be re-reviewed. Re-reviewing is costly, and not all commits are worth that cost. > > One example of such a commit is a simple merge. During a PR's lifetime, the PR's target branch (typically, repo's `master`) might be merged into the PR multiple times. Usually, such merges are trivial and would effectively be performed by Skara automatically if the PR didn't have them in the first place [^*]. For such commits, it makes sense to not require review. > > This is my first contribution to Skara domain logic, which I've just started learning about. Also, while I tried to code this change according to Skara customs and idioms, I might have missed something. I guess what I'm saying is **take extra care** reviewing this PR. Thanks. > > > [^*]: This is the main assumption of this PR. Any simple merges present in a PR change the end result of that PR insignificantly, if at all. This pull request has now been integrated. Changeset: 45468cde Author: Pavel Rappo Committer: Zhao Song URL: https://git.openjdk.org/skara/commit/45468cde2dc5273c70f728c46c6b133e3d16b55a Stats: 510 lines in 17 files changed: 459 ins; 7 del; 44 mod 2312: Do not require re-review for a simple merge Reviewed-by: zsong, erikj ------------- PR: https://git.openjdk.org/skara/pull/1672 From zsong at openjdk.org Thu Jul 11 22:22:56 2024 From: zsong at openjdk.org (Zhao Song) Date: Thu, 11 Jul 2024 22:22:56 GMT Subject: RFR: 2326: Don't send the ready for sponsor comment to mailing list if the pr is closed Message-ID: After we deployed [SKARA-2302](https://bugs.openjdk.org/browse/SKARA-2302) and [SKARA-2322](https://bugs.openjdk.org/browse/SKARA-2322), some users complained about receiving numerous "ready for sponsor" emails from closed PRs. We should prevent the bot from retroactively sending out these emails. ------------- Commit messages: - SKARA-2236 Changes: https://git.openjdk.org/skara/pull/1676/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1676&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-2326 Stats: 10 lines in 1 file changed: 8 ins; 0 del; 2 mod Patch: https://git.openjdk.org/skara/pull/1676.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1676/head:pull/1676 PR: https://git.openjdk.org/skara/pull/1676 From prappo at openjdk.org Thu Jul 11 23:02:53 2024 From: prappo at openjdk.org (Pavel Rappo) Date: Thu, 11 Jul 2024 23:02:53 GMT Subject: RFR: 2327: Skip CheckTests.acceptSimpleMerges on older Git Message-ID: Please review this test fix. A recently added test fails in environments with Git versions older than 2.36. This is because the test verifies functionality that uses `--remerge-diff` added to [Git 2.36]( https://github.blog/2022-04-18-highlights-from-git-2-36/). Note that it's sufficient to conditionally skip the test. We don't need to amend the logic being tested, as bots are run on Git 2.36 or newer. The test assumes 2.36 as the minimum Git version. The test uses the existing functionality provided by `org.openjdk.skara.vcs.git.GitVersion`. Hope, that new dependency is okay. ------------- Commit messages: - Initial commit Changes: https://git.openjdk.org/skara/pull/1677/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1677&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-2327 Stats: 4 lines in 2 files changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.org/skara/pull/1677.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1677/head:pull/1677 PR: https://git.openjdk.org/skara/pull/1677 From zsong at openjdk.org Thu Jul 11 23:17:20 2024 From: zsong at openjdk.org (Zhao Song) Date: Thu, 11 Jul 2024 23:17:20 GMT Subject: RFR: 2327: Skip CheckTests.acceptSimpleMerges on older Git In-Reply-To: References: Message-ID: <9yvFdtOWKSzQ7aace2ijE4UYMYyJa34nV_SbaQQzf4s=.2653b568-faad-4907-9f0d-b48f3c4e3073@github.com> On Thu, 11 Jul 2024 23:00:05 GMT, Pavel Rappo wrote: > Please review this test fix. > > A recently added test fails in environments with Git versions older than 2.36. This is because the test verifies functionality that uses `--remerge-diff` added to [Git 2.36]( https://github.blog/2022-04-18-highlights-from-git-2-36/). > > Note that it's sufficient to conditionally skip the test. We don't need to amend the logic being tested, as bots are run on Git 2.36 or newer. The test assumes 2.36 as the minimum Git version. The test uses the existing functionality provided by `org.openjdk.skara.vcs.git.GitVersion`. Hope, that new dependency is okay. LGTM ------------- Marked as reviewed by zsong (Reviewer). PR Review: https://git.openjdk.org/skara/pull/1677#pullrequestreview-2173233826 From dholmes at openjdk.org Thu Jul 11 23:17:29 2024 From: dholmes at openjdk.org (David Holmes) Date: Thu, 11 Jul 2024 23:17:29 GMT Subject: RFR: 2326: Don't send the ready for sponsor comment to mailing list if the pr is closed In-Reply-To: References: Message-ID: On Thu, 11 Jul 2024 22:13:57 GMT, Zhao Song wrote: > After we deployed [SKARA-2302](https://bugs.openjdk.org/browse/SKARA-2302) and [SKARA-2322](https://bugs.openjdk.org/browse/SKARA-2322), some users complained about receiving numerous "ready for sponsor" emails from closed PRs. > We should prevent the bot from retroactively sending out these emails. bots/mlbridge/src/main/java/org/openjdk/skara/bots/mlbridge/ArchiveWorkItem.java line 156: > 154: if (bot.ignoredUsers().contains(author.username())) { > 155: if (pr.isOpen()) { > 156: return !PullRequestConstants.READY_FOR_SPONSOR_MARKER_PATTERN.matcher(body).find() && pr.isOpen(); You already know `pr.IsOpen()` is true here. ------------- PR Review Comment: https://git.openjdk.org/skara/pull/1676#discussion_r1674811729 From zsong at openjdk.org Thu Jul 11 23:54:35 2024 From: zsong at openjdk.org (Zhao Song) Date: Thu, 11 Jul 2024 23:54:35 GMT Subject: RFR: 2326: Don't send the ready for sponsor comment to mailing list if the pr is closed [v2] In-Reply-To: References: Message-ID: > After we deployed [SKARA-2302](https://bugs.openjdk.org/browse/SKARA-2302) and [SKARA-2322](https://bugs.openjdk.org/browse/SKARA-2322), some users complained about receiving numerous "ready for sponsor" emails from closed PRs. > We should prevent the bot from retroactively sending out these emails. Zhao Song has updated the pull request incrementally with one additional commit since the last revision: review comment ------------- Changes: - all: https://git.openjdk.org/skara/pull/1676/files - new: https://git.openjdk.org/skara/pull/1676/files/7cd0152d..7d8f4396 Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1676&range=01 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1676&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/skara/pull/1676.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1676/head:pull/1676 PR: https://git.openjdk.org/skara/pull/1676 From zsong at openjdk.org Thu Jul 11 23:54:35 2024 From: zsong at openjdk.org (Zhao Song) Date: Thu, 11 Jul 2024 23:54:35 GMT Subject: RFR: 2326: Don't send the ready for sponsor comment to mailing list if the pr is closed [v2] In-Reply-To: References:

Message-ID: <2o3D6Z8FqQ5y7X-NQO8UtUMVAa7YPW_-N-fnqyAqtVk=.418d741b-6b1d-4584-8456-70cfc3c24a3a@github.com> On Thu, 11 Jul 2024 23:15:23 GMT, David Holmes wrote: >> Zhao Song has updated the pull request incrementally with one additional commit since the last revision: >> >> review comment > > bots/mlbridge/src/main/java/org/openjdk/skara/bots/mlbridge/ArchiveWorkItem.java line 156: > >> 154: if (bot.ignoredUsers().contains(author.username())) { >> 155: if (pr.isOpen()) { >> 156: return !PullRequestConstants.READY_FOR_SPONSOR_MARKER_PATTERN.matcher(body).find() && pr.isOpen(); > > You already know `pr.IsOpen()` is true here. Oh right, thanks ------------- PR Review Comment: https://git.openjdk.org/skara/pull/1676#discussion_r1674829933 From erikj at openjdk.org Fri Jul 12 06:09:26 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 12 Jul 2024 06:09:26 GMT Subject: RFR: 2327: Skip CheckTests.acceptSimpleMerges on older Git In-Reply-To: References: Message-ID: On Thu, 11 Jul 2024 23:00:05 GMT, Pavel Rappo wrote: > Please review this test fix. > > A recently added test fails in environments with Git versions older than 2.36. This is because the test verifies functionality that uses `--remerge-diff` added to [Git 2.36]( https://github.blog/2022-04-18-highlights-from-git-2-36/). > > Note that it's sufficient to conditionally skip the test. We don't need to amend the logic being tested, as bots are run on Git 2.36 or newer. The test assumes 2.36 as the minimum Git version. The test uses the existing functionality provided by `org.openjdk.skara.vcs.git.GitVersion`. Hope, that new dependency is okay. Marked as reviewed by erikj (Lead). ------------- PR Review: https://git.openjdk.org/skara/pull/1677#pullrequestreview-2173947954 From erikj at openjdk.org Fri Jul 12 06:10:39 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 12 Jul 2024 06:10:39 GMT Subject: RFR: 2326: Don't send the ready for sponsor comment to mailing list if the pr is closed [v2] In-Reply-To: References:

Message-ID: On Thu, 11 Jul 2024 23:54:35 GMT, Zhao Song wrote: >> After we deployed [SKARA-2302](https://bugs.openjdk.org/browse/SKARA-2302) and [SKARA-2322](https://bugs.openjdk.org/browse/SKARA-2322), some users complained about receiving numerous "ready for sponsor" emails from closed PRs. >> We should prevent the bot from retroactively sending out these emails. > > Zhao Song has updated the pull request incrementally with one additional commit since the last revision: > > review comment Marked as reviewed by erikj (Lead). ------------- PR Review: https://git.openjdk.org/skara/pull/1676#pullrequestreview-2173949386 From duke at openjdk.org Fri Jul 12 08:39:12 2024 From: duke at openjdk.org (duke) Date: Fri, 12 Jul 2024 08:39:12 GMT Subject: RFR: 2327: Skip CheckTests.acceptSimpleMerges on older Git In-Reply-To: References: Message-ID: On Thu, 11 Jul 2024 23:00:05 GMT, Pavel Rappo wrote: > Please review this test fix. > > A recently added test fails in environments with Git versions older than 2.36. This is because the test verifies functionality that uses `--remerge-diff` added to [Git 2.36]( https://github.blog/2022-04-18-highlights-from-git-2-36/). > > Note that it's sufficient to conditionally skip the test. We don't need to amend the logic being tested, as bots are run on Git 2.36 or newer. The test assumes 2.36 as the minimum Git version. The test uses the existing functionality provided by `org.openjdk.skara.vcs.git.GitVersion`. Hope, that new dependency is okay. @pavelrappo Your change (at version b124332850ac259a067c45f8dbb925d0ca543583) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/skara/pull/1677#issuecomment-2225096721 From prappo at openjdk.org Fri Jul 12 09:00:54 2024 From: prappo at openjdk.org (Pavel Rappo) Date: Fri, 12 Jul 2024 09:00:54 GMT Subject: Integrated: 2327: Skip CheckTests.acceptSimpleMerges on older Git In-Reply-To: References: Message-ID: On Thu, 11 Jul 2024 23:00:05 GMT, Pavel Rappo