From ihse at openjdk.java.net Wed Mar 2 17:23:02 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Wed, 2 Mar 2022 17:23:02 GMT Subject: RFR: 1365: Draft PRs do not get extra time before auto closing Message-ID: The PullRequestPrunerBot automatically closes PRs that have been inactive for too long. The maxAge is configurable, and we have it set to 28 days for most repos on Github. [SKARA-831](https://bugs.openjdk.java.net/browse/SKARA-831) tried to give draft PRs double the time before being auto closed. Unfortunately, that fix wasn't enough, as it only affects the printed message and not the actual age check. I tried to add a unit test for this, but in the end I could find no reliable way to do this. I don't want to rely on timings. And the only other thing I could think of checking was the message printed -- but that was already "correct" so it would not verify this bug anyway. ------------- Commit messages: - 1365: Draft PRs do not get extra time before auto closing Changes: https://git.openjdk.java.net/skara/pull/1293/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1293&range=00 Issue: https://bugs.openjdk.java.net/browse/SKARA-1365 Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/skara/pull/1293.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1293/head:pull/1293 PR: https://git.openjdk.java.net/skara/pull/1293 From erikj at openjdk.java.net Wed Mar 2 17:53:37 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 2 Mar 2022 17:53:37 GMT Subject: RFR: 1365: Draft PRs do not get extra time before auto closing In-Reply-To: References: Message-ID: <0PUKG7kJDAG3H-YhXZ9Lk3f2yx1oWBrchxFSJ9W8ixE=.83dbdeff-f2b8-4ea9-b895-e50155e02846@github.com> On Wed, 2 Mar 2022 17:18:50 GMT, Magnus Ihse Bursie wrote: > The PullRequestPrunerBot automatically closes PRs that have been inactive for too long. The maxAge is configurable, and we have it set to 28 days for most repos on Github. [SKARA-831](https://bugs.openjdk.java.net/browse/SKARA-831) tried to give draft PRs double the time before being auto closed. Unfortunately, that fix wasn't enough, as it only affects the printed message and not the actual age check. > > I tried to add a unit test for this, but in the end I could find no reliable way to do this. I don't want to rely on timings. And the only other thing I could think of checking was the message printed -- but that was already "correct" so it would not verify this bug anyway. Looks good. If you really want to test this, you would have to modify the bot to use an explicit Clock object to get timestamps. Then the test can inject a different Clock implementation which can be made to output customized timestamps. I've done this before to test more complicated scheduling behavior in a different project, but I'm not sure it's worth it here. ------------- Marked as reviewed by erikj (Lead). PR: https://git.openjdk.java.net/skara/pull/1293 From ihse at openjdk.java.net Wed Mar 2 19:47:45 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Wed, 2 Mar 2022 19:47:45 GMT Subject: RFR: 1365: Draft PRs do not get extra time before auto closing In-Reply-To: References: Message-ID: On Wed, 2 Mar 2022 17:18:50 GMT, Magnus Ihse Bursie wrote: > The PullRequestPrunerBot automatically closes PRs that have been inactive for too long. The maxAge is configurable, and we have it set to 28 days for most repos on Github. [SKARA-831](https://bugs.openjdk.java.net/browse/SKARA-831) tried to give draft PRs double the time before being auto closed. Unfortunately, that fix wasn't enough, as it only affects the printed message and not the actual age check. > > I tried to add a unit test for this, but in the end I could find no reliable way to do this. I don't want to rely on timings. And the only other thing I could think of checking was the message printed -- but that was already "correct" so it would not verify this bug anyway. Nah. "Jag gitter inte", as the untranslatable Swedish expression goes. :) ------------- PR: https://git.openjdk.java.net/skara/pull/1293 From ihse at openjdk.java.net Wed Mar 2 19:47:45 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Wed, 2 Mar 2022 19:47:45 GMT Subject: Integrated: 1365: Draft PRs do not get extra time before auto closing In-Reply-To: References: Message-ID: On Wed, 2 Mar 2022 17:18:50 GMT, Magnus Ihse Bursie wrote: > The PullRequestPrunerBot automatically closes PRs that have been inactive for too long. The maxAge is configurable, and we have it set to 28 days for most repos on Github. [SKARA-831](https://bugs.openjdk.java.net/browse/SKARA-831) tried to give draft PRs double the time before being auto closed. Unfortunately, that fix wasn't enough, as it only affects the printed message and not the actual age check. > > I tried to add a unit test for this, but in the end I could find no reliable way to do this. I don't want to rely on timings. And the only other thing I could think of checking was the message printed -- but that was already "correct" so it would not verify this bug anyway. This pull request has now been integrated. Changeset: 518d71bc Author: Magnus Ihse Bursie URL: https://git.openjdk.java.net/skara/commit/518d71bc3911b19e0d4582c43775728de6199c03 Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod 1365: Draft PRs do not get extra time before auto closing Reviewed-by: erikj ------------- PR: https://git.openjdk.java.net/skara/pull/1293 From gli at openjdk.java.net Mon Mar 7 10:11:39 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Mon, 7 Mar 2022 10:11:39 GMT Subject: RFR: SKARA-1340: Correct email domain not always used when adding a contributor to a PR [v2] In-Reply-To: References: Message-ID: On Tue, 8 Feb 2022 14:20:14 GMT, Erik Joelsson wrote: > I don't know what the correct solution for this is without thoroughly investigating the known cases where the current behavior was wrong. Unfortunately those are Oracle internal cases, so I can't share any details. Could I get the result of the investigation? Without the result, I can't fix this issue. Or I should re-assign this issue to you? ------------- PR: https://git.openjdk.java.net/skara/pull/1281 From gli at openjdk.java.net Mon Mar 7 13:38:54 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Mon, 7 Mar 2022 13:38:54 GMT Subject: RFR: 1236: Add jcheck option to check for large binary files [v7] In-Reply-To: References: Message-ID: On Wed, 15 Dec 2021 12:47:50 GMT, Guoxiong Li wrote: >> Hi all, >> >> This patch adds the large binary file check to the jcheck. >> >> The corresponding configuration is like the following code. Each key/value in the `[checks "binary"]` is a mapper. The `key` means the file pattern and the `value` means the limited file size. For example, `.*\.bin=200B` means the file which ends with `.bin` should not exceed 200 Bytes. >> >> >> [checks] >> error = binary >> >> [checks "binary"] >> .*.bin=200B >> .*.o=1k >> >> >> The limited file size can use one of these several units: b(Byte), kb(KiloByte), mb(MegaByte), gb(GigaByte). The units is case insensitive, which means the `Kb`, `kB` and `KB` are equals to `kb(KiloByte)`. If the unit is not provided, it defauts to `b(Byte)`. And these is no a unit called `bit`. >> >> The corresponding test cases are added. >> >> Best Regards, >> -- Guoxiong > > Guoxiong Li 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 13 additional commits since the last revision: > > - Merge branch 'master' into SKARA-1236 > - Excluded copied and renamed files. > - Excluded renamed and copied files. Use Git commit information. > - Fix the output message. > - Check the renamed/modified binary file. > - Enable the binary check. > - Fix copyright. > - Polish > - Use simple config. Restore BinaryIssue. Only check the newly added or copied files. > - Merge branch 'master' into SKARA-1236 > - ... and 3 more: https://git.openjdk.java.net/skara/compare/01832458...3b4eb2c3 I would like to close this PR and let other developers, who are familiar with Git/Mercurial, solve this issue. ------------- PR: https://git.openjdk.java.net/skara/pull/1247 From lgxbslgx at gmail.com Mon Mar 7 14:08:16 2022 From: lgxbslgx at gmail.com (Guoxiong Li) Date: Mon, 7 Mar 2022 22:08:16 +0800 Subject: [Investigation] The design for SKARA-1096 about JEP check In-Reply-To: References: Message-ID: Hi all, > If in the future, if your suggestion for JBS improvements goes through, we can add auto discovery of JEPs. I agree with Erik now because skara can't always push the issue trackers or other systems to change. We should firstly meet the request from the developers by using the currently usable mechanism. So I propose the following design: 1. Use the command `/jep issue-number` and `/jep jep-nunber` to mark a PR as JEP PR (similar to command `/issue issue-number`) 2. Use the command `/jep unneeded` and `/jep uneeded` to restore the state (similar to command `/csr unneeded`) 3. Use a new bot to check the jep is targeted or not (similar to CSRBot) And some related items may be changed: 1. The jep link can be listed at the PR `Issues` (similar to the csr issue link) 2. A label named `jep` could be added to the PR(similar to the label `csr`) 3. An item about jep could be added to the `Progress`, such as `Change requires a JEP request to be targeted`. What do you think about it? Any ideas are appreciated. Best Regards, -- Guoxiong > From erikj at openjdk.java.net Mon Mar 7 14:52:26 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 7 Mar 2022 14:52:26 GMT Subject: RFR: SKARA-1340: Correct email domain not always used when adding a contributor to a PR [v2] In-Reply-To: References: Message-ID: <1xsA5FZ4H7otJ3By1n_q7fgqgHCIs7hKyZqI7JDdcRA=.7597e952-d1e9-4abb-92ab-413f01df0a9b@github.com> On Mon, 7 Mar 2022 10:08:59 GMT, Guoxiong Li wrote: > > I don't know what the correct solution for this is without thoroughly investigating the known cases where the current behavior was wrong. Unfortunately those are Oracle internal cases, so I can't share any details. > > Could I get the result of the investigation? Without the result, I can't fix this issue. Or I should re-assign this issue to you? I have no immediate plans to work on this issue. I understand that you don't have enough information to fix it, and I don't have the time to spend on investigating it. It's fine to leave the issue unassigned. ------------- PR: https://git.openjdk.java.net/skara/pull/1281 From erik.joelsson at oracle.com Mon Mar 7 18:37:55 2022 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Mon, 7 Mar 2022 10:37:55 -0800 Subject: [Investigation] The design for SKARA-1096 about JEP check In-Reply-To: References: Message-ID: On 2022-03-07 06:08, Guoxiong Li wrote: > Hi all, > >> If in the future, if your suggestion for JBS improvements goes through, > we can add auto discovery of JEPs. > > I agree with Erik now because skara can't always push the issue trackers or > other systems to change. > We should firstly meet the request from the developers by using the > currently usable mechanism. > > So I propose the following design: > > 1. Use the command `/jep issue-number` and `/jep jep-nunber` to mark a PR > as JEP PR (similar to command `/issue issue-number`) > 2. Use the command `/jep unneeded` and `/jep uneeded` to restore the state > (similar to command `/csr unneeded`) > 3. Use a new bot to check the jep is targeted or not (similar to CSRBot) > > And some related items may be changed: > 1. The jep link can be listed at the PR `Issues` (similar to the csr issue > link) > 2. A label named `jep` could be added to the PR(similar to the label `csr`) > 3. An item about jep could be added to the `Progress`, such as `Change > requires a JEP request to be targeted`. > > What do you think about it? Any ideas are appreciated. I think this looks reasonable. /Erik > Best Regards, > -- Guoxiong > From weijun at openjdk.java.net Mon Mar 14 19:34:04 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Mon, 14 Mar 2022 19:34:04 GMT Subject: RFR: 1372: Only add security label to jarsigner related files Message-ID: Currently, the core-libs and compiler labels are also set. They should be removed. ------------- Commit messages: - 1372: Only add security label to jarsigner related files Changes: https://git.openjdk.java.net/skara/pull/1294/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1294&range=00 Issue: https://bugs.openjdk.java.net/browse/SKARA-1372 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/skara/pull/1294.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1294/head:pull/1294 PR: https://git.openjdk.java.net/skara/pull/1294 From erikj at openjdk.java.net Mon Mar 14 20:04:19 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 14 Mar 2022 20:04:19 GMT Subject: RFR: 1372: Only add security label to jarsigner related files In-Reply-To: References: Message-ID: On Mon, 14 Mar 2022 19:29:40 GMT, Weijun Wang wrote: > Currently, the core-libs and compiler labels are also set. They should be removed. Marked as reviewed by erikj (Lead). ------------- PR: https://git.openjdk.java.net/skara/pull/1294 From weijun at openjdk.java.net Mon Mar 14 21:10:21 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Mon, 14 Mar 2022 21:10:21 GMT Subject: Integrated: 1372: Only add security label to jarsigner related files In-Reply-To: References: Message-ID: On Mon, 14 Mar 2022 19:29:40 GMT, Weijun Wang wrote: > Currently, the core-libs and compiler labels are also set. They should be removed. This pull request has now been integrated. Changeset: 631323a2 Author: Weijun Wang Committer: Erik Joelsson URL: https://git.openjdk.java.net/skara/commit/631323a25f383d2f0b227239a683423bc159f879 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod 1372: Only add security label to jarsigner related files Reviewed-by: erikj ------------- PR: https://git.openjdk.java.net/skara/pull/1294 From djelinski at openjdk.java.net Mon Mar 21 10:31:44 2022 From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Mon, 21 Mar 2022 10:31:44 GMT Subject: RFR: 1383: Add core-libs label to jdk.random files Message-ID: Currently no label is set on PRs touching jdk.random files. These PRs should be reviewed on core-libs mailing list. ------------- Commit messages: - Map jdk.random to core-libs Changes: https://git.openjdk.java.net/skara/pull/1295/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1295&range=00 Issue: https://bugs.openjdk.java.net/browse/SKARA-1383 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/skara/pull/1295.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1295/head:pull/1295 PR: https://git.openjdk.java.net/skara/pull/1295 From kcr at openjdk.java.net Mon Mar 21 12:22:52 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 21 Mar 2022 12:22:52 GMT Subject: RFR: 1383: Add core-libs label to jdk.random files In-Reply-To: References: Message-ID: On Mon, 21 Mar 2022 10:27:52 GMT, Daniel Jeli?ski wrote: > Currently no label is set on PRs touching jdk.random files. These PRs should be reviewed on core-libs mailing list. Looks good. ------------- Marked as reviewed by kcr (Reviewer). PR: https://git.openjdk.java.net/skara/pull/1295 From djelinski at openjdk.java.net Mon Mar 21 12:43:15 2022 From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Mon, 21 Mar 2022 12:43:15 GMT Subject: Integrated: 1383: Add core-libs label to jdk.random files In-Reply-To: References: Message-ID: On Mon, 21 Mar 2022 10:27:52 GMT, Daniel Jeli?ski wrote: > Currently no label is set on PRs touching jdk.random files. These PRs should be reviewed on core-libs mailing list. This pull request has now been integrated. Changeset: 52d88f37 Author: Daniel Jeli?ski Committer: Kevin Rushforth URL: https://git.openjdk.java.net/skara/commit/52d88f37c2e31cce09bfa6dae6452783fc432902 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 1383: Add core-libs label to jdk.random files Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/skara/pull/1295 From erikj at openjdk.java.net Mon Mar 28 20:45:20 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 28 Mar 2022 20:45:20 GMT Subject: RFR: 1288: Adjust the implementation of the 'reviewers' command to match the documentation In-Reply-To: References: Message-ID: On Wed, 15 Dec 2021 12:36:24 GMT, Guoxiong Li wrote: > Hi all, > > The `reviewers` command [documentation](https://wiki.openjdk.java.net/display/SKARA/Pull+Request+Commands#PullRequestCommands-/reviewers) states: > >> Description >> Require that at least N users with given role (defaults to Author) review the pull request before it can be integrated. The requirements are in addition to the ones specified by the .jcheck/conf file. > > But the implementation doesn't match the documentation now, especially the bug reported at [JDK-PULL-6752](https://github.com/openjdk/jdk/pull/6752) ([SKARA-1288](https://bugs.openjdk.java.net/browse/SKARA-1288) also recorded this bug). > > This patch fixes the bug and revises the code to match the documentation. > > The logic has small change(Please see the following code). In the past, the reviewer number of the role will be the sum of the `updatedLimits.get(r)` and `remainingAdditional`. But I don't know it meets our expectation. Because the higher roles can reduce the `remainingAdditional`, I think the remaining number should be only set to `updatedLimits` but not added to `updatedLimits`. This matches the documentation `Require that at least N users with given role (defaults to Author) review the pull request`, especially the key work `at least`. > > > - updatedLimits.replace(r, updatedLimits.get(r) + remainingAdditional); > + if (remainingAdditional > updatedLimits.get(r)) { > + // Set the number for the lower roles to remove. > + remainingRemovals = remainingAdditional - updatedLimits.get(r); > + // The new number of the reviewers should larger or equal than the requirement of the '.jcheck/conf' file. > + // Because the '.jcheck/conf' file means the minimal reviewer requirement. > + updatedLimits.replace(r, remainingAdditional); > + } > > > The other code changes are listed below: > - add negative number check. > - remove the updated limits check. Because it is not needed after adding the negative number check. > - adjust the reply message, always output the concrete reviewers. Because the merged logic of jcheck config and user `reviewers` command is a little hard, we should let the user know the result directly instead of guessing the result. > - `decrease lower roles` in the method `ReviewersTracker#updatedRoleLimits` doesn't work as expected. I fix it. > - add more test cases. > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong Just a few nits on language in replies and comments. Copyright years need to be updated. Otherwise this looks really good! bots/pr/src/main/java/org/openjdk/skara/bots/pr/ReviewersCommand.java line 136: > 134: var totalRequired = updatedLimits.values().stream().mapToInt(Integer::intValue).sum(); > 135: reply.print("The total number of required reviews for this PR, " + > 136: "which is combined by the configuration and the command, is now set to " + totalRequired); I would suggest: "The total number of required reviews for this PR (including the jcheck configuration and the last /reviewers command) is now set to" bots/pr/src/main/java/org/openjdk/skara/bots/pr/ReviewersTracker.java line 66: > 64: // Set the number for the lower roles to remove. > 65: remainingRemovals = remainingAdditional - updatedLimits.get(r); > 66: // The new number of the reviewers should larger or equal than the requirement of the '.jcheck/conf' file. I would suggest moving this comment to before line 63 and express it something like this: // The new value cannot the lower than the value in .jcheck/conf bots/pr/src/main/java/org/openjdk/skara/bots/pr/ReviewersTracker.java line 86: > 84: var removed = Math.max(0, originalVal - remainingRemovals); > 85: updatedLimits.replace(r, removed); > 86: remainingRemovals -= (originalVal - updatedLimits.get(r)); Maybe use the local variable `removed` instead of updatedLimits.get(r). I think that reads better. ------------- PR: https://git.openjdk.java.net/skara/pull/1262 From gli at openjdk.java.net Tue Mar 29 10:39:44 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Tue, 29 Mar 2022 10:39:44 GMT Subject: RFR: 1288: Adjust the implementation of the 'reviewers' command to match the documentation [v2] In-Reply-To: References: Message-ID: > Hi all, > > The `reviewers` command [documentation](https://wiki.openjdk.java.net/display/SKARA/Pull+Request+Commands#PullRequestCommands-/reviewers) states: > >> Description >> Require that at least N users with given role (defaults to Author) review the pull request before it can be integrated. The requirements are in addition to the ones specified by the .jcheck/conf file. > > But the implementation doesn't match the documentation now, especially the bug reported at [JDK-PULL-6752](https://github.com/openjdk/jdk/pull/6752) ([SKARA-1288](https://bugs.openjdk.java.net/browse/SKARA-1288) also recorded this bug). > > This patch fixes the bug and revises the code to match the documentation. > > The logic has small change(Please see the following code). In the past, the reviewer number of the role will be the sum of the `updatedLimits.get(r)` and `remainingAdditional`. But I don't know it meets our expectation. Because the higher roles can reduce the `remainingAdditional`, I think the remaining number should be only set to `updatedLimits` but not added to `updatedLimits`. This matches the documentation `Require that at least N users with given role (defaults to Author) review the pull request`, especially the key work `at least`. > > > - updatedLimits.replace(r, updatedLimits.get(r) + remainingAdditional); > + if (remainingAdditional > updatedLimits.get(r)) { > + // Set the number for the lower roles to remove. > + remainingRemovals = remainingAdditional - updatedLimits.get(r); > + // The new number of the reviewers should larger or equal than the requirement of the '.jcheck/conf' file. > + // Because the '.jcheck/conf' file means the minimal reviewer requirement. > + updatedLimits.replace(r, remainingAdditional); > + } > > > The other code changes are listed below: > - add negative number check. > - remove the updated limits check. Because it is not needed after adding the negative number check. > - adjust the reply message, always output the concrete reviewers. Because the merged logic of jcheck config and user `reviewers` command is a little hard, we should let the user know the result directly instead of guessing the result. > - `decrease lower roles` in the method `ReviewersTracker#updatedRoleLimits` doesn't work as expected. I fix it. > - add more test cases. > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: Fix comments, names and copyrights. ------------- Changes: - all: https://git.openjdk.java.net/skara/pull/1262/files - new: https://git.openjdk.java.net/skara/pull/1262/files/3880e32c..50e062f7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=skara&pr=1262&range=01 - incr: https://webrevs.openjdk.java.net/?repo=skara&pr=1262&range=00-01 Stats: 37 lines in 3 files changed: 5 ins; 14 del; 18 mod Patch: https://git.openjdk.java.net/skara/pull/1262.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1262/head:pull/1262 PR: https://git.openjdk.java.net/skara/pull/1262 From gli at openjdk.java.net Tue Mar 29 10:39:44 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Tue, 29 Mar 2022 10:39:44 GMT Subject: RFR: 1288: Adjust the implementation of the 'reviewers' command to match the documentation In-Reply-To: References: Message-ID: On Wed, 15 Dec 2021 22:09:19 GMT, Erik Joelsson wrote: >> Unless there is a corner case that I haven't hit, the implementation is working as expected now. I will need to look at your proposed change more closely, but I don't see the need to change the existing logic. >> >> What problem are you trying to solve? > >> Unless there is a corner case that I haven't hit, the implementation is working as expected now. I will need to look at your proposed change more closely, but I don't see the need to change the existing logic. >> >> What problem are you trying to solve? > > In the linked PR, they tried to run `/reviewers 2 reviewer`, which gave a very weird error. At least that part is completely wrong in the current implementation. There isn't really any test coverage for using the command with a role argument. As for the rest, I'm still investigating. > > The command as implemented does not do what the documentation at https://wiki.openjdk.java.net/display/SKARA/Pull+Request+Commands#PullRequestCommands-/reviewers says it's supposed to do, that I definitely agree on. I think one point of confusion is if multiple command invocations should be added together, or just override the previous one, and should the override apply globally or just to the specified role? > > Before we go any further with an implementation, I think we need to agree on what the desired behavior actually is. The bug comments seems like a good forum for suggesting and commenting on bot behavior. @erikj79 Thanks for the review. I updated the code just now. ------------- PR: https://git.openjdk.java.net/skara/pull/1262 From gli at openjdk.java.net Tue Mar 29 10:39:45 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Tue, 29 Mar 2022 10:39:45 GMT Subject: RFR: 1288: Adjust the implementation of the 'reviewers' command to match the documentation [v2] In-Reply-To: References: Message-ID: <6UKoGv3F-g8fbJmbMsUKY9AAuDBfLLsJx8g0gMez0Xg=.3d977453-c4bb-4944-bce1-cb76580c23f2@github.com> On Mon, 28 Mar 2022 20:32:52 GMT, Erik Joelsson wrote: >> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix comments, names and copyrights. > > bots/pr/src/main/java/org/openjdk/skara/bots/pr/ReviewersCommand.java line 136: > >> 134: var totalRequired = updatedLimits.values().stream().mapToInt(Integer::intValue).sum(); >> 135: reply.print("The total number of required reviews for this PR, " + >> 136: "which is combined by the configuration and the command, is now set to " + totalRequired); > > I would suggest: > > "The total number of required reviews for this PR (including the jcheck configuration and the last /reviewers command) is now set to" Fixed > bots/pr/src/main/java/org/openjdk/skara/bots/pr/ReviewersTracker.java line 66: > >> 64: // Set the number for the lower roles to remove. >> 65: remainingRemovals = remainingAdditional - updatedLimits.get(r); >> 66: // The new number of the reviewers should larger or equal than the requirement of the '.jcheck/conf' file. > > I would suggest moving this comment to before line 63 and express it something like this: > > // The new value cannot the lower than the value in .jcheck/conf Fixed > bots/pr/src/main/java/org/openjdk/skara/bots/pr/ReviewersTracker.java line 86: > >> 84: var removed = Math.max(0, originalVal - remainingRemovals); >> 85: updatedLimits.replace(r, removed); >> 86: remainingRemovals -= (originalVal - updatedLimits.get(r)); > > Maybe use the local variable `removed` instead of updatedLimits.get(r). I think that reads better. Fixed ------------- PR: https://git.openjdk.java.net/skara/pull/1262 From erikj at openjdk.java.net Tue Mar 29 13:04:16 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 29 Mar 2022 13:04:16 GMT Subject: RFR: 1288: Adjust the implementation of the 'reviewers' command to match the documentation [v2] In-Reply-To: References: Message-ID: On Tue, 29 Mar 2022 10:39:44 GMT, Guoxiong Li wrote: >> Hi all, >> >> The `reviewers` command [documentation](https://wiki.openjdk.java.net/display/SKARA/Pull+Request+Commands#PullRequestCommands-/reviewers) states: >> >>> Description >>> Require that at least N users with given role (defaults to Author) review the pull request before it can be integrated. The requirements are in addition to the ones specified by the .jcheck/conf file. >> >> But the implementation doesn't match the documentation now, especially the bug reported at [JDK-PULL-6752](https://github.com/openjdk/jdk/pull/6752) ([SKARA-1288](https://bugs.openjdk.java.net/browse/SKARA-1288) also recorded this bug). >> >> This patch fixes the bug and revises the code to match the documentation. >> >> The logic has small change(Please see the following code). In the past, the reviewer number of the role will be the sum of the `updatedLimits.get(r)` and `remainingAdditional`. But I don't know it meets our expectation. Because the higher roles can reduce the `remainingAdditional`, I think the remaining number should be only set to `updatedLimits` but not added to `updatedLimits`. This matches the documentation `Require that at least N users with given role (defaults to Author) review the pull request`, especially the key work `at least`. >> >> >> - updatedLimits.replace(r, updatedLimits.get(r) + remainingAdditional); >> + if (remainingAdditional > updatedLimits.get(r)) { >> + // Set the number for the lower roles to remove. >> + remainingRemovals = remainingAdditional - updatedLimits.get(r); >> + // The new number of the reviewers should larger or equal than the requirement of the '.jcheck/conf' file. >> + // Because the '.jcheck/conf' file means the minimal reviewer requirement. >> + updatedLimits.replace(r, remainingAdditional); >> + } >> >> >> The other code changes are listed below: >> - add negative number check. >> - remove the updated limits check. Because it is not needed after adding the negative number check. >> - adjust the reply message, always output the concrete reviewers. Because the merged logic of jcheck config and user `reviewers` command is a little hard, we should let the user know the result directly instead of guessing the result. >> - `decrease lower roles` in the method `ReviewersTracker#updatedRoleLimits` doesn't work as expected. I fix it. >> - add more test cases. >> >> Thanks for taking the time to review. >> >> Best Regards, >> -- Guoxiong > > Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: > > Fix comments, names and copyrights. Marked as reviewed by erikj (Lead). ------------- PR: https://git.openjdk.java.net/skara/pull/1262 From gli at openjdk.java.net Tue Mar 29 13:15:58 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Tue, 29 Mar 2022 13:15:58 GMT Subject: RFR: 1288: Adjust the implementation of the 'reviewers' command to match the documentation In-Reply-To: References: Message-ID: On Wed, 15 Dec 2021 22:09:19 GMT, Erik Joelsson wrote: >> Unless there is a corner case that I haven't hit, the implementation is working as expected now. I will need to look at your proposed change more closely, but I don't see the need to change the existing logic. >> >> What problem are you trying to solve? > >> Unless there is a corner case that I haven't hit, the implementation is working as expected now. I will need to look at your proposed change more closely, but I don't see the need to change the existing logic. >> >> What problem are you trying to solve? > > In the linked PR, they tried to run `/reviewers 2 reviewer`, which gave a very weird error. At least that part is completely wrong in the current implementation. There isn't really any test coverage for using the command with a role argument. As for the rest, I'm still investigating. > > The command as implemented does not do what the documentation at https://wiki.openjdk.java.net/display/SKARA/Pull+Request+Commands#PullRequestCommands-/reviewers says it's supposed to do, that I definitely agree on. I think one point of confusion is if multiple command invocations should be added together, or just override the previous one, and should the override apply globally or just to the specified role? > > Before we go any further with an implementation, I think we need to agree on what the desired behavior actually is. The bug comments seems like a good forum for suggesting and commenting on bot behavior. @erikj79 Could I get your help to sponsor this patch? Thanks a lot. ------------- PR: https://git.openjdk.java.net/skara/pull/1262 From gli at openjdk.java.net Tue Mar 29 13:30:31 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Tue, 29 Mar 2022 13:30:31 GMT Subject: Integrated: 1288: Adjust the implementation of the 'reviewers' command to match the documentation In-Reply-To: References: Message-ID: On Wed, 15 Dec 2021 12:36:24 GMT, Guoxiong Li wrote: > Hi all, > > The `reviewers` command [documentation](https://wiki.openjdk.java.net/display/SKARA/Pull+Request+Commands#PullRequestCommands-/reviewers) states: > >> Description >> Require that at least N users with given role (defaults to Author) review the pull request before it can be integrated. The requirements are in addition to the ones specified by the .jcheck/conf file. > > But the implementation doesn't match the documentation now, especially the bug reported at [JDK-PULL-6752](https://github.com/openjdk/jdk/pull/6752) ([SKARA-1288](https://bugs.openjdk.java.net/browse/SKARA-1288) also recorded this bug). > > This patch fixes the bug and revises the code to match the documentation. > > The logic has small change(Please see the following code). In the past, the reviewer number of the role will be the sum of the `updatedLimits.get(r)` and `remainingAdditional`. But I don't know it meets our expectation. Because the higher roles can reduce the `remainingAdditional`, I think the remaining number should be only set to `updatedLimits` but not added to `updatedLimits`. This matches the documentation `Require that at least N users with given role (defaults to Author) review the pull request`, especially the key work `at least`. > > > - updatedLimits.replace(r, updatedLimits.get(r) + remainingAdditional); > + if (remainingAdditional > updatedLimits.get(r)) { > + // Set the number for the lower roles to remove. > + remainingRemovals = remainingAdditional - updatedLimits.get(r); > + // The new number of the reviewers should larger or equal than the requirement of the '.jcheck/conf' file. > + // Because the '.jcheck/conf' file means the minimal reviewer requirement. > + updatedLimits.replace(r, remainingAdditional); > + } > > > The other code changes are listed below: > - add negative number check. > - remove the updated limits check. Because it is not needed after adding the negative number check. > - adjust the reply message, always output the concrete reviewers. Because the merged logic of jcheck config and user `reviewers` command is a little hard, we should let the user know the result directly instead of guessing the result. > - `decrease lower roles` in the method `ReviewersTracker#updatedRoleLimits` doesn't work as expected. I fix it. > - add more test cases. > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong This pull request has now been integrated. Changeset: 919cef49 Author: Guoxiong Li Committer: Erik Joelsson URL: https://git.openjdk.java.net/skara/commit/919cef4910c461a3eb60a97c05f8a6c43923141e Stats: 188 lines in 3 files changed: 161 ins; 8 del; 19 mod 1288: Adjust the implementation of the 'reviewers' command to match the documentation Reviewed-by: erikj ------------- PR: https://git.openjdk.java.net/skara/pull/1262