From christoph.langer at sap.com Fri Apr 1 05:40:19 2022 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 1 Apr 2022 05:40:19 +0000 Subject: Github PR emails from Skara bots stalled since yesterday Message-ID: Hi, I think as of some time yesterday the flow of mails from Github PRs to the OpenJDK mailing lists has stopped. Can you please check and fix this? Thanks Christoph From david.holmes at oracle.com Fri Apr 1 06:18:21 2022 From: david.holmes at oracle.com (David Holmes) Date: Fri, 1 Apr 2022 16:18:21 +1000 Subject: Github PR emails from Skara bots stalled since yesterday In-Reply-To: References: Message-ID: Hi Christoph, On 1/04/2022 3:40 pm, Langer, Christoph wrote: > Hi, > > I think as of some time yesterday the flow of mails from Github PRs to the OpenJDK mailing lists has stopped. Can you please check and fix this? We are aware and it is being looked into. Cheers, David > Thanks > Christoph > From rcastanedalo at openjdk.java.net Mon Apr 4 12:28:36 2022 From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano) Date: Mon, 4 Apr 2022 12:28:36 GMT Subject: RFR: 1390: Do not automatically assign the 'build' label to pull requests for IdealGraphVisualizer and LogCompilation Message-ID: This change removes the mapping of `src/utils/IdealGraphVisualizer` and `src/utils/LogCompilation` to the `build` label to avoid sending irrelevant review emails to the `build-dev` mailing list. These tools are maintained by HotSpot compiler developers and already mapped to the `hotspot-compiler` label. ------------- Commit messages: - Map only the 'hsdis' and 'src' subdirectories of 'src/utils/' to 'build' Changes: https://git.openjdk.java.net/skara/pull/1296/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1296&range=00 Issue: https://bugs.openjdk.java.net/browse/SKARA-1390 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/skara/pull/1296.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1296/head:pull/1296 PR: https://git.openjdk.java.net/skara/pull/1296 From ihse at openjdk.java.net Mon Apr 4 12:31:56 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Mon, 4 Apr 2022 12:31:56 GMT Subject: RFR: 1390: Do not automatically assign the 'build' label to pull requests for IdealGraphVisualizer and LogCompilation In-Reply-To: References: Message-ID: On Mon, 4 Apr 2022 12:24:04 GMT, Roberto Casta?eda Lozano wrote: > This change removes the mapping of `src/utils/IdealGraphVisualizer` and `src/utils/LogCompilation` to the `build` label to avoid sending irrelevant review emails to the `build-dev` mailing list. These tools are maintained by HotSpot compiler developers and already mapped to the `hotspot-compiler` label. Marked as reviewed by ihse (Reviewer). ------------- PR: https://git.openjdk.java.net/skara/pull/1296 From rcastanedalo at openjdk.java.net Mon Apr 4 12:53:31 2022 From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano) Date: Mon, 4 Apr 2022 12:53:31 GMT Subject: RFR: 1390: Do not automatically assign the 'build' label to pull requests for IdealGraphVisualizer and LogCompilation In-Reply-To: References: Message-ID: On Mon, 4 Apr 2022 12:24:04 GMT, Roberto Casta?eda Lozano wrote: > This change removes the mapping of `src/utils/IdealGraphVisualizer` and `src/utils/LogCompilation` to the `build` label to avoid sending irrelevant review emails to the `build-dev` mailing list. These tools are maintained by HotSpot compiler developers and already mapped to the `hotspot-compiler` label. Thanks for reviewing, Magnus! ------------- PR: https://git.openjdk.java.net/skara/pull/1296 From erikj at openjdk.java.net Mon Apr 4 13:08:29 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 4 Apr 2022 13:08:29 GMT Subject: RFR: 1390: Do not automatically assign the 'build' label to pull requests for IdealGraphVisualizer and LogCompilation In-Reply-To: References: Message-ID: <5AH_9lldaBjBpU1_HeAvNzRWvsJ9_veAYW6XmYb9H7g=.32a02d55-527b-4dc5-8f1c-4f2a737483ec@github.com> On Mon, 4 Apr 2022 12:24:04 GMT, Roberto Casta?eda Lozano wrote: > This change removes the mapping of `src/utils/IdealGraphVisualizer` and `src/utils/LogCompilation` to the `build` label to avoid sending irrelevant review emails to the `build-dev` mailing list. These tools are maintained by HotSpot compiler developers and already mapped to the `hotspot-compiler` label. Marked as reviewed by erikj (Lead). ------------- PR: https://git.openjdk.java.net/skara/pull/1296 From rcastanedalo at openjdk.java.net Mon Apr 4 13:21:08 2022 From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano) Date: Mon, 4 Apr 2022 13:21:08 GMT Subject: RFR: 1390: Do not automatically assign the 'build' label to pull requests for IdealGraphVisualizer and LogCompilation In-Reply-To: References: Message-ID: On Mon, 4 Apr 2022 12:24:04 GMT, Roberto Casta?eda Lozano wrote: > This change removes the mapping of `src/utils/IdealGraphVisualizer` and `src/utils/LogCompilation` to the `build` label to avoid sending irrelevant review emails to the `build-dev` mailing list. These tools are maintained by HotSpot compiler developers and already mapped to the `hotspot-compiler` label. Thanks, Erik! ------------- PR: https://git.openjdk.java.net/skara/pull/1296 From ihse at openjdk.java.net Mon Apr 4 21:01:47 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Mon, 4 Apr 2022 21:01:47 GMT Subject: RFR: 1390: Do not automatically assign the 'build' label to pull requests for IdealGraphVisualizer and LogCompilation In-Reply-To: References: Message-ID: On Mon, 4 Apr 2022 13:18:28 GMT, Roberto Casta?eda Lozano wrote: >> This change removes the mapping of `src/utils/IdealGraphVisualizer` and `src/utils/LogCompilation` to the `build` label to avoid sending irrelevant review emails to the `build-dev` mailing list. These tools are maintained by HotSpot compiler developers and already mapped to the `hotspot-compiler` label. > > Thanks, Erik! @robcasloz You need to "/integrate" so we can "/sponsor". ------------- PR: https://git.openjdk.java.net/skara/pull/1296 From christoph.langer at sap.com Tue Apr 5 12:05:56 2022 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 5 Apr 2022 12:05:56 +0000 Subject: Github PR emails from Skara bots stalled since yesterday In-Reply-To: References: Message-ID: Hi, any updates on the mailinglist issue? Thanks Christoph > -----Original Message----- > From: David Holmes > Sent: Freitag, 1. April 2022 08:18 > To: Langer, Christoph ; skara- > dev at openjdk.java.net; ops at openjdk.java.net > Cc: jdk-dev at openjdk.java.net > Subject: Re: Github PR emails from Skara bots stalled since yesterday > > Hi Christoph, > > On 1/04/2022 3:40 pm, Langer, Christoph wrote: > > Hi, > > > > I think as of some time yesterday the flow of mails from Github PRs to the > OpenJDK mailing lists has stopped. Can you please check and fix this? > > We are aware and it is being looked into. > > Cheers, > David > > > Thanks > > Christoph > > From rcastanedalo at openjdk.java.net Tue Apr 5 18:15:54 2022 From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano) Date: Tue, 5 Apr 2022 18:15:54 GMT Subject: RFR: 1390: Do not automatically assign the 'build' label to pull requests for IdealGraphVisualizer and LogCompilation In-Reply-To: References: Message-ID: On Mon, 4 Apr 2022 13:18:28 GMT, Roberto Casta?eda Lozano wrote: >> This change removes the mapping of `src/utils/IdealGraphVisualizer` and `src/utils/LogCompilation` to the `build` label to avoid sending irrelevant review emails to the `build-dev` mailing list. These tools are maintained by HotSpot compiler developers and already mapped to the `hotspot-compiler` label. > > Thanks, Erik! > @robcasloz You need to "/integrate" so we can "/sponsor". Thanks for the reminder, I was just waiting a bit in case anyone else had comments on the changes. ------------- PR: https://git.openjdk.java.net/skara/pull/1296 From rcastanedalo at openjdk.java.net Tue Apr 5 18:32:49 2022 From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano) Date: Tue, 5 Apr 2022 18:32:49 GMT Subject: Integrated: 1390: Do not automatically assign the 'build' label to pull requests for IdealGraphVisualizer and LogCompilation In-Reply-To: References: Message-ID: <-9CS8WBkQEG5FZ4Un3ReDNjn2YwrBvnGqHNlrZGAEeI=.0276f5b0-7116-44ad-8909-0263bc185b9a@github.com> On Mon, 4 Apr 2022 12:24:04 GMT, Roberto Casta?eda Lozano wrote: > This change removes the mapping of `src/utils/IdealGraphVisualizer` and `src/utils/LogCompilation` to the `build` label to avoid sending irrelevant review emails to the `build-dev` mailing list. These tools are maintained by HotSpot compiler developers and already mapped to the `hotspot-compiler` label. This pull request has now been integrated. Changeset: 4183bde9 Author: Roberto Casta?eda Lozano Committer: Erik Joelsson URL: https://git.openjdk.java.net/skara/commit/4183bde9e8fc58eb6962d4e48ec8f2f86dcc3565 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod 1390: Do not automatically assign the 'build' label to pull requests for IdealGraphVisualizer and LogCompilation Reviewed-by: ihse, erikj ------------- PR: https://git.openjdk.java.net/skara/pull/1296 From gli at openjdk.java.net Fri Apr 8 09:48:14 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Fri, 8 Apr 2022 09:48:14 GMT Subject: RFR: SKARA-1096: New command and label for JEPs, similar to CSR Message-ID: <0-E7MblNqSvFkCZ6IEkmU1oEoWvphBbIZoVMFLRlPto=.a160de74-142c-466a-87fd-cbe76306bee8@github.com> Hi all, This patch implements the features about the `/jep` command and JEP bot. The detailed designs and discussions are listed at [1][2]. Thanks for taking the time to review. Best Regards, -- Guoxiong [1] https://mail.openjdk.java.net/pipermail/skara-dev/2021-December/005481.html [2] https://mail.openjdk.java.net/pipermail/skara-dev/2022-March/005770.html ------------- Commit messages: - Remove whitespace. - SKARA-1096: New command and label for JEPs, similar to CSR Changes: https://git.openjdk.java.net/skara/pull/1297/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1297&range=00 Issue: https://bugs.openjdk.java.net/browse/SKARA-1096 Stats: 1326 lines in 19 files changed: 1306 ins; 0 del; 20 mod Patch: https://git.openjdk.java.net/skara/pull/1297.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1297/head:pull/1297 PR: https://git.openjdk.java.net/skara/pull/1297 From erikj at openjdk.java.net Fri Apr 8 18:53:19 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 8 Apr 2022 18:53:19 GMT Subject: RFR: SKARA-1096: New command and label for JEPs, similar to CSR In-Reply-To: <0-E7MblNqSvFkCZ6IEkmU1oEoWvphBbIZoVMFLRlPto=.a160de74-142c-466a-87fd-cbe76306bee8@github.com> References: <0-E7MblNqSvFkCZ6IEkmU1oEoWvphBbIZoVMFLRlPto=.a160de74-142c-466a-87fd-cbe76306bee8@github.com> Message-ID: <8mdIeqJiFU0Bemzc0ousCH7PZZlsQz82WrLxvEn4w68=.7d1f9816-05cb-4958-9898-b12f151de0be@github.com> On Thu, 7 Apr 2022 18:18:34 GMT, Guoxiong Li wrote: > Hi all, > > This patch implements the features about the `/jep` command and JEP bot. The detailed designs and discussions are listed at [1][2]. > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong > > [1] https://mail.openjdk.java.net/pipermail/skara-dev/2021-December/005481.html > [2] https://mail.openjdk.java.net/pipermail/skara-dev/2022-March/005770.html I have looked over the design and the product code and left some comments. I have not yet looked at the tests. bots/jep/src/main/java/org/openjdk/skara/bots/jep/JEPBot.java line 52: > 50: @Override > 51: public boolean concurrentWith(WorkItem other) { > 52: if (!(other instanceof JEPBot otherBot)) Please don't omit bracers around conditional blocks. bots/notify/src/test/java/org/openjdk/skara/bots/notify/issue/IssueNotifierTests.java line 50: > 48: > 49: public class IssueNotifierTests { > 50: private static final String JEP_NUMBER = "customfield_10701"; You should be able to import this from JiraProject instead of duplicating the definition. bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckRun.java line 158: > 156: > 157: private Optional getJepIssue() { > 158: var issueOpt = getJepIssueFromIssueTracker(); Do we really need to get the issue from the issue tracker at this point? For other issues, CheckRun just gets the ID and description from the encoded marker pattern. See SolvesTracker.java. bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckRun.java line 278: > 276: "Completed".equals(issueStatus) || ("Closed".equals(issueStatus) && "Delivered".equals(resolutionName))) { > 277: ret.put("Change requires a JEP request to be targeted", true); > 278: } We shouldn't need to repeat the work of the JEPBot here. We should just need to check if there is a comment matching the jepPattern and it's not saying unneeded. bots/pr/src/main/java/org/openjdk/skara/bots/pr/JEPCommand.java line 50: > 48: * `/jep JEP-` > 49: * `/jep jep-` > 50: * `/jep [unneeded|uneeded]` The command should accept the alternate spelling 'uneeded' but we should not list it in the help text. bots/pr/src/main/java/org/openjdk/skara/bots/pr/JEPCommand.java line 99: > 97: reply.println("only [Reviewers](https://openjdk.java.net/bylaws#reviewer) can determine that a JEP request is not needed."); > 98: return; > 99: } I don't think I agree with this check. If the author is able to link the PR to a JEP, then the author should be able to correct a mistakenly linked JEP. bots/pr/src/main/java/org/openjdk/skara/bots/pr/JEPCommand.java line 156: > 154: @Override > 155: public String description() { > 156: return "require a JDK enhancement proposal for this pull request"; Suggestion: return "require a JDK Enhancement Proposal for this pull request"; bots/pr/src/test/java/org/openjdk/skara/bots/pr/CheckTests.java line 44: > 42: > 43: class CheckTests { > 44: private static final String JEP_NUMBER = "customfield_10701"; It should be possible to import this from JiraProject as well. issuetracker/src/main/java/org/openjdk/skara/issuetracker/jira/JiraProject.java line 438: > 436: > 437: @Override > 438: public Optional jepIssue(String jepId) { Have you verified that this works? ------------- PR: https://git.openjdk.java.net/skara/pull/1297 From gli at openjdk.java.net Sat Apr 9 06:46:37 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Sat, 9 Apr 2022 06:46:37 GMT Subject: RFR: SKARA-1096: New command and label for JEPs, similar to CSR [v2] In-Reply-To: <0-E7MblNqSvFkCZ6IEkmU1oEoWvphBbIZoVMFLRlPto=.a160de74-142c-466a-87fd-cbe76306bee8@github.com> References: <0-E7MblNqSvFkCZ6IEkmU1oEoWvphBbIZoVMFLRlPto=.a160de74-142c-466a-87fd-cbe76306bee8@github.com> Message-ID: <0I8bvpKUbIug1uIZxCji_r4Vu81mdS1JFFlDSnO3SIE=.3017149d-fe3e-49b4-afb2-893403a10995@github.com> > Hi all, > > This patch implements the features about the `/jep` command and JEP bot. The detailed designs and discussions are listed at [1][2]. > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong > > [1] https://mail.openjdk.java.net/pipermail/skara-dev/2021-December/005481.html > [2] https://mail.openjdk.java.net/pipermail/skara-dev/2022-March/005770.html Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: Fixes code according to the PR comments. ------------- Changes: - all: https://git.openjdk.java.net/skara/pull/1297/files - new: https://git.openjdk.java.net/skara/pull/1297/files/a2ddc8eb..72d2a46c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=skara&pr=1297&range=01 - incr: https://webrevs.openjdk.java.net/?repo=skara&pr=1297&range=00-01 Stats: 50 lines in 5 files changed: 7 ins; 26 del; 17 mod Patch: https://git.openjdk.java.net/skara/pull/1297.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1297/head:pull/1297 PR: https://git.openjdk.java.net/skara/pull/1297 From gli at openjdk.java.net Sat Apr 9 06:46:41 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Sat, 9 Apr 2022 06:46:41 GMT Subject: RFR: SKARA-1096: New command and label for JEPs, similar to CSR [v2] In-Reply-To: <8mdIeqJiFU0Bemzc0ousCH7PZZlsQz82WrLxvEn4w68=.7d1f9816-05cb-4958-9898-b12f151de0be@github.com> References: <0-E7MblNqSvFkCZ6IEkmU1oEoWvphBbIZoVMFLRlPto=.a160de74-142c-466a-87fd-cbe76306bee8@github.com> <8mdIeqJiFU0Bemzc0ousCH7PZZlsQz82WrLxvEn4w68=.7d1f9816-05cb-4958-9898-b12f151de0be@github.com> Message-ID: On Fri, 8 Apr 2022 17:52:10 GMT, Erik Joelsson wrote: >> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixes code according to the PR comments. > > bots/jep/src/main/java/org/openjdk/skara/bots/jep/JEPBot.java line 52: > >> 50: @Override >> 51: public boolean concurrentWith(WorkItem other) { >> 52: if (!(other instanceof JEPBot otherBot)) > > Please don't omit bracers around conditional blocks. Fixed. > bots/notify/src/test/java/org/openjdk/skara/bots/notify/issue/IssueNotifierTests.java line 50: > >> 48: >> 49: public class IssueNotifierTests { >> 50: private static final String JEP_NUMBER = "customfield_10701"; > > You should be able to import this from JiraProject instead of duplicating the definition. Fixed. > bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckRun.java line 158: > >> 156: >> 157: private Optional getJepIssue() { >> 158: var issueOpt = getJepIssueFromIssueTracker(); > > Do we really need to get the issue from the issue tracker at this point? For other issues, CheckRun just gets the ID and description from the encoded marker pattern. See SolvesTracker.java. Fixed. > bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckRun.java line 278: > >> 276: "Completed".equals(issueStatus) || ("Closed".equals(issueStatus) && "Delivered".equals(resolutionName))) { >> 277: ret.put("Change requires a JEP request to be targeted", true); >> 278: } > > We shouldn't need to repeat the work of the JEPBot here. We should just need to check if there is a comment matching the jepPattern and it's not saying unneeded. Fixed. > bots/pr/src/main/java/org/openjdk/skara/bots/pr/JEPCommand.java line 50: > >> 48: * `/jep JEP-` >> 49: * `/jep jep-` >> 50: * `/jep [unneeded|uneeded]` > > The command should accept the alternate spelling 'uneeded' but we should not list it in the help text. Fixed. > bots/pr/src/main/java/org/openjdk/skara/bots/pr/JEPCommand.java line 99: > >> 97: reply.println("only [Reviewers](https://openjdk.java.net/bylaws#reviewer) can determine that a JEP request is not needed."); >> 98: return; >> 99: } > > I don't think I agree with this check. If the author is able to link the PR to a JEP, then the author should be able to correct a mistakenly linked JEP. The author can use the `/jep |` again if the author linked the wrong JEP. This check follows the convention of the `csr` command. It can protect the situation that the author uses the command `/jep unneeded` and integrates the patch unexpectly. Actually, the `/jep unneeded` command is rarely used and the author can request the reviewers to do that if the patch really don't need a JEP to be targeted. Preventing the unexpected (and maybe wrong) code from integrating should be the most important thing we need to ensure even though it has not happened in the past. > bots/pr/src/main/java/org/openjdk/skara/bots/pr/JEPCommand.java line 156: > >> 154: @Override >> 155: public String description() { >> 156: return "require a JDK enhancement proposal for this pull request"; > > Suggestion: > > return "require a JDK Enhancement Proposal for this pull request"; Fixed. > bots/pr/src/test/java/org/openjdk/skara/bots/pr/CheckTests.java line 44: > >> 42: >> 43: class CheckTests { >> 44: private static final String JEP_NUMBER = "customfield_10701"; > > It should be possible to import this from JiraProject as well. Fixed. > issuetracker/src/main/java/org/openjdk/skara/issuetracker/jira/JiraProject.java line 438: > >> 436: >> 437: @Override >> 438: public Optional jepIssue(String jepId) { > > Have you verified that this works? Not, I have not. When I request the link `https://bugs.openjdk.java.net/rest/api/2/search?jql=project = JDK AND customfield_10701 = 11` locally, it reports `{"errorMessages":["Field 'customfield_10701' does not exist or you do not have permission to view it."],"errors":{}}`. But when I request the link `https://bugs.openjdk.java.net/rest/api/2/search?jql=project = JDK AND type = JEP`, it returns the correct data. It seems that my account don't have permission to search the field `customfield_10701`. Could I get your help to verify it? ------------- PR: https://git.openjdk.java.net/skara/pull/1297 From erikj at openjdk.java.net Mon Apr 11 13:30:24 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 11 Apr 2022 13:30:24 GMT Subject: RFR: SKARA-1096: New command and label for JEPs, similar to CSR [v2] In-Reply-To: References: <0-E7MblNqSvFkCZ6IEkmU1oEoWvphBbIZoVMFLRlPto=.a160de74-142c-466a-87fd-cbe76306bee8@github.com> <8mdIeqJiFU0Bemzc0ousCH7PZZlsQz82WrLxvEn4w68=.7d1f9816-05cb-4958-9898-b12f151de0be@github.com> Message-ID: On Sat, 9 Apr 2022 06:43:11 GMT, Guoxiong Li wrote: >> bots/pr/src/main/java/org/openjdk/skara/bots/pr/JEPCommand.java line 99: >> >>> 97: reply.println("only [Reviewers](https://openjdk.java.net/bylaws#reviewer) can determine that a JEP request is not needed."); >>> 98: return; >>> 99: } >> >> I don't think I agree with this check. If the author is able to link the PR to a JEP, then the author should be able to correct a mistakenly linked JEP. > > The author can use the `/jep |` again if the author linked the wrong JEP. This check follows the convention of the `csr` command. It can protect the situation that the author uses the command `/jep unneeded` and integrates the patch unexpectly. > > Actually, the `/jep unneeded` command is rarely used and the author can request the reviewers to do that if the patch really don't need a JEP to be targeted. Preventing the unexpected (and maybe wrong) code from integrating should be the most important thing we need to ensure even though it has not happened in the past. I understand that this is how it would work with the current logic, and I don't agree with it. Declaring the need for a JEP and a CSR are different, so they do not need to follow the same model (though I'm not sure I agree with the limitation on `/csr unneeded` either). In order for a committer to mishandle this, they would have to actively issue `/jep unneeded` and then integrate. I think it's unlikely to happen by mistake, and mistakes are what this feature intends to protect against. We already trust committers to handle `/integrate` on their own, this isn't about protecting against malicious committers. ------------- PR: https://git.openjdk.java.net/skara/pull/1297 From erikj at openjdk.java.net Mon Apr 11 13:40:18 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 11 Apr 2022 13:40:18 GMT Subject: RFR: SKARA-1096: New command and label for JEPs, similar to CSR [v2] In-Reply-To: References: <0-E7MblNqSvFkCZ6IEkmU1oEoWvphBbIZoVMFLRlPto=.a160de74-142c-466a-87fd-cbe76306bee8@github.com> <8mdIeqJiFU0Bemzc0ousCH7PZZlsQz82WrLxvEn4w68=.7d1f9816-05cb-4958-9898-b12f151de0be@github.com> Message-ID: On Sat, 9 Apr 2022 06:43:08 GMT, Guoxiong Li wrote: >> issuetracker/src/main/java/org/openjdk/skara/issuetracker/jira/JiraProject.java line 438: >> >>> 436: >>> 437: @Override >>> 438: public Optional jepIssue(String jepId) { >> >> Have you verified that this works? > > Not, I have not. > > When I request the link `https://bugs.openjdk.java.net/rest/api/2/search?jql=project = JDK AND customfield_10701 = 11` locally, it reports `{"errorMessages":["Field 'customfield_10701' does not exist or you do not have permission to view it."],"errors":{}}`. > > But when I request the link `https://bugs.openjdk.java.net/rest/api/2/search?jql=project = JDK AND type = JEP`, it returns the correct data. > > It seems that my account don't have permission to search the field `customfield_10701`. Could I get your help to verify it? Where did you find the name of the field? ------------- PR: https://git.openjdk.java.net/skara/pull/1297 From gli at openjdk.java.net Mon Apr 11 13:54:19 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Mon, 11 Apr 2022 13:54:19 GMT Subject: RFR: SKARA-1096: New command and label for JEPs, similar to CSR [v2] In-Reply-To: References: <0-E7MblNqSvFkCZ6IEkmU1oEoWvphBbIZoVMFLRlPto=.a160de74-142c-466a-87fd-cbe76306bee8@github.com> <8mdIeqJiFU0Bemzc0ousCH7PZZlsQz82WrLxvEn4w68=.7d1f9816-05cb-4958-9898-b12f151de0be@github.com> Message-ID: <_lDdboPolyRlt_Jn-JpueH7jRa8BzXZG1ozB5uFLDCE=.825121f3-ef8e-4355-b8c0-233c2d066a2c@github.com> On Mon, 11 Apr 2022 13:27:01 GMT, Erik Joelsson wrote: > We already trust committers to handle /integrate on their own, this isn't about protecting against malicious committers. I agree with you now and I will fix it later. >> Not, I have not. >> >> When I request the link `https://bugs.openjdk.java.net/rest/api/2/search?jql=project = JDK AND customfield_10701 = 11` locally, it reports `{"errorMessages":["Field 'customfield_10701' does not exist or you do not have permission to view it."],"errors":{}}`. >> >> But when I request the link `https://bugs.openjdk.java.net/rest/api/2/search?jql=project = JDK AND type = JEP`, it returns the correct data. >> >> It seems that my account don't have permission to search the field `customfield_10701`. Could I get your help to verify it? > > Where did you find the name of the field? I opened a JEP issue in the browser and then pressed `F12` to get the HTML info which contains the field name. ------------- PR: https://git.openjdk.java.net/skara/pull/1297 From gli at openjdk.java.net Mon Apr 11 13:54:19 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Mon, 11 Apr 2022 13:54:19 GMT Subject: RFR: SKARA-1096: New command and label for JEPs, similar to CSR [v2] In-Reply-To: <_lDdboPolyRlt_Jn-JpueH7jRa8BzXZG1ozB5uFLDCE=.825121f3-ef8e-4355-b8c0-233c2d066a2c@github.com> References: <0-E7MblNqSvFkCZ6IEkmU1oEoWvphBbIZoVMFLRlPto=.a160de74-142c-466a-87fd-cbe76306bee8@github.com> <8mdIeqJiFU0Bemzc0ousCH7PZZlsQz82WrLxvEn4w68=.7d1f9816-05cb-4958-9898-b12f151de0be@github.com> <_lDdboPolyRlt_Jn-JpueH7jRa8BzXZG1ozB5uFLDCE=.825121f3-ef8e-4355-b8c0-233c2d066a2c@github.com> Message-ID: On Mon, 11 Apr 2022 13:47:08 GMT, Guoxiong Li wrote: >> Where did you find the name of the field? > > I opened a JEP issue in the browser and then pressed `F12` to get the HTML info which contains the field name. The link `https://bugs.openjdk.java.net/rest/api/2/search?jql=project = JDK AND type = JEP` also returns this field. Such as `"customfield_10701":"419"`. ------------- PR: https://git.openjdk.java.net/skara/pull/1297 From erikj at openjdk.java.net Mon Apr 11 14:02:23 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 11 Apr 2022 14:02:23 GMT Subject: RFR: SKARA-1096: New command and label for JEPs, similar to CSR [v2] In-Reply-To: References: <0-E7MblNqSvFkCZ6IEkmU1oEoWvphBbIZoVMFLRlPto=.a160de74-142c-466a-87fd-cbe76306bee8@github.com> <8mdIeqJiFU0Bemzc0ousCH7PZZlsQz82WrLxvEn4w68=.7d1f9816-05cb-4958-9898-b12f151de0be@github.com> <_lDdboPolyRlt_Jn-JpueH7jRa8BzXZG1ozB5uFLDCE=.825121f3-ef8e-4355-b8c0-233c2d066a2c@github.com> Message-ID: <6u3Ggq5-WyiLAAUrj3v20bk_9CrCV-VudJNtJC2dc6c=.6106a08c-8f90-4184-9886-01fb4e3af763@github.com> On Mon, 11 Apr 2022 13:49:41 GMT, Guoxiong Li wrote: >> I opened a JEP issue in the browser and then pressed `F12` to get the HTML info which contains the field name. > > The link `https://bugs.openjdk.java.net/rest/api/2/search?jql=project = JDK AND type = JEP` also returns this field. Such as `"customfield_10701":"419"`. Ok, I see the field name. I don't know how you are supposed to query for it, but it doesn't seem to have to do with permissions. You need to figure out the right way to perform the query. ------------- PR: https://git.openjdk.java.net/skara/pull/1297 From kcr at openjdk.java.net Mon Apr 11 16:02:35 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 11 Apr 2022 16:02:35 GMT Subject: RFR: SKARA-1096: New command and label for JEPs, similar to CSR [v2] In-Reply-To: <_lDdboPolyRlt_Jn-JpueH7jRa8BzXZG1ozB5uFLDCE=.825121f3-ef8e-4355-b8c0-233c2d066a2c@github.com> References: <0-E7MblNqSvFkCZ6IEkmU1oEoWvphBbIZoVMFLRlPto=.a160de74-142c-466a-87fd-cbe76306bee8@github.com> <8mdIeqJiFU0Bemzc0ousCH7PZZlsQz82WrLxvEn4w68=.7d1f9816-05cb-4958-9898-b12f151de0be@github.com> <_lDdboPolyRlt_Jn-JpueH7jRa8BzXZG1ozB5uFLDCE=.825121f3-ef8e-4355-b8c0-233c2d066a2c@github.com> Message-ID: On Mon, 11 Apr 2022 13:51:23 GMT, Guoxiong Li wrote: >> I understand that this is how it would work with the current logic, and I don't agree with it. Declaring the need for a JEP and a CSR are different, so they do not need to follow the same model (though I'm not sure I agree with the limitation on `/csr unneeded` either). >> >> In order for a committer to mishandle this, they would have to actively issue `/jep unneeded` and then integrate. I think it's unlikely to happen by mistake, and mistakes are what this feature intends to protect against. We already trust committers to handle `/integrate` on their own, this isn't about protecting against malicious committers. > >> We already trust committers to handle /integrate on their own, this isn't about protecting against malicious committers. > > I agree with you now and I will fix it later. > I understand that this is how it would work with the current logic, and I don't agree with it. Declaring the need for a JEP and a CSR are different, so they do not need to follow the same model (though I'm not sure I agree with the limitation on `/csr unneeded` either). I feel that the current limitation on `/csr unneeded` is a good one, but I also agree that JEP need not (and probably should not) have this same restriction. ------------- PR: https://git.openjdk.java.net/skara/pull/1297 From gli at openjdk.java.net Mon Apr 11 17:41:53 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Mon, 11 Apr 2022 17:41:53 GMT Subject: RFR: SKARA-1096: New command and label for JEPs, similar to CSR [v3] In-Reply-To: <0-E7MblNqSvFkCZ6IEkmU1oEoWvphBbIZoVMFLRlPto=.a160de74-142c-466a-87fd-cbe76306bee8@github.com> References: <0-E7MblNqSvFkCZ6IEkmU1oEoWvphBbIZoVMFLRlPto=.a160de74-142c-466a-87fd-cbe76306bee8@github.com> Message-ID: > Hi all, > > This patch implements the features about the `/jep` command and JEP bot. The detailed designs and discussions are listed at [1][2]. > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong > > [1] https://mail.openjdk.java.net/pipermail/skara-dev/2021-December/005481.html > [2] https://mail.openjdk.java.net/pipermail/skara-dev/2022-March/005770.html Guoxiong Li has updated the pull request incrementally with two additional commits since the last revision: - Change jql. - Remove authorization test of the command 'jep unneeded' ------------- Changes: - all: https://git.openjdk.java.net/skara/pull/1297/files - new: https://git.openjdk.java.net/skara/pull/1297/files/72d2a46c..ccac4dbd Webrevs: - full: https://webrevs.openjdk.java.net/?repo=skara&pr=1297&range=02 - incr: https://webrevs.openjdk.java.net/?repo=skara&pr=1297&range=01-02 Stats: 14 lines in 3 files changed: 0 ins; 13 del; 1 mod Patch: https://git.openjdk.java.net/skara/pull/1297.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1297/head:pull/1297 PR: https://git.openjdk.java.net/skara/pull/1297 From gli at openjdk.java.net Mon Apr 11 17:41:54 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Mon, 11 Apr 2022 17:41:54 GMT Subject: RFR: SKARA-1096: New command and label for JEPs, similar to CSR [v3] In-Reply-To: References: <0-E7MblNqSvFkCZ6IEkmU1oEoWvphBbIZoVMFLRlPto=.a160de74-142c-466a-87fd-cbe76306bee8@github.com> <8mdIeqJiFU0Bemzc0ousCH7PZZlsQz82WrLxvEn4w68=.7d1f9816-05cb-4958-9898-b12f151de0be@github.com> <_lDdboPolyRlt_Jn-JpueH7jRa8BzXZG1ozB5uFLDCE=.825121f3-ef8e-4355-b8c0-233c2d066a2c@github.com> Message-ID: On Mon, 11 Apr 2022 15:59:45 GMT, Kevin Rushforth wrote: >>> We already trust committers to handle /integrate on their own, this isn't about protecting against malicious committers. >> >> I agree with you now and I will fix it later. > >> I understand that this is how it would work with the current logic, and I don't agree with it. Declaring the need for a JEP and a CSR are different, so they do not need to follow the same model (though I'm not sure I agree with the limitation on `/csr unneeded` either). > > I feel that the current limitation on `/csr unneeded` is a good one, but I also agree that JEP need not (and probably should not) have this same restriction. Fixed just now. ------------- PR: https://git.openjdk.java.net/skara/pull/1297 From gli at openjdk.java.net Mon Apr 11 17:41:54 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Mon, 11 Apr 2022 17:41:54 GMT Subject: RFR: SKARA-1096: New command and label for JEPs, similar to CSR [v3] In-Reply-To: <6u3Ggq5-WyiLAAUrj3v20bk_9CrCV-VudJNtJC2dc6c=.6106a08c-8f90-4184-9886-01fb4e3af763@github.com> References: <0-E7MblNqSvFkCZ6IEkmU1oEoWvphBbIZoVMFLRlPto=.a160de74-142c-466a-87fd-cbe76306bee8@github.com> <8mdIeqJiFU0Bemzc0ousCH7PZZlsQz82WrLxvEn4w68=.7d1f9816-05cb-4958-9898-b12f151de0be@github.com> <_lDdboPolyRlt_Jn-JpueH7jRa8BzXZG1ozB5uFLDCE=.825121f3-ef8e-4355-b8c0-233c2d066a2c@github.com> <6u3Ggq5-WyiLAAUrj3v20bk_9CrCV-VudJNtJC2dc6c=.6106a08c-8f90-4184-9886-01fb4e3af763@github.com> Message-ID: On Mon, 11 Apr 2022 13:59:47 GMT, Erik Joelsson wrote: >> The link `https://bugs.openjdk.java.net/rest/api/2/search?jql=project = JDK AND type = JEP` also returns this field. Such as `"customfield_10701":"419"`. > > Ok, I see the field name. I don't know how you are supposed to query for it, but it doesn't seem to have to do with permissions. You need to figure out the right way to perform the query. The previous link `https://bugs.openjdk.java.net/rest/api/2/search?jql=project = JDK AND customfield_10701 = 11` has two errors. 1. We should use the display name to query instead of the internal name. So the `customfield_10701` need to be changed to `JEP Number`. 2. We can't query text field by using the operator `=`. We need to use the operator `~`. So the link should be `https://bugs.openjdk.java.net/rest/api/2/search?jql=project = JDK AND "JEP Number" ~ "11"` Related documentation: [1] https://developer.atlassian.com/cloud/jira/platform/rest/v2/api-group-issue-search/#api-rest-api-2-search-post [2] https://support.atlassian.com/jira-software-cloud/docs/advanced-search-reference-jql-operators/ ------------- PR: https://git.openjdk.java.net/skara/pull/1297 From erikj at openjdk.java.net Mon Apr 11 17:41:54 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 11 Apr 2022 17:41:54 GMT Subject: RFR: SKARA-1096: New command and label for JEPs, similar to CSR [v3] In-Reply-To: References: <0-E7MblNqSvFkCZ6IEkmU1oEoWvphBbIZoVMFLRlPto=.a160de74-142c-466a-87fd-cbe76306bee8@github.com> <8mdIeqJiFU0Bemzc0ousCH7PZZlsQz82WrLxvEn4w68=.7d1f9816-05cb-4958-9898-b12f151de0be@github.com> <_lDdboPolyRlt_Jn-JpueH7jRa8BzXZG1ozB5uFLDCE=.825121f3-ef8e-4355-b8c0-233c2d066a2c@github.com> <6u3Ggq5-WyiLAAUrj3v20bk_9CrCV-VudJNtJC2dc6c=.6106a08c-8f90-4184-9886-01fb4e3af763@github.com> Message-ID: On Mon, 11 Apr 2022 17:37:36 GMT, Guoxiong Li wrote: >> Ok, I see the field name. I don't know how you are supposed to query for it, but it doesn't seem to have to do with permissions. You need to figure out the right way to perform the query. > > The previous link `https://bugs.openjdk.java.net/rest/api/2/search?jql=project = JDK AND customfield_10701 = 11` has two errors. > > 1. We should use the display name to query instead of the internal name. So the `customfield_10701` need to be changed to `JEP Number`. > 2. We can't query text field by using the operator `=`. We need to use the operator `~`. > > So the link should be `https://bugs.openjdk.java.net/rest/api/2/search?jql=project = JDK AND "JEP Number" ~ "11"` > > Related documentation: > [1] https://developer.atlassian.com/cloud/jira/platform/rest/v2/api-group-issue-search/#api-rest-api-2-search-post > [2] https://support.atlassian.com/jira-software-cloud/docs/advanced-search-reference-jql-operators/ I tried to query in the webUI and then convert to advanced query. That gives me: https://bugs.openjdk.java.net/issues/?jql=project%20%3D%20JDK%20AND%20issuetype%20%3D%20JEP%20AND%20%22JEP%20Number%22%20~%20%2211%22 Trying that with the rest api seems to work too: https://bugs.openjdk.java.net/rest/api/2/search?jql=project=JDK%20AND%20%22JEP%20Number%22~11 ------------- PR: https://git.openjdk.java.net/skara/pull/1297 From gli at openjdk.java.net Mon Apr 11 17:41:54 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Mon, 11 Apr 2022 17:41:54 GMT Subject: RFR: SKARA-1096: New command and label for JEPs, similar to CSR [v3] In-Reply-To: References: <0-E7MblNqSvFkCZ6IEkmU1oEoWvphBbIZoVMFLRlPto=.a160de74-142c-466a-87fd-cbe76306bee8@github.com> <8mdIeqJiFU0Bemzc0ousCH7PZZlsQz82WrLxvEn4w68=.7d1f9816-05cb-4958-9898-b12f151de0be@github.com> <_lDdboPolyRlt_Jn-JpueH7jRa8BzXZG1ozB5uFLDCE=.825121f3-ef8e-4355-b8c0-233c2d066a2c@github.com> <6u3Ggq5-WyiLAAUrj3v20bk_9CrCV-VudJNtJC2dc6c=.6106a08c-8f90-4184-9886-01fb4e3af763@github.com> Message-ID: On Mon, 11 Apr 2022 17:37:44 GMT, Erik Joelsson wrote: >> The previous link `https://bugs.openjdk.java.net/rest/api/2/search?jql=project = JDK AND customfield_10701 = 11` has two errors. >> >> 1. We should use the display name to query instead of the internal name. So the `customfield_10701` need to be changed to `JEP Number`. >> 2. We can't query text field by using the operator `=`. We need to use the operator `~`. >> >> So the link should be `https://bugs.openjdk.java.net/rest/api/2/search?jql=project = JDK AND "JEP Number" ~ "11"` >> >> Related documentation: >> [1] https://developer.atlassian.com/cloud/jira/platform/rest/v2/api-group-issue-search/#api-rest-api-2-search-post >> [2] https://support.atlassian.com/jira-software-cloud/docs/advanced-search-reference-jql-operators/ > > I tried to query in the webUI and then convert to advanced query. That gives me: > https://bugs.openjdk.java.net/issues/?jql=project%20%3D%20JDK%20AND%20issuetype%20%3D%20JEP%20AND%20%22JEP%20Number%22%20~%20%2211%22 > > Trying that with the rest api seems to work too: > https://bugs.openjdk.java.net/rest/api/2/search?jql=project=JDK%20AND%20%22JEP%20Number%22~11 Fixed just now. ------------- PR: https://git.openjdk.java.net/skara/pull/1297 From gli at openjdk.java.net Mon Apr 11 17:45:36 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Mon, 11 Apr 2022 17:45:36 GMT Subject: RFR: SKARA-1096: New command and label for JEPs, similar to CSR [v3] In-Reply-To: References: <0-E7MblNqSvFkCZ6IEkmU1oEoWvphBbIZoVMFLRlPto=.a160de74-142c-466a-87fd-cbe76306bee8@github.com> <8mdIeqJiFU0Bemzc0ousCH7PZZlsQz82WrLxvEn4w68=.7d1f9816-05cb-4958-9898-b12f151de0be@github.com> <_lDdboPolyRlt_Jn-JpueH7jRa8BzXZG1ozB5uFLDCE=.825121f3-ef8e-4355-b8c0-233c2d066a2c@github.com> <6u3Ggq5-WyiLAAUrj3v20bk_9CrCV-VudJNtJC2dc6c=.6106a08c-8f90-4184-9886-01fb4e3af763@github.com> Message-ID: On Mon, 11 Apr 2022 17:37:44 GMT, Erik Joelsson wrote: >> The previous link `https://bugs.openjdk.java.net/rest/api/2/search?jql=project = JDK AND customfield_10701 = 11` has two errors. >> >> 1. We should use the display name to query instead of the internal name. So the `customfield_10701` need to be changed to `JEP Number`. >> 2. We can't query text field by using the operator `=`. We need to use the operator `~`. >> >> So the link should be `https://bugs.openjdk.java.net/rest/api/2/search?jql=project = JDK AND "JEP Number" ~ "11"` >> >> Related documentation: >> [1] https://developer.atlassian.com/cloud/jira/platform/rest/v2/api-group-issue-search/#api-rest-api-2-search-post >> [2] https://support.atlassian.com/jira-software-cloud/docs/advanced-search-reference-jql-operators/ > > I tried to query in the webUI and then convert to advanced query. That gives me: > https://bugs.openjdk.java.net/issues/?jql=project%20%3D%20JDK%20AND%20issuetype%20%3D%20JEP%20AND%20%22JEP%20Number%22%20~%20%2211%22 > > Trying that with the rest api seems to work too: > https://bugs.openjdk.java.net/rest/api/2/search?jql=project=JDK%20AND%20%22JEP%20Number%22~11 @erikj79 we tried the same thing at the same time and get the same result. So the result should be reliable. ------------- PR: https://git.openjdk.java.net/skara/pull/1297 From gli at openjdk.java.net Mon Apr 11 19:05:19 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Mon, 11 Apr 2022 19:05:19 GMT Subject: RFR: SKARA-1096: New command and label for JEPs, similar to CSR [v4] In-Reply-To: <0-E7MblNqSvFkCZ6IEkmU1oEoWvphBbIZoVMFLRlPto=.a160de74-142c-466a-87fd-cbe76306bee8@github.com> References: <0-E7MblNqSvFkCZ6IEkmU1oEoWvphBbIZoVMFLRlPto=.a160de74-142c-466a-87fd-cbe76306bee8@github.com> Message-ID: > Hi all, > > This patch implements the features about the `/jep` command and JEP bot. The detailed designs and discussions are listed at [1][2]. > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong > > [1] https://mail.openjdk.java.net/pipermail/skara-dev/2021-December/005481.html > [2] https://mail.openjdk.java.net/pipermail/skara-dev/2022-March/005770.html Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: Add a test case about the jira api. Fix a bug found by this test case. ------------- Changes: - all: https://git.openjdk.java.net/skara/pull/1297/files - new: https://git.openjdk.java.net/skara/pull/1297/files/ccac4dbd..7591f847 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=skara&pr=1297&range=03 - incr: https://webrevs.openjdk.java.net/?repo=skara&pr=1297&range=02-03 Stats: 61 lines in 3 files changed: 59 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/skara/pull/1297.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1297/head:pull/1297 PR: https://git.openjdk.java.net/skara/pull/1297 From erikj at openjdk.java.net Mon Apr 11 19:05:20 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 11 Apr 2022 19:05:20 GMT Subject: RFR: SKARA-1096: New command and label for JEPs, similar to CSR [v4] In-Reply-To: References: <0-E7MblNqSvFkCZ6IEkmU1oEoWvphBbIZoVMFLRlPto=.a160de74-142c-466a-87fd-cbe76306bee8@github.com> <8mdIeqJiFU0Bemzc0ousCH7PZZlsQz82WrLxvEn4w68=.7d1f9816-05cb-4958-9898-b12f151de0be@github.com> <_lDdboPolyRlt_Jn-JpueH7jRa8BzXZG1ozB5uFLDCE=.825121f3-ef8e-4355-b8c0-233c2d066a2c@github.com> <6u3Ggq5-WyiLAAUrj3v20bk_9CrCV-VudJNtJC2dc6c=.6106a08c-8f90-4184-9886-01fb4e3af763@github.com> Message-ID: <2_We6yyqJqmCJwayYVLauP6LLCK1oGe-ZfQF5TF9XuA=.178d157c-48d5-4b6b-ac07-52e3dee2b771@github.com> On Mon, 11 Apr 2022 17:42:54 GMT, Guoxiong Li wrote: >> I tried to query in the webUI and then convert to advanced query. That gives me: >> https://bugs.openjdk.java.net/issues/?jql=project%20%3D%20JDK%20AND%20issuetype%20%3D%20JEP%20AND%20%22JEP%20Number%22%20~%20%2211%22 >> >> Trying that with the rest api seems to work too: >> https://bugs.openjdk.java.net/rest/api/2/search?jql=project=JDK%20AND%20%22JEP%20Number%22~11 > > @erikj79 we tried the same thing at the same time and got the same result. So the result should be reliable. When I have been introducing new API calls to Github/Gitlab, I introduced manual tests so that I could verify and debug the interaction with the remote services. These tests required specialized setup that we can't put in the OpenJDK Skara repo (credentials and URLs) and the tests are of a nature that we don't want to run automatically all the time. But at least having something that you can run when you need to, helps a lot. See `forge/src/test/java/org/openjdk/skara/forge/ManualForgeTests.java` for an example. I don't have any example for Jira. Since this is just a read query, this test won't need authentication at least. ------------- PR: https://git.openjdk.java.net/skara/pull/1297 From gli at openjdk.java.net Mon Apr 11 19:05:20 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Mon, 11 Apr 2022 19:05:20 GMT Subject: RFR: SKARA-1096: New command and label for JEPs, similar to CSR [v4] In-Reply-To: <2_We6yyqJqmCJwayYVLauP6LLCK1oGe-ZfQF5TF9XuA=.178d157c-48d5-4b6b-ac07-52e3dee2b771@github.com> References: <0-E7MblNqSvFkCZ6IEkmU1oEoWvphBbIZoVMFLRlPto=.a160de74-142c-466a-87fd-cbe76306bee8@github.com> <8mdIeqJiFU0Bemzc0ousCH7PZZlsQz82WrLxvEn4w68=.7d1f9816-05cb-4958-9898-b12f151de0be@github.com> <_lDdboPolyRlt_Jn-JpueH7jRa8BzXZG1ozB5uFLDCE=.825121f3-ef8e-4355-b8c0-233c2d066a2c@github.com> <6u3Ggq5-WyiLAAUrj3v20bk_9CrCV-VudJNtJC2dc6c=.6106a08c-8f90-4184-9886-01fb4e3af763@github.com> <2_We6yyqJqmCJwayYVLauP6LLCK1oGe-ZfQ F5TF9XuA=.178d157c-48d5-4b6b-ac07-52e3dee2b771@github.com> Message-ID: On Mon, 11 Apr 2022 17:49:41 GMT, Erik Joelsson wrote: >> @erikj79 we tried the same thing at the same time and got the same result. So the result should be reliable. > > When I have been introducing new API calls to Github/Gitlab, I introduced manual tests so that I could verify and debug the interaction with the remote services. These tests required specialized setup that we can't put in the OpenJDK Skara repo (credentials and URLs) and the tests are of a nature that we don't want to run automatically all the time. But at least having something that you can run when you need to, helps a lot. See `forge/src/test/java/org/openjdk/skara/forge/ManualForgeTests.java` for an example. I don't have any example for Jira. Since this is just a read query, this test won't need authentication at least. I added a test case about the jira api just now. ------------- PR: https://git.openjdk.java.net/skara/pull/1297 From erikj at openjdk.java.net Mon Apr 11 19:24:27 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 11 Apr 2022 19:24:27 GMT Subject: RFR: SKARA-1096: New command and label for JEPs, similar to CSR [v4] In-Reply-To: References: <0-E7MblNqSvFkCZ6IEkmU1oEoWvphBbIZoVMFLRlPto=.a160de74-142c-466a-87fd-cbe76306bee8@github.com> Message-ID: On Mon, 11 Apr 2022 19:05:19 GMT, Guoxiong Li wrote: >> Hi all, >> >> This patch implements the features about the `/jep` command and JEP bot. The detailed designs and discussions are listed at [1][2]. >> >> Thanks for taking the time to review. >> >> Best Regards, >> -- Guoxiong >> >> [1] https://mail.openjdk.java.net/pipermail/skara-dev/2021-December/005481.html >> [2] https://mail.openjdk.java.net/pipermail/skara-dev/2022-March/005770.html > > Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: > > Add a test case about the jira api. Fix a bug found by this test case. issuetracker/src/test/java/org/openjdk/skara/issuetracker/jira/JiraProjectTests.java line 33: > 31: import static org.junit.jupiter.api.Assertions.assertTrue; > 32: > 33: public class JiraProjectTests { To my knowledge, no automatic tests in the Skara project use remote services. Until we decide to change this policy, or find a reasonable way to run such tests, please mark this test as disabled. Suggestion: /** * To be able to run the tests, you need to remove or comment out the @Disabled * annotation first. */ @Disabled("Manual") public class JiraProjectTests { ------------- PR: https://git.openjdk.java.net/skara/pull/1297 From gli at openjdk.java.net Mon Apr 11 19:39:03 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Mon, 11 Apr 2022 19:39:03 GMT Subject: RFR: SKARA-1096: New command and label for JEPs, similar to CSR [v5] In-Reply-To: <0-E7MblNqSvFkCZ6IEkmU1oEoWvphBbIZoVMFLRlPto=.a160de74-142c-466a-87fd-cbe76306bee8@github.com> References: <0-E7MblNqSvFkCZ6IEkmU1oEoWvphBbIZoVMFLRlPto=.a160de74-142c-466a-87fd-cbe76306bee8@github.com> Message-ID: > Hi all, > > This patch implements the features about the `/jep` command and JEP bot. The detailed designs and discussions are listed at [1][2]. > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong > > [1] https://mail.openjdk.java.net/pipermail/skara-dev/2021-December/005481.html > [2] https://mail.openjdk.java.net/pipermail/skara-dev/2022-March/005770.html Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: Disable the test in JiraProjectTests. ------------- Changes: - all: https://git.openjdk.java.net/skara/pull/1297/files - new: https://git.openjdk.java.net/skara/pull/1297/files/7591f847..8512c896 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=skara&pr=1297&range=04 - incr: https://webrevs.openjdk.java.net/?repo=skara&pr=1297&range=03-04 Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/skara/pull/1297.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1297/head:pull/1297 PR: https://git.openjdk.java.net/skara/pull/1297 From gli at openjdk.java.net Mon Apr 11 19:39:04 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Mon, 11 Apr 2022 19:39:04 GMT Subject: RFR: SKARA-1096: New command and label for JEPs, similar to CSR [v4] In-Reply-To: References: <0-E7MblNqSvFkCZ6IEkmU1oEoWvphBbIZoVMFLRlPto=.a160de74-142c-466a-87fd-cbe76306bee8@github.com> Message-ID: On Mon, 11 Apr 2022 19:21:34 GMT, Erik Joelsson wrote: >> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: >> >> Add a test case about the jira api. Fix a bug found by this test case. > > issuetracker/src/test/java/org/openjdk/skara/issuetracker/jira/JiraProjectTests.java line 33: > >> 31: import static org.junit.jupiter.api.Assertions.assertTrue; >> 32: >> 33: public class JiraProjectTests { > > To my knowledge, no automatic tests in the Skara project use remote services. Until we decide to change this policy, or find a reasonable way to run such tests, please mark this test as disabled. > > Suggestion: > > /** > * To be able to run the tests, you need to remove or comment out the @Disabled > * annotation first. > */ > @Disabled("Manual") > public class JiraProjectTests { Fixed. ------------- PR: https://git.openjdk.java.net/skara/pull/1297 From dholmes at openjdk.java.net Tue Apr 12 04:15:03 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 12 Apr 2022 04:15:03 GMT Subject: RFR: SKARA-1096: New command and label for JEPs, similar to CSR [v5] In-Reply-To: References: <0-E7MblNqSvFkCZ6IEkmU1oEoWvphBbIZoVMFLRlPto=.a160de74-142c-466a-87fd-cbe76306bee8@github.com> Message-ID: On Mon, 11 Apr 2022 19:39:03 GMT, Guoxiong Li wrote: >> Hi all, >> >> This patch implements the features about the `/jep` command and JEP bot. The detailed designs and discussions are listed at [1][2]. >> >> Thanks for taking the time to review. >> >> Best Regards, >> -- Guoxiong >> >> [1] https://mail.openjdk.java.net/pipermail/skara-dev/2021-December/005481.html >> [2] https://mail.openjdk.java.net/pipermail/skara-dev/2022-March/005770.html > > Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: > > Disable the test in JiraProjectTests. I think this is totally unwarranted and there was not enough previous discussion at the JDK level to actually conclude anything about the need for this and how it should work. A JEP is not like a CSR-request. It is extremely rare to create an issue and raise a PR and have someone then say "this really needs a JEP". David ------------- PR: https://git.openjdk.java.net/skara/pull/1297 From gli at openjdk.java.net Tue Apr 12 12:43:06 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Tue, 12 Apr 2022 12:43:06 GMT Subject: RFR: SKARA-1096: New command and label for JEPs, similar to CSR [v5] In-Reply-To: References: <0-E7MblNqSvFkCZ6IEkmU1oEoWvphBbIZoVMFLRlPto=.a160de74-142c-466a-87fd-cbe76306bee8@github.com> Message-ID: On Tue, 12 Apr 2022 04:12:04 GMT, David Holmes wrote: > A JEP is not like a CSR-request. It is extremely rare to create an issue and raise a PR and have someone then say "this really needs a JEP". @dholmes-ora The current design[4] and this patch have the following advantages or features at least: **1. Prevent a JEP implemetation PR from accidentally integrating before the JEP has been targeted** As Jon stated in the SKARA-1096[5]: > It would be convenient to mark a PR as dependent on a JEP being targeted. This would help prevent accidental premature integration This situation has already occured in the past[6-9]. So it is necessary and important to prevent it. **2. Mark a PR as a JEP implemetation** The `jep` label can be added to the PR, so the developers can use `is:open is:pr label:jep` in the github to search all the JEPs which are under review. It is nice because we didn't have a right way to search them in the past. **3. Show the clear JEP Progress in the PR** This patch adds a checkbox item `Change requires a JEP request to be targeted` in the `Progresses` of the PR body. It shows the clear JEP Progress to the PR author. And the JEP progress can be changed automatically by the bot according to the JEP issue status, which is very convenient. **4. Provide a JEP link** This patch provides a JEP issue link in the `Issues` of the PR body. It is also convenient to the developers who want to jump to the JEP issue from the PR. After this patch integrating, what the PR author need to do is only typing the command `/jep `. Then SKARA can help complete all such good features. --- > there was not enough previous discussion at the JDK level to actually conclude anything about the need for this and how it should work. I posted the first design to the skara-dev mailing list at Dec, 2021[1]. After 3-4 months, I only recieved 2 comments, and one is yours[2]. The skara-dev mailing list has at least dozens of (if not hundreds or thousands of) subscribers, including all the SKARA reviewers and you @dholmes-ora. Are all of you so busy at these months that you can't give some concrete suggessions or can't give the right mailing list to discuss it? As you said in the email[2], `I'll have to make enquiries.`: > I don't think that is a decision to be made just in skara-dev. I'm not > certain where would be the best place to discuss it ... we don't have a > general infrastructure mailing list to discuss JBS. I'll have to make > enquiries. Does you need several months to find a right mailing list? Maybe it is only because all of you are lazy or are not instereting in this issue. At Mar. 2022, I provided another design[4] and had still waited for your ideas and suggestions. One month passed, no one gave a suggestion or expressed the objection. You have to know that most of the SKARA subscribers are the experienced OpenJDK developers who are both instereted in JDK and SKARA. Such developers can't or don't want to give any suggestion or point the right mailing list. Can the developers from other mailing list can give the actually good suggestions? If you still think that it need to be discussed. I can post the design detail to the jdk-dev or other mailing lists to re-start the discussion. But I don't think it is necessary personally. --- > I think this is totally unwarranted @dholmes-ora Actually, I am so sad when I read this comment. Because it seems that you have not read the issue[5] and the design[4] (or not read carefully/patiently) before opposing to the whole design. Please read the first advantage mentioned above again, this feature is necessary and important so that @jonathan-gibbons reported the issue[5] and so that we take so much time to discuss and complete the design and patch. --- Anyway, It @dholmes-ora you think we need to continue to discuss the design, I am happy to do that. Because I don't want to integrate a patch that all of you don't like. But can @dholmes-ora you provide some real suggesions at the following discussion and provide the reason when stating your opposition, which can let the design and patch better, at the next time? [1] https://mail.openjdk.java.net/pipermail/skara-dev/2021-December/005481.html [2] https://mail.openjdk.java.net/pipermail/skara-dev/2021-December/005482.html [3] https://mail.openjdk.java.net/pipermail/skara-dev/2021-December/005490.html [4] https://mail.openjdk.java.net/pipermail/skara-dev/2022-March/005770.html [5] https://bugs.openjdk.java.net/browse/SKARA-1096 [6] https://github.com/openjdk/jdk/pull/290 [7] https://github.com/openjdk/jdk/pull/291 [8] https://github.com/openjdk/jdk/pull/740 [9] https://github.com/openjdk/jdk/pull/769 ------------- PR: https://git.openjdk.java.net/skara/pull/1297 From erikj at openjdk.java.net Tue Apr 12 12:55:40 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 12 Apr 2022 12:55:40 GMT Subject: RFR: SKARA-1096: New command and label for JEPs, similar to CSR [v5] In-Reply-To: References: <0-E7MblNqSvFkCZ6IEkmU1oEoWvphBbIZoVMFLRlPto=.a160de74-142c-466a-87fd-cbe76306bee8@github.com> Message-ID: On Tue, 12 Apr 2022 04:12:04 GMT, David Holmes wrote: > I think this is totally unwarranted and there was not enough previous discussion at the JDK level to actually conclude anything about the need for this and how it should work. A JEP is not like a CSR-request. It is extremely rare to create an issue and raise a PR and have someone then say "this really needs a JEP". That isn't the intended usecase here. To issue the command, a JEP must already exist, as you have to reference a bugid/jepid pointing to the JEP. This command is mostly intended for the author to run, to make it clearer that the PR is related to a JEP. ------------- PR: https://git.openjdk.java.net/skara/pull/1297 From erikj at openjdk.java.net Tue Apr 12 19:11:08 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 12 Apr 2022 19:11:08 GMT Subject: RFR: 1396: Gitlab MR merged outside of Skara causes NPE in mlbridge Message-ID: In gitlab, if an MR is merged through Gitlab, without the user of Skara, we end up in a retry loop getting NPE in the mlbridge bot. This is caused by trying to extract the value of the "closed_by" field of the PR object. This patch adds a fallback to instead look at the "merged_by" field instead. ------------- Commit messages: - SKARA-1396 Changes: https://git.openjdk.java.net/skara/pull/1298/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1298&range=00 Issue: https://bugs.openjdk.java.net/browse/SKARA-1396 Stats: 11 lines in 1 file changed: 9 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/skara/pull/1298.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1298/head:pull/1298 PR: https://git.openjdk.java.net/skara/pull/1298 From kcr at openjdk.java.net Tue Apr 12 19:57:33 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 12 Apr 2022 19:57:33 GMT Subject: RFR: 1396: Gitlab MR merged outside of Skara causes NPE in mlbridge In-Reply-To: References: Message-ID: <2luTuIQ7GnLWZpGD6zgrHNxIr5mxEl7OmEBpKL2VyfI=.340fb898-870d-4358-b0b7-71d080903008@github.com> On Tue, 12 Apr 2022 19:06:02 GMT, Erik Joelsson wrote: > In gitlab, if an MR is merged through Gitlab, without the user of Skara, we end up in a retry loop getting NPE in the mlbridge bot. This is caused by trying to extract the value of the "closed_by" field of the PR object. This patch adds a fallback to instead look at the "merged_by" field instead. Looks good. ------------- Marked as reviewed by kcr (Reviewer). PR: https://git.openjdk.java.net/skara/pull/1298 From erikj at openjdk.java.net Tue Apr 12 20:05:20 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 12 Apr 2022 20:05:20 GMT Subject: Integrated: 1396: Gitlab MR merged outside of Skara causes NPE in mlbridge In-Reply-To: References: Message-ID: On Tue, 12 Apr 2022 19:06:02 GMT, Erik Joelsson wrote: > If an MR is merged through Gitlab, without the use of Skara, we end up in a retry loop getting NPE in the mlbridge bot. This is caused by trying to extract the value of the "closed_by" field of the PR object. This patch adds a fallback to look at the "merged_by" field instead. This pull request has now been integrated. Changeset: fe8bd087 Author: Erik Joelsson URL: https://git.openjdk.java.net/skara/commit/fe8bd087abf6921a02ce8dde5bdfa4aeb63cc02f Stats: 11 lines in 1 file changed: 9 ins; 0 del; 2 mod 1396: Gitlab MR merged outside of Skara causes NPE in mlbridge Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/skara/pull/1298 From erikj at openjdk.java.net Tue Apr 12 22:57:23 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 12 Apr 2022 22:57:23 GMT Subject: RFR: SKARA-1096: New command and label for JEPs, similar to CSR [v5] In-Reply-To: References: <0-E7MblNqSvFkCZ6IEkmU1oEoWvphBbIZoVMFLRlPto=.a160de74-142c-466a-87fd-cbe76306bee8@github.com> Message-ID: On Mon, 11 Apr 2022 19:39:03 GMT, Guoxiong Li wrote: >> Hi all, >> >> This patch implements the features about the `/jep` command and JEP bot. The detailed designs and discussions are listed at [1][2]. >> >> Thanks for taking the time to review. >> >> Best Regards, >> -- Guoxiong >> >> [1] https://mail.openjdk.java.net/pipermail/skara-dev/2021-December/005481.html >> [2] https://mail.openjdk.java.net/pipermail/skara-dev/2022-March/005770.html > > Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: > > Disable the test in JiraProjectTests. bots/jep/src/main/java/org/openjdk/skara/bots/jep/JEPBot.java line 71: > 69: if (jepComment == null) { > 70: if (pr.labelNames().contains(JEP_LABEL)) { > 71: pr.removeLabel(JEP_LABEL); There is a potential race here. The /jep command adds the label first and the comment after. Not sure how to solve that. Ideally the label should be added after the comment. bots/jep/src/main/java/org/openjdk/skara/bots/jep/JEPBot.java line 89: > 87: if (issueOpt.isEmpty()) { > 88: if (pr.labelNames().contains(JEP_LABEL)) { > 89: pr.removeLabel(JEP_LABEL); If we remove the label in this situation, then the PR bot will mark the PR as `[x] Change requires a JEP request to be targeted`, which isn't true. I think the label should stay on. The jep command will not add the label unless it finds the JEP. I can imagine the following situations where this could happen: * Jira is having a temporary outage - In this case we should do nothing. * The JEP is no longer visible (e.g. made oracle confidential) - The user/author needs to decide how to handle this, by referencing another JEP or /jep unneeded. * The JEP comment is corrupted - I don't think we can expect the bot to figure out this on its own. Since this is an error state that shouldn't be possible to reach from normal operation, we should log SEVERE so that an admin gets notified. The same goes for the case below where the issue is of the wrong type. bots/jep/src/main/java/org/openjdk/skara/bots/jep/JEPBot.java line 143: > 141: @Override > 142: public String name() { > 143: return JEP_LABEL; Suggestion: return CSRBotFactory.NAME; bots/notify/src/test/java/org/openjdk/skara/bots/notify/issue/IssueNotifierTests.java line 504: > 502: > 503: var csrIssueComments = updatedJepIssue.comments(); > 504: assertEquals(0, csrIssueComments.size()); Suggestion: var jepIssueLinks = updatedJepIssue.links(); assertEquals(0, jepIssueLinks.size()); var jepIssueComments = updatedJepIssue.comments(); assertEquals(0, jepIssueComments.size()); bots/pr/src/main/java/org/openjdk/skara/bots/pr/JEPCommand.java line 139: > 137: } > 138: } else if ("Draft".equals(issueStatus) || "Submitted".equals(issueStatus) || "Candidate".equals(issueStatus) || > 139: "Proposed to Target".equals(issueStatus) || "Proposed to Drop".equals(issueStatus) || "Closed".equals(issueStatus)) { I think this should either just be "else", or we need an else clause after this for catching any unknown states. I think I prefer the former. bots/pr/src/test/java/org/openjdk/skara/bots/pr/CheckTests.java line 1215: > 1213: var mainIssue = issueProject.createIssue("The main issue", List.of("main"), Map.of("issuetype", JSON.of("Bug"))); > 1214: var jepIssue = issueProject.createIssue("The jep issue", List.of("Jep body"), > 1215: Map.of("issuetype", JSON.of("JEP"), "status", JSON.object().put("name", "Submitted"), JiraProject.JEP_NUMBER, JSON.of("123"))); Consider using static import for JEP_NUMBER. bots/pr/src/test/java/org/openjdk/skara/bots/pr/CheckTests.java line 1248: > 1246: assertTrue(pr.body().contains("### Issues")); > 1247: assertTrue(pr.body().contains("The main issue")); > 1248: assertTrue(pr.body().contains("The jep issue (**JEP**)")); This part of the test isn't really doing anything. Should it perhaps remove the JEP label and verify that the JEP requirement is now met? ------------- PR: https://git.openjdk.java.net/skara/pull/1297 From dholmes at openjdk.java.net Wed Apr 13 01:14:00 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 13 Apr 2022 01:14:00 GMT Subject: RFR: SKARA-1096: New command and label for JEPs, similar to CSR [v5] In-Reply-To: References: <0-E7MblNqSvFkCZ6IEkmU1oEoWvphBbIZoVMFLRlPto=.a160de74-142c-466a-87fd-cbe76306bee8@github.com> Message-ID: <8oJgJnQxODVrBGIHX37JBLgZdIzY2IwsZJ84fo51KhQ=.2d4dee2a-0be0-4b6d-9a17-a7579cf0e64c@github.com> On Mon, 11 Apr 2022 19:39:03 GMT, Guoxiong Li wrote: >> Hi all, >> >> This patch implements the features about the `/jep` command and JEP bot. The detailed designs and discussions are listed at [1][2]. >> >> Thanks for taking the time to review. >> >> Best Regards, >> -- Guoxiong >> >> [1] https://mail.openjdk.java.net/pipermail/skara-dev/2021-December/005481.html >> [2] https://mail.openjdk.java.net/pipermail/skara-dev/2022-March/005770.html > > Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: > > Disable the test in JiraProjectTests. The original proposal for this solicited only two responses from myself and Erik and we both expressed concerns that this was beyond the scope of discussion for skara-dev - codifying these aspects of the JEP process (particularly with the original proposed changes to JBS) needed to be done as part of the JEP process. So that "discussion" went nowhere. I apologise that I did not get back regarding looking into a more suitable place to discuss the JBS changes - there really isn't one, so jdk-dev (as suggested by Erik at the time) seems a reasonable place. After that initial "discussion" nothing was said for three months at which point you decided to proceed with a reduced proposal. I would have taken the lack of further discussion as sign of either a general lack of interest about the proposal, or a sign that it was not being seen by the right people in the right place. So the current simplified proposal addresses the basic need expressed in SKARA-1096, and prevents the accidental integrations that you rightly point out have actually occurred. I withdraw, and apologise for, my comment that this feature is "unwarranted". I would still like to see the proposal announced on a broader mailing, such as jdk-dev, to increase awareness and potentially garner some feedback. Thanks, David ------------- PR: https://git.openjdk.java.net/skara/pull/1297 From lgxbslgx at gmail.com Wed Apr 13 12:54:09 2022 From: lgxbslgx at gmail.com (Guoxiong Li) Date: Wed, 13 Apr 2022 20:54:09 +0800 Subject: [Investigation] Add JEP check to the PR Message-ID: Hi all, Recently, SKARA developers started the work about adding the JEP check to the PR. The enhancement was firstly reported by Jon [1]. Then we discussed it at the skara-dev mailing list[2-6]. Currently, we have a basic design[5] and draft patch[7] to solve the issue and would like to get your feedback. The design is shown below for you. --- *The main goals of this enhancement:* *1. Prevent accidentally premature integration* Sometimes, the author of the JEP implementation PR integrates the JEP patch without checking if the JEP has been targeted or not in the JBS. The JEP-295 patch[8-11] is one of the examples. It seems like a personal mistake but is actually an issue in the PR development flow. The JEP PR shouldn't be integrated by the bot until the JEP has been targeted even though the author requested integration by using the command `/integrate`. This enhancement will add the corresponding check, which is similar to the CSR mechanism, to prevent accidentally premature integration. *2. Make the JEP development flow in the PR clearer* Currently, when we want to identify whether the patch is a JEP implementation, we can only read the comments from the PR author or other people and then find the JEP 'announcement' or the JEP issue link or other clues to confirm that it is a JEP implementation. It is not clear and not convenient. So we need to have a mechanism to represent it, including marking it as a JEP and displaying the JEP status. *The basic design:* *1. Use the command `/jep ` and `/jep ` to mark a PR as JEP implementation.* Only the author of the PR and the formal reviewers can use this command. The or must reference an issue in the JBS and the type of the issue must be `JEP` and the issue must have the correct field `JEP Number`. Some command examples are listed below: * `/jep JDK-1234567` * `/jep 1234567` * `/jep jep-123` * `/jep JEP-123` If the verification mentioned above fails, the bot will reply to a message with a failed reason. If the verification passes and the JEP issue have ***not*** been targeted (the status may be "Draft", "Submitted", "Candidate", "Proposed to Target", "Proposed to Drop" and "Close" ***without*** "Delivered"), the bot will perform the following steps: - Reply a successful message like `this pull request will not be integrated until the []() has been targeted.` - Add a checkbox item about jep,like `[ ] Change requires a JEP request to be targeted`, to the `Progresses` part of the PR body. Note: the checkbox is* **not* *selected***. - Add the jep issue link to the `Issues` part in the PR body. - Add a PR label named `jep` to the PR. If the verification passes and the JEP issue have been targeted (the status may be "Targeted", "Integrated", "Completed", "Close" ***with*** "Delivered"), the bot will perform the following steps: - Reply a successful message like `the JEP for this pull request []() , has already been targeted.` - Add a checkbox item about jep `[x] Change requires a JEP request to be targeted` to the `Progresses` part in the PR body. Note: the checkbox is ***selected***. - Add the jep issue link to the `Issues` part in the PR body. The label `jep` is not added to the PR in this situation. It follows the `CSR` convention. I think it can be re-considered. If the previous `` or `` is wrong, you can use this command again to re-correct it. Only the latest `jep` command can be finally checked and the last `` or `` can be validated. And all the previous `jep` commands will be ignored. *2. Use the command `/jep unneeded` to restore the state* Only the author of the PR and the formal reviewers can use this command. If you have used the command `/jep ` and `/jep ` mistakenly, and actually the PR doesn't need any JEP to be targeted. You can use this command to restore the state. If the verification mentioned above fails, the bot will reply to a message with a failed reason. If the verification passes, all the previous `/jep` commands will be ignored, too. And the bot will remove the corresponding checkbox item, the issue link and the label `jep` if existing. *3. Check the jep is targeted or not automatically* If the status of the JEP issue changes from `"Draft", "Submitted", "Candidate", "Proposed to Target", "Proposed to Drop" and "Close" ***without*** "Delivered"` to `"Targeted", "Integrated", "Completed", "Close" ***with*** "Delivered"`, the bot will select the checkbox item about jep in the `Progresses` part and remove the `jep` label in the PR. And vice versa. Please note: the meaning of the checkbox item `[ ] Change requires a JEP request to be targeted` in the `Progresses` is the same as other checkbox items, such as `[ ] Commit message must refer to an issue`, which means if it is not selected, the integration will be blocked. *As a conclusion, after this enhancement, the JEP PR author only need to simply type the command `/jep |` in the Github PR.* *All the other things will be done by the bot and all the other mechanisms will be performed as before.* --- It is nice to receive your opinion and feedback about the design and the patch[7]. Any ideas are appreciated. Best Regards, -- Guoxiong [1] https://bugs.openjdk.java.net/browse/SKARA-1096 [2] https://mail.openjdk.java.net/pipermail/skara-dev/2021-December/005481.html [3] https://mail.openjdk.java.net/pipermail/skara-dev/2021-December/005482.html [4] https://mail.openjdk.java.net/pipermail/skara-dev/2021-December/005490.html [5] https://mail.openjdk.java.net/pipermail/skara-dev/2022-March/005770.html [6] https://mail.openjdk.java.net/pipermail/skara-dev/2022-March/005772.html [7] https://github.com/openjdk/skara/pull/1297 [8] https://github.com/openjdk/jdk/pull/290 [9] https://github.com/openjdk/jdk/pull/291 [10] https://github.com/openjdk/jdk/pull/740 [11] https://github.com/openjdk/jdk/pull/769 From gli at openjdk.java.net Wed Apr 13 13:07:58 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Wed, 13 Apr 2022 13:07:58 GMT Subject: RFR: SKARA-1096: New command and label for JEPs, similar to CSR [v5] In-Reply-To: References: <0-E7MblNqSvFkCZ6IEkmU1oEoWvphBbIZoVMFLRlPto=.a160de74-142c-466a-87fd-cbe76306bee8@github.com> Message-ID: On Mon, 11 Apr 2022 19:39:03 GMT, Guoxiong Li wrote: >> Hi all, >> >> This patch implements the features about the `/jep` command and JEP bot. The detailed designs and discussions are listed at [1][2]. >> >> Thanks for taking the time to review. >> >> Best Regards, >> -- Guoxiong >> >> [1] https://mail.openjdk.java.net/pipermail/skara-dev/2021-December/005481.html >> [2] https://mail.openjdk.java.net/pipermail/skara-dev/2022-March/005770.html > > Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: > > Disable the test in JiraProjectTests. I posted https://mail.openjdk.java.net/pipermail/jdk-dev/2022-April/006498.html to re-start the discussion. ------------- PR: https://git.openjdk.java.net/skara/pull/1297 From gli at openjdk.java.net Wed Apr 13 15:01:50 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Wed, 13 Apr 2022 15:01:50 GMT Subject: RFR: SKARA-1096: New command and label for JEPs, similar to CSR [v6] In-Reply-To: <0-E7MblNqSvFkCZ6IEkmU1oEoWvphBbIZoVMFLRlPto=.a160de74-142c-466a-87fd-cbe76306bee8@github.com> References: <0-E7MblNqSvFkCZ6IEkmU1oEoWvphBbIZoVMFLRlPto=.a160de74-142c-466a-87fd-cbe76306bee8@github.com> Message-ID: > Hi all, > > This patch implements the features about the `/jep` command and JEP bot. The detailed designs and discussions are listed at [1][2]. > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong > > [1] https://mail.openjdk.java.net/pipermail/skara-dev/2021-December/005481.html > [2] https://mail.openjdk.java.net/pipermail/skara-dev/2022-March/005770.html Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: Fixes code according to Erik's comments ------------- Changes: - all: https://git.openjdk.java.net/skara/pull/1297/files - new: https://git.openjdk.java.net/skara/pull/1297/files/8512c896..49f4dfa5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=skara&pr=1297&range=05 - incr: https://webrevs.openjdk.java.net/?repo=skara&pr=1297&range=04-05 Stats: 32 lines in 5 files changed: 9 ins; 7 del; 16 mod Patch: https://git.openjdk.java.net/skara/pull/1297.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1297/head:pull/1297 PR: https://git.openjdk.java.net/skara/pull/1297 From gli at openjdk.java.net Wed Apr 13 15:01:52 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Wed, 13 Apr 2022 15:01:52 GMT Subject: RFR: SKARA-1096: New command and label for JEPs, similar to CSR [v5] In-Reply-To: References: <0-E7MblNqSvFkCZ6IEkmU1oEoWvphBbIZoVMFLRlPto=.a160de74-142c-466a-87fd-cbe76306bee8@github.com> Message-ID: On Tue, 12 Apr 2022 22:44:11 GMT, Erik Joelsson wrote: >> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: >> >> Disable the test in JiraProjectTests. > > bots/jep/src/main/java/org/openjdk/skara/bots/jep/JEPBot.java line 89: > >> 87: if (issueOpt.isEmpty()) { >> 88: if (pr.labelNames().contains(JEP_LABEL)) { >> 89: pr.removeLabel(JEP_LABEL); > > If we remove the label in this situation, then the PR bot will mark the PR as `[x] Change requires a JEP request to be targeted`, which isn't true. I think the label should stay on. The jep command will not add the label unless it finds the JEP. I can imagine the following situations where this could happen: > > * Jira is having a temporary outage - In this case we should do nothing. > * The JEP is no longer visible (e.g. made oracle confidential) - The user/author needs to decide how to handle this, by referencing another JEP or /jep unneeded. > * The JEP comment is corrupted - I don't think we can expect the bot to figure out this on its own. > > Since this is an error state that shouldn't be possible to reach from normal operation, we should log SEVERE so that an admin gets notified. The same goes for the case below where the issue is of the wrong type. Fixed. > bots/jep/src/main/java/org/openjdk/skara/bots/jep/JEPBot.java line 143: > >> 141: @Override >> 142: public String name() { >> 143: return JEP_LABEL; > > Suggestion: > > return CSRBotFactory.NAME; Fixed and used the static import. > bots/notify/src/test/java/org/openjdk/skara/bots/notify/issue/IssueNotifierTests.java line 504: > >> 502: >> 503: var csrIssueComments = updatedJepIssue.comments(); >> 504: assertEquals(0, csrIssueComments.size()); > > Suggestion: > > var jepIssueLinks = updatedJepIssue.links(); > assertEquals(0, jepIssueLinks.size()); > > var jepIssueComments = updatedJepIssue.comments(); > assertEquals(0, jepIssueComments.size()); Fixed. > bots/pr/src/main/java/org/openjdk/skara/bots/pr/JEPCommand.java line 139: > >> 137: } >> 138: } else if ("Draft".equals(issueStatus) || "Submitted".equals(issueStatus) || "Candidate".equals(issueStatus) || >> 139: "Proposed to Target".equals(issueStatus) || "Proposed to Drop".equals(issueStatus) || "Closed".equals(issueStatus)) { > > I think this should either just be "else", or we need an else clause after this for catching any unknown states. I think I prefer the former. I fixed it by using the former style and added a comment. > bots/pr/src/test/java/org/openjdk/skara/bots/pr/CheckTests.java line 1215: > >> 1213: var mainIssue = issueProject.createIssue("The main issue", List.of("main"), Map.of("issuetype", JSON.of("Bug"))); >> 1214: var jepIssue = issueProject.createIssue("The jep issue", List.of("Jep body"), >> 1215: Map.of("issuetype", JSON.of("JEP"), "status", JSON.object().put("name", "Submitted"), JiraProject.JEP_NUMBER, JSON.of("123"))); > > Consider using static import for JEP_NUMBER. Fixed. > bots/pr/src/test/java/org/openjdk/skara/bots/pr/CheckTests.java line 1248: > >> 1246: assertTrue(pr.body().contains("### Issues")); >> 1247: assertTrue(pr.body().contains("The main issue")); >> 1248: assertTrue(pr.body().contains("The jep issue (**JEP**)")); > > This part of the test isn't really doing anything. Should it perhaps remove the JEP label and verify that the JEP requirement is now met? I want to simulate the JEPBot to remove the `jep` label when the jep issue has been targeted. But I missed it. Added just now. ------------- PR: https://git.openjdk.java.net/skara/pull/1297 From mark.reinhold at oracle.com Wed Apr 13 16:06:32 2022 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 13 Apr 2022 09:06:32 -0700 Subject: [Investigation] Add JEP check to the PR In-Reply-To: References: Message-ID: <20220413090632.745851236@eggemoggin.niobe.net> I have to ask: Is this really worth the trouble? We?ve targeted and integrated over three hundred JEPs since the inception of the process in 2011. How many of those, besides JEP 295, were integrated prematurely? The solution you offer requires the JEP implementor to remember to type the `/jep` command in the PR. They could forget to do that just as easily as they forget to check the targeting status of the JEP itself. Now if you could automagically determine that a PR issue is a JEP implementation and block it when the JEP is not targeted, without the JEP implementor having to do anything special, then that might be more compelling -- but still, is it a problem worth solving? - Mark From gli at openjdk.java.net Wed Apr 13 16:31:14 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Wed, 13 Apr 2022 16:31:14 GMT Subject: RFR: SKARA-1096: New command and label for JEPs, similar to CSR [v5] In-Reply-To: References: <0-E7MblNqSvFkCZ6IEkmU1oEoWvphBbIZoVMFLRlPto=.a160de74-142c-466a-87fd-cbe76306bee8@github.com> Message-ID: <5tf6rv0BnPEynkhcCEJxs0vO5p04dULD3Q5OLnvyP3k=.c188acce-00ad-4f58-9bc9-4c0200e53957@github.com> On Tue, 12 Apr 2022 22:48:48 GMT, Erik Joelsson wrote: >> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: >> >> Disable the test in JiraProjectTests. > > bots/jep/src/main/java/org/openjdk/skara/bots/jep/JEPBot.java line 71: > >> 69: if (jepComment == null) { >> 70: if (pr.labelNames().contains(JEP_LABEL)) { >> 71: pr.removeLabel(JEP_LABEL); > > There is a potential race here. The /jep command adds the label first and the comment after. Not sure how to solve that. Ideally the label should be added after the comment. Another case: If there is a exiting jep command comment before. We may get the wrong comment and get the wrong issue in the following code. The error state will be fixed in the next JEPBot cycle, but it is not accepted because it seems that the error occurs frequently. Currently, the JEPBot implements the interface `Bot` and `WorkItem`. I would like to seperate the Bot (also named JEPBot) and the WorkItem (may named JEPStateCheckWorkItem). This new WorkItem maps to the pre PR, which is similar to the PullRequestWorkItem. And we need to override the method `WorkItem#concurrentWith` carefully to let the new WorkItem not concurrent with the PullRequestWorkItem if they operate the same PR. This is a common way to solve concurrency issues in the current SKARA "framework". ------------- PR: https://git.openjdk.java.net/skara/pull/1297 From lgxbslgx at gmail.com Wed Apr 13 19:46:45 2022 From: lgxbslgx at gmail.com (Guoxiong Li) Date: Thu, 14 Apr 2022 03:46:45 +0800 Subject: [Investigation] Add JEP check to the PR In-Reply-To: <20220413090632.745851236@eggemoggin.niobe.net> References: <20220413090632.745851236@eggemoggin.niobe.net> Message-ID: Hi mark, Thanks for the comment. > We?ve targeted and integrated over three hundred JEPs since the > inception of the process in 2011. How many of those, besides JEP > 295, were integrated prematurely? I have not counted the number of such JEPs like JEP-295. But I know such mistakes have already occured before and similar mistakes may occur in the future if we don't restrict it. > The solution you offer requires the JEP implementor to remember to > type the `/jep` command in the PR. They could forget to do that > just as easily as they forget to check the targeting status of the > JEP itself. When the JEP PR author integrates the patch without checking the targeting status, it happens at a moment and then the author needs to revert and redo the patch. If we have the `/jep` command, the author and all the reviewers can use it and all the readers (who are not reviewers) of the JEP PR can remind it. Considering the JEP PR review time may be from 1 week to 1 month, I think it is almost impossible to forget to use the command `/jep`. After using the command `/jep`, all the following work will be finished by the bot, and the author doesn't need to worry about it in the future. > Now if you could automagically determine that a PR issue is a JEP > implementation and block it when the JEP is not targeted, without > the JEP implementor having to do anything special, then that might > be more compelling I have proposed a completely automagical design[1] at the beginning, but it needs to change the JBS and needs more people and more time to complete the work. Erik and I have discussed the design[2][3]. In order to firstly meet the request from the developers and let the developers use the feature as soon as possible, I proposed this new design. > I have to ask: Is this really worth the trouble? > but still, is it a problem worth solving? It looks like an economics and management problem, but actually it is a personal emotional problem. I will analyse it from both aspects. *1. economics and management aspect* To implement this feature, we cost the following time: *cost_time = discussion time + coding time + review time + maintenance time (if have bug) + others* We may reduce the following time: jep_find_time: Everytime we review a JEP PR, we may spend time finding the original JEP to read. The newly added JEP link can reduce the time. jep_confirm_time: Everytime we want to integrate a JEP PR, we need to spend time to confirm the JEP status. If the JEP has not been targeted, we need to confirm several times. revert_time: when we make a mistake like JEP-925, we need to revert the patch. redo_time: After reverting the patch, we need to redo it. So all the time we reduce is: *reduce_time = (jep_find_time + jep_confirm_time + revert_time + redo_time + others) * ** (JEP PRs per year or mistake number per year)* ** (the years that JDK Project will live in the future)* So the problem `is it a problem worth solving?` can change to `does the reduce_time can be larger than the cost_time?`. We can know that the answer depends on how many years the JDK Project will live. *2. Personal emotional aspect* Please read the SKARA command reference[4] in the wiki. You can find there are many commands that we have not used and unnecessary, especially the `/open` command. When we firstly read the `/open` command, we may think the Github already have the `open` button, we don't need this command totally. When I meeted the situation that I couldn't re-open the PR which was closed by the bot[5], I found the `/open` command and understood that the `/open` command is very good and I thanked the SKRA developers for providing such a feature. Back to the `/jep` command, maybe now @mark you don't think it is necessary to have such a feature. But when you make the mistake like the developer @vicente in the JEP-925 and spend the extra time reverting/redoing the patch which actually can be avoided, you may think I need such a feature like `/jep`. When @Jonathan reported this feature enhancement [6], I believe he was from the developers' point of view and wanted to help the developers to reduce mistakes and not waste unnecessary time. It is also what I think now. It is also currently what the SKARA project needs to do. Best Regards, -- Guoxiong [1] https://mail.openjdk.java.net/pipermail/skara-dev/2021-December/005481.html [2] https://mail.openjdk.java.net/pipermail/skara-dev/2021-December/005490.html [3] https://mail.openjdk.java.net/pipermail/skara-dev/2022-March/005770.html [4] https://wiki.openjdk.java.net/display/SKARA [5] https://github.com/openjdk/jdk/pull/1898#issuecomment-813826446 [6] https://bugs.openjdk.java.net/browse/SKARA-1096 From erikj at openjdk.java.net Wed Apr 13 21:19:28 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 13 Apr 2022 21:19:28 GMT Subject: RFR: 1397: Skara doesn't handle tags with more than 4 digits in version number Message-ID: To be able to react to new tags, Skara needs to know how to parse our tag formats. For this we have the OpenJDKTag class. The current pattern for Verona based version numbers in this class is limited to tags with 4 digit version numbers. This becomes a problem when a JDK release uses more of the up to 7 possible version digits currently allowed in mainline since [JDK-8207849](https://bugs.openjdk.java.net/browse/JDK-8207849). This patch raises the limit to 7 digits to match what is currently possible in the JDK build. I'm also removing the redundant and incomplete "OpenJDKVersionPattern" which seemed to not serve any purpose as the existing OpenJFXVersionPattern covered everything for both JDK and JFX tags. ------------- Commit messages: - SKARA-1397 Changes: https://git.openjdk.java.net/skara/pull/1299/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1299&range=00 Issue: https://bugs.openjdk.java.net/browse/SKARA-1397 Stats: 28 lines in 2 files changed: 24 ins; 1 del; 3 mod Patch: https://git.openjdk.java.net/skara/pull/1299.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1299/head:pull/1299 PR: https://git.openjdk.java.net/skara/pull/1299 From erikj at openjdk.java.net Wed Apr 13 21:39:54 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 13 Apr 2022 21:39:54 GMT Subject: RFR: SKARA-1096: New command and label for JEPs, similar to CSR [v5] In-Reply-To: <5tf6rv0BnPEynkhcCEJxs0vO5p04dULD3Q5OLnvyP3k=.c188acce-00ad-4f58-9bc9-4c0200e53957@github.com> References: <0-E7MblNqSvFkCZ6IEkmU1oEoWvphBbIZoVMFLRlPto=.a160de74-142c-466a-87fd-cbe76306bee8@github.com> <5tf6rv0BnPEynkhcCEJxs0vO5p04dULD3Q5OLnvyP3k=.c188acce-00ad-4f58-9bc9-4c0200e53957@github.com> Message-ID: <5jSDMPlsLM0kGsSwcIXqBnnjN5sZZl0DKFDiFeGfVro=.a011f223-ceaf-4622-a183-41a2b5bfb2c8@github.com> On Wed, 13 Apr 2022 16:28:22 GMT, Guoxiong Li wrote: >> bots/jep/src/main/java/org/openjdk/skara/bots/jep/JEPBot.java line 71: >> >>> 69: if (jepComment == null) { >>> 70: if (pr.labelNames().contains(JEP_LABEL)) { >>> 71: pr.removeLabel(JEP_LABEL); >> >> There is a potential race here. The /jep command adds the label first and the comment after. Not sure how to solve that. Ideally the label should be added after the comment. > > Another case: If there is a exiting jep command comment before. We may get the wrong comment and get the wrong issue in the following code. > The error state will be fixed in the next JEPBot cycle, but it is not accepted because it seems that the error occurs frequently. > > Currently, the JEPBot implements the interface `Bot` and `WorkItem`. I would like to seperate the Bot (also named JEPBot) and the WorkItem (may named JEPStateCheckWorkItem). This new WorkItem maps to the pre PR, which is similar to the PullRequestWorkItem. And we need to override the method `WorkItem#concurrentWith` carefully to let the new WorkItem not concurrent with the PullRequestWorkItem if they operate the same PR. This is a common way to solve concurrency issues in the current SKARA "framework". Unfortunately that won't work. The concurrentWith construct only works for WorkItems within the same bot module. An important property of the different bot modules is that they can be run independently in different Java processes. We are for instance currently not running the PullRequestBot and the CSRBot in the same JVM instance. ------------- PR: https://git.openjdk.java.net/skara/pull/1297 From gli at openjdk.java.net Thu Apr 14 06:07:14 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Thu, 14 Apr 2022 06:07:14 GMT Subject: RFR: SKARA-1096: New command and label for JEPs, similar to CSR [v5] In-Reply-To: <5jSDMPlsLM0kGsSwcIXqBnnjN5sZZl0DKFDiFeGfVro=.a011f223-ceaf-4622-a183-41a2b5bfb2c8@github.com> References: <0-E7MblNqSvFkCZ6IEkmU1oEoWvphBbIZoVMFLRlPto=.a160de74-142c-466a-87fd-cbe76306bee8@github.com> <5tf6rv0BnPEynkhcCEJxs0vO5p04dULD3Q5OLnvyP3k=.c188acce-00ad-4f58-9bc9-4c0200e53957@github.com> <5jSDMPlsLM0kGsSwcIXqBnnjN5sZZl0DKFDiFeGfVro=.a011f223-ceaf-4622-a183-41a2b5bfb2c8@github.com> Message-ID: On Wed, 13 Apr 2022 21:37:13 GMT, Erik Joelsson wrote: > An important property of the different bot modules is that they can be run independently in different Java processes. We are for instance currently not running the PullRequestBot and the CSRBot in the same JVM instance. >From your description, I think this is a synchronization problem in a distributed system. Conceptually, the correct solution is using the distributed lock, but the current SKARA project don't have such mechanism. ------------- PR: https://git.openjdk.java.net/skara/pull/1297 From kcr at openjdk.java.net Thu Apr 14 12:47:58 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 14 Apr 2022 12:47:58 GMT Subject: RFR: 1397: Skara doesn't handle tags with more than 4 digits in version number In-Reply-To: References: Message-ID: On Wed, 13 Apr 2022 21:15:19 GMT, Erik Joelsson wrote: > To be able to react to new tags, Skara needs to know how to parse our tag formats. For this we have the OpenJDKTag class. The current pattern for Verona based version numbers in this class is limited to tags with 4 digit version numbers. This becomes a problem when a JDK release uses more of the up to 7 possible version digits currently allowed in mainline since [JDK-8207849](https://bugs.openjdk.java.net/browse/JDK-8207849). > > This patch raises the limit to 7 digits to match what is currently possible in the JDK build. I'm also removing the redundant and incomplete "OpenJDKVersionPattern" which seemed to not serve any purpose as the existing OpenJFXVersionPattern covered everything for both JDK and JFX tags. Marked as reviewed by kcr (Reviewer). ------------- PR: https://git.openjdk.java.net/skara/pull/1299 From erikj at openjdk.java.net Thu Apr 14 12:57:29 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 14 Apr 2022 12:57:29 GMT Subject: RFR: SKARA-1096: New command and label for JEPs, similar to CSR [v5] In-Reply-To: References: <0-E7MblNqSvFkCZ6IEkmU1oEoWvphBbIZoVMFLRlPto=.a160de74-142c-466a-87fd-cbe76306bee8@github.com> <5tf6rv0BnPEynkhcCEJxs0vO5p04dULD3Q5OLnvyP3k=.c188acce-00ad-4f58-9bc9-4c0200e53957@github.com> <5jSDMPlsLM0kGsSwcIXqBnnjN5sZZl0DKFDiFeGfVro=.a011f223-ceaf-4622-a183-41a2b5bfb2c8@github.com> Message-ID: <5EU1ywjXsJgm1-aLbaX7YPbsYbQ4u_LAfnX7idN_nOo=.26b4af26-5995-4ff6-b5df-9925330c5703@github.com> On Thu, 14 Apr 2022 06:04:29 GMT, Guoxiong Li wrote: >> Unfortunately that won't work. The concurrentWith construct only works for WorkItems within the same bot module. An important property of the different bot modules is that they can be run independently in different Java processes. We are for instance currently not running the PullRequestBot and the CSRBot in the same JVM instance. > >> An important property of the different bot modules is that they can be run independently in different Java processes. We are for instance currently not running the PullRequestBot and the CSRBot in the same JVM instance. > > From your description, I think this is a synchronization problem in a distributed system. Conceptually, the correct solution is using the distributed lock, but the current SKARA project don't have such mechanism. If change operations are done in the right order, it wouldn't be a problem. In this case, if the jep command added the label after the comment, it would be fine without synchronization. One can also argue that this issue will self correct anyway. The JEPBot will see the correct comment eventually and restore the label. The downside is that until that happens (which can easily take enough time to be confusing to users), the PR will show that the JEP has been targeted. ------------- PR: https://git.openjdk.java.net/skara/pull/1297 From erikj at openjdk.java.net Thu Apr 14 13:08:25 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 14 Apr 2022 13:08:25 GMT Subject: RFR: SKARA-1096: New command and label for JEPs, similar to CSR [v5] In-Reply-To: <5EU1ywjXsJgm1-aLbaX7YPbsYbQ4u_LAfnX7idN_nOo=.26b4af26-5995-4ff6-b5df-9925330c5703@github.com> References: <0-E7MblNqSvFkCZ6IEkmU1oEoWvphBbIZoVMFLRlPto=.a160de74-142c-466a-87fd-cbe76306bee8@github.com> <5tf6rv0BnPEynkhcCEJxs0vO5p04dULD3Q5OLnvyP3k=.c188acce-00ad-4f58-9bc9-4c0200e53957@github.com> <5jSDMPlsLM0kGsSwcIXqBnnjN5sZZl0DKFDiFeGfVro=.a011f223-ceaf-4622-a183-41a2b5bfb2c8@github.com> <5EU1ywjXsJgm1-aLbaX7YPbsYbQ4u_LAfnX7idN_nOo=.26b4af26-5995-4ff6-b5df-9925330c5703@github.com> Message-ID: On Thu, 14 Apr 2022 12:54:46 GMT, Erik Joelsson wrote: >>> An important property of the different bot modules is that they can be run independently in different Java processes. We are for instance currently not running the PullRequestBot and the CSRBot in the same JVM instance. >> >> From your description, I think this is a synchronization problem in a distributed system. Conceptually, the correct solution is using the distributed lock, but the current SKARA project don't have such mechanism. > > If change operations are done in the right order, it wouldn't be a problem. In this case, if the jep command added the label after the comment, it would be fine without synchronization. One can also argue that this issue will self correct anyway. The JEPBot will see the correct comment eventually and restore the label. The downside is that until that happens (which can easily take enough time to be confusing to users), the PR will show that the JEP has been targeted. I pondered on this some more and I think we can fix it. We can extend `CommandHandler::handle` for PRs with another parameter for returning a collection of labels to add to the PR. PullRequestCommandWorkItem calls this with an empty collection and any command that needs to add labels after the reply is posted can add them to this collection. ------------- PR: https://git.openjdk.java.net/skara/pull/1297 From erikj at openjdk.java.net Thu Apr 14 13:10:07 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 14 Apr 2022 13:10:07 GMT Subject: Integrated: 1397: Skara doesn't handle tags with more than 4 digits in version number In-Reply-To: References: Message-ID: On Wed, 13 Apr 2022 21:15:19 GMT, Erik Joelsson wrote: > To be able to react to new tags, Skara needs to know how to parse our tag formats. For this we have the OpenJDKTag class. The current pattern for Verona based version numbers in this class is limited to tags with 4 digit version numbers. This becomes a problem when a JDK release uses more of the up to 7 possible version digits currently allowed in mainline since [JDK-8207849](https://bugs.openjdk.java.net/browse/JDK-8207849). > > This patch raises the limit to 7 digits to match what is currently possible in the JDK build. I'm also removing the redundant and incomplete "OpenJDKVersionPattern" which seemed to not serve any purpose as the existing OpenJFXVersionPattern covered everything for both JDK and JFX tags. This pull request has now been integrated. Changeset: 4714cae0 Author: Erik Joelsson URL: https://git.openjdk.java.net/skara/commit/4714cae0521a93be8fb5760917c892893c042a5e Stats: 28 lines in 2 files changed: 24 ins; 1 del; 3 mod 1397: Skara doesn't handle tags with more than 4 digits in version number Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/skara/pull/1299 From magnus.ihse.bursie at oracle.com Thu Apr 14 13:17:39 2022 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 14 Apr 2022 15:17:39 +0200 Subject: [Investigation] Add JEP check to the PR In-Reply-To: <20220413090632.745851236@eggemoggin.niobe.net> References: <20220413090632.745851236@eggemoggin.niobe.net> Message-ID: On 2022-04-13 18:06, mark.reinhold at oracle.com wrote: > I have to ask: Is this really worth the trouble? If Guoxiong is taking the time to implement it, why not? I like the general concept -- it is similar to the /csr command. I think it is useful to have a correspondence between PRs and JEPs, just as we have a correspondence between PRs and CSR requests. (The idea has been along for a while, and I'm not certain the current suggestion is 100% correct, but it is certainly good enough to start with, and then we can adjust issues that arise later on -- just as we have done with almost all of the Skara development. Start by doing mostly right, and then fix edge cases or issues we discover later on.) /Magnus > > We?ve targeted and integrated over three hundred JEPs since the > inception of the process in 2011. How many of those, besides JEP > 295, were integrated prematurely? > > The solution you offer requires the JEP implementor to remember to > type the `/jep` command in the PR. They could forget to do that > just as easily as they forget to check the targeting status of the > JEP itself. > > Now if you could automagically determine that a PR issue is a JEP > implementation and block it when the JEP is not targeted, without > the JEP implementor having to do anything special, then that might > be more compelling -- but still, is it a problem worth solving? > > - Mark From gli at openjdk.java.net Fri Apr 15 06:48:28 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Fri, 15 Apr 2022 06:48:28 GMT Subject: RFR: SKARA-1096: New command and label for JEPs, similar to CSR [v5] In-Reply-To: References: <0-E7MblNqSvFkCZ6IEkmU1oEoWvphBbIZoVMFLRlPto=.a160de74-142c-466a-87fd-cbe76306bee8@github.com> <5tf6rv0BnPEynkhcCEJxs0vO5p04dULD3Q5OLnvyP3k=.c188acce-00ad-4f58-9bc9-4c0200e53957@github.com> <5jSDMPlsLM0kGsSwcIXqBnnjN5sZZl0DKFDiFeGfVro=.a011f223-ceaf-4622-a183-41a2b5bfb2c8@github.com> <5EU1ywjXsJgm1-aLbaX7YPbsYbQ4u_LAfnX7idN_nOo=.26b4af26-5995-4ff6-b5df-9925330c5703@github.com> Message-ID: On Thu, 14 Apr 2022 13:05:34 GMT, Erik Joelsson wrote: >> If change operations are done in the right order, it wouldn't be a problem. In this case, if the jep command added the label after the comment, it would be fine without synchronization. One can also argue that this issue will self correct anyway. The JEPBot will see the correct comment eventually and restore the label. The downside is that until that happens (which can easily take enough time to be confusing to users), the PR will show that the JEP has been targeted. > > I pondered on this some more and I think we can fix it. We can extend `CommandHandler::handle` for PRs with another parameter for returning a collection of labels to add to the PR. PullRequestCommandWorkItem calls this with an empty collection and any command that needs to add labels after the reply is posted can add them to this collection. Good idea. Actually, we also need to remove labels sometimes, such as the command `/jep unneeded`. What about returning a pair collections like `` ? ------------- PR: https://git.openjdk.java.net/skara/pull/1297 From erikj at openjdk.java.net Fri Apr 15 12:48:36 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 15 Apr 2022 12:48:36 GMT Subject: RFR: SKARA-1096: New command and label for JEPs, similar to CSR [v5] In-Reply-To: References: <0-E7MblNqSvFkCZ6IEkmU1oEoWvphBbIZoVMFLRlPto=.a160de74-142c-466a-87fd-cbe76306bee8@github.com> <5tf6rv0BnPEynkhcCEJxs0vO5p04dULD3Q5OLnvyP3k=.c188acce-00ad-4f58-9bc9-4c0200e53957@github.com> <5jSDMPlsLM0kGsSwcIXqBnnjN5sZZl0DKFDiFeGfVro=.a011f223-ceaf-4622-a183-41a2b5bfb2c8@github.com> <5EU1ywjXsJgm1-aLbaX7YPbsYbQ4u_LAfnX7idN_nOo=.26b4af26-5995-4ff6-b5df-9925330c5703@github.com> Message-ID: On Fri, 15 Apr 2022 06:45:37 GMT, Guoxiong Li wrote: >> I pondered on this some more and I think we can fix it. We can extend `CommandHandler::handle` for PRs with another parameter for returning a collection of labels to add to the PR. PullRequestCommandWorkItem calls this with an empty collection and any command that needs to add labels after the reply is posted can add them to this collection. > > Good idea. Actually, we also need to remove labels sometimes, such as the command `/jep unneeded`. What about returning a pair collections like `` ? At least in the jep command case, removing before posting comment is fine. I don't think we should add a dead parameter at this time. This can easily be extended if we ever find a need for it. ------------- PR: https://git.openjdk.java.net/skara/pull/1297 From erikj at openjdk.java.net Fri Apr 15 12:54:42 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 15 Apr 2022 12:54:42 GMT Subject: RFR: SKARA-1096: New command and label for JEPs, similar to CSR [v5] In-Reply-To: References: <0-E7MblNqSvFkCZ6IEkmU1oEoWvphBbIZoVMFLRlPto=.a160de74-142c-466a-87fd-cbe76306bee8@github.com> <5tf6rv0BnPEynkhcCEJxs0vO5p04dULD3Q5OLnvyP3k=.c188acce-00ad-4f58-9bc9-4c0200e53957@github.com> <5jSDMPlsLM0kGsSwcIXqBnnjN5sZZl0DKFDiFeGfVro=.a011f223-ceaf-4622-a183-41a2b5bfb2c8@github.com> <5EU1ywjXsJgm1-aLbaX7YPbsYbQ4u_LAfnX7idN_nOo=.26b4af26-5995-4ff6-b5df-9925330c5703@github.com> Message-ID: On Fri, 15 Apr 2022 12:45:40 GMT, Erik Joelsson wrote: >> Good idea. Actually, we also need to remove labels sometimes, such as the command `/jep unneeded`. What about returning a pair collections like `` ? > > At least in the jep command case, removing before posting comment is fine. I don't think we should add a dead parameter at this time. This can easily be extended if we ever find a need for it. Hm, at second thought, I take that back. Removing it after adding a new comment is better. ------------- PR: https://git.openjdk.java.net/skara/pull/1297 From gli at openjdk.java.net Mon Apr 18 09:19:52 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Mon, 18 Apr 2022 09:19:52 GMT Subject: RFR: SKARA-1096: New command and label for JEPs, similar to CSR [v7] In-Reply-To: <0-E7MblNqSvFkCZ6IEkmU1oEoWvphBbIZoVMFLRlPto=.a160de74-142c-466a-87fd-cbe76306bee8@github.com> References: <0-E7MblNqSvFkCZ6IEkmU1oEoWvphBbIZoVMFLRlPto=.a160de74-142c-466a-87fd-cbe76306bee8@github.com> Message-ID: > Hi all, > > This patch implements the features about the `/jep` command and JEP bot. The detailed designs and discussions are listed at [1][2]. > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong > > [1] https://mail.openjdk.java.net/pipermail/skara-dev/2021-December/005481.html > [2] https://mail.openjdk.java.net/pipermail/skara-dev/2022-March/005770.html Guoxiong Li has updated the pull request incrementally with two additional commits since the last revision: - Change labels after comment. Refactor the method 'processCommand' - Remove unnecessary parameter. ------------- Changes: - all: https://git.openjdk.java.net/skara/pull/1297/files - new: https://git.openjdk.java.net/skara/pull/1297/files/49f4dfa5..b5026119 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=skara&pr=1297&range=06 - incr: https://webrevs.openjdk.java.net/?repo=skara&pr=1297&range=05-06 Stats: 162 lines in 4 files changed: 118 ins; 30 del; 14 mod Patch: https://git.openjdk.java.net/skara/pull/1297.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1297/head:pull/1297 PR: https://git.openjdk.java.net/skara/pull/1297 From gli at openjdk.java.net Mon Apr 18 09:23:22 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Mon, 18 Apr 2022 09:23:22 GMT Subject: RFR: SKARA-1096: New command and label for JEPs, similar to CSR [v5] In-Reply-To: References: <0-E7MblNqSvFkCZ6IEkmU1oEoWvphBbIZoVMFLRlPto=.a160de74-142c-466a-87fd-cbe76306bee8@github.com> <5tf6rv0BnPEynkhcCEJxs0vO5p04dULD3Q5OLnvyP3k=.c188acce-00ad-4f58-9bc9-4c0200e53957@github.com> <5jSDMPlsLM0kGsSwcIXqBnnjN5sZZl0DKFDiFeGfVro=.a011f223-ceaf-4622-a183-41a2b5bfb2c8@github.com> <5EU1ywjXsJgm1-aLbaX7YPbsYbQ4u_LAfnX7idN_nOo=.26b4af26-5995-4ff6-b5df-9925330c5703@github.com> Message-ID: On Fri, 15 Apr 2022 12:51:52 GMT, Erik Joelsson wrote: >> At least in the jep command case, removing before posting comment is fine. I don't think we should add a dead parameter at this time. This can easily be extended if we ever find a need for it. > > Hm, at second thought, I take that back. Removing it after adding a new comment is better. I updated the code just now. The new code changes the PR labels after commenting just as we discussed before. And I refactored the method `processCommand` to avoid the multi-level nested conditional statements. ------------- PR: https://git.openjdk.java.net/skara/pull/1297 From erikj at openjdk.java.net Mon Apr 18 13:28:05 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 18 Apr 2022 13:28:05 GMT Subject: RFR: SKARA-1096: New command and label for JEPs, similar to CSR [v5] In-Reply-To: References: <0-E7MblNqSvFkCZ6IEkmU1oEoWvphBbIZoVMFLRlPto=.a160de74-142c-466a-87fd-cbe76306bee8@github.com> <5tf6rv0BnPEynkhcCEJxs0vO5p04dULD3Q5OLnvyP3k=.c188acce-00ad-4f58-9bc9-4c0200e53957@github.com> <5jSDMPlsLM0kGsSwcIXqBnnjN5sZZl0DKFDiFeGfVro=.a011f223-ceaf-4622-a183-41a2b5bfb2c8@github.com> <5EU1ywjXsJgm1-aLbaX7YPbsYbQ4u_LAfnX7idN_nOo=.26b4af26-5995-4ff6-b5df-9925330c5703@github.com> Message-ID: On Mon, 18 Apr 2022 09:20:32 GMT, Guoxiong Li wrote: >> Hm, at second thought, I take that back. Removing it after adding a new comment is better. > > I updated the code just now. The new code changes the PR labels after commenting just as we discussed before. > > And I refactored the method `processCommand` to avoid the multi-level nested conditional statements. This wasn't quite how I envisioned it. I don't think we need to overload the handle method. I also don't think we should use the return value for this. We already use the reply parameter as a kind of return value, a parameter that you modify to return a new state to the caller. My idea was to just add two more parameters to the existing handle method: ..., List labelsToAdd, List labelsToRemove) The logic in `processCommand` wouldn't need to change much. It would need to instantiate two ArrayLists in the case of `isCommit==false`, and then loop through each list to process the label changes on the pr. The `pr.addComment(writer.toString())` line would need to be moved from the end to just after each of the two `handle` calls. ------------- PR: https://git.openjdk.java.net/skara/pull/1297 From gli at openjdk.java.net Mon Apr 18 14:05:50 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Mon, 18 Apr 2022 14:05:50 GMT Subject: RFR: SKARA-1096: New command and label for JEPs, similar to CSR [v5] In-Reply-To: References: <0-E7MblNqSvFkCZ6IEkmU1oEoWvphBbIZoVMFLRlPto=.a160de74-142c-466a-87fd-cbe76306bee8@github.com> <5tf6rv0BnPEynkhcCEJxs0vO5p04dULD3Q5OLnvyP3k=.c188acce-00ad-4f58-9bc9-4c0200e53957@github.com> <5jSDMPlsLM0kGsSwcIXqBnnjN5sZZl0DKFDiFeGfVro=.a011f223-ceaf-4622-a183-41a2b5bfb2c8@github.com> <5EU1ywjXsJgm1-aLbaX7YPbsYbQ4u_LAfnX7idN_nOo=.26b4af26-5995-4ff6-b5df-9925330c5703@github.com> Message-ID: On Mon, 18 Apr 2022 13:25:26 GMT, Erik Joelsson wrote: >> I updated the code just now. The new code changes the PR labels after commenting just as we discussed before. >> >> And I refactored the method `processCommand` to avoid the multi-level nested conditional statements. > > This wasn't quite how I envisioned it. I don't think we need to overload the handle method. I also don't think we should use the return value for this. We already use the reply parameter as a kind of return value, a parameter that you modify to return a new state to the caller. My idea was to just add two more parameters to the existing handle method: > > ..., List labelsToAdd, List labelsToRemove) > > The logic in `processCommand` wouldn't need to change much. It would need to instantiate two ArrayLists in the case of `isCommit==false`, and then loop through each list to process the label changes on the pr. The `pr.addComment(writer.toString())` line would need to be moved from the end to just after each of the two `handle` calls. I misunderstood your idea previously. It is better to add two more parameters to the existing handle method than overload it. After adding two more parameters, the signatures of the method `handle` in all the commands need to be changed, too. Is it the expected behaviour? I need to confirm it, because it may change many files. --- The method `CommandHandler#changeLabelsAfterComment` can be added if we want to control it explicitly. If the `changeLabelsAfterComment` is true, it has these three steps: 1. add/remove labels before comment (in the method `handle`) 2. comment (in the method `processCommand`) 3. add/remove labels after comment (in the method `processCommand`) If the `changeLabelsAfterComment` is false, it has only two steps: 1. add/remove labels before comment (in the method `handle`) 2. comment (in the method `processCommand`) If we choose not to add the method `CommandHandler#changeLabelsAfterComment`, we may do the test `labelsToAdd is not empty && labelsToRemove is not empty` to implicitly confirm whether the command want to change the labels after commenting. This implicit way actually make the same three steps : 1. add/remove labels before comment (in the method `handle`) 2. comment (in the method `processCommand`) 3. add/remove labels after comment if existing (in the method `processCommand`) What's your opinion, explicitly or implicitly? ------------- PR: https://git.openjdk.java.net/skara/pull/1297 From gli at openjdk.java.net Mon Apr 18 14:47:12 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Mon, 18 Apr 2022 14:47:12 GMT Subject: RFR: SKARA-1096: New command and label for JEPs, similar to CSR [v5] In-Reply-To: References: <0-E7MblNqSvFkCZ6IEkmU1oEoWvphBbIZoVMFLRlPto=.a160de74-142c-466a-87fd-cbe76306bee8@github.com> <5tf6rv0BnPEynkhcCEJxs0vO5p04dULD3Q5OLnvyP3k=.c188acce-00ad-4f58-9bc9-4c0200e53957@github.com> <5jSDMPlsLM0kGsSwcIXqBnnjN5sZZl0DKFDiFeGfVro=.a011f223-ceaf-4622-a183-41a2b5bfb2c8@github.com> <5EU1ywjXsJgm1-aLbaX7YPbsYbQ4u_LAfnX7idN_nOo=.26b4af26-5995-4ff6-b5df-9925330c5703@github.com> Message-ID: On Mon, 18 Apr 2022 14:02:54 GMT, Guoxiong Li wrote: >> This wasn't quite how I envisioned it. I don't think we need to overload the handle method. I also don't think we should use the return value for this. We already use the reply parameter as a kind of return value, a parameter that you modify to return a new state to the caller. My idea was to just add two more parameters to the existing handle method: >> >> ..., List labelsToAdd, List labelsToRemove) >> >> The logic in `processCommand` wouldn't need to change much. It would need to instantiate two ArrayLists in the case of `isCommit==false`, and then loop through each list to process the label changes on the pr. The `pr.addComment(writer.toString())` line would need to be moved from the end to just after each of the two `handle` calls. > > I misunderstood your idea previously. It is better to add two more parameters to the existing handle method than overload it. > > After adding two more parameters, the signatures of the method `handle` in all the commands need to be changed, too. Is it the expected behaviour? I need to confirm it, because it may change many files. > > --- > > The method `CommandHandler#changeLabelsAfterComment` can be added if we want to control it explicitly. > If the `changeLabelsAfterComment` is true, it has these three steps: > 1. add/remove labels before comment (in the method `handle`) > 2. comment (in the method `processCommand`) > 3. add/remove labels after comment (in the method `processCommand`) > > If the `changeLabelsAfterComment` is false, it has only two steps: > 1. add/remove labels before comment (in the method `handle`) > 2. comment (in the method `processCommand`) > > If we choose not to add the method `CommandHandler#changeLabelsAfterComment`, we may do the test `labelsToAdd is not empty && labelsToRemove is not empty` to implicitly confirm whether the command want to change the labels after commenting. This implicit way actually make the same three steps : > 1. add/remove labels before comment (in the method `handle`) > 2. comment (in the method `processCommand`) > 3. add/remove labels after comment if existing (in the method `processCommand`) > > What's your opinion, explicitly or implicitly? Now, I think the implicit way is better and follow your idea above. ------------- PR: https://git.openjdk.java.net/skara/pull/1297 From duke at openjdk.java.net Mon Apr 18 14:53:53 2022 From: duke at openjdk.java.net (duke) Date: Mon, 18 Apr 2022 14:53:53 GMT Subject: Withdrawn: SKARA-1340: Correct email domain not always used when adding a contributor to a PR In-Reply-To: References: Message-ID: On Tue, 8 Feb 2022 08:25:24 GMT, Guoxiong Li wrote: > Hi all, > > The contributor command uses the static domain `openjdk.org` which causes this issue. This patch uses the domain of the configuration instead of the static `openjdk.org` and adjusts the test cases. > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/skara/pull/1281 From gli at openjdk.java.net Mon Apr 18 15:26:53 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Mon, 18 Apr 2022 15:26:53 GMT Subject: RFR: SKARA-1096: New command and label for JEPs, similar to CSR [v5] In-Reply-To: References: <0-E7MblNqSvFkCZ6IEkmU1oEoWvphBbIZoVMFLRlPto=.a160de74-142c-466a-87fd-cbe76306bee8@github.com> Message-ID: On Tue, 12 Apr 2022 12:52:52 GMT, Erik Joelsson wrote: >> I think this is totally unwarranted and there was not enough previous discussion at the JDK level to actually conclude anything about the need for this and how it should work. A JEP is not like a CSR-request. It is extremely rare to create an issue and raise a PR and have someone then say "this really needs a JEP". >> >> David > >> I think this is totally unwarranted and there was not enough previous discussion at the JDK level to actually conclude anything about the need for this and how it should work. A JEP is not like a CSR-request. It is extremely rare to create an issue and raise a PR and have someone then say "this really needs a JEP". > > That isn't the intended usecase here. To issue the command, a JEP must already exist, as you have to reference a bugid/jepid pointing to the JEP. This command is mostly intended for the author to run, to make it clearer that the PR is related to a JEP. @erikj79 During revising the code, I find two issues: 1. the `AllowCommand` and `RejectCommand` are not used in the `PullRequestCommandWorkItem` 2. the `AllowCommand`, `RejectCommand` and `OpenCommand` are not documented at the wiki [1] Is it the intentional behavious or a bug or unfinished work? [1] https://wiki.openjdk.java.net/display/SKARA/Pull+Request+Commands ------------- PR: https://git.openjdk.java.net/skara/pull/1297 From gli at openjdk.java.net Mon Apr 18 17:04:51 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Mon, 18 Apr 2022 17:04:51 GMT Subject: RFR: SKARA-1096: New command and label for JEPs, similar to CSR [v8] In-Reply-To: <0-E7MblNqSvFkCZ6IEkmU1oEoWvphBbIZoVMFLRlPto=.a160de74-142c-466a-87fd-cbe76306bee8@github.com> References: <0-E7MblNqSvFkCZ6IEkmU1oEoWvphBbIZoVMFLRlPto=.a160de74-142c-466a-87fd-cbe76306bee8@github.com> Message-ID: > Hi all, > > This patch implements the features about the `/jep` command and JEP bot. The detailed designs and discussions are listed at [1][2]. > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong > > [1] https://mail.openjdk.java.net/pipermail/skara-dev/2021-December/005481.html > [2] https://mail.openjdk.java.net/pipermail/skara-dev/2022-March/005770.html Guoxiong Li has updated the pull request incrementally with two additional commits since the last revision: - Redo: Change labels after comment. - Revert: Change labels after comment. ------------- Changes: - all: https://git.openjdk.java.net/skara/pull/1297/files - new: https://git.openjdk.java.net/skara/pull/1297/files/b5026119..da63618f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=skara&pr=1297&range=07 - incr: https://webrevs.openjdk.java.net/?repo=skara&pr=1297&range=06-07 Stats: 238 lines in 17 files changed: 66 ins; 134 del; 38 mod Patch: https://git.openjdk.java.net/skara/pull/1297.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1297/head:pull/1297 PR: https://git.openjdk.java.net/skara/pull/1297 From erikj at openjdk.java.net Mon Apr 18 21:03:49 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 18 Apr 2022 21:03:49 GMT Subject: RFR: 1400: GitlabMergeRequest sometimes associates reviews with the wrong commit Message-ID: GitlabMergeRequset::reviews can sometimes associate a review with the wrong commit. This can happen if multiple commits have the same "created_at" date (the date the commit was pushed to gitlab). In this case, sorting on date will leave the older commit last. When later comparing the date of each commit with the date of a review note, the older commit gets picked. The consequence of this is that a review can end up stuck with "Re-review required" if the repository requires new reviews for new commits. This patch fixes this by first reversing the order of the commits and then trusting the stable sort to keep any commits considered equal in the correct (reversed) order. ------------- Commit messages: - SKARA-1400 Changes: https://git.openjdk.java.net/skara/pull/1300/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1300&range=00 Issue: https://bugs.openjdk.java.net/browse/SKARA-1400 Stats: 7 lines in 1 file changed: 5 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/skara/pull/1300.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1300/head:pull/1300 PR: https://git.openjdk.java.net/skara/pull/1300 From kcr at openjdk.java.net Mon Apr 18 21:12:29 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 18 Apr 2022 21:12:29 GMT Subject: RFR: 1400: GitlabMergeRequest sometimes associates reviews with the wrong commit In-Reply-To: References: Message-ID: On Mon, 18 Apr 2022 20:59:01 GMT, Erik Joelsson wrote: > GitlabMergeRequset::reviews can sometimes associate a review with the wrong commit. This can happen if multiple commits have the same "created_at" date (the date the commit was pushed to gitlab). In this case, sorting on date will leave the older commit last. When later comparing the date of each commit with the date of a review note, the older commit gets picked. > > The consequence of this is that a review can end up stuck with "Re-review required" if the repository requires new reviews for new commits. > > This patch fixes this by first reversing the order of the commits and then trusting the stable sort to keep any commits considered equal in the correct (reversed) order. Marked as reviewed by kcr (Reviewer). ------------- PR: https://git.openjdk.java.net/skara/pull/1300 From erikj at openjdk.java.net Mon Apr 18 22:32:32 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 18 Apr 2022 22:32:32 GMT Subject: Integrated: 1400: GitlabMergeRequest sometimes associates reviews with the wrong commit In-Reply-To: References: Message-ID: On Mon, 18 Apr 2022 20:59:01 GMT, Erik Joelsson wrote: > GitlabMergeRequset::reviews can sometimes associate a review with the wrong commit. This can happen if multiple commits have the same "created_at" date (the date the commit was pushed to gitlab). In this case, sorting on date will leave the older commit last. When later comparing the date of each commit with the date of a review note, the older commit gets picked. > > The consequence of this is that a review can end up stuck with "Re-review required" if the repository requires new reviews for new commits. > > This patch fixes this by first reversing the order of the commits and then trusting the stable sort to keep any commits considered equal in the correct (reversed) order. This pull request has now been integrated. Changeset: 3a889291 Author: Erik Joelsson URL: https://git.openjdk.java.net/skara/commit/3a889291b80d8ac52a780ebfc7e08cfd2a46a4c8 Stats: 7 lines in 1 file changed: 5 ins; 0 del; 2 mod 1400: GitlabMergeRequest sometimes associates reviews with the wrong commit Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/skara/pull/1300 From erikj at openjdk.java.net Tue Apr 19 15:12:30 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 19 Apr 2022 15:12:30 GMT Subject: RFR: SKARA-1096: New command and label for JEPs, similar to CSR [v5] In-Reply-To: References: <0-E7MblNqSvFkCZ6IEkmU1oEoWvphBbIZoVMFLRlPto=.a160de74-142c-466a-87fd-cbe76306bee8@github.com> Message-ID: On Tue, 12 Apr 2022 12:52:52 GMT, Erik Joelsson wrote: >> I think this is totally unwarranted and there was not enough previous discussion at the JDK level to actually conclude anything about the need for this and how it should work. A JEP is not like a CSR-request. It is extremely rare to create an issue and raise a PR and have someone then say "this really needs a JEP". >> >> David > >> I think this is totally unwarranted and there was not enough previous discussion at the JDK level to actually conclude anything about the need for this and how it should work. A JEP is not like a CSR-request. It is extremely rare to create an issue and raise a PR and have someone then say "this really needs a JEP". > > That isn't the intended usecase here. To issue the command, a JEP must already exist, as you have to reference a bugid/jepid pointing to the JEP. This command is mostly intended for the author to run, to make it clearer that the PR is related to a JEP. > @erikj79 During revising the code, I find two issues: > > 1. the `AllowCommand` and `RejectCommand` are not used in the `PullRequestCommandWorkItem` > 2. the `AllowCommand`, `RejectCommand` and `OpenCommand` are not documented at the wiki [1] > > Is it the intentional behavious or a bug or unfinished work? > > [1] https://wiki.openjdk.java.net/display/SKARA/Pull+Request+Commands The OpenCommand should probably be documented on the wiki. The other two I don't know the purpose of. I would say unfinished/unclear/prototype work from pretty early in Skara development. I don't think we need them. ------------- PR: https://git.openjdk.java.net/skara/pull/1297 From erikj at openjdk.java.net Tue Apr 19 15:16:51 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 19 Apr 2022 15:16:51 GMT Subject: RFR: SKARA-1096: New command and label for JEPs, similar to CSR [v5] In-Reply-To: References: <0-E7MblNqSvFkCZ6IEkmU1oEoWvphBbIZoVMFLRlPto=.a160de74-142c-466a-87fd-cbe76306bee8@github.com> <5tf6rv0BnPEynkhcCEJxs0vO5p04dULD3Q5OLnvyP3k=.c188acce-00ad-4f58-9bc9-4c0200e53957@github.com> <5jSDMPlsLM0kGsSwcIXqBnnjN5sZZl0DKFDiFeGfVro=.a011f223-ceaf-4622-a183-41a2b5bfb2c8@github.com> <5EU1ywjXsJgm1-aLbaX7YPbsYbQ4u_LAfnX7idN_nOo=.26b4af26-5995-4ff6-b5df-9925330c5703@github.com> Message-ID: On Mon, 18 Apr 2022 14:44:17 GMT, Guoxiong Li wrote: >> I misunderstood your idea previously. It is better to add two more parameters to the existing handle method than overload it. >> >> After adding two more parameters, the signatures of the method `handle` in all the commands need to be changed, too. Is it the expected behaviour? I need to confirm it, because it may change many files. >> >> --- >> >> The method `CommandHandler#changeLabelsAfterComment` can be added if we want to control it explicitly. >> If the `changeLabelsAfterComment` is true, it has these three steps: >> 1. add/remove labels before comment (in the method `handle`) >> 2. comment (in the method `processCommand`) >> 3. add/remove labels after comment (in the method `processCommand`) >> >> If the `changeLabelsAfterComment` is false, it has only two steps: >> 1. add/remove labels before comment (in the method `handle`) >> 2. comment (in the method `processCommand`) >> >> If we choose not to add the method `CommandHandler#changeLabelsAfterComment`, we may do the test `labelsToAdd is not empty && labelsToRemove is not empty` to implicitly confirm whether the command want to change the labels after commenting. This implicit way actually make the same three steps : >> 1. add/remove labels before comment (in the method `handle`) >> 2. comment (in the method `processCommand`) >> 3. add/remove labels after comment if existing (in the method `processCommand`) >> >> What's your opinion, explicitly or implicitly? > > Now, I think the implicit way is better and follow your idea above. I don't think we need `CommandHandler#changeLabelsAfterComment`, it just adds extra complexity. ------------- PR: https://git.openjdk.java.net/skara/pull/1297 From erikj at openjdk.java.net Tue Apr 19 15:32:31 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 19 Apr 2022 15:32:31 GMT Subject: RFR: SKARA-1096: New command and label for JEPs, similar to CSR [v8] In-Reply-To: References: <0-E7MblNqSvFkCZ6IEkmU1oEoWvphBbIZoVMFLRlPto=.a160de74-142c-466a-87fd-cbe76306bee8@github.com> Message-ID: On Mon, 18 Apr 2022 17:04:51 GMT, Guoxiong Li wrote: >> Hi all, >> >> This patch implements the features about the `/jep` command and JEP bot. The detailed designs and discussions are listed at [1][2]. >> >> Thanks for taking the time to review. >> >> Best Regards, >> -- Guoxiong >> >> [1] https://mail.openjdk.java.net/pipermail/skara-dev/2021-December/005481.html >> [2] https://mail.openjdk.java.net/pipermail/skara-dev/2022-March/005770.html > > Guoxiong Li has updated the pull request incrementally with two additional commits since the last revision: > > - Redo: Change labels after comment. > - Revert: Change labels after comment. This is starting to look good now. My only remaining concern is that the total execution time of the Skara tests goes up quite a bit with all these new and rather expensive tests. Not sure we can do much about this, perhaps something to investigate separately. ------------- PR: https://git.openjdk.java.net/skara/pull/1297 From ihse at openjdk.java.net Tue Apr 19 15:37:00 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Tue, 19 Apr 2022 15:37:00 GMT Subject: RFR: SKARA-1096: New command and label for JEPs, similar to CSR [v8] In-Reply-To: References: <0-E7MblNqSvFkCZ6IEkmU1oEoWvphBbIZoVMFLRlPto=.a160de74-142c-466a-87fd-cbe76306bee8@github.com> Message-ID: On Mon, 18 Apr 2022 17:04:51 GMT, Guoxiong Li wrote: >> Hi all, >> >> This patch implements the features about the `/jep` command and JEP bot. The detailed designs and discussions are listed at [1][2]. >> >> Thanks for taking the time to review. >> >> Best Regards, >> -- Guoxiong >> >> [1] https://mail.openjdk.java.net/pipermail/skara-dev/2021-December/005481.html >> [2] https://mail.openjdk.java.net/pipermail/skara-dev/2022-March/005770.html > > Guoxiong Li has updated the pull request incrementally with two additional commits since the last revision: > > - Redo: Change labels after comment. > - Revert: Change labels after comment. FWIW, I've looked through all the code in the PR now. I added a few suggestions on user fronting strings, otherwise I have not much to add. I'll mark this as approved, but you do need to get Erik's approval as well. (And please fix the strings :)) ------------- Marked as reviewed by ihse (Reviewer). PR: https://git.openjdk.java.net/skara/pull/1297 From magnus.ihse.bursie at oracle.com Tue Apr 19 15:46:13 2022 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 19 Apr 2022 17:46:13 +0200 Subject: Fwd: Integrated: 8285012: Problemlist gc/arguments/TestUseCompressedOopsFlagsWithUlimit.java In-Reply-To: References: Message-ID: This mail subject starts with "Integrated:" even though it is an RFR. WTF? Is this just an odd error caused by cosmic ray bitflipping, or something we should investigate? /Magnus -------- Forwarded Message -------- Subject: Integrated: 8285012: Problemlist gc/arguments/TestUseCompressedOopsFlagsWithUlimit.java Date: Tue, 19 Apr 2022 15:34:39 GMT From: Thomas Schatzl To: hotspot-gc-dev at openjdk.java.net Hi all, please review this problemlisting of the test `gc/arguments/TestUseCompressedOopsFlagsWithUlimit.java` since it causes lots of noise. Thanks, Thomas ------------- Commit messages: - Problemlist test Changes: https://git.openjdk.java.net/jdk/pull/8299/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8299&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8285012 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8299.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8299/head:pull/8299 PR: https://git.openjdk.java.net/jdk/pull/8299 From erikj at openjdk.java.net Tue Apr 19 15:48:13 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 19 Apr 2022 15:48:13 GMT Subject: RFR: SKARA-1096: New command and label for JEPs, similar to CSR [v8] In-Reply-To: References: <0-E7MblNqSvFkCZ6IEkmU1oEoWvphBbIZoVMFLRlPto=.a160de74-142c-466a-87fd-cbe76306bee8@github.com> Message-ID: <9wGHtuPgRubfkwWJPq2TuaZZrNFAWA2zAUvlVjROzD8=.a5bb02a0-8cb7-4f52-99c6-ef2e627ba5ec@github.com> On Tue, 19 Apr 2022 15:29:24 GMT, Erik Joelsson wrote: > This is starting to look good now. My only remaining concern is that the total execution time of the Skara tests goes up quite a bit with all these new and rather expensive tests. Not sure we can do much about this, perhaps something to investigate separately. I take that back, when I ran all the tests just now, the total time was close enough to what it usually is. Last time I ran it took considerably longer. Might have just been a fluke. ------------- PR: https://git.openjdk.java.net/skara/pull/1297 From ihse at openjdk.java.net Tue Apr 19 15:48:15 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Tue, 19 Apr 2022 15:48:15 GMT Subject: RFR: SKARA-1096: New command and label for JEPs, similar to CSR [v8] In-Reply-To: References: <0-E7MblNqSvFkCZ6IEkmU1oEoWvphBbIZoVMFLRlPto=.a160de74-142c-466a-87fd-cbe76306bee8@github.com> Message-ID: On Mon, 18 Apr 2022 17:04:51 GMT, Guoxiong Li wrote: >> Hi all, >> >> This patch implements the features about the `/jep` command and JEP bot. The detailed designs and discussions are listed at [1][2]. >> >> Thanks for taking the time to review. >> >> Best Regards, >> -- Guoxiong >> >> [1] https://mail.openjdk.java.net/pipermail/skara-dev/2021-December/005481.html >> [2] https://mail.openjdk.java.net/pipermail/skara-dev/2022-March/005770.html > > Guoxiong Li has updated the pull request incrementally with two additional commits since the last revision: > > - Redo: Change labels after comment. > - Revert: Change labels after comment. bots/pr/src/main/java/org/openjdk/skara/bots/pr/CommandHandler.java line 38: > 36: default void handle(PullRequestBot bot, PullRequest pr, CensusInstance censusInstance, Path scratchPath, CommandInvocation command, > 37: List allComments, PrintWriter reply, List labelsToAdd, List labelsToRemove) { > 38: } I keep coming back to this in my reviewing. It would be better if we did not have to update all those other places where handle() is implemented. I might be thinking wrong here, but I believe that you should be able to keep the original `handle(PullRequestBot bot, PullRequest pr, CensusInstance censusInstance, Path scratchPath, CommandInvocation command, List allComments, PrintWriter reply)` method, and instead add the new `handle` (with `List labelsToAdd, List labelsToRemove` as a default method, with the implementatation handle(bot, pr, censusInstance, scratchPath, command, allComments, reply); This way, the commands that need the new label handling mechanism can implement the new handle override with the extended argument list. All other commands needs no change. Once again, I don't feel 100% confident I'm thinking correctly here, but it seems to me like it would work, and be a better solution. bots/pr/src/main/java/org/openjdk/skara/bots/pr/JEPCommand.java line 62: > 60: The project prefix of the issue ID (`JDK-` in the above examples) is optional. > 61: But the `JEP-` or `jep-` prefix is required when you provide a JEP ID. > 62: And the issue type must be `JEP`. Suggestion: The project prefix (`JDK-` in the above examples) is optional if you use an issue ID. The issue type in that case must be `JEP`. The `JEP-` or `jep-` prefix is required if you instead provide a JEP ID. bots/pr/src/main/java/org/openjdk/skara/bots/pr/JEPCommand.java line 68: > 66: private Optional getJepIssue(String args, PullRequestBot bot) { > 67: Optional jbsIssue; > 68: if (args.startsWith("jep-") || args.startsWith("JEP-")) { Suggestion: if (args.toUpperCase().startsWith("JEP-")) { Then variations like "Jep-123" is also accepted. bots/pr/src/main/java/org/openjdk/skara/bots/pr/JEPCommand.java line 98: > 96: } > 97: reply.println(unneededMarker); > 98: reply.println("determined that the [JEP](https://openjdk.java.net/jeps) request " + Suggestion: reply.println("determined that the JEP request " + bots/pr/src/main/java/org/openjdk/skara/bots/pr/JEPCommand.java line 150: > 148: @Override > 149: public String description() { > 150: return "require a JDK Enhancement Proposal for this pull request"; Suggestion: return "require a JDK Enhancement Proposal (JEP) for this pull request"; ------------- PR: https://git.openjdk.java.net/skara/pull/1297 From erikj at openjdk.java.net Tue Apr 19 15:48:15 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 19 Apr 2022 15:48:15 GMT Subject: RFR: SKARA-1096: New command and label for JEPs, similar to CSR [v8] In-Reply-To: References: <0-E7MblNqSvFkCZ6IEkmU1oEoWvphBbIZoVMFLRlPto=.a160de74-142c-466a-87fd-cbe76306bee8@github.com> Message-ID: On Tue, 19 Apr 2022 15:40:51 GMT, Magnus Ihse Bursie wrote: >> Guoxiong Li has updated the pull request incrementally with two additional commits since the last revision: >> >> - Redo: Change labels after comment. >> - Revert: Change labels after comment. > > bots/pr/src/main/java/org/openjdk/skara/bots/pr/CommandHandler.java line 38: > >> 36: default void handle(PullRequestBot bot, PullRequest pr, CensusInstance censusInstance, Path scratchPath, CommandInvocation command, >> 37: List allComments, PrintWriter reply, List labelsToAdd, List labelsToRemove) { >> 38: } > > I keep coming back to this in my reviewing. It would be better if we did not have to update all those other places where handle() is implemented. > > I might be thinking wrong here, but I believe that you should be able to keep the original `handle(PullRequestBot bot, PullRequest pr, CensusInstance censusInstance, Path scratchPath, CommandInvocation command, List allComments, PrintWriter reply)` method, and instead add the new `handle` (with `List labelsToAdd, List labelsToRemove` as a default method, with the implementatation > > handle(bot, pr, censusInstance, scratchPath, command, allComments, reply); > > > This way, the commands that need the new label handling mechanism can implement the new handle override with the extended argument list. All other commands needs no change. > > Once again, I don't feel 100% confident I'm thinking correctly here, but it seems to me like it would work, and be a better solution. You are correct Magnus, that would be nicer indeed. ------------- PR: https://git.openjdk.java.net/skara/pull/1297 From erikj at openjdk.java.net Tue Apr 19 15:48:14 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 19 Apr 2022 15:48:14 GMT Subject: RFR: SKARA-1096: New command and label for JEPs, similar to CSR [v5] In-Reply-To: References: <0-E7MblNqSvFkCZ6IEkmU1oEoWvphBbIZoVMFLRlPto=.a160de74-142c-466a-87fd-cbe76306bee8@github.com> <5tf6rv0BnPEynkhcCEJxs0vO5p04dULD3Q5OLnvyP3k=.c188acce-00ad-4f58-9bc9-4c0200e53957@github.com> <5jSDMPlsLM0kGsSwcIXqBnnjN5sZZl0DKFDiFeGfVro=.a011f223-ceaf-4622-a183-41a2b5bfb2c8@github.com> <5EU1ywjXsJgm1-aLbaX7YPbsYbQ4u_LAfnX7idN_nOo=.26b4af26-5995-4ff6-b5df-9925330c5703@github.com> Message-ID: <7HjYba1OLtpI3w5peL431HCW4CKEm3RB2Tf-D_4fPzA=.f368bb0d-c9c6-474b-9f9a-eb6d1cba275d@github.com> On Tue, 19 Apr 2022 15:13:48 GMT, Erik Joelsson wrote: >> Now, I think the implicit way is better and follow your idea above. > > I don't think we need `CommandHandler#changeLabelsAfterComment`, it just adds extra complexity. Yes, I meant to change the signature. Updating it in all the command implementations is fine. ------------- PR: https://git.openjdk.java.net/skara/pull/1297 From ihse at openjdk.java.net Tue Apr 19 15:48:16 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Tue, 19 Apr 2022 15:48:16 GMT Subject: RFR: SKARA-1096: New command and label for JEPs, similar to CSR [v8] In-Reply-To: References: <0-E7MblNqSvFkCZ6IEkmU1oEoWvphBbIZoVMFLRlPto=.a160de74-142c-466a-87fd-cbe76306bee8@github.com> Message-ID: On Tue, 19 Apr 2022 15:22:45 GMT, Magnus Ihse Bursie wrote: >> Guoxiong Li has updated the pull request incrementally with two additional commits since the last revision: >> >> - Redo: Change labels after comment. >> - Revert: Change labels after comment. > > bots/pr/src/main/java/org/openjdk/skara/bots/pr/JEPCommand.java line 98: > >> 96: } >> 97: reply.println(unneededMarker); >> 98: reply.println("determined that the [JEP](https://openjdk.java.net/jeps) request " + > > Suggestion: > > reply.println("determined that the JEP request " + ... and possibly join with the line below, depending on line length (hard to tell in github review mode) ------------- PR: https://git.openjdk.java.net/skara/pull/1297 From erik.joelsson at oracle.com Tue Apr 19 15:52:12 2022 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Tue, 19 Apr 2022 08:52:12 -0700 Subject: Fwd: Integrated: 8285012: Problemlist gc/arguments/TestUseCompressedOopsFlagsWithUlimit.java In-Reply-To: References: Message-ID: <80b43415-4c6f-25e2-6da1-7665a6aee625@oracle.com> It looks like the mailinglist bridge didn't get a chance to send any emails before the PR was already integrated. The PR didn't initially have any label, so there wasn't much time between it getting 'hotspot-gc' and being integrated. Even though it probably should say RFR for the first few emails, it's also not wrong to mark them as integrated, as the PR was already integrated and didn't need any more review. /Erik On 2022-04-19 08:46, Magnus Ihse Bursie wrote: > This mail subject starts with "Integrated:" even though it is an RFR. > WTF? Is this just an odd error caused by cosmic ray bitflipping, or > something we should investigate? > > /Magnus > > > -------- Forwarded Message -------- > Subject:???? Integrated: 8285012: Problemlist > gc/arguments/TestUseCompressedOopsFlagsWithUlimit.java > Date:???? Tue, 19 Apr 2022 15:34:39 GMT > From:???? Thomas Schatzl > To:???? hotspot-gc-dev at openjdk.java.net > > > > Hi all, > > please review this problemlisting of the test > `gc/arguments/TestUseCompressedOopsFlagsWithUlimit.java` since it > causes lots of noise. > > Thanks, > Thomas > > ------------- > > Commit messages: > - Problemlist test > > Changes: https://git.openjdk.java.net/jdk/pull/8299/files > Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8299&range=00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8285012 > Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod > Patch: https://git.openjdk.java.net/jdk/pull/8299.diff > Fetch: git fetch https://git.openjdk.java.net/jdk > pull/8299/head:pull/8299 > > PR: https://git.openjdk.java.net/jdk/pull/8299 From erikj at openjdk.java.net Tue Apr 19 16:04:15 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 19 Apr 2022 16:04:15 GMT Subject: RFR: SKARA-1096: New command and label for JEPs, similar to CSR [v8] In-Reply-To: References: <0-E7MblNqSvFkCZ6IEkmU1oEoWvphBbIZoVMFLRlPto=.a160de74-142c-466a-87fd-cbe76306bee8@github.com> Message-ID: On Tue, 19 Apr 2022 15:45:13 GMT, Erik Joelsson wrote: >> bots/pr/src/main/java/org/openjdk/skara/bots/pr/CommandHandler.java line 38: >> >>> 36: default void handle(PullRequestBot bot, PullRequest pr, CensusInstance censusInstance, Path scratchPath, CommandInvocation command, >>> 37: List allComments, PrintWriter reply, List labelsToAdd, List labelsToRemove) { >>> 38: } >> >> I keep coming back to this in my reviewing. It would be better if we did not have to update all those other places where handle() is implemented. >> >> I might be thinking wrong here, but I believe that you should be able to keep the original `handle(PullRequestBot bot, PullRequest pr, CensusInstance censusInstance, Path scratchPath, CommandInvocation command, List allComments, PrintWriter reply)` method, and instead add the new `handle` (with `List labelsToAdd, List labelsToRemove` as a default method, with the implementatation >> >> handle(bot, pr, censusInstance, scratchPath, command, allComments, reply); >> >> >> This way, the commands that need the new label handling mechanism can implement the new handle override with the extended argument list. All other commands needs no change. >> >> Once again, I don't feel 100% confident I'm thinking correctly here, but it seems to me like it would work, and be a better solution. > > You are correct Magnus, that would be nicer indeed. The drawback of doing that is that JEPCommand would still need to implement the old handle method, which doesn't make sense for it to do. Unless we also add a default empty implementation for the original handle method. @lgxbslgx If you want to change it to avoid touching all the other commands, using default methods in the interface instead, that's ok, but I'm also ok leaving it as it is. ------------- PR: https://git.openjdk.java.net/skara/pull/1297 From gli at openjdk.java.net Tue Apr 19 16:53:35 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Tue, 19 Apr 2022 16:53:35 GMT Subject: RFR: SKARA-1096: New command and label for JEPs, similar to CSR [v9] In-Reply-To: <0-E7MblNqSvFkCZ6IEkmU1oEoWvphBbIZoVMFLRlPto=.a160de74-142c-466a-87fd-cbe76306bee8@github.com> References: <0-E7MblNqSvFkCZ6IEkmU1oEoWvphBbIZoVMFLRlPto=.a160de74-142c-466a-87fd-cbe76306bee8@github.com> Message-ID: > Hi all, > > This patch implements the features about the `/jep` command and JEP bot. The detailed designs and discussions are listed at [1][2]. > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong > > [1] https://mail.openjdk.java.net/pipermail/skara-dev/2021-December/005481.html > [2] https://mail.openjdk.java.net/pipermail/skara-dev/2022-March/005770.html Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: Fix some strings and the test cases. ------------- Changes: - all: https://git.openjdk.java.net/skara/pull/1297/files - new: https://git.openjdk.java.net/skara/pull/1297/files/da63618f..84a87bc4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=skara&pr=1297&range=08 - incr: https://webrevs.openjdk.java.net/?repo=skara&pr=1297&range=07-08 Stats: 33 lines in 2 files changed: 18 ins; 3 del; 12 mod Patch: https://git.openjdk.java.net/skara/pull/1297.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1297/head:pull/1297 PR: https://git.openjdk.java.net/skara/pull/1297 From gli at openjdk.java.net Tue Apr 19 16:53:35 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Tue, 19 Apr 2022 16:53:35 GMT Subject: RFR: SKARA-1096: New command and label for JEPs, similar to CSR [v8] In-Reply-To: References: <0-E7MblNqSvFkCZ6IEkmU1oEoWvphBbIZoVMFLRlPto=.a160de74-142c-466a-87fd-cbe76306bee8@github.com> Message-ID: On Tue, 19 Apr 2022 15:57:37 GMT, Erik Joelsson wrote: >> You are correct Magnus, that would be nicer indeed. > > The drawback of doing that is that JEPCommand would still need to implement the old handle method, which doesn't make sense for it to do. Unless we also add a default empty implementation for the original handle method. > > @lgxbslgx If you want to change it to avoid touching all the other commands, using default methods in the interface instead, that's ok, but I'm also ok leaving it as it is. > This way, the commands that need the new label handling mechanism can implement the new handle override with the extended argument list. All other commands needs no change. If we obey this convention which adds a new "bridge" `handle` method. Next time, we want to add another parameter and add a new `handle` method, too. The interface `CommandHandler` will have sevaral such "bridge" `handle` methods in the future which are actually unnecessary. @erikj79, @magicus and I may feel good with it because we added or reviewed it. But in the future, the new SKARA developers may be confused by it. In other words, the maintainment of the project may become a little more complex. > but I'm also ok leaving it as it is. I would like to keep the code as it is now. ------------- PR: https://git.openjdk.java.net/skara/pull/1297 From gli at openjdk.java.net Tue Apr 19 16:53:36 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Tue, 19 Apr 2022 16:53:36 GMT Subject: RFR: SKARA-1096: New command and label for JEPs, similar to CSR [v8] In-Reply-To: References: <0-E7MblNqSvFkCZ6IEkmU1oEoWvphBbIZoVMFLRlPto=.a160de74-142c-466a-87fd-cbe76306bee8@github.com> Message-ID: On Tue, 19 Apr 2022 15:19:21 GMT, Magnus Ihse Bursie wrote: >> Guoxiong Li has updated the pull request incrementally with two additional commits since the last revision: >> >> - Redo: Change labels after comment. >> - Revert: Change labels after comment. > > bots/pr/src/main/java/org/openjdk/skara/bots/pr/JEPCommand.java line 62: > >> 60: The project prefix of the issue ID (`JDK-` in the above examples) is optional. >> 61: But the `JEP-` or `jep-` prefix is required when you provide a JEP ID. >> 62: And the issue type must be `JEP`. > > Suggestion: > > The project prefix (`JDK-` in the above examples) is optional if you use an issue ID. > The issue type in that case must be `JEP`. > The `JEP-` or `jep-` prefix is required if you instead provide a JEP ID. Fixed. > bots/pr/src/main/java/org/openjdk/skara/bots/pr/JEPCommand.java line 68: > >> 66: private Optional getJepIssue(String args, PullRequestBot bot) { >> 67: Optional jbsIssue; >> 68: if (args.startsWith("jep-") || args.startsWith("JEP-")) { > > Suggestion: > > if (args.toUpperCase().startsWith("JEP-")) { > > > Then variations like "Jep-123" is also accepted. Fixed and added a test case. > bots/pr/src/main/java/org/openjdk/skara/bots/pr/JEPCommand.java line 150: > >> 148: @Override >> 149: public String description() { >> 150: return "require a JDK Enhancement Proposal for this pull request"; > > Suggestion: > > return "require a JDK Enhancement Proposal (JEP) for this pull request"; Fixed. ------------- PR: https://git.openjdk.java.net/skara/pull/1297 From gli at openjdk.java.net Tue Apr 19 16:53:37 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Tue, 19 Apr 2022 16:53:37 GMT Subject: RFR: SKARA-1096: New command and label for JEPs, similar to CSR [v8] In-Reply-To: References: <0-E7MblNqSvFkCZ6IEkmU1oEoWvphBbIZoVMFLRlPto=.a160de74-142c-466a-87fd-cbe76306bee8@github.com> Message-ID: On Tue, 19 Apr 2022 15:23:28 GMT, Magnus Ihse Bursie wrote: >> bots/pr/src/main/java/org/openjdk/skara/bots/pr/JEPCommand.java line 98: >> >>> 96: } >>> 97: reply.println(unneededMarker); >>> 98: reply.println("determined that the [JEP](https://openjdk.java.net/jeps) request " + >> >> Suggestion: >> >> reply.println("determined that the JEP request " + > > ... and possibly join with the line below, depending on line length (hard to tell in github review mode) Fixed and joined with next line and revised the corresponding tests. ------------- PR: https://git.openjdk.java.net/skara/pull/1297 From gli at openjdk.java.net Tue Apr 19 16:56:55 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Tue, 19 Apr 2022 16:56:55 GMT Subject: RFR: SKARA-1096: New command and label for JEPs, similar to CSR [v8] In-Reply-To: References: <0-E7MblNqSvFkCZ6IEkmU1oEoWvphBbIZoVMFLRlPto=.a160de74-142c-466a-87fd-cbe76306bee8@github.com> Message-ID: On Tue, 19 Apr 2022 15:34:04 GMT, Magnus Ihse Bursie wrote: >> Guoxiong Li has updated the pull request incrementally with two additional commits since the last revision: >> >> - Redo: Change labels after comment. >> - Revert: Change labels after comment. > > FWIW, I've looked through all the code in the PR now. I added a few suggestions on user fronting strings, otherwise I have not much to add. I'll mark this as approved, but you do need to get Erik's approval as well. (And please fix the strings :)) @magicus Thanks for the review. I updated the code just now. ------------- PR: https://git.openjdk.java.net/skara/pull/1297 From ihse at openjdk.java.net Tue Apr 19 18:52:40 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Tue, 19 Apr 2022 18:52:40 GMT Subject: RFR: SKARA-1096: New command and label for JEPs, similar to CSR [v8] In-Reply-To: References: <0-E7MblNqSvFkCZ6IEkmU1oEoWvphBbIZoVMFLRlPto=.a160de74-142c-466a-87fd-cbe76306bee8@github.com> Message-ID: On Tue, 19 Apr 2022 16:48:19 GMT, Guoxiong Li wrote: >> The drawback of doing that is that JEPCommand would still need to implement the old handle method, which doesn't make sense for it to do. Unless we also add a default empty implementation for the original handle method. >> >> @lgxbslgx If you want to change it to avoid touching all the other commands, using default methods in the interface instead, that's ok, but I'm also ok leaving it as it is. > >> This way, the commands that need the new label handling mechanism can implement the new handle override with the extended argument list. All other commands needs no change. > > If we obey this convention which adds a new "bridge" `handle` method. Next time, we want to add another parameter and add a new `handle` method, too. The interface `CommandHandler` will have sevaral such "bridge" `handle` methods in the future which are actually unnecessary. @erikj79, @magicus and I may feel good with it because we added or reviewed it. But in the future, the new SKARA developers may be confused by it. In other words, the maintainment of the project may become a little more complex. > >> but I'm also ok leaving it as it is. > > I would like to keep the code as it is now. No, each and every implementation of `CommandHandler` would only implement a single `handle()` method. At least, if I'm thinking correctly about this. :-) When processing WorkItems, in `processCommand`, we call the "long" version, with the two extra arguments. This will have a default implementation in the `CommandHandler` interface, which calls the "short" version, dropping the two last arguments. The "short" version will have a default implementation, which does nothing. (This is exactly the case of the code right now, without this PR.) So, my suggestion is that we leave the old "short" method untouched, add a new "long" method which by default delegates to the "short" method, and call the new "long" method in `processCommand`. Then all old implementations can keep their "short" implementations, and everything will work as before. JEPCommand will need to override the new "long" version instead (and can just ignore the "short" version), and everything will work perfect for it too. And if we in the future need to add further arguments, we can do the same procedure again -- add a new long-long method, which deletages to the long method, etc. I believe this was the exact use case that the `default` method implementation in interfaces was intended for. ------------- PR: https://git.openjdk.java.net/skara/pull/1297 From ihse at openjdk.java.net Tue Apr 19 18:52:41 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Tue, 19 Apr 2022 18:52:41 GMT Subject: RFR: SKARA-1096: New command and label for JEPs, similar to CSR [v8] In-Reply-To: References: <0-E7MblNqSvFkCZ6IEkmU1oEoWvphBbIZoVMFLRlPto=.a160de74-142c-466a-87fd-cbe76306bee8@github.com> Message-ID: On Tue, 19 Apr 2022 18:48:38 GMT, Magnus Ihse Bursie wrote: >>> This way, the commands that need the new label handling mechanism can implement the new handle override with the extended argument list. All other commands needs no change. >> >> If we obey this convention which adds a new "bridge" `handle` method. Next time, we want to add another parameter and add a new `handle` method, too. The interface `CommandHandler` will have sevaral such "bridge" `handle` methods in the future which are actually unnecessary. @erikj79, @magicus and I may feel good with it because we added or reviewed it. But in the future, the new SKARA developers may be confused by it. In other words, the maintainment of the project may become a little more complex. >> >>> but I'm also ok leaving it as it is. >> >> I would like to keep the code as it is now. > > No, each and every implementation of `CommandHandler` would only implement a single `handle()` method. > > At least, if I'm thinking correctly about this. :-) > > When processing WorkItems, in `processCommand`, we call the "long" version, with the two extra arguments. This will have a default implementation in the `CommandHandler` interface, which calls the "short" version, dropping the two last arguments. The "short" version will have a default implementation, which does nothing. (This is exactly the case of the code right now, without this PR.) > > So, my suggestion is that we leave the old "short" method untouched, add a new "long" method which by default delegates to the "short" method, and call the new "long" method in `processCommand`. > > Then all old implementations can keep their "short" implementations, and everything will work as before. > > JEPCommand will need to override the new "long" version instead (and can just ignore the "short" version), and everything will work perfect for it too. > > And if we in the future need to add further arguments, we can do the same procedure again -- add a new long-long method, which deletages to the long method, etc. > > I believe this was the exact use case that the `default` method implementation in interfaces was intended for. And I believe this solution is so much better that I'd strongly argue that we should not keep the code as it looks right now. There is no need nor good reason to push these additional argument to command implementations. ------------- PR: https://git.openjdk.java.net/skara/pull/1297 From magnus.ihse.bursie at oracle.com Tue Apr 19 19:10:37 2022 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 19 Apr 2022 21:10:37 +0200 Subject: Fwd: Integrated: 8285012: Problemlist gc/arguments/TestUseCompressedOopsFlagsWithUlimit.java In-Reply-To: <80b43415-4c6f-25e2-6da1-7665a6aee625@oracle.com> References: <80b43415-4c6f-25e2-6da1-7665a6aee625@oracle.com> Message-ID: <301b87e5-387c-1c70-834a-c20598f567f8@oracle.com> On 2022-04-19 17:52, erik.joelsson at oracle.com wrote: > It looks like the mailinglist bridge didn't get a chance to send any > emails before the PR was already integrated. The PR didn't initially > have any label, so there wasn't much time between it getting > 'hotspot-gc' and being integrated. Even though it probably should say > RFR for the first few emails, it's also not wrong to mark them as > integrated, as the PR was already integrated and didn't need any more > review. So all mails that are sent after a PR is actually integrated are prefixed with "Integrated:" instead of "RFR:"? I thought it was due to the *type* of mail, so mails originating from Github comments got RFR (or created PRs), while mails originating from bots actually integrating the PR starts with "Integrated". But that is not the case? This particular case might not be common, but it is definitely confusing. I'd consider it a bug. /Magnus > > /Erik > > On 2022-04-19 08:46, Magnus Ihse Bursie wrote: >> This mail subject starts with "Integrated:" even though it is an RFR. >> WTF? Is this just an odd error caused by cosmic ray bitflipping, or >> something we should investigate? >> >> /Magnus >> >> >> -------- Forwarded Message -------- >> Subject:???? Integrated: 8285012: Problemlist >> gc/arguments/TestUseCompressedOopsFlagsWithUlimit.java >> Date:???? Tue, 19 Apr 2022 15:34:39 GMT >> From:???? Thomas Schatzl >> To:???? hotspot-gc-dev at openjdk.java.net >> >> >> >> Hi all, >> >> please review this problemlisting of the test >> `gc/arguments/TestUseCompressedOopsFlagsWithUlimit.java` since it >> causes lots of noise. >> >> Thanks, >> Thomas >> >> ------------- >> >> Commit messages: >> - Problemlist test >> >> Changes: https://git.openjdk.java.net/jdk/pull/8299/files >> Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8299&range=00 >> Issue: https://bugs.openjdk.java.net/browse/JDK-8285012 >> Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod >> Patch: https://git.openjdk.java.net/jdk/pull/8299.diff >> Fetch: git fetch https://git.openjdk.java.net/jdk >> pull/8299/head:pull/8299 >> >> PR: https://git.openjdk.java.net/jdk/pull/8299 From erik.joelsson at oracle.com Tue Apr 19 19:35:46 2022 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Tue, 19 Apr 2022 12:35:46 -0700 Subject: Fwd: Integrated: 8285012: Problemlist gc/arguments/TestUseCompressedOopsFlagsWithUlimit.java In-Reply-To: <301b87e5-387c-1c70-834a-c20598f567f8@oracle.com> References: <80b43415-4c6f-25e2-6da1-7665a6aee625@oracle.com> <301b87e5-387c-1c70-834a-c20598f567f8@oracle.com> Message-ID: On 2022-04-19 12:10, Magnus Ihse Bursie wrote: > On 2022-04-19 17:52, erik.joelsson at oracle.com wrote: >> It looks like the mailinglist bridge didn't get a chance to send any >> emails before the PR was already integrated. The PR didn't initially >> have any label, so there wasn't much time between it getting >> 'hotspot-gc' and being integrated. Even though it probably should say >> RFR for the first few emails, it's also not wrong to mark them as >> integrated, as the PR was already integrated and didn't need any more >> review. > > So all mails that are sent after a PR is actually integrated are > prefixed with "Integrated:" instead of "RFR:"? I thought it was due to > the *type* of mail, so mails originating from Github comments got RFR > (or created PRs), while mails originating from bots actually > integrating the PR starts with "Integrated". But that is not the case? > All the kinds of mails you are describing here are sent by the MailingListBridgeBot. I wasn't aware of this until now, but that is apparently how it works. The prefix is based on the current state of the PR. See [1] if you are curious. > This particular case might not be common, but it is definitely > confusing. I'd consider it a bug. > It may be confusing, it depends on your assumption/internal model of how Skara works. I kinda think it makes sense, but could go either way if I got to pick at equal cost. However, given that this is the way it currently works, I'm going to lean quite heavily in that direction as I don't think rewriting this logic is a good idea. /Erik [1] bots/mlbridge/src/main/java/org/openjdk/skara/bots/mlbridge/ReviewArchive.java:105 > /Magnus > >> >> /Erik >> >> On 2022-04-19 08:46, Magnus Ihse Bursie wrote: >>> This mail subject starts with "Integrated:" even though it is an >>> RFR. WTF? Is this just an odd error caused by cosmic ray >>> bitflipping, or something we should investigate? >>> >>> /Magnus >>> >>> >>> -------- Forwarded Message -------- >>> Subject:???? Integrated: 8285012: Problemlist >>> gc/arguments/TestUseCompressedOopsFlagsWithUlimit.java >>> Date:???? Tue, 19 Apr 2022 15:34:39 GMT >>> From:???? Thomas Schatzl >>> To:???? hotspot-gc-dev at openjdk.java.net >>> >>> >>> >>> Hi all, >>> >>> please review this problemlisting of the test >>> `gc/arguments/TestUseCompressedOopsFlagsWithUlimit.java` since it >>> causes lots of noise. >>> >>> Thanks, >>> Thomas >>> >>> ------------- >>> >>> Commit messages: >>> - Problemlist test >>> >>> Changes: https://git.openjdk.java.net/jdk/pull/8299/files >>> Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8299&range=00 >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8285012 >>> Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod >>> Patch: https://git.openjdk.java.net/jdk/pull/8299.diff >>> Fetch: git fetch https://git.openjdk.java.net/jdk >>> pull/8299/head:pull/8299 >>> >>> PR: https://git.openjdk.java.net/jdk/pull/8299 > From magnus.ihse.bursie at oracle.com Tue Apr 19 20:20:40 2022 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 19 Apr 2022 22:20:40 +0200 Subject: Fwd: Integrated: 8285012: Problemlist gc/arguments/TestUseCompressedOopsFlagsWithUlimit.java In-Reply-To: References: <80b43415-4c6f-25e2-6da1-7665a6aee625@oracle.com> <301b87e5-387c-1c70-834a-c20598f567f8@oracle.com> Message-ID: <2534d417-b126-e3d0-5487-a71b1c439cc2@oracle.com> On 2022-04-19 21:35, erik.joelsson at oracle.com wrote > On 2022-04-19 12:10, Magnus Ihse Bursie wrote: >> On 2022-04-19 17:52, erik.joelsson at oracle.com wrote: >>> It looks like the mailinglist bridge didn't get a chance to send any >>> emails before the PR was already integrated. The PR didn't initially >>> have any label, so there wasn't much time between it getting >>> 'hotspot-gc' and being integrated. Even though it probably should >>> say RFR for the first few emails, it's also not wrong to mark them >>> as integrated, as the PR was already integrated and didn't need any >>> more review. >> >> So all mails that are sent after a PR is actually integrated are >> prefixed with "Integrated:" instead of "RFR:"? I thought it was due >> to the *type* of mail, so mails originating from Github comments got >> RFR (or created PRs), while mails originating from bots actually >> integrating the PR starts with "Integrated". But that is not the case? >> > All the kinds of mails you are describing here are sent by the > MailingListBridgeBot. I wasn't aware of this until now, but that is > apparently how it works. The prefix is based on the current state of > the PR. See [1] if you are curious. Oooookay... >> This particular case might not be common, but it is definitely >> confusing. I'd consider it a bug. >> > It may be confusing, it depends on your assumption/internal model of > how Skara works. I kinda think it makes sense, but could go either way > if I got to pick at equal cost. However, given that this is the way it > currently works, I'm going to lean quite heavily in that direction as > I don't think rewriting this logic is a good idea. I'll grudgingly agree that perhaps we should leave it be then. I'm not happy about it, but "if it ain't broken don't fix it" -- the risks and costs involved in changing this is too large. /Magnus > > /Erik > > [1] > bots/mlbridge/src/main/java/org/openjdk/skara/bots/mlbridge/ReviewArchive.java:105 >> /Magnus >> >>> >>> /Erik >>> >>> On 2022-04-19 08:46, Magnus Ihse Bursie wrote: >>>> This mail subject starts with "Integrated:" even though it is an >>>> RFR. WTF? Is this just an odd error caused by cosmic ray >>>> bitflipping, or something we should investigate? >>>> >>>> /Magnus >>>> >>>> >>>> -------- Forwarded Message -------- >>>> Subject:???? Integrated: 8285012: Problemlist >>>> gc/arguments/TestUseCompressedOopsFlagsWithUlimit.java >>>> Date:???? Tue, 19 Apr 2022 15:34:39 GMT >>>> From:???? Thomas Schatzl >>>> To:???? hotspot-gc-dev at openjdk.java.net >>>> >>>> >>>> >>>> Hi all, >>>> >>>> please review this problemlisting of the test >>>> `gc/arguments/TestUseCompressedOopsFlagsWithUlimit.java` since it >>>> causes lots of noise. >>>> >>>> Thanks, >>>> Thomas >>>> >>>> ------------- >>>> >>>> Commit messages: >>>> - Problemlist test >>>> >>>> Changes: https://git.openjdk.java.net/jdk/pull/8299/files >>>> Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8299&range=00 >>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8285012 >>>> Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod >>>> Patch: https://git.openjdk.java.net/jdk/pull/8299.diff >>>> Fetch: git fetch https://git.openjdk.java.net/jdk >>>> pull/8299/head:pull/8299 >>>> >>>> PR: https://git.openjdk.java.net/jdk/pull/8299 >> From gli at openjdk.java.net Wed Apr 20 10:03:58 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Wed, 20 Apr 2022 10:03:58 GMT Subject: RFR: SKARA-1096: New command and label for JEPs, similar to CSR [v5] In-Reply-To: References: <0-E7MblNqSvFkCZ6IEkmU1oEoWvphBbIZoVMFLRlPto=.a160de74-142c-466a-87fd-cbe76306bee8@github.com> Message-ID: On Tue, 19 Apr 2022 15:09:33 GMT, Erik Joelsson wrote: > The OpenCommand should probably be documented on the wiki. @erikj79 Could you help add the OpenCommand to the wiki? Or we can file an issue to record it so that it can be added in the future by others? > The other two I don't know the purpose of. I would say unfinished/unclear/prototype work from pretty early in Skara development. I don't think we need them. It is good to file a new issue to remove it instead of leaving it which may confuse other developers. ------------- PR: https://git.openjdk.java.net/skara/pull/1297 From gli at openjdk.java.net Wed Apr 20 10:52:24 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Wed, 20 Apr 2022 10:52:24 GMT Subject: RFR: SKARA-1096: New command and label for JEPs, similar to CSR [v10] In-Reply-To: <0-E7MblNqSvFkCZ6IEkmU1oEoWvphBbIZoVMFLRlPto=.a160de74-142c-466a-87fd-cbe76306bee8@github.com> References: <0-E7MblNqSvFkCZ6IEkmU1oEoWvphBbIZoVMFLRlPto=.a160de74-142c-466a-87fd-cbe76306bee8@github.com> Message-ID: > Hi all, > > This patch implements the features about the `/jep` command and JEP bot. The detailed designs and discussions are listed at [1][2]. > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong > > [1] https://mail.openjdk.java.net/pipermail/skara-dev/2021-December/005481.html > [2] https://mail.openjdk.java.net/pipermail/skara-dev/2022-March/005770.html Guoxiong Li has updated the pull request incrementally with two additional commits since the last revision: - Polish - Overload the handle method and revert the change of unrelated commands ------------- Changes: - all: https://git.openjdk.java.net/skara/pull/1297/files - new: https://git.openjdk.java.net/skara/pull/1297/files/84a87bc4..ee84a2b9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=skara&pr=1297&range=09 - incr: https://webrevs.openjdk.java.net/?repo=skara&pr=1297&range=08-09 Stats: 62 lines in 15 files changed: 22 ins; 15 del; 25 mod Patch: https://git.openjdk.java.net/skara/pull/1297.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1297/head:pull/1297 PR: https://git.openjdk.java.net/skara/pull/1297 From gli at openjdk.java.net Wed Apr 20 10:52:25 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Wed, 20 Apr 2022 10:52:25 GMT Subject: RFR: SKARA-1096: New command and label for JEPs, similar to CSR [v8] In-Reply-To: References: <0-E7MblNqSvFkCZ6IEkmU1oEoWvphBbIZoVMFLRlPto=.a160de74-142c-466a-87fd-cbe76306bee8@github.com> Message-ID: On Tue, 19 Apr 2022 15:57:37 GMT, Erik Joelsson wrote: >> You are correct Magnus, that would be nicer indeed. > > The drawback of doing that is that JEPCommand would still need to implement the old handle method, which doesn't make sense for it to do. Unless we also add a default empty implementation for the original handle method. > > @lgxbslgx If you want to change it to avoid touching all the other commands, using default methods in the interface instead, that's ok, but I'm also ok leaving it as it is. > @erikj79, @magicus and I may feel good with it because we added or reviewed it. But in the future, the new SKARA developers may be confused by it. In other words, the maintainment of the project may become a little more complex. @magicus previously, I thought it is not good to add the "bridge" "long" methods because it may confused other developers. > There is no need nor good reason to push these additional argument to command implementations. But now, I think that the additional parameter `labelsToAdd` and `labelsToRemove` which have not used in much cammands confused the developers, too and are more terrible. So I agree with you and updated the code just now. ------------- PR: https://git.openjdk.java.net/skara/pull/1297 From gli at openjdk.java.net Wed Apr 20 11:05:08 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Wed, 20 Apr 2022 11:05:08 GMT Subject: RFR: SKARA-1096: New command and label for JEPs, similar to CSR [v5] In-Reply-To: References: <0-E7MblNqSvFkCZ6IEkmU1oEoWvphBbIZoVMFLRlPto=.a160de74-142c-466a-87fd-cbe76306bee8@github.com> Message-ID: On Wed, 20 Apr 2022 10:01:05 GMT, Guoxiong Li wrote: > It is good to file a new issue to remove it instead of leaving it which may confuse other developers. I filed https://bugs.openjdk.java.net/browse/SKARA-1402 to follow up. ------------- PR: https://git.openjdk.java.net/skara/pull/1297 From david.holmes at oracle.com Wed Apr 20 12:45:00 2022 From: david.holmes at oracle.com (David Holmes) Date: Wed, 20 Apr 2022 22:45:00 +1000 Subject: Fwd: Integrated: 8285012: Problemlist gc/arguments/TestUseCompressedOopsFlagsWithUlimit.java In-Reply-To: References: Message-ID: <08574bcd-11c6-b6cb-6608-b690ddc548d3@oracle.com> Just FYI we see this a lot with ProblemListing issues as normally the reviewer is arranged directly in the gatekeeper chat and gets to the PR as soon as it exists and reviews it; then it gets integrated. All before the mail bot gets a chance to send the original RFR email. But it only seems to happen if the integration happens before the first email is sent. I can add a comment to a PR that has already been integrated and the subject line is what you would expect. Cheers, David On 20/04/2022 1:46 am, Magnus Ihse Bursie wrote: > This mail subject starts with "Integrated:" even though it is an RFR. > WTF? Is this just an odd error caused by cosmic ray bitflipping, or > something we should investigate? > > /Magnus > > > -------- Forwarded Message -------- > Subject:???? Integrated: 8285012: Problemlist > gc/arguments/TestUseCompressedOopsFlagsWithUlimit.java > Date:???? Tue, 19 Apr 2022 15:34:39 GMT > From:???? Thomas Schatzl > To:???? hotspot-gc-dev at openjdk.java.net > > > > Hi all, > > please review this problemlisting of the test > `gc/arguments/TestUseCompressedOopsFlagsWithUlimit.java` since it causes > lots of noise. > > Thanks, > Thomas > > ------------- > > Commit messages: > - Problemlist test > > Changes: https://git.openjdk.java.net/jdk/pull/8299/files > Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8299&range=00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8285012 > Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod > Patch: https://git.openjdk.java.net/jdk/pull/8299.diff > Fetch: git fetch https://git.openjdk.java.net/jdk pull/8299/head:pull/8299 > > PR: https://git.openjdk.java.net/jdk/pull/8299 From gli at openjdk.java.net Wed Apr 20 13:28:26 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Wed, 20 Apr 2022 13:28:26 GMT Subject: RFR: 1402: Cleanup some commands Message-ID: Hi all, During the review of SKARA-1096 [1][2], I find the `AllowCommand` and `RejectCommand` are never used. And the `OpenCommand` and `CleanCommand` have many unused import statements. It is good to remove/cleanup them. Thanks for taking the time to review. Best Regards, -- Guoxiong [1] https://bugs.openjdk.java.net/browse/SKARA-1096 [2] https://github.com/openjdk/skara/pull/1297 ------------- Commit messages: - 1402: Cleanup some commands Changes: https://git.openjdk.java.net/skara/pull/1301/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1301&range=00 Issue: https://bugs.openjdk.java.net/browse/SKARA-1402 Stats: 500 lines in 6 files changed: 0 ins; 498 del; 2 mod Patch: https://git.openjdk.java.net/skara/pull/1301.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1301/head:pull/1301 PR: https://git.openjdk.java.net/skara/pull/1301 From erik.joelsson at oracle.com Wed Apr 20 13:44:28 2022 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Wed, 20 Apr 2022 06:44:28 -0700 Subject: Fwd: Integrated: 8285012: Problemlist gc/arguments/TestUseCompressedOopsFlagsWithUlimit.java In-Reply-To: <08574bcd-11c6-b6cb-6608-b690ddc548d3@oracle.com> References: <08574bcd-11c6-b6cb-6608-b690ddc548d3@oracle.com> Message-ID: On 2022-04-20 05:45, David Holmes wrote: > Just FYI we see this a lot with ProblemListing issues as normally the > reviewer is arranged directly in the gatekeeper chat and gets to the > PR as soon as it exists and reviews it; then it gets integrated. All > before the mail bot gets a chance to send the original RFR email. > > But it only seems to happen if the integration happens before the > first email is sent. I can add a comment to a PR that has already been > integrated and the subject line is what you would expect. > That is an interesting data point, and perhaps that makes it worth looking into. /Erik > Cheers, > David > > On 20/04/2022 1:46 am, Magnus Ihse Bursie wrote: >> This mail subject starts with "Integrated:" even though it is an RFR. >> WTF? Is this just an odd error caused by cosmic ray bitflipping, or >> something we should investigate? >> >> /Magnus >> >> >> -------- Forwarded Message -------- >> Subject:???? Integrated: 8285012: Problemlist >> gc/arguments/TestUseCompressedOopsFlagsWithUlimit.java >> Date:???? Tue, 19 Apr 2022 15:34:39 GMT >> From:???? Thomas Schatzl >> To:???? hotspot-gc-dev at openjdk.java.net >> >> >> >> Hi all, >> >> please review this problemlisting of the test >> `gc/arguments/TestUseCompressedOopsFlagsWithUlimit.java` since it >> causes lots of noise. >> >> Thanks, >> Thomas >> >> ------------- >> >> Commit messages: >> - Problemlist test >> >> Changes: https://git.openjdk.java.net/jdk/pull/8299/files >> Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8299&range=00 >> Issue: https://bugs.openjdk.java.net/browse/JDK-8285012 >> Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod >> Patch: https://git.openjdk.java.net/jdk/pull/8299.diff >> Fetch: git fetch https://git.openjdk.java.net/jdk >> pull/8299/head:pull/8299 >> >> PR: https://git.openjdk.java.net/jdk/pull/8299 From erikj at openjdk.java.net Wed Apr 20 17:43:31 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 20 Apr 2022 17:43:31 GMT Subject: RFR: SKARA-1096: New command and label for JEPs, similar to CSR [v10] In-Reply-To: References: <0-E7MblNqSvFkCZ6IEkmU1oEoWvphBbIZoVMFLRlPto=.a160de74-142c-466a-87fd-cbe76306bee8@github.com> Message-ID: On Wed, 20 Apr 2022 10:52:24 GMT, Guoxiong Li wrote: >> Hi all, >> >> This patch implements the features about the `/jep` command and JEP bot. The detailed designs and discussions are listed at [1][2]. >> >> Thanks for taking the time to review. >> >> Best Regards, >> -- Guoxiong >> >> [1] https://mail.openjdk.java.net/pipermail/skara-dev/2021-December/005481.html >> [2] https://mail.openjdk.java.net/pipermail/skara-dev/2022-March/005770.html > > Guoxiong Li has updated the pull request incrementally with two additional commits since the last revision: > > - Polish > - Overload the handle method and revert the change of unrelated commands Looks pretty good now. I focused on logging this time as that's something I will need to trace from this in the future. Thanks for fixing the API change with a default method, it turned out a lot better. Thanks Magnus for pushing through. I had missed that the existing method already had a default and was considered optional to implement. I have added the /open command to the wiki. bots/jep/src/main/java/org/openjdk/skara/bots/jep/JEPBot.java line 75: > 73: pr.removeLabel(JEP_LABEL); > 74: } > 75: log.info("No jep command found in comment for PR-" + pr.id()); This is going to log for most PRs every time this WorkItem runs. I would like to lower it to `fine` level. Also, please see CSR bot for a good way of logging pr name/IDs. I would recommend copying the describe method here. bots/jep/src/main/java/org/openjdk/skara/bots/jep/JEPBot.java line 82: > 80: if ("unneeded".equals(issueId)) { > 81: if (pr.labelNames().contains(JEP_LABEL)) { > 82: pr.removeLabel(JEP_LABEL); Please log that action was taken, see example below. bots/jep/src/main/java/org/openjdk/skara/bots/jep/JEPBot.java line 84: > 82: pr.removeLabel(JEP_LABEL); > 83: } > 84: log.info("Found `/jep unneeded` command"); Please include the `describe(pr)` in the log message. bots/jep/src/main/java/org/openjdk/skara/bots/jep/JEPBot.java line 116: > 114: pr.removeLabel(JEP_LABEL); > 115: } else if (!hasTargeted && !pr.labelNames().contains(JEP_LABEL)) { > 116: pr.addLabel(JEP_LABEL); Here we are taking action, I would like this logged at info level. Something like this: Suggestion: log.info("JEP issue " + issue.id() + " found in state " + issueStatus + ", removing JEP label from " + describe(pr); pr.removeLabel(JEP_LABEL); } else if (!hasTargeted && !pr.labelNames().contains(JEP_LABEL)) { log.info("JEP issue " + issue.id() + " found in state " + issueStatus + ", adding JEP label to " + describe(pr); pr.addLabel(JEP_LABEL); bots/pr/src/main/java/org/openjdk/skara/bots/pr/PullRequestCommandWorkItem.java line 154: > 152: for (var label : labelsToAdd) { > 153: if (!pr.labelNames().contains(label)) { > 154: pr.addLabel(label); Could you add an info log about adding and removing labels to the PR. ------------- PR: https://git.openjdk.java.net/skara/pull/1297 From erikj at openjdk.java.net Wed Apr 20 17:46:55 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 20 Apr 2022 17:46:55 GMT Subject: RFR: 1402: Cleanup some commands In-Reply-To: References: Message-ID: On Wed, 20 Apr 2022 13:24:09 GMT, Guoxiong Li wrote: > Hi all, > > During the review of SKARA-1096 [1][2], I find the `AllowCommand` and `RejectCommand` are never used. > And the `OpenCommand` and `CleanCommand` have many unused import statements. > It is good to remove/cleanup them. > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong > > [1] https://bugs.openjdk.java.net/browse/SKARA-1096 > [2] https://github.com/openjdk/skara/pull/1297 Marked as reviewed by erikj (Lead). ------------- PR: https://git.openjdk.java.net/skara/pull/1301 From gli at openjdk.java.net Wed Apr 20 18:00:19 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Wed, 20 Apr 2022 18:00:19 GMT Subject: RFR: 1402: Cleanup some commands In-Reply-To: References: Message-ID: On Wed, 20 Apr 2022 17:43:50 GMT, Erik Joelsson wrote: >> Hi all, >> >> During the review of SKARA-1096 [1][2], I find the `AllowCommand` and `RejectCommand` are never used. >> And the `OpenCommand` and `CleanCommand` have many unused import statements. >> It is good to remove/cleanup them. >> >> Thanks for taking the time to review. >> >> Best Regards, >> -- Guoxiong >> >> [1] https://bugs.openjdk.java.net/browse/SKARA-1096 >> [2] https://github.com/openjdk/skara/pull/1297 > > Marked as reviewed by erikj (Lead). @erikj79 Thanks for the review. Could I get your help to sponsor this patch? ------------- PR: https://git.openjdk.java.net/skara/pull/1301 From gli at openjdk.java.net Wed Apr 20 18:28:56 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Wed, 20 Apr 2022 18:28:56 GMT Subject: RFR: SKARA-1096: New command and label for JEPs, similar to CSR [v11] In-Reply-To: <0-E7MblNqSvFkCZ6IEkmU1oEoWvphBbIZoVMFLRlPto=.a160de74-142c-466a-87fd-cbe76306bee8@github.com> References: <0-E7MblNqSvFkCZ6IEkmU1oEoWvphBbIZoVMFLRlPto=.a160de74-142c-466a-87fd-cbe76306bee8@github.com> Message-ID: > Hi all, > > This patch implements the features about the `/jep` command and JEP bot. The detailed designs and discussions are listed at [1][2]. > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong > > [1] https://mail.openjdk.java.net/pipermail/skara-dev/2021-December/005481.html > [2] https://mail.openjdk.java.net/pipermail/skara-dev/2022-March/005770.html Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: Fix log. ------------- Changes: - all: https://git.openjdk.java.net/skara/pull/1297/files - new: https://git.openjdk.java.net/skara/pull/1297/files/ee84a2b9..5b58294e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=skara&pr=1297&range=10 - incr: https://webrevs.openjdk.java.net/?repo=skara&pr=1297&range=09-10 Stats: 19 lines in 2 files changed: 15 ins; 1 del; 3 mod Patch: https://git.openjdk.java.net/skara/pull/1297.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1297/head:pull/1297 PR: https://git.openjdk.java.net/skara/pull/1297 From gli at openjdk.java.net Wed Apr 20 18:28:57 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Wed, 20 Apr 2022 18:28:57 GMT Subject: RFR: SKARA-1096: New command and label for JEPs, similar to CSR [v10] In-Reply-To: References: <0-E7MblNqSvFkCZ6IEkmU1oEoWvphBbIZoVMFLRlPto=.a160de74-142c-466a-87fd-cbe76306bee8@github.com> Message-ID: On Wed, 20 Apr 2022 17:19:45 GMT, Erik Joelsson wrote: >> Guoxiong Li has updated the pull request incrementally with two additional commits since the last revision: >> >> - Polish >> - Overload the handle method and revert the change of unrelated commands > > bots/jep/src/main/java/org/openjdk/skara/bots/jep/JEPBot.java line 75: > >> 73: pr.removeLabel(JEP_LABEL); >> 74: } >> 75: log.info("No jep command found in comment for PR-" + pr.id()); > > This is going to log for most PRs every time this WorkItem runs. I would like to lower it to `fine` level. Also, please see CSR bot for a good way of logging pr name/IDs. I would recommend copying the describe method here. Fixed. > bots/jep/src/main/java/org/openjdk/skara/bots/jep/JEPBot.java line 82: > >> 80: if ("unneeded".equals(issueId)) { >> 81: if (pr.labelNames().contains(JEP_LABEL)) { >> 82: pr.removeLabel(JEP_LABEL); > > Please log that action was taken, see example below. Fixed. > bots/jep/src/main/java/org/openjdk/skara/bots/jep/JEPBot.java line 84: > >> 82: pr.removeLabel(JEP_LABEL); >> 83: } >> 84: log.info("Found `/jep unneeded` command"); > > Please include the `describe(pr)` in the log message. Fixed. > bots/jep/src/main/java/org/openjdk/skara/bots/jep/JEPBot.java line 116: > >> 114: pr.removeLabel(JEP_LABEL); >> 115: } else if (!hasTargeted && !pr.labelNames().contains(JEP_LABEL)) { >> 116: pr.addLabel(JEP_LABEL); > > Here we are taking action, I would like this logged at info level. Something like this: > Suggestion: > > log.info("JEP issue " + issue.id() + " found in state " + issueStatus + ", removing JEP label from " + describe(pr); > pr.removeLabel(JEP_LABEL); > } else if (!hasTargeted && !pr.labelNames().contains(JEP_LABEL)) { > log.info("JEP issue " + issue.id() + " found in state " + issueStatus + ", adding JEP label to " + describe(pr); > pr.addLabel(JEP_LABEL); Fixed. > bots/pr/src/main/java/org/openjdk/skara/bots/pr/PullRequestCommandWorkItem.java line 154: > >> 152: for (var label : labelsToAdd) { >> 153: if (!pr.labelNames().contains(label)) { >> 154: pr.addLabel(label); > > Could you add an info log about adding and removing labels to the PR. Fixed. ------------- PR: https://git.openjdk.java.net/skara/pull/1297 From gli at openjdk.java.net Wed Apr 20 18:32:04 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Wed, 20 Apr 2022 18:32:04 GMT Subject: Integrated: 1402: Cleanup some commands In-Reply-To: References: Message-ID: On Wed, 20 Apr 2022 13:24:09 GMT, Guoxiong Li wrote: > Hi all, > > During the review of SKARA-1096 [1][2], I find the `AllowCommand` and `RejectCommand` are never used. > And the `OpenCommand` and `CleanCommand` have many unused import statements. > It is good to remove/cleanup them. > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong > > [1] https://bugs.openjdk.java.net/browse/SKARA-1096 > [2] https://github.com/openjdk/skara/pull/1297 This pull request has now been integrated. Changeset: 565f04f4 Author: Guoxiong Li Committer: Erik Joelsson URL: https://git.openjdk.java.net/skara/commit/565f04f48e60560f2b19981a05fe53d6d6871804 Stats: 500 lines in 6 files changed: 0 ins; 498 del; 2 mod 1402: Cleanup some commands Reviewed-by: erikj ------------- PR: https://git.openjdk.java.net/skara/pull/1301 From ihse at openjdk.java.net Wed Apr 20 21:02:43 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Wed, 20 Apr 2022 21:02:43 GMT Subject: RFR: SKARA-1096: New command and label for JEPs, similar to CSR [v11] In-Reply-To: References: <0-E7MblNqSvFkCZ6IEkmU1oEoWvphBbIZoVMFLRlPto=.a160de74-142c-466a-87fd-cbe76306bee8@github.com> Message-ID: On Wed, 20 Apr 2022 18:28:56 GMT, Guoxiong Li wrote: >> Hi all, >> >> This patch implements the features about the `/jep` command and JEP bot. The detailed designs and discussions are listed at [1][2]. >> >> Thanks for taking the time to review. >> >> Best Regards, >> -- Guoxiong >> >> [1] https://mail.openjdk.java.net/pipermail/skara-dev/2021-December/005481.html >> [2] https://mail.openjdk.java.net/pipermail/skara-dev/2022-March/005770.html > > Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: > > Fix log. Thanks for fixing `handle`! Looks much better now. issuetracker/src/main/java/org/openjdk/skara/issuetracker/jira/JiraProject.java line 39: > 37: public static final String RESOLVED_IN_BUILD = "customfield_10006"; > 38: public static final String SUBCOMPONENT = "customfield_10008"; > 39: public static final String JEP_NUMBER = "customfield_10701"; Don't think this is needed anymore? ------------- PR: https://git.openjdk.java.net/skara/pull/1297 From gli at openjdk.java.net Wed Apr 20 21:18:22 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Wed, 20 Apr 2022 21:18:22 GMT Subject: RFR: SKARA-1096: New command and label for JEPs, similar to CSR [v11] In-Reply-To: References: <0-E7MblNqSvFkCZ6IEkmU1oEoWvphBbIZoVMFLRlPto=.a160de74-142c-466a-87fd-cbe76306bee8@github.com> Message-ID: On Wed, 20 Apr 2022 20:59:39 GMT, Magnus Ihse Bursie wrote: >> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix log. > > issuetracker/src/main/java/org/openjdk/skara/issuetracker/jira/JiraProject.java line 39: > >> 37: public static final String RESOLVED_IN_BUILD = "customfield_10006"; >> 38: public static final String SUBCOMPONENT = "customfield_10008"; >> 39: public static final String JEP_NUMBER = "customfield_10701"; > > Don't think this is needed anymore? Why? It is used in many test cases and the convention is putting such field name at the `JiraProjec.java`. ------------- PR: https://git.openjdk.java.net/skara/pull/1297 From ihse at openjdk.java.net Wed Apr 20 22:09:20 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Wed, 20 Apr 2022 22:09:20 GMT Subject: RFR: SKARA-1096: New command and label for JEPs, similar to CSR [v11] In-Reply-To: References: <0-E7MblNqSvFkCZ6IEkmU1oEoWvphBbIZoVMFLRlPto=.a160de74-142c-466a-87fd-cbe76306bee8@github.com> Message-ID: <7zLwZoue79cAjTTl3utYluvn36gigMbbJ0RBU__olSs=.8fd6c307-94e4-44a2-b2b9-d997eec6925f@github.com> On Wed, 20 Apr 2022 18:28:56 GMT, Guoxiong Li wrote: >> Hi all, >> >> This patch implements the features about the `/jep` command and JEP bot. The detailed designs and discussions are listed at [1][2]. >> >> Thanks for taking the time to review. >> >> Best Regards, >> -- Guoxiong >> >> [1] https://mail.openjdk.java.net/pipermail/skara-dev/2021-December/005481.html >> [2] https://mail.openjdk.java.net/pipermail/skara-dev/2022-March/005770.html > > Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: > > Fix log. Seems the bots did not like that I added a comment using the review function; they took it as me withdrawing my review... ------------- Marked as reviewed by ihse (Reviewer). PR: https://git.openjdk.java.net/skara/pull/1297 From ihse at openjdk.java.net Wed Apr 20 22:09:20 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Wed, 20 Apr 2022 22:09:20 GMT Subject: RFR: SKARA-1096: New command and label for JEPs, similar to CSR [v11] In-Reply-To: References: <0-E7MblNqSvFkCZ6IEkmU1oEoWvphBbIZoVMFLRlPto=.a160de74-142c-466a-87fd-cbe76306bee8@github.com> Message-ID: On Wed, 20 Apr 2022 21:15:20 GMT, Guoxiong Li wrote: >> issuetracker/src/main/java/org/openjdk/skara/issuetracker/jira/JiraProject.java line 39: >> >>> 37: public static final String RESOLVED_IN_BUILD = "customfield_10006"; >>> 38: public static final String SUBCOMPONENT = "customfield_10008"; >>> 39: public static final String JEP_NUMBER = "customfield_10701"; >> >> Don't think this is needed anymore? > > Why? It is used in many test cases and the convention is putting such field name at the `JiraProjec.java`. Aha, I did not notice that. I only looked at that particular class. Nevermind, then. ------------- PR: https://git.openjdk.java.net/skara/pull/1297 From gli at openjdk.java.net Wed Apr 20 22:12:07 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Wed, 20 Apr 2022 22:12:07 GMT Subject: RFR: SKARA-1096: New command and label for JEPs, similar to CSR [v12] In-Reply-To: <0-E7MblNqSvFkCZ6IEkmU1oEoWvphBbIZoVMFLRlPto=.a160de74-142c-466a-87fd-cbe76306bee8@github.com> References: <0-E7MblNqSvFkCZ6IEkmU1oEoWvphBbIZoVMFLRlPto=.a160de74-142c-466a-87fd-cbe76306bee8@github.com> Message-ID: > Hi all, > > This patch implements the features about the `/jep` command and JEP bot. The detailed designs and discussions are listed at [1][2]. > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong > > [1] https://mail.openjdk.java.net/pipermail/skara-dev/2021-December/005481.html > [2] https://mail.openjdk.java.net/pipermail/skara-dev/2022-March/005770.html Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: Use static import. ------------- Changes: - all: https://git.openjdk.java.net/skara/pull/1297/files - new: https://git.openjdk.java.net/skara/pull/1297/files/5b58294e..50c8c057 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=skara&pr=1297&range=11 - incr: https://webrevs.openjdk.java.net/?repo=skara&pr=1297&range=10-11 Stats: 29 lines in 6 files changed: 8 ins; 5 del; 16 mod Patch: https://git.openjdk.java.net/skara/pull/1297.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1297/head:pull/1297 PR: https://git.openjdk.java.net/skara/pull/1297 From erikj at openjdk.java.net Thu Apr 21 17:23:09 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 21 Apr 2022 17:23:09 GMT Subject: RFR: SKARA-1096: New command and label for JEPs, similar to CSR [v12] In-Reply-To: References: <0-E7MblNqSvFkCZ6IEkmU1oEoWvphBbIZoVMFLRlPto=.a160de74-142c-466a-87fd-cbe76306bee8@github.com> Message-ID: On Wed, 20 Apr 2022 22:12:07 GMT, Guoxiong Li wrote: >> Hi all, >> >> This patch implements the features about the `/jep` command and JEP bot. The detailed designs and discussions are listed at [1][2]. >> >> Thanks for taking the time to review. >> >> Best Regards, >> -- Guoxiong >> >> [1] https://mail.openjdk.java.net/pipermail/skara-dev/2021-December/005481.html >> [2] https://mail.openjdk.java.net/pipermail/skara-dev/2022-March/005770.html > > Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: > > Use static import. bots/jep/src/main/java/org/openjdk/skara/bots/jep/JEPBot.java line 74: > 72: if (jepComment == null) { > 73: if (pr.labelNames().contains(JEP_LABEL)) { > 74: pr.removeLabel(JEP_LABEL); Missed this remove label in the previous review due to the long thread in the middle of the block. Please add logging here too. ------------- PR: https://git.openjdk.java.net/skara/pull/1297 From gli at openjdk.java.net Thu Apr 21 17:56:34 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Thu, 21 Apr 2022 17:56:34 GMT Subject: RFR: SKARA-1096: New command and label for JEPs, similar to CSR [v12] In-Reply-To: References: <0-E7MblNqSvFkCZ6IEkmU1oEoWvphBbIZoVMFLRlPto=.a160de74-142c-466a-87fd-cbe76306bee8@github.com> Message-ID: On Thu, 21 Apr 2022 17:14:28 GMT, Erik Joelsson wrote: >> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: >> >> Use static import. > > bots/jep/src/main/java/org/openjdk/skara/bots/jep/JEPBot.java line 74: > >> 72: if (jepComment == null) { >> 73: if (pr.labelNames().contains(JEP_LABEL)) { >> 74: pr.removeLabel(JEP_LABEL); > > Missed this remove label in the previous review due to the long thread in the middle of the block. Please add logging here too. I missed it, too. Added. Use the `info` level instead of `fine` because the condition only occurs when the developers add the `jep` label manually in the PR. ------------- PR: https://git.openjdk.java.net/skara/pull/1297 From gli at openjdk.java.net Thu Apr 21 17:56:33 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Thu, 21 Apr 2022 17:56:33 GMT Subject: RFR: SKARA-1096: New command and label for JEPs, similar to CSR [v13] In-Reply-To: <0-E7MblNqSvFkCZ6IEkmU1oEoWvphBbIZoVMFLRlPto=.a160de74-142c-466a-87fd-cbe76306bee8@github.com> References: <0-E7MblNqSvFkCZ6IEkmU1oEoWvphBbIZoVMFLRlPto=.a160de74-142c-466a-87fd-cbe76306bee8@github.com> Message-ID: > Hi all, > > This patch implements the features about the `/jep` command and JEP bot. The detailed designs and discussions are listed at [1][2]. > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong > > [1] https://mail.openjdk.java.net/pipermail/skara-dev/2021-December/005481.html > [2] https://mail.openjdk.java.net/pipermail/skara-dev/2022-March/005770.html Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: Add log. ------------- Changes: - all: https://git.openjdk.java.net/skara/pull/1297/files - new: https://git.openjdk.java.net/skara/pull/1297/files/50c8c057..861c3a3e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=skara&pr=1297&range=12 - incr: https://webrevs.openjdk.java.net/?repo=skara&pr=1297&range=11-12 Stats: 3 lines in 1 file changed: 2 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/skara/pull/1297.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1297/head:pull/1297 PR: https://git.openjdk.java.net/skara/pull/1297 From ihse at openjdk.java.net Fri Apr 22 07:34:26 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Fri, 22 Apr 2022 07:34:26 GMT Subject: RFR: SKARA-1096: New command and label for JEPs, similar to CSR [v13] In-Reply-To: References: <0-E7MblNqSvFkCZ6IEkmU1oEoWvphBbIZoVMFLRlPto=.a160de74-142c-466a-87fd-cbe76306bee8@github.com> Message-ID: On Thu, 21 Apr 2022 17:56:33 GMT, Guoxiong Li wrote: >> Hi all, >> >> This patch implements the features about the `/jep` command and JEP bot. The detailed designs and discussions are listed at [1][2]. >> >> Thanks for taking the time to review. >> >> Best Regards, >> -- Guoxiong >> >> [1] https://mail.openjdk.java.net/pipermail/skara-dev/2021-December/005481.html >> [2] https://mail.openjdk.java.net/pipermail/skara-dev/2022-March/005770.html > > Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: > > Add log. Marked as reviewed by ihse (Reviewer). ------------- PR: https://git.openjdk.java.net/skara/pull/1297 From gli at openjdk.java.net Fri Apr 22 07:43:14 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Fri, 22 Apr 2022 07:43:14 GMT Subject: RFR: 1332: Skara sometimes fails to detect that a backport was clean Message-ID: <_gvFWa5LQojANqX7OgbYwnGB_8yTQDaL6yBvZsjV3V8=.a953d587-15b5-41e7-af43-90d9b0fa8f8f@github.com> Hi all, When the bot checks whether a backport is clean, it would use the [get-a-commit](https://docs.github.com/en/rest/commits/commits#get-a-commit) api to get the patch files of the original commit and use the [list-pull-requests-files](https://docs.github.com/en/rest/pulls/pulls#list-pull-requests-files) api to get the patch files of the backport PR, and then compare them. But the [get-a-commit](https://docs.github.com/en/rest/commits/commits#get-a-commit) api has the following drawbacks: 1. When the `per_page` argument exceeds 70, the files after 70th don't have the `patch` field. Please see the link [1] with `per_page` as 71, the final file, 71th, doesn't have the `patch` field. And the default `per_page` of this api is **300**, so if we don't provide a `per_page` and the total files number exceeds 70, we get the wrong result without `patch` field as well [2]. 2. At most 3000 patch files of a commit are returned by the api. If the files number exceeds 3000, such as [3], the api returns only 3000 files. The class `RestRequest` gets the pagination information duplicately, but finally only get 3000 files. (The test case of this patch can prove it.) 3. If a patch file of the commit is too large (not exactly know the api how to judge "too large"), the api doesn't return the patch file as well. Please use the link [1] and find `modules/javafx.web/src/main/native/Source/ThirdParty/libxml/src/ChangeLog` or `modules/javafx.web/src/main/native/Source/ThirdParty/libxml/src/HTMLparser.c`, you can identify that they don't have the `patch` field. The [list-pull-requests-files](https://docs.github.com/en/rest/pulls/pulls#list-pull-requests-files) api has the same drawbacks, but its default `per_page` is **30** instead of **300**, so the first drawback above doesn't happen in this api **now**. This patch adds the `per_page` argument to these two api so that we can solve the first drawback. Note: considering the default `per_page` of the api [list-pull-requests-files](https://docs.github.com/en/rest/pulls/pulls#list-pull-requests-files) will change in the future (may exceed 70), it is good to also provide a explicit `per_page` for it. I can't solve second and third drawbacks now. A possible alternative is using the media-type [5] `application/vnd.github.VERSION.diff` or `application/vnd.github.VERSION.patch` to get the meta `diff` or `patch` data and parse them. But the current paser classes `GitRawDiffParser` and `UnifiedDiffParser` can't parse such meta diff or patch (the format is not suitable). It needs many changes to the code about vcs, so I don't think it is a short term solution. As a conclusion, this patch can solve the situations provided by kevin in SKARA-1332. But it can't identify the difference of the "too large" files and the files which exceeds 3000. Note: this shortcoming has already existed in SKARA and is not produced by this patch. Best Regards, -- Guoxiong [1] https://api.github.com/repos/openjdk/jfx/commits/b0f2521219efc1b0d0c45088736d5105712bc2c9?&per_page=71 [2] https://api.github.com/repos/openjdk/jfx/commits/b0f2521219efc1b0d0c45088736d5105712bc2c9 [3] https://git.openjdk.java.net/jfx/commit/6f28d912024495278c4c35ab054bc2aab480b3e4 [4] https://api.github.com/repos/openjdk/jfx/commits/6f28d912024495278c4c35ab054bc2aab480b3e4 [5] https://docs.github.com/en/rest/overview/media-types#commits-commit-comparison-and-pull-requests ------------- Commit messages: - 1332: Skara sometimes fails to detect that a backport was clean Changes: https://git.openjdk.java.net/skara/pull/1302/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1302&range=00 Issue: https://bugs.openjdk.java.net/browse/SKARA-1332 Stats: 104 lines in 3 files changed: 101 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/skara/pull/1302.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1302/head:pull/1302 PR: https://git.openjdk.java.net/skara/pull/1302 From erikj at openjdk.java.net Fri Apr 22 13:06:37 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 22 Apr 2022 13:06:37 GMT Subject: RFR: SKARA-1096: New command and label for JEPs, similar to CSR [v13] In-Reply-To: References: <0-E7MblNqSvFkCZ6IEkmU1oEoWvphBbIZoVMFLRlPto=.a160de74-142c-466a-87fd-cbe76306bee8@github.com> Message-ID: <4rZSXr9cG_cfsgs_dW7X-S3FN7bQVZexjdz9f5SJIJ4=.b4ab1697-9520-490b-b823-34a56cfbc271@github.com> On Thu, 21 Apr 2022 17:56:33 GMT, Guoxiong Li wrote: >> Hi all, >> >> This patch implements the features about the `/jep` command and JEP bot. The detailed designs and discussions are listed at [1][2]. >> >> Thanks for taking the time to review. >> >> Best Regards, >> -- Guoxiong >> >> [1] https://mail.openjdk.java.net/pipermail/skara-dev/2021-December/005481.html >> [2] https://mail.openjdk.java.net/pipermail/skara-dev/2022-March/005770.html > > Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: > > Add log. Marked as reviewed by erikj (Lead). ------------- PR: https://git.openjdk.java.net/skara/pull/1297 From gli at openjdk.java.net Fri Apr 22 13:44:01 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Fri, 22 Apr 2022 13:44:01 GMT Subject: RFR: SKARA-1096: New command and label for JEPs, similar to CSR [v13] In-Reply-To: References: <0-E7MblNqSvFkCZ6IEkmU1oEoWvphBbIZoVMFLRlPto=.a160de74-142c-466a-87fd-cbe76306bee8@github.com> Message-ID: On Fri, 22 Apr 2022 07:31:30 GMT, Magnus Ihse Bursie wrote: >> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: >> >> Add log. > > Marked as reviewed by ihse (Reviewer). @magicus @erikj79 Thanks for the review. Could I get your help to sponsor this patch? ------------- PR: https://git.openjdk.java.net/skara/pull/1297 From gli at openjdk.java.net Fri Apr 22 13:57:09 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Fri, 22 Apr 2022 13:57:09 GMT Subject: Integrated: SKARA-1096: New command and label for JEPs, similar to CSR In-Reply-To: <0-E7MblNqSvFkCZ6IEkmU1oEoWvphBbIZoVMFLRlPto=.a160de74-142c-466a-87fd-cbe76306bee8@github.com> References: <0-E7MblNqSvFkCZ6IEkmU1oEoWvphBbIZoVMFLRlPto=.a160de74-142c-466a-87fd-cbe76306bee8@github.com> Message-ID: On Thu, 7 Apr 2022 18:18:34 GMT, Guoxiong Li wrote: > Hi all, > > This patch implements the features about the `/jep` command and JEP bot. The detailed designs and discussions are listed at [1][2]. > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong > > [1] https://mail.openjdk.java.net/pipermail/skara-dev/2021-December/005481.html > [2] https://mail.openjdk.java.net/pipermail/skara-dev/2022-March/005770.html This pull request has now been integrated. Changeset: 11f1c4fb Author: Guoxiong Li Committer: Erik Joelsson URL: https://git.openjdk.java.net/skara/commit/11f1c4fbe4959b8b26ef98aef1b541e69023a920 Stats: 1429 lines in 22 files changed: 1402 ins; 1 del; 26 mod 1096: New command and label for JEPs, similar to CSR Reviewed-by: erikj, ihse ------------- PR: https://git.openjdk.java.net/skara/pull/1297 From erikj at openjdk.java.net Fri Apr 22 14:03:12 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 22 Apr 2022 14:03:12 GMT Subject: RFR: 1332: Skara sometimes fails to detect that a backport was clean In-Reply-To: <_gvFWa5LQojANqX7OgbYwnGB_8yTQDaL6yBvZsjV3V8=.a953d587-15b5-41e7-af43-90d9b0fa8f8f@github.com> References: <_gvFWa5LQojANqX7OgbYwnGB_8yTQDaL6yBvZsjV3V8=.a953d587-15b5-41e7-af43-90d9b0fa8f8f@github.com> Message-ID: On Fri, 22 Apr 2022 07:38:59 GMT, Guoxiong Li wrote: > Hi all, > > When the bot checks whether a backport is clean, it would use the [get-a-commit](https://docs.github.com/en/rest/commits/commits#get-a-commit) api to get the patch files of the original commit and use the [list-pull-requests-files](https://docs.github.com/en/rest/pulls/pulls#list-pull-requests-files) api to get the patch files of the backport PR, and then compare them. > > But the [get-a-commit](https://docs.github.com/en/rest/commits/commits#get-a-commit) api has the following drawbacks: > > 1. When the `per_page` argument exceeds 70, the files after 70th don't have the `patch` field. Please see the link [1] with `per_page` as 71, the final file, 71th, doesn't have the `patch` field. And the default `per_page` of this api is **300**, so if we don't provide a `per_page` and the total files number exceeds 70, we get the wrong result without `patch` field as well [2]. > 2. At most 3000 patch files of a commit are returned by the api. If the files number exceeds 3000, such as [3], the api returns only 3000 files. The class `RestRequest` gets the pagination information duplicately, but finally only get 3000 files. (The test case of this patch can prove it.) > 3. If a patch file of the commit is too large (not exactly know the api how to judge "too large"), the api doesn't return the patch file as well. Please use the link [1] and find `modules/javafx.web/src/main/native/Source/ThirdParty/libxml/src/ChangeLog` or `modules/javafx.web/src/main/native/Source/ThirdParty/libxml/src/HTMLparser.c`, you can identify that they don't have the `patch` field. > > The [list-pull-requests-files](https://docs.github.com/en/rest/pulls/pulls#list-pull-requests-files) api has the same drawbacks, but its default `per_page` is **30** instead of **300**, so the first drawback above doesn't happen in this api **now**. > > This patch adds the `per_page` argument to these two api so that we can solve the first drawback. Note: considering the default `per_page` of the api [list-pull-requests-files](https://docs.github.com/en/rest/pulls/pulls#list-pull-requests-files) will change in the future (may exceed 70), it is good to also provide a explicit `per_page` for it. > > I can't solve second and third drawbacks now. A possible alternative is using the media-type [5] `application/vnd.github.VERSION.diff` or `application/vnd.github.VERSION.patch` to get the meta `diff` or `patch` data and parse them. But the current paser classes `GitRawDiffParser` and `UnifiedDiffParser` can't parse such meta diff or patch (the format is not suitable). It needs many changes to the code about vcs, so I don't think it is a short term solution. > > As a conclusion, this patch can solve the situations provided by kevin in SKARA-1332. But it can't identify the difference of the "too large" files and the files which exceeds 3000. Note: this shortcoming has already existed in SKARA and is not produced by this patch. > > Best Regards, > -- Guoxiong > > [1] https://api.github.com/repos/openjdk/jfx/commits/b0f2521219efc1b0d0c45088736d5105712bc2c9?&per_page=71 > [2] https://api.github.com/repos/openjdk/jfx/commits/b0f2521219efc1b0d0c45088736d5105712bc2c9 > [3] https://git.openjdk.java.net/jfx/commit/6f28d912024495278c4c35ab054bc2aab480b3e4 > [4] https://api.github.com/repos/openjdk/jfx/commits/6f28d912024495278c4c35ab054bc2aab480b3e4 > [5] https://docs.github.com/en/rest/overview/media-types#commits-commit-comparison-and-pull-requests This looks like a good change. Thanks for identifying these causes for failing to get patch information from Github. In addition to the cases you have identified here which aren't solved, most of the examples given in the original bug were hidden from you as they pertain to a private Gitlab instance. So until we can address those, I would like the original bug open. Could you file a new bug describing the particular problem you are solving here and change this PR to reference that bug? Please link it to the existing bug and add a comment in the original explaining that part of the problem is being solved in the new bug. forge/src/main/java/org/openjdk/skara/forge/github/GitHubPullRequest.java line 740: > 738: public Diff diff() { > 739: var files = request.get("pulls/" + json.get("number").toString() + "/files") > 740: .param("per_page", "50") Can we add a comment explaining the need for per_page? Something like: "Need to specify an explicit per_page < 70 to guarantee that we get patch information in the result set." ------------- PR: https://git.openjdk.java.net/skara/pull/1302 From gli at openjdk.java.net Fri Apr 22 15:23:58 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Fri, 22 Apr 2022 15:23:58 GMT Subject: RFR: 1406: Two GitHub APIs don't return `patch` field when `per_page` argument exceeds 70 In-Reply-To: <_gvFWa5LQojANqX7OgbYwnGB_8yTQDaL6yBvZsjV3V8=.a953d587-15b5-41e7-af43-90d9b0fa8f8f@github.com> References: <_gvFWa5LQojANqX7OgbYwnGB_8yTQDaL6yBvZsjV3V8=.a953d587-15b5-41e7-af43-90d9b0fa8f8f@github.com> Message-ID: On Fri, 22 Apr 2022 07:38:59 GMT, Guoxiong Li wrote: > Hi all, > > When the bot checks whether a backport is clean, it would use the [get-a-commit](https://docs.github.com/en/rest/commits/commits#get-a-commit) api to get the patch files of the original commit and use the [list-pull-requests-files](https://docs.github.com/en/rest/pulls/pulls#list-pull-requests-files) api to get the patch files of the backport PR, and then compare them. > > But the [get-a-commit](https://docs.github.com/en/rest/commits/commits#get-a-commit) api has the following drawbacks: > > 1. When the `per_page` argument exceeds 70, the files after 70th don't have the `patch` field. Please see the link [1] with `per_page` as 71, the final file, 71th, doesn't have the `patch` field. And the default `per_page` of this api is **300**, so if we don't provide a `per_page` and the total files number exceeds 70, we get the wrong result without `patch` field as well [2]. > 2. At most 3000 patch files of a commit are returned by the api. If the files number exceeds 3000, such as [3], the api returns only 3000 files. The class `RestRequest` gets the pagination information duplicately, but finally only get 3000 files. (The test case of this patch can prove it.) > 3. If a patch file of the commit is too large (not exactly know the api how to judge "too large"), the api doesn't return the patch file as well. Please use the link [1] and find `modules/javafx.web/src/main/native/Source/ThirdParty/libxml/src/ChangeLog` or `modules/javafx.web/src/main/native/Source/ThirdParty/libxml/src/HTMLparser.c`, you can identify that they don't have the `patch` field. > > The [list-pull-requests-files](https://docs.github.com/en/rest/pulls/pulls#list-pull-requests-files) api has the same drawbacks, but its default `per_page` is **30** instead of **300**, so the first drawback above doesn't happen in this api **now**. > > This patch adds the `per_page` argument to these two api so that we can solve the first drawback. Note: considering the default `per_page` of the api [list-pull-requests-files](https://docs.github.com/en/rest/pulls/pulls#list-pull-requests-files) will change in the future (may exceed 70), it is good to also provide a explicit `per_page` for it. > > I can't solve second and third drawbacks now. A possible alternative is using the media-type [5] `application/vnd.github.VERSION.diff` or `application/vnd.github.VERSION.patch` to get the meta `diff` or `patch` data and parse them. But the current paser classes `GitRawDiffParser` and `UnifiedDiffParser` can't parse such meta diff or patch (the format is not suitable). It needs many changes to the code about vcs, so I don't think it is a short term solution. > > As a conclusion, this patch can solve the situations provided by kevin in SKARA-1332. But it can't identify the difference of the "too large" files and the files which exceeds 3000. Note: this shortcoming has already existed in SKARA and is not produced by this patch. > > Best Regards, > -- Guoxiong > > [1] https://api.github.com/repos/openjdk/jfx/commits/b0f2521219efc1b0d0c45088736d5105712bc2c9?&per_page=71 > [2] https://api.github.com/repos/openjdk/jfx/commits/b0f2521219efc1b0d0c45088736d5105712bc2c9 > [3] https://git.openjdk.java.net/jfx/commit/6f28d912024495278c4c35ab054bc2aab480b3e4 > [4] https://api.github.com/repos/openjdk/jfx/commits/6f28d912024495278c4c35ab054bc2aab480b3e4 > [5] https://docs.github.com/en/rest/overview/media-types#commits-commit-comparison-and-pull-requests Filed https://bugs.openjdk.java.net/browse/SKARA-1406 ------------- PR: https://git.openjdk.java.net/skara/pull/1302 From gli at openjdk.java.net Fri Apr 22 15:31:37 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Fri, 22 Apr 2022 15:31:37 GMT Subject: RFR: 1406: Two GitHub APIs don't return `patch` field when `per_page` argument exceeds 70 [v2] In-Reply-To: <_gvFWa5LQojANqX7OgbYwnGB_8yTQDaL6yBvZsjV3V8=.a953d587-15b5-41e7-af43-90d9b0fa8f8f@github.com> References: <_gvFWa5LQojANqX7OgbYwnGB_8yTQDaL6yBvZsjV3V8=.a953d587-15b5-41e7-af43-90d9b0fa8f8f@github.com> Message-ID: <74BocmlWE7zZ3FjD2DxzL0dUmTHQv-J1lc96ziyF6NI=.a1800fa1-2b27-4111-916c-b9d48344b4ba@github.com> > Hi all, > > When the bot checks whether a backport is clean, it would use the [get-a-commit](https://docs.github.com/en/rest/commits/commits#get-a-commit) api to get the patch files of the original commit and use the [list-pull-requests-files](https://docs.github.com/en/rest/pulls/pulls#list-pull-requests-files) api to get the patch files of the backport PR, and then compare them. > > But the [get-a-commit](https://docs.github.com/en/rest/commits/commits#get-a-commit) api has the following drawbacks: > > 1. When the `per_page` argument exceeds 70, the files after 70th don't have the `patch` field. Please see the link [1] with `per_page` as 71, the final file, 71th, doesn't have the `patch` field. And the default `per_page` of this api is **300**, so if we don't provide a `per_page` and the total files number exceeds 70, we get the wrong result without `patch` field as well [2]. > 2. At most 3000 patch files of a commit are returned by the api. If the files number exceeds 3000, such as [3], the api returns only 3000 files. The class `RestRequest` gets the pagination information duplicately, but finally only get 3000 files. (The test case of this patch can prove it.) > 3. If a patch file of the commit is too large (not exactly know the api how to judge "too large"), the api doesn't return the patch file as well. Please use the link [1] and find `modules/javafx.web/src/main/native/Source/ThirdParty/libxml/src/ChangeLog` or `modules/javafx.web/src/main/native/Source/ThirdParty/libxml/src/HTMLparser.c`, you can identify that they don't have the `patch` field. > > The [list-pull-requests-files](https://docs.github.com/en/rest/pulls/pulls#list-pull-requests-files) api has the same drawbacks, but its default `per_page` is **30** instead of **300**, so the first drawback above doesn't happen in this api **now**. > > This patch adds the `per_page` argument to these two api so that we can solve the first drawback. Note: considering the default `per_page` of the api [list-pull-requests-files](https://docs.github.com/en/rest/pulls/pulls#list-pull-requests-files) will change in the future (may exceed 70), it is good to also provide a explicit `per_page` for it. > > I can't solve second and third drawbacks now. A possible alternative is using the media-type [5] `application/vnd.github.VERSION.diff` or `application/vnd.github.VERSION.patch` to get the meta `diff` or `patch` data and parse them. But the current paser classes `GitRawDiffParser` and `UnifiedDiffParser` can't parse such meta diff or patch (the format is not suitable). It needs many changes to the code about vcs, so I don't think it is a short term solution. > > As a conclusion, this patch can solve the situations provided by kevin in SKARA-1332. But it can't identify the difference of the "too large" files and the files which exceeds 3000. Note: this shortcoming has already existed in SKARA and is not produced by this patch. > > Best Regards, > -- Guoxiong > > [1] https://api.github.com/repos/openjdk/jfx/commits/b0f2521219efc1b0d0c45088736d5105712bc2c9?&per_page=71 > [2] https://api.github.com/repos/openjdk/jfx/commits/b0f2521219efc1b0d0c45088736d5105712bc2c9 > [3] https://git.openjdk.java.net/jfx/commit/6f28d912024495278c4c35ab054bc2aab480b3e4 > [4] https://api.github.com/repos/openjdk/jfx/commits/6f28d912024495278c4c35ab054bc2aab480b3e4 > [5] https://docs.github.com/en/rest/overview/media-types#commits-commit-comparison-and-pull-requests Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: Add comment. ------------- Changes: - all: https://git.openjdk.java.net/skara/pull/1302/files - new: https://git.openjdk.java.net/skara/pull/1302/files/19d1d9ff..15b69898 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=skara&pr=1302&range=01 - incr: https://webrevs.openjdk.java.net/?repo=skara&pr=1302&range=00-01 Stats: 2 lines in 2 files changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/skara/pull/1302.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1302/head:pull/1302 PR: https://git.openjdk.java.net/skara/pull/1302 From gli at openjdk.java.net Fri Apr 22 15:31:38 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Fri, 22 Apr 2022 15:31:38 GMT Subject: RFR: 1406: Two GitHub APIs don't return `patch` field when `per_page` argument exceeds 70 [v2] In-Reply-To: References: <_gvFWa5LQojANqX7OgbYwnGB_8yTQDaL6yBvZsjV3V8=.a953d587-15b5-41e7-af43-90d9b0fa8f8f@github.com> Message-ID: On Fri, 22 Apr 2022 14:00:35 GMT, Erik Joelsson wrote: >> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: >> >> Add comment. > > forge/src/main/java/org/openjdk/skara/forge/github/GitHubPullRequest.java line 740: > >> 738: public Diff diff() { >> 739: var files = request.get("pulls/" + json.get("number").toString() + "/files") >> 740: .param("per_page", "50") > > Can we add a comment explaining the need for per_page? Something like: > > "Need to specify an explicit per_page < 70 to guarantee that we get patch information in the result set." Added. ------------- PR: https://git.openjdk.java.net/skara/pull/1302 From erikj at openjdk.java.net Fri Apr 22 16:48:17 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 22 Apr 2022 16:48:17 GMT Subject: RFR: 1406: Two GitHub APIs don't return `patch` field when `per_page` argument exceeds 70 [v2] In-Reply-To: <74BocmlWE7zZ3FjD2DxzL0dUmTHQv-J1lc96ziyF6NI=.a1800fa1-2b27-4111-916c-b9d48344b4ba@github.com> References: <_gvFWa5LQojANqX7OgbYwnGB_8yTQDaL6yBvZsjV3V8=.a953d587-15b5-41e7-af43-90d9b0fa8f8f@github.com> <74BocmlWE7zZ3FjD2DxzL0dUmTHQv-J1lc96ziyF6NI=.a1800fa1-2b27-4111-916c-b9d48344b4ba@github.com> Message-ID: On Fri, 22 Apr 2022 15:31:37 GMT, Guoxiong Li wrote: >> Hi all, >> >> When the bot checks whether a backport is clean, it would use the [get-a-commit](https://docs.github.com/en/rest/commits/commits#get-a-commit) api to get the patch files of the original commit and use the [list-pull-requests-files](https://docs.github.com/en/rest/pulls/pulls#list-pull-requests-files) api to get the patch files of the backport PR, and then compare them. >> >> But the [get-a-commit](https://docs.github.com/en/rest/commits/commits#get-a-commit) api has the following drawbacks: >> >> 1. When the `per_page` argument exceeds 70, the files after 70th don't have the `patch` field. Please see the link [1] with `per_page` as 71, the final file, 71th, doesn't have the `patch` field. And the default `per_page` of this api is **300**, so if we don't provide a `per_page` and the total files number exceeds 70, we get the wrong result without `patch` field as well [2]. >> 2. At most 3000 patch files of a commit are returned by the api. If the files number exceeds 3000, such as [3], the api returns only 3000 files. The class `RestRequest` gets the pagination information duplicately, but finally only get 3000 files. (The test case of this patch can prove it.) >> 3. If a patch file of the commit is too large (not exactly know the api how to judge "too large"), the api doesn't return the patch file as well. Please use the link [1] and find `modules/javafx.web/src/main/native/Source/ThirdParty/libxml/src/ChangeLog` or `modules/javafx.web/src/main/native/Source/ThirdParty/libxml/src/HTMLparser.c`, you can identify that they don't have the `patch` field. >> >> The [list-pull-requests-files](https://docs.github.com/en/rest/pulls/pulls#list-pull-requests-files) api has the same drawbacks, but its default `per_page` is **30** instead of **300**, so the first drawback above doesn't happen in this api **now**. >> >> This patch adds the `per_page` argument to these two api so that we can solve the first drawback. Note: considering the default `per_page` of the api [list-pull-requests-files](https://docs.github.com/en/rest/pulls/pulls#list-pull-requests-files) will change in the future (may exceed 70), it is good to also provide a explicit `per_page` for it. >> >> I can't solve second and third drawbacks now. A possible alternative is using the media-type [5] `application/vnd.github.VERSION.diff` or `application/vnd.github.VERSION.patch` to get the meta `diff` or `patch` data and parse them. But the current paser classes `GitRawDiffParser` and `UnifiedDiffParser` can't parse such meta diff or patch (the format is not suitable). It needs many changes to the code about vcs, so I don't think it is a short term solution. >> >> As a conclusion, this patch can solve the situations provided by kevin in SKARA-1332. But it can't identify the difference of the "too large" files and the files which exceeds 3000. Note: this shortcoming has already existed in SKARA and is not produced by this patch. >> >> Best Regards, >> -- Guoxiong >> >> [1] https://api.github.com/repos/openjdk/jfx/commits/b0f2521219efc1b0d0c45088736d5105712bc2c9?&per_page=71 >> [2] https://api.github.com/repos/openjdk/jfx/commits/b0f2521219efc1b0d0c45088736d5105712bc2c9 >> [3] https://git.openjdk.java.net/jfx/commit/6f28d912024495278c4c35ab054bc2aab480b3e4 >> [4] https://api.github.com/repos/openjdk/jfx/commits/6f28d912024495278c4c35ab054bc2aab480b3e4 >> [5] https://docs.github.com/en/rest/overview/media-types#commits-commit-comparison-and-pull-requests > > Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: > > Add comment. Thanks, looks good. ------------- Marked as reviewed by erikj (Lead). PR: https://git.openjdk.java.net/skara/pull/1302 From gli at openjdk.java.net Fri Apr 22 17:24:23 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Fri, 22 Apr 2022 17:24:23 GMT Subject: RFR: 1406: Two GitHub APIs don't return `patch` field when `per_page` argument exceeds 70 In-Reply-To: References: <_gvFWa5LQojANqX7OgbYwnGB_8yTQDaL6yBvZsjV3V8=.a953d587-15b5-41e7-af43-90d9b0fa8f8f@github.com> Message-ID: On Fri, 22 Apr 2022 13:59:34 GMT, Erik Joelsson wrote: >> Hi all, >> >> When the bot checks whether a backport is clean, it would use the [get-a-commit](https://docs.github.com/en/rest/commits/commits#get-a-commit) api to get the patch files of the original commit and use the [list-pull-requests-files](https://docs.github.com/en/rest/pulls/pulls#list-pull-requests-files) api to get the patch files of the backport PR, and then compare them. >> >> But the [get-a-commit](https://docs.github.com/en/rest/commits/commits#get-a-commit) api has the following drawbacks: >> >> 1. When the `per_page` argument exceeds 70, the files after 70th don't have the `patch` field. Please see the link [1] with `per_page` as 71, the final file, 71th, doesn't have the `patch` field. And the default `per_page` of this api is **300**, so if we don't provide a `per_page` and the total files number exceeds 70, we get the wrong result without `patch` field as well [2]. >> 2. At most 3000 patch files of a commit are returned by the api. If the files number exceeds 3000, such as [3], the api returns only 3000 files. The class `RestRequest` gets the pagination information duplicately, but finally only get 3000 files. (The test case of this patch can prove it.) >> 3. If a patch file of the commit is too large (not exactly know the api how to judge "too large"), the api doesn't return the patch file as well. Please use the link [1] and find `modules/javafx.web/src/main/native/Source/ThirdParty/libxml/src/ChangeLog` or `modules/javafx.web/src/main/native/Source/ThirdParty/libxml/src/HTMLparser.c`, you can identify that they don't have the `patch` field. >> >> The [list-pull-requests-files](https://docs.github.com/en/rest/pulls/pulls#list-pull-requests-files) api has the same drawbacks, but its default `per_page` is **30** instead of **300**, so the first drawback above doesn't happen in this api **now**. >> >> This patch adds the `per_page` argument to these two api so that we can solve the first drawback. Note: considering the default `per_page` of the api [list-pull-requests-files](https://docs.github.com/en/rest/pulls/pulls#list-pull-requests-files) will change in the future (may exceed 70), it is good to also provide a explicit `per_page` for it. >> >> I can't solve second and third drawbacks now. A possible alternative is using the media-type [5] `application/vnd.github.VERSION.diff` or `application/vnd.github.VERSION.patch` to get the meta `diff` or `patch` data and parse them. But the current paser classes `GitRawDiffParser` and `UnifiedDiffParser` can't parse such meta diff or patch (the format is not suitable). It needs many changes to the code about vcs, so I don't think it is a short term solution. >> >> As a conclusion, this patch can solve the situations provided by kevin in SKARA-1332. But it can't identify the difference of the "too large" files and the files which exceeds 3000. Note: this shortcoming has already existed in SKARA and is not produced by this patch. >> >> Best Regards, >> -- Guoxiong >> >> [1] https://api.github.com/repos/openjdk/jfx/commits/b0f2521219efc1b0d0c45088736d5105712bc2c9?&per_page=71 >> [2] https://api.github.com/repos/openjdk/jfx/commits/b0f2521219efc1b0d0c45088736d5105712bc2c9 >> [3] https://git.openjdk.java.net/jfx/commit/6f28d912024495278c4c35ab054bc2aab480b3e4 >> [4] https://api.github.com/repos/openjdk/jfx/commits/6f28d912024495278c4c35ab054bc2aab480b3e4 >> [5] https://docs.github.com/en/rest/overview/media-types#commits-commit-comparison-and-pull-requests > > This looks like a good change. Thanks for identifying these causes for failing to get patch information from Github. In addition to the cases you have identified here which aren't solved, most of the examples given in the original bug were hidden from you as they pertain to a private Gitlab instance. So until we can address those, I would like the original bug open. Could you file a new bug describing the particular problem you are solving here and change this PR to reference that bug? Please link it to the existing bug and add a comment in the original explaining that part of the problem is being solved in the new bug. @erikj79 thanks for the review. Could I get your help to sponsor this patch? ------------- PR: https://git.openjdk.java.net/skara/pull/1302 From gli at openjdk.java.net Fri Apr 22 17:56:05 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Fri, 22 Apr 2022 17:56:05 GMT Subject: Integrated: 1406: Two GitHub APIs don't return `patch` field when `per_page` argument exceeds 70 In-Reply-To: <_gvFWa5LQojANqX7OgbYwnGB_8yTQDaL6yBvZsjV3V8=.a953d587-15b5-41e7-af43-90d9b0fa8f8f@github.com> References: <_gvFWa5LQojANqX7OgbYwnGB_8yTQDaL6yBvZsjV3V8=.a953d587-15b5-41e7-af43-90d9b0fa8f8f@github.com> Message-ID: On Fri, 22 Apr 2022 07:38:59 GMT, Guoxiong Li wrote: > Hi all, > > When the bot checks whether a backport is clean, it would use the [get-a-commit](https://docs.github.com/en/rest/commits/commits#get-a-commit) api to get the patch files of the original commit and use the [list-pull-requests-files](https://docs.github.com/en/rest/pulls/pulls#list-pull-requests-files) api to get the patch files of the backport PR, and then compare them. > > But the [get-a-commit](https://docs.github.com/en/rest/commits/commits#get-a-commit) api has the following drawbacks: > > 1. When the `per_page` argument exceeds 70, the files after 70th don't have the `patch` field. Please see the link [1] with `per_page` as 71, the final file, 71th, doesn't have the `patch` field. And the default `per_page` of this api is **300**, so if we don't provide a `per_page` and the total files number exceeds 70, we get the wrong result without `patch` field as well [2]. > 2. At most 3000 patch files of a commit are returned by the api. If the files number exceeds 3000, such as [3], the api returns only 3000 files. The class `RestRequest` gets the pagination information duplicately, but finally only get 3000 files. (The test case of this patch can prove it.) > 3. If a patch file of the commit is too large (not exactly know the api how to judge "too large"), the api doesn't return the patch file as well. Please use the link [1] and find `modules/javafx.web/src/main/native/Source/ThirdParty/libxml/src/ChangeLog` or `modules/javafx.web/src/main/native/Source/ThirdParty/libxml/src/HTMLparser.c`, you can identify that they don't have the `patch` field. > > The [list-pull-requests-files](https://docs.github.com/en/rest/pulls/pulls#list-pull-requests-files) api has the same drawbacks, but its default `per_page` is **30** instead of **300**, so the first drawback above doesn't happen in this api **now**. > > This patch adds the `per_page` argument to these two api so that we can solve the first drawback. Note: considering the default `per_page` of the api [list-pull-requests-files](https://docs.github.com/en/rest/pulls/pulls#list-pull-requests-files) will change in the future (may exceed 70), it is good to also provide a explicit `per_page` for it. > > I can't solve second and third drawbacks now. A possible alternative is using the media-type [5] `application/vnd.github.VERSION.diff` or `application/vnd.github.VERSION.patch` to get the meta `diff` or `patch` data and parse them. But the current paser classes `GitRawDiffParser` and `UnifiedDiffParser` can't parse such meta diff or patch (the format is not suitable). It needs many changes to the code about vcs, so I don't think it is a short term solution. > > As a conclusion, this patch can solve the situations provided by kevin in SKARA-1332. But it can't identify the difference of the "too large" files and the files which exceeds 3000. Note: this shortcoming has already existed in SKARA and is not produced by this patch. > > Best Regards, > -- Guoxiong > > [1] https://api.github.com/repos/openjdk/jfx/commits/b0f2521219efc1b0d0c45088736d5105712bc2c9?&per_page=71 > [2] https://api.github.com/repos/openjdk/jfx/commits/b0f2521219efc1b0d0c45088736d5105712bc2c9 > [3] https://git.openjdk.java.net/jfx/commit/6f28d912024495278c4c35ab054bc2aab480b3e4 > [4] https://api.github.com/repos/openjdk/jfx/commits/6f28d912024495278c4c35ab054bc2aab480b3e4 > [5] https://docs.github.com/en/rest/overview/media-types#commits-commit-comparison-and-pull-requests This pull request has now been integrated. Changeset: 528895bf Author: Guoxiong Li Committer: Erik Joelsson URL: https://git.openjdk.java.net/skara/commit/528895bf34aa737017c18ced7aa776ef2f5596e3 Stats: 106 lines in 3 files changed: 103 ins; 0 del; 3 mod 1406: Two GitHub APIs don't return `patch` field when `per_page` argument exceeds 70 Reviewed-by: erikj ------------- PR: https://git.openjdk.java.net/skara/pull/1302 From gli at openjdk.java.net Sat Apr 23 15:53:09 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Sat, 23 Apr 2022 15:53:09 GMT Subject: RFR: 1395: The "Review applies to " link is misleading Message-ID: <3otviio5QVDRGqEX7ott0Pa4CaTK1dml0tf1bNsabHw=.350e2297-3156-42a4-bdfb-bcddab8364c3@github.com> Hi all, This trivial patch changes the `commit hash value` to a link which contains the changed files from the first commit of a PR to this `commit`. And the test case is adjusted. Thanks for taking the time to review. Best Regards, -- Guoxiong ------------- Commit messages: - 1395: The "Review applies to " link is misleading Changes: https://git.openjdk.java.net/skara/pull/1303/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1303&range=00 Issue: https://bugs.openjdk.java.net/browse/SKARA-1395 Stats: 6 lines in 2 files changed: 3 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/skara/pull/1303.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1303/head:pull/1303 PR: https://git.openjdk.java.net/skara/pull/1303 From gli at openjdk.java.net Sat Apr 23 21:26:39 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Sat, 23 Apr 2022 21:26:39 GMT Subject: RFR: 1407: GitLabMergeRequest#filesUrl returns wrong result Message-ID: Hi all, The SKARA-744 [1][2] solved a problem about the link to the changes for just one commit. But it didn't solve the issue completely in GitLab. Please see the current issue [3] for more information. This patch revises `GitLabMergeRequest#filesUrl` to return a `version url` if it exists which can represent the changed files **from the first commit to the provided commit HASH**. A corresponding test is added and a previous test is polished. You can use the following config to run the new test `GitLabRestApiTest#testFilesUrl`: gitlab.user= gitlab.pat= gitlab.uri=https://gitlab.com gitlab.repository=35596381 gitlab.merge.request.id=1 gitlab.version.hash=60f39eb698e73cc2660f870667a54e7a53ee7018 gitlab.version.url=https://gitlab.com/lgxbslgx/test/-/merge_requests/1/diffs?diff_id=379601911 gitlab.nonversion.hash=c9b5a70790b13c3e7e182c9b83015f9f10d53df7 gitlab.nonversion.url=https://gitlab.com/lgxbslgx/test/-/merge_requests/1/diffs?commit_id=c9b5a70790b13c3e7e182c9b83015f9f10d53df7 Thanks for taking the time to review. Best Regards, -- Guoxiong [1] https://bugs.openjdk.java.net/browse/SKARA-744 [2] https://git.openjdk.java.net/skara/commit/f16663b7 [3] https://bugs.openjdk.java.net/browse/SKARA-1407 ------------- Commit messages: - 1407: GitLabMergeRequest#filesUrl returns wrong result Changes: https://git.openjdk.java.net/skara/pull/1304/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1304&range=00 Issue: https://bugs.openjdk.java.net/browse/SKARA-1407 Stats: 76 lines in 3 files changed: 71 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/skara/pull/1304.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1304/head:pull/1304 PR: https://git.openjdk.java.net/skara/pull/1304 From gli at openjdk.java.net Sun Apr 24 15:28:08 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Sun, 24 Apr 2022 15:28:08 GMT Subject: RFR: 1407: GitLabMergeRequest#filesUrl returns wrong result In-Reply-To: References: Message-ID: <55Vw9tFXXlagkdT20UD7aMX9h6if6YUmsU-deWeBREA=.dd481196-8c1f-403d-a880-a6d5672688b4@github.com> On Sat, 23 Apr 2022 21:22:34 GMT, Guoxiong Li wrote: > Hi all, > > The SKARA-744 [1][2] solved a problem about the link to the changes for just one commit. But it didn't solve the issue completely in GitLab. Please see the current issue [3] for more information. > > This patch revises `GitLabMergeRequest#filesUrl` to return a `version url` if it exists which can represent the changed files **from the first commit to the provided commit HASH**. A corresponding test is added and a previous test is polished. > > You can use the following config to run the new test `GitLabRestApiTest#testFilesUrl`: > > > gitlab.user= > gitlab.pat= > > gitlab.uri=https://gitlab.com > gitlab.repository=35596381 > gitlab.merge.request.id=1 > > gitlab.version.hash=60f39eb698e73cc2660f870667a54e7a53ee7018 > gitlab.version.url=https://gitlab.com/lgxbslgx/test/-/merge_requests/1/diffs?diff_id=379601911 > gitlab.nonversion.hash=c9b5a70790b13c3e7e182c9b83015f9f10d53df7 > gitlab.nonversion.url=https://gitlab.com/lgxbslgx/test/-/merge_requests/1/diffs?commit_id=c9b5a70790b13c3e7e182c9b83015f9f10d53df7 > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong > > [1] https://bugs.openjdk.java.net/browse/SKARA-744 > [2] https://git.openjdk.java.net/skara/commit/f16663b7 > [3] https://bugs.openjdk.java.net/browse/SKARA-1407 I mistook this PR for [the PR in the playground](https://github.com/openjdk/playground/pull/94). I apologize for it. Could I get your help to reset the reviewers? Thanks a lot. ------------- PR: https://git.openjdk.java.net/skara/pull/1304 From gli at openjdk.java.net Sun Apr 24 16:04:14 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Sun, 24 Apr 2022 16:04:14 GMT Subject: RFR: 282: Make the review requirements more explicit in the progress list Message-ID: Hi all, This patch adds the explicit review requirements, such as ` (2 reviews required, with at least 1 Reviewer).`, to the progress list and adds some test cases. Thanks for taking the time to review. Best Regards, -- Guoxiong ------------- Commit messages: - 282: Make the review requirements more explicit in the progress list Changes: https://git.openjdk.java.net/skara/pull/1305/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1305&range=00 Issue: https://bugs.openjdk.java.net/browse/SKARA-282 Stats: 166 lines in 3 files changed: 153 ins; 0 del; 13 mod Patch: https://git.openjdk.java.net/skara/pull/1305.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1305/head:pull/1305 PR: https://git.openjdk.java.net/skara/pull/1305 From dholmes at openjdk.java.net Mon Apr 25 02:09:49 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 25 Apr 2022 02:09:49 GMT Subject: RFR: 282: Make the review requirements more explicit in the progress list In-Reply-To: References: Message-ID: On Sun, 24 Apr 2022 15:59:42 GMT, Guoxiong Li wrote: > Hi all, > > This patch adds the explicit review requirements, such as ` (2 reviews required, with at least 1 Reviewer).`, to the progress list and adds some test cases. > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong These are informal rules not codified anywhere so how are you determining what criteria to report? Hotspot generally requires two reviews, but that is not a blanket rule. ------------- PR: https://git.openjdk.java.net/skara/pull/1305 From gli at openjdk.java.net Mon Apr 25 06:14:02 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Mon, 25 Apr 2022 06:14:02 GMT Subject: RFR: 282: Make the review requirements more explicit in the progress list In-Reply-To: References: Message-ID: On Mon, 25 Apr 2022 02:07:04 GMT, David Holmes wrote: > These are informal rules not codified anywhere so how are you determining what criteria to report? Hotspot generally requires two reviews, but that is not a blanket rule. The concrete reviews information depends on the configuration in `.jcheck/conf` and the `reviewers` command. For example, please see this [PR](https://github.com/openjdk/jdk/pull/7204#issuecomment-1032111596), when someone typed `/reviewers 2`, the bot replied `The number of required reviews for this PR is now set to 2 (with at least 1 of role reviewers)`. This patch puts similar information to the `Progress` of the PR body so that developers can read it earily instead of searching it in the comments. ------------- PR: https://git.openjdk.java.net/skara/pull/1305 From gli at openjdk.java.net Mon Apr 25 09:41:13 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Mon, 25 Apr 2022 09:41:13 GMT Subject: RFR: 1408: GitLabMergeRequest#reviews sometimes finds the wrong commit HASH Message-ID: Hi all, Please consider the following steps: - the author creates "commit 1" locally (with hash "95f2d613cf392275075d7c87285845531f5fe827" [1]) - the author pushes it and creates a merge request in the Gitlab, then the Gitlab creates "version 1" [2] (its hash is the hash of "commit 1") which has the changed files of "commit 1" - the author creates "commit 2" locally (with hash "99ca51edfa0063113a2236fce548ba453aee7275" [3]) - a reviewer approves the MR with the "**version 1**" in the Gitlab. Note: the "commit 2" is not pushed now. - the author creates "commit 3" locally (with hash "50b119c4c325053b8151ea6e761a60d1acfbb746" [4]) Note: this step seems optional - the author pushes the commits and the gitlab create "version 2" [5] (its hash is the hash of "commit 3") which has the changed files of "commit 1-3" When we use the method `GitLabMergeRequest#reviews` to get the reviews list, we can see the review hash is the hash of the "commit 2" ("99ca51edfa0063113a2236fce548ba453aee7275"). But actually, the reviewer only approved "version 1" with hash of the "commit 1" ("95f2d613cf392275075d7c87285845531f5fe827"). This patch uses the `versions` list instead of all the `commits` list to fix the issue. And when I wrote a test case to verify it, I got a NPE and filed SKARA-1409 to record it. This patch also solves SKARA-1409 so that the reviewer can run the test locally. You can use the following config to run the test: gitlab.user= gitlab.pat= gitlab.uri=https://gitlab.com gitlab.repository=35596381 gitlab.merge.request.id=2 gitlab.review.hash=95f2d613cf392275075d7c87285845531f5fe827 Note: this PR seems have git conflict with [SKARA-1407-PATCH](https://github.com/openjdk/skara/pull/1304). I will solve the conflict when one of them is integrated. Thanks for taking the time to review. Best Regards, -- Guoxiong [1] https://gitlab.com/lgxbslgx/test/-/merge_requests/2/diffs?commit_id=95f2d613cf392275075d7c87285845531f5fe827 [2] https://gitlab.com/lgxbslgx/test/-/merge_requests/2/diffs?diff_id=379883693 [3] https://gitlab.com/lgxbslgx/test/-/merge_requests/2/diffs?commit_id=99ca51edfa0063113a2236fce548ba453aee7275 [4] https://gitlab.com/lgxbslgx/test/-/merge_requests/2/diffs?commit_id=50b119c4c325053b8151ea6e761a60d1acfbb746 [5] https://gitlab.com/lgxbslgx/test/-/merge_requests/2/diffs?diff_id=379907777 --- ------------- Commit messages: - Disable test. - 1409: The GitLab 'list-users' api doesn't return 'email' field for normal users - 1408: GitLabMergeRequest#reviews sometimes finds the wrong commit HASH Changes: https://git.openjdk.java.net/skara/pull/1306/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1306&range=00 Issue: https://bugs.openjdk.java.net/browse/SKARA-1408 Stats: 63 lines in 3 files changed: 58 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/skara/pull/1306.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1306/head:pull/1306 PR: https://git.openjdk.java.net/skara/pull/1306 From erikj at openjdk.java.net Mon Apr 25 13:16:34 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 25 Apr 2022 13:16:34 GMT Subject: RFR: 1407: GitLabMergeRequest#filesUrl returns wrong result In-Reply-To: References: Message-ID: On Sat, 23 Apr 2022 21:22:34 GMT, Guoxiong Li wrote: > Hi all, > > The SKARA-744 [1][2] solved a problem about the link to the changes for just one commit. But it didn't solve the issue completely in GitLab. Please see the current issue [3] for more information. > > This patch revises `GitLabMergeRequest#filesUrl` to return a `version url` if it exists which can represent the changed files **from the first commit to the provided commit HASH**. A corresponding test is added and a previous test is polished. > > You can use the following config to run the new test `GitLabRestApiTest#testFilesUrl`: > > > gitlab.user= > gitlab.pat= > > gitlab.uri=https://gitlab.com > gitlab.repository=35596381 > gitlab.merge.request.id=1 > > gitlab.version.hash=60f39eb698e73cc2660f870667a54e7a53ee7018 > gitlab.version.url=https://gitlab.com/lgxbslgx/test/-/merge_requests/1/diffs?diff_id=379601911 > gitlab.nonversion.hash=c9b5a70790b13c3e7e182c9b83015f9f10d53df7 > gitlab.nonversion.url=https://gitlab.com/lgxbslgx/test/-/merge_requests/1/diffs?commit_id=c9b5a70790b13c3e7e182c9b83015f9f10d53df7 > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong > > [1] https://bugs.openjdk.java.net/browse/SKARA-744 > [2] https://git.openjdk.java.net/skara/commit/f16663b7 > [3] https://bugs.openjdk.java.net/browse/SKARA-1407 forge/src/main/java/org/openjdk/skara/forge/gitlab/GitLabMergeRequest.java line 846: > 844: var versionId = request.get("versions").execute().stream() > 845: .filter(version -> hash.hex().equals(version.get("head_commit_sha").asString())) > 846: .map(version -> String.valueOf(version.get("id").asInt())) I don't think we need to convert this to an int to then just create a string again. ------------- PR: https://git.openjdk.java.net/skara/pull/1304 From erikj at openjdk.java.net Mon Apr 25 13:17:57 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 25 Apr 2022 13:17:57 GMT Subject: RFR: 1395: The "Review applies to " link is misleading In-Reply-To: <3otviio5QVDRGqEX7ott0Pa4CaTK1dml0tf1bNsabHw=.350e2297-3156-42a4-bdfb-bcddab8364c3@github.com> References: <3otviio5QVDRGqEX7ott0Pa4CaTK1dml0tf1bNsabHw=.350e2297-3156-42a4-bdfb-bcddab8364c3@github.com> Message-ID: On Sat, 23 Apr 2022 15:48:52 GMT, Guoxiong Li wrote: > Hi all, > > This trivial patch changes the `commit hash value` to a link which contains the changed files from the first commit of a PR to this `commit`. And the test case is adjusted. > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong Marked as reviewed by erikj (Lead). ------------- PR: https://git.openjdk.java.net/skara/pull/1303 From gli at openjdk.java.net Mon Apr 25 13:25:54 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Mon, 25 Apr 2022 13:25:54 GMT Subject: RFR: 1407: GitLabMergeRequest#filesUrl returns wrong result In-Reply-To: References: Message-ID: <5-M07Wvlym_z0nREhJb4lTGzGrUqhURnOYEJ1eNVeCo=.ead1a34d-9bf4-414c-a637-6eb53bae0273@github.com> On Mon, 25 Apr 2022 13:13:11 GMT, Erik Joelsson wrote: >> Hi all, >> >> The SKARA-744 [1][2] solved a problem about the link to the changes for just one commit. But it didn't solve the issue completely in GitLab. Please see the current issue [3] for more information. >> >> This patch revises `GitLabMergeRequest#filesUrl` to return a `version url` if it exists which can represent the changed files **from the first commit to the provided commit HASH**. A corresponding test is added and a previous test is polished. >> >> You can use the following config to run the new test `GitLabRestApiTest#testFilesUrl`: >> >> >> gitlab.user= >> gitlab.pat= >> >> gitlab.uri=https://gitlab.com >> gitlab.repository=35596381 >> gitlab.merge.request.id=1 >> >> gitlab.version.hash=60f39eb698e73cc2660f870667a54e7a53ee7018 >> gitlab.version.url=https://gitlab.com/lgxbslgx/test/-/merge_requests/1/diffs?diff_id=379601911 >> gitlab.nonversion.hash=c9b5a70790b13c3e7e182c9b83015f9f10d53df7 >> gitlab.nonversion.url=https://gitlab.com/lgxbslgx/test/-/merge_requests/1/diffs?commit_id=c9b5a70790b13c3e7e182c9b83015f9f10d53df7 >> >> Thanks for taking the time to review. >> >> Best Regards, >> -- Guoxiong >> >> [1] https://bugs.openjdk.java.net/browse/SKARA-744 >> [2] https://git.openjdk.java.net/skara/commit/f16663b7 >> [3] https://bugs.openjdk.java.net/browse/SKARA-1407 > > forge/src/main/java/org/openjdk/skara/forge/gitlab/GitLabMergeRequest.java line 846: > >> 844: var versionId = request.get("versions").execute().stream() >> 845: .filter(version -> hash.hex().equals(version.get("head_commit_sha").asString())) >> 846: .map(version -> String.valueOf(version.get("id").asInt())) > > I don't think we need to convert this to an int to then just create a string again. The `id` field of a `version` is a int type in the json so that `version.get("id").asString()` will throw a exception. ------------- PR: https://git.openjdk.java.net/skara/pull/1304 From gli at openjdk.java.net Mon Apr 25 13:28:00 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Mon, 25 Apr 2022 13:28:00 GMT Subject: RFR: 1395: The "Review applies to " link is misleading In-Reply-To: References: <3otviio5QVDRGqEX7ott0Pa4CaTK1dml0tf1bNsabHw=.350e2297-3156-42a4-bdfb-bcddab8364c3@github.com> Message-ID: On Mon, 25 Apr 2022 13:15:09 GMT, Erik Joelsson wrote: >> Hi all, >> >> This trivial patch changes the `commit hash value` to a link which contains the changed files from the first commit of a PR to this `commit`. And the test case is adjusted. >> >> Thanks for taking the time to review. >> >> Best Regards, >> -- Guoxiong > > Marked as reviewed by erikj (Lead). @erikj79 Thanks for the review. Could I get your help to sponsor this patch? ------------- PR: https://git.openjdk.java.net/skara/pull/1303 From erikj at openjdk.java.net Mon Apr 25 13:31:34 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 25 Apr 2022 13:31:34 GMT Subject: RFR: 1408: GitLabMergeRequest#reviews sometimes finds the wrong commit HASH In-Reply-To: References: Message-ID: On Mon, 25 Apr 2022 09:37:04 GMT, Guoxiong Li wrote: > Hi all, > > Please consider the following steps: > > - the author creates "commit 1" locally (with hash "95f2d613cf392275075d7c87285845531f5fe827" [1]) > - the author pushes it and creates a merge request in the Gitlab, then the Gitlab creates "version 1" [2] (its hash is the hash of "commit 1") which has the changed files of "commit 1" > - the author creates "commit 2" locally (with hash "99ca51edfa0063113a2236fce548ba453aee7275" [3]) > - a reviewer approves the MR with the "**version 1**" in the Gitlab. Note: the "commit 2" is not pushed now. > - the author creates "commit 3" locally (with hash "50b119c4c325053b8151ea6e761a60d1acfbb746" [4]) Note: this step seems optional > - the author pushes the commits and the gitlab create "version 2" [5] (its hash is the hash of "commit 3") which has the changed files of "commit 1-3" > > When we use the method `GitLabMergeRequest#reviews` to get the reviews list, we can see the review hash is the hash of the "commit 2" ("99ca51edfa0063113a2236fce548ba453aee7275"). But actually, the reviewer only approved "version 1" with hash of the "commit 1" ("95f2d613cf392275075d7c87285845531f5fe827"). > > This patch uses the `versions` list instead of all the `commits` list to fix the issue. And when I wrote a test case to verify it, I got a NPE and filed SKARA-1409 to record it. This patch also solves SKARA-1409 so that the reviewer can run the test locally. > > You can use the following config to run the test: > > gitlab.user= > gitlab.pat= > > gitlab.uri=https://gitlab.com > gitlab.repository=35596381 > gitlab.merge.request.id=2 > gitlab.review.hash=95f2d613cf392275075d7c87285845531f5fe827 > > > Note: this PR seems have git conflict with [SKARA-1407-PATCH](https://github.com/openjdk/skara/pull/1304). I will solve the conflict when one of them is integrated. > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong > > [1] https://gitlab.com/lgxbslgx/test/-/merge_requests/2/diffs?commit_id=95f2d613cf392275075d7c87285845531f5fe827 > [2] https://gitlab.com/lgxbslgx/test/-/merge_requests/2/diffs?diff_id=379883693 > [3] https://gitlab.com/lgxbslgx/test/-/merge_requests/2/diffs?commit_id=99ca51edfa0063113a2236fce548ba453aee7275 > [4] https://gitlab.com/lgxbslgx/test/-/merge_requests/2/diffs?commit_id=50b119c4c325053b8151ea6e761a60d1acfbb746 > [5] https://gitlab.com/lgxbslgx/test/-/merge_requests/2/diffs?diff_id=379907777 > > --- Marked as reviewed by erikj (Lead). ------------- PR: https://git.openjdk.java.net/skara/pull/1306 From erikj at openjdk.java.net Mon Apr 25 13:35:39 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 25 Apr 2022 13:35:39 GMT Subject: RFR: 1407: GitLabMergeRequest#filesUrl returns wrong result In-Reply-To: References: Message-ID: On Sat, 23 Apr 2022 21:22:34 GMT, Guoxiong Li wrote: > Hi all, > > The SKARA-744 [1][2] solved a problem about the link to the changes for just one commit. But it didn't solve the issue completely in GitLab. Please see the current issue [3] for more information. > > This patch revises `GitLabMergeRequest#filesUrl` to return a `version url` if it exists which can represent the changed files **from the first commit to the provided commit HASH**. A corresponding test is added and a previous test is polished. > > You can use the following config to run the new test `GitLabRestApiTest#testFilesUrl`: > > > gitlab.user= > gitlab.pat= > > gitlab.uri=https://gitlab.com > gitlab.repository=35596381 > gitlab.merge.request.id=1 > > gitlab.version.hash=60f39eb698e73cc2660f870667a54e7a53ee7018 > gitlab.version.url=https://gitlab.com/lgxbslgx/test/-/merge_requests/1/diffs?diff_id=379601911 > gitlab.nonversion.hash=c9b5a70790b13c3e7e182c9b83015f9f10d53df7 > gitlab.nonversion.url=https://gitlab.com/lgxbslgx/test/-/merge_requests/1/diffs?commit_id=c9b5a70790b13c3e7e182c9b83015f9f10d53df7 > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong > > [1] https://bugs.openjdk.java.net/browse/SKARA-744 > [2] https://git.openjdk.java.net/skara/commit/f16663b7 > [3] https://bugs.openjdk.java.net/browse/SKARA-1407 Marked as reviewed by erikj (Lead). ------------- PR: https://git.openjdk.java.net/skara/pull/1304 From gli at openjdk.java.net Mon Apr 25 13:35:39 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Mon, 25 Apr 2022 13:35:39 GMT Subject: RFR: 1407: GitLabMergeRequest#filesUrl returns wrong result In-Reply-To: References: Message-ID: On Mon, 25 Apr 2022 13:30:22 GMT, Erik Joelsson wrote: >> Hi all, >> >> The SKARA-744 [1][2] solved a problem about the link to the changes for just one commit. But it didn't solve the issue completely in GitLab. Please see the current issue [3] for more information. >> >> This patch revises `GitLabMergeRequest#filesUrl` to return a `version url` if it exists which can represent the changed files **from the first commit to the provided commit HASH**. A corresponding test is added and a previous test is polished. >> >> You can use the following config to run the new test `GitLabRestApiTest#testFilesUrl`: >> >> >> gitlab.user= >> gitlab.pat= >> >> gitlab.uri=https://gitlab.com >> gitlab.repository=35596381 >> gitlab.merge.request.id=1 >> >> gitlab.version.hash=60f39eb698e73cc2660f870667a54e7a53ee7018 >> gitlab.version.url=https://gitlab.com/lgxbslgx/test/-/merge_requests/1/diffs?diff_id=379601911 >> gitlab.nonversion.hash=c9b5a70790b13c3e7e182c9b83015f9f10d53df7 >> gitlab.nonversion.url=https://gitlab.com/lgxbslgx/test/-/merge_requests/1/diffs?commit_id=c9b5a70790b13c3e7e182c9b83015f9f10d53df7 >> >> Thanks for taking the time to review. >> >> Best Regards, >> -- Guoxiong >> >> [1] https://bugs.openjdk.java.net/browse/SKARA-744 >> [2] https://git.openjdk.java.net/skara/commit/f16663b7 >> [3] https://bugs.openjdk.java.net/browse/SKARA-1407 > > Marked as reviewed by erikj (Lead). @erikj79 Could I get your help to descrease the reviews requirement? I mistakenly typed `/reviewers 3 reviewer` in this PR and don't have permission to descrease it now. ------------- PR: https://git.openjdk.java.net/skara/pull/1304 From erikj at openjdk.java.net Mon Apr 25 13:35:39 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 25 Apr 2022 13:35:39 GMT Subject: RFR: 1407: GitLabMergeRequest#filesUrl returns wrong result In-Reply-To: <5-M07Wvlym_z0nREhJb4lTGzGrUqhURnOYEJ1eNVeCo=.ead1a34d-9bf4-414c-a637-6eb53bae0273@github.com> References: <5-M07Wvlym_z0nREhJb4lTGzGrUqhURnOYEJ1eNVeCo=.ead1a34d-9bf4-414c-a637-6eb53bae0273@github.com> Message-ID: On Mon, 25 Apr 2022 13:22:59 GMT, Guoxiong Li wrote: >> forge/src/main/java/org/openjdk/skara/forge/gitlab/GitLabMergeRequest.java line 846: >> >>> 844: var versionId = request.get("versions").execute().stream() >>> 845: .filter(version -> hash.hex().equals(version.get("head_commit_sha").asString())) >>> 846: .map(version -> String.valueOf(version.get("id").asInt())) >> >> I don't think we need to convert this to an int to then just create a string again. > > The `id` field of a `version` is a int type in the json so that `version.get("id").asString()` will throw a exception. Oh ok, didn't know the parser was that picky. ------------- PR: https://git.openjdk.java.net/skara/pull/1304 From gli at openjdk.java.net Mon Apr 25 13:42:42 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Mon, 25 Apr 2022 13:42:42 GMT Subject: RFR: 1408: GitLabMergeRequest#reviews sometimes finds the wrong commit HASH In-Reply-To: References: Message-ID: On Mon, 25 Apr 2022 13:28:42 GMT, Erik Joelsson wrote: >> Hi all, >> >> Please consider the following steps: >> >> - the author creates "commit 1" locally (with hash "95f2d613cf392275075d7c87285845531f5fe827" [1]) >> - the author pushes it and creates a merge request in the Gitlab, then the Gitlab creates "version 1" [2] (its hash is the hash of "commit 1") which has the changed files of "commit 1" >> - the author creates "commit 2" locally (with hash "99ca51edfa0063113a2236fce548ba453aee7275" [3]) >> - a reviewer approves the MR with the "**version 1**" in the Gitlab. Note: the "commit 2" is not pushed now. >> - the author creates "commit 3" locally (with hash "50b119c4c325053b8151ea6e761a60d1acfbb746" [4]) Note: this step seems optional >> - the author pushes the commits and the gitlab create "version 2" [5] (its hash is the hash of "commit 3") which has the changed files of "commit 1-3" >> >> When we use the method `GitLabMergeRequest#reviews` to get the reviews list, we can see the review hash is the hash of the "commit 2" ("99ca51edfa0063113a2236fce548ba453aee7275"). But actually, the reviewer only approved "version 1" with hash of the "commit 1" ("95f2d613cf392275075d7c87285845531f5fe827"). >> >> This patch uses the `versions` list instead of all the `commits` list to fix the issue. And when I wrote a test case to verify it, I got a NPE and filed SKARA-1409 to record it. This patch also solves SKARA-1409 so that the reviewer can run the test locally. >> >> You can use the following config to run the test: >> >> gitlab.user= >> gitlab.pat= >> >> gitlab.uri=https://gitlab.com >> gitlab.repository=35596381 >> gitlab.merge.request.id=2 >> gitlab.review.hash=95f2d613cf392275075d7c87285845531f5fe827 >> >> >> Note: this PR seems have git conflict with [SKARA-1407-PATCH](https://github.com/openjdk/skara/pull/1304). I will solve the conflict when one of them is integrated. >> >> Thanks for taking the time to review. >> >> Best Regards, >> -- Guoxiong >> >> [1] https://gitlab.com/lgxbslgx/test/-/merge_requests/2/diffs?commit_id=95f2d613cf392275075d7c87285845531f5fe827 >> [2] https://gitlab.com/lgxbslgx/test/-/merge_requests/2/diffs?diff_id=379883693 >> [3] https://gitlab.com/lgxbslgx/test/-/merge_requests/2/diffs?commit_id=99ca51edfa0063113a2236fce548ba453aee7275 >> [4] https://gitlab.com/lgxbslgx/test/-/merge_requests/2/diffs?commit_id=50b119c4c325053b8151ea6e761a60d1acfbb746 >> [5] https://gitlab.com/lgxbslgx/test/-/merge_requests/2/diffs?diff_id=379907777 >> >> --- > > Marked as reviewed by erikj (Lead). @erikj79 Thanks for the review. Could I get your help to sponsor this patch? ------------- PR: https://git.openjdk.java.net/skara/pull/1306 From gli at openjdk.java.net Mon Apr 25 14:31:08 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Mon, 25 Apr 2022 14:31:08 GMT Subject: RFR: 282: Make the review requirements more explicit in the progress list In-Reply-To: References: Message-ID: On Sun, 24 Apr 2022 15:59:42 GMT, Guoxiong Li wrote: > Hi all, > > This patch adds the explicit review requirements, such as ` (2 reviews required, with at least 1 Reviewer).`, to the progress list and adds some test cases. > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckablePullRequest.java line 229: > 227: } > 228: // Set the review requirements for using in CheckRun#getChecksList > 229: setReviewRequirements(conf.get()); I don't think it is good to put such code in `CheckablePullRequest#executeChecks`. But I can't find a better way to do that because we need the complete `JCheckConfiguration` config information. An alternative way is duplicating the following code in the `CheckRun` so that we can get the complete config information. Optional conf; if (confOverride != null) { conf = JCheck.parseConfiguration(confOverride, additionalConfiguration); } else { conf = JCheck.parseConfiguration(localRepo, targetHash(), additionalConfiguration); } if (conf.isEmpty()) { throw new RuntimeException("Failed to parse jcheck configuration at: " + targetHash() + " with extra: " + additionalConfiguration); } ------------- PR: https://git.openjdk.java.net/skara/pull/1305 From gli at openjdk.java.net Mon Apr 25 22:04:04 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Mon, 25 Apr 2022 22:04:04 GMT Subject: RFR: 1408: GitLabMergeRequest#reviews sometimes finds the wrong commit HASH In-Reply-To: References: Message-ID: On Mon, 25 Apr 2022 09:37:04 GMT, Guoxiong Li wrote: > Hi all, > > Please consider the following steps: > > - the author creates "commit 1" locally (with hash "95f2d613cf392275075d7c87285845531f5fe827" [1]) > - the author pushes it and creates a merge request in the Gitlab, then the Gitlab creates "version 1" [2] (its hash is the hash of "commit 1") which has the changed files of "commit 1" > - the author creates "commit 2" locally (with hash "99ca51edfa0063113a2236fce548ba453aee7275" [3]) > - a reviewer approves the MR with the "**version 1**" in the Gitlab. Note: the "commit 2" is not pushed now. > - the author creates "commit 3" locally (with hash "50b119c4c325053b8151ea6e761a60d1acfbb746" [4]) Note: this step seems optional > - the author pushes the commits and the gitlab create "version 2" [5] (its hash is the hash of "commit 3") which has the changed files of "commit 1-3" > > When we use the method `GitLabMergeRequest#reviews` to get the reviews list, we can see the review hash is the hash of the "commit 2" ("99ca51edfa0063113a2236fce548ba453aee7275"). But actually, the reviewer only approved "version 1" with hash of the "commit 1" ("95f2d613cf392275075d7c87285845531f5fe827"). > > This patch uses the `versions` list instead of all the `commits` list to fix the issue. And when I wrote a test case to verify it, I got a NPE and filed SKARA-1409 to record it. This patch also solves SKARA-1409 so that the reviewer can run the test locally. > > You can use the following config to run the test: > > gitlab.user= > gitlab.pat= > > gitlab.uri=https://gitlab.com > gitlab.repository=35596381 > gitlab.merge.request.id=2 > gitlab.review.hash=95f2d613cf392275075d7c87285845531f5fe827 > > > Note: this PR seems have git conflict with [SKARA-1407-PATCH](https://github.com/openjdk/skara/pull/1304). I will solve the conflict when one of them is integrated. > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong > > [1] https://gitlab.com/lgxbslgx/test/-/merge_requests/2/diffs?commit_id=95f2d613cf392275075d7c87285845531f5fe827 > [2] https://gitlab.com/lgxbslgx/test/-/merge_requests/2/diffs?diff_id=379883693 > [3] https://gitlab.com/lgxbslgx/test/-/merge_requests/2/diffs?commit_id=99ca51edfa0063113a2236fce548ba453aee7275 > [4] https://gitlab.com/lgxbslgx/test/-/merge_requests/2/diffs?commit_id=50b119c4c325053b8151ea6e761a60d1acfbb746 > [5] https://gitlab.com/lgxbslgx/test/-/merge_requests/2/diffs?diff_id=379907777 > > --- Please don't sponsor this patch now. I found a strange point at SKARA-1400 [1][2] which seems be related to this patch. I will provide the concrete info in next comment. [1] https://bugs.openjdk.java.net/browse/SKARA-1400 [2] https://github.com/openjdk/skara/pull/1300 ------------- PR: https://git.openjdk.java.net/skara/pull/1306 From gli at openjdk.java.net Mon Apr 25 22:16:00 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Mon, 25 Apr 2022 22:16:00 GMT Subject: RFR: 1408: GitLabMergeRequest#reviews sometimes finds the wrong commit HASH In-Reply-To: References: Message-ID: On Mon, 25 Apr 2022 09:37:04 GMT, Guoxiong Li wrote: > Hi all, > > Please consider the following steps: > > - the author creates "commit 1" locally (with hash "95f2d613cf392275075d7c87285845531f5fe827" [1]) > - the author pushes it and creates a merge request in the Gitlab, then the Gitlab creates "version 1" [2] (its hash is the hash of "commit 1") which has the changed files of "commit 1" > - the author creates "commit 2" locally (with hash "99ca51edfa0063113a2236fce548ba453aee7275" [3]) > - a reviewer approves the MR with the "**version 1**" in the Gitlab. Note: the "commit 2" is not pushed now. > - the author creates "commit 3" locally (with hash "50b119c4c325053b8151ea6e761a60d1acfbb746" [4]) Note: this step seems optional > - the author pushes the commits and the gitlab create "version 2" [5] (its hash is the hash of "commit 3") which has the changed files of "commit 1-3" > > When we use the method `GitLabMergeRequest#reviews` to get the reviews list, we can see the review hash is the hash of the "commit 2" ("99ca51edfa0063113a2236fce548ba453aee7275"). But actually, the reviewer only approved "version 1" with hash of the "commit 1" ("95f2d613cf392275075d7c87285845531f5fe827"). > > This patch uses the `versions` list instead of all the `commits` list to fix the issue. And when I wrote a test case to verify it, I got a NPE and filed SKARA-1409 to record it. This patch also solves SKARA-1409 so that the reviewer can run the test locally. > > You can use the following config to run the test: > > gitlab.user= > gitlab.pat= > > gitlab.uri=https://gitlab.com > gitlab.repository=35596381 > gitlab.merge.request.id=2 > gitlab.review.hash=95f2d613cf392275075d7c87285845531f5fe827 > > > Note: this PR seems have git conflict with [SKARA-1407-PATCH](https://github.com/openjdk/skara/pull/1304). I will solve the conflict when one of them is integrated. > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong > > [1] https://gitlab.com/lgxbslgx/test/-/merge_requests/2/diffs?commit_id=95f2d613cf392275075d7c87285845531f5fe827 > [2] https://gitlab.com/lgxbslgx/test/-/merge_requests/2/diffs?diff_id=379883693 > [3] https://gitlab.com/lgxbslgx/test/-/merge_requests/2/diffs?commit_id=99ca51edfa0063113a2236fce548ba453aee7275 > [4] https://gitlab.com/lgxbslgx/test/-/merge_requests/2/diffs?commit_id=50b119c4c325053b8151ea6e761a60d1acfbb746 > [5] https://gitlab.com/lgxbslgx/test/-/merge_requests/2/diffs?diff_id=379907777 > > --- >From the description in issue SKARA-1400 [1]: > This can happen if multiple commits have the same "created_at" date (the date the commit was pushed to gitlab). It seems that the `created_at` date is not the date the commit was pushed to gitlab. Please see the 3 commits of the PR body [2], the "commit 2" and "commit 3" were pushed at the same time but they have different `create_at` date which are their commit date instead of push date. So I think SKARA-1400 may be a wrong analysis and different commit should have different `create_at` date (which means we don't need to handle the situation of the same `create_at` date). What's your opinion? Did I miss anything? If you agree with me, I would like to revert SKARA-1400 in this patch. [1] https://bugs.openjdk.java.net/browse/SKARA-1400 [2] https://gitlab.com/api/v4/projects/35596381/merge_requests/2/commits ------------- PR: https://git.openjdk.java.net/skara/pull/1306 From dholmes at openjdk.java.net Mon Apr 25 22:40:49 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 25 Apr 2022 22:40:49 GMT Subject: RFR: 282: Make the review requirements more explicit in the progress list In-Reply-To: References: Message-ID: On Mon, 25 Apr 2022 06:11:13 GMT, Guoxiong Li wrote: > > These are informal rules not codified anywhere so how are you determining what criteria to report? Hotspot generally requires two reviews, but that is not a blanket rule. > > The concrete reviews information depends on the configuration in `.jcheck/conf` and the `reviewers` command. For example, please see this [PR](https://github.com/openjdk/jdk/pull/7204#issuecomment-1032111596), when someone typed `/reviewers 2`, the bot replied `The number of required reviews for this PR is now set to 2 (with at least 1 of role reviewers)`. This patch puts similar information to the `Progress` of the PR body so that developers can read it earily instead of searching it in the comments. I see - that makes sense. I'm not sure if that is what SKARA-282 was actually referring to though. ------------- PR: https://git.openjdk.java.net/skara/pull/1305 From erikj at openjdk.java.net Mon Apr 25 23:20:25 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 25 Apr 2022 23:20:25 GMT Subject: RFR: 282: Make the review requirements more explicit in the progress list In-Reply-To: References: Message-ID: On Sun, 24 Apr 2022 15:59:42 GMT, Guoxiong Li wrote: > Hi all, > > This patch adds the explicit review requirements, such as ` (2 reviews required, with at least 1 Reviewer).`, to the progress list and adds some test cases. > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong I don't think this is the right solution. After having looked through the various classes involved here, I think I would put the logic for generating a string describing the reviewer requirements in the ReviewersConfiguration class. Then I would keep PullRequestCheckIssueVisitor responsible for extracting the proper message for each kind of issue returned from the get*Checks methods, instead of modifying them in CheckRun. To do this the TooFewReviewersIssue would need to hold the requirements string from the configuration, but I think it makes enough sense for it to do that. ReviewersCheck has access to it and can provide it to the constructor. ------------- PR: https://git.openjdk.java.net/skara/pull/1305 From gli at openjdk.java.net Mon Apr 25 23:33:29 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Mon, 25 Apr 2022 23:33:29 GMT Subject: RFR: 282: Make the review requirements more explicit in the progress list In-Reply-To: References: Message-ID: On Mon, 25 Apr 2022 23:17:32 GMT, Erik Joelsson wrote: > To do this the TooFewReviewersIssue would need to hold the requirements string from the configuration, but I think it makes enough sense for it to do that. ReviewersCheck has access to it and can provide it to the constructor. I tried this way at first when I solved this issue. But then I found the ReviewersCheck doesn?t always return the TooFewReviewersIssue which means the message may miss sometimes. And if we return the message in all the issues of the ReviewersCheck, the message may also miss when the ReviewersCheck passes without any issue. ------------- PR: https://git.openjdk.java.net/skara/pull/1305 From erikj at openjdk.java.net Mon Apr 25 23:34:57 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 25 Apr 2022 23:34:57 GMT Subject: RFR: 1408: GitLabMergeRequest#reviews sometimes finds the wrong commit HASH In-Reply-To: References: Message-ID: On Mon, 25 Apr 2022 22:13:10 GMT, Guoxiong Li wrote: > So I think SKARA-1400 may be a wrong analysis and different commit should have different `create_at` date (which means we don't need to handle the situation of the same `create_at` date). I filed SKARA-1400 because I had a merge request in our internal Gitlab instance where the two commits were committed at different times, but pushed at the same time, and the `created_at` time was exactly the same. This caused the sorting to go the wrong way, just as I described in that issue. It's possible that by working with "versions" instead of "commits", the issue in SKARA-1400 won't happen, because commits pushed at the same time will automatically be part of the same version. I would rather keep it there though, it won't cause any harm. ------------- PR: https://git.openjdk.java.net/skara/pull/1306 From gli at openjdk.java.net Mon Apr 25 23:50:55 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Mon, 25 Apr 2022 23:50:55 GMT Subject: RFR: 1408: GitLabMergeRequest#reviews sometimes finds the wrong commit HASH In-Reply-To: References: Message-ID: On Mon, 25 Apr 2022 23:32:07 GMT, Erik Joelsson wrote: > the two commits were committed at different times, but pushed at the same time, and the created_at time was exactly the same This description is the same as the issue SKARA-1400, and it confuses me because the commits shouldn?t have the same create_at time if they were committed at different times. > I would rather keep it there though, it won't cause any harm. Ok, got it. ------------- PR: https://git.openjdk.java.net/skara/pull/1306 From kcr at openjdk.java.net Mon Apr 25 23:50:55 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 25 Apr 2022 23:50:55 GMT Subject: RFR: 1408: GitLabMergeRequest#reviews sometimes finds the wrong commit HASH In-Reply-To: References: Message-ID: On Mon, 25 Apr 2022 23:32:07 GMT, Erik Joelsson wrote: > I had a merge request in our internal Gitlab instance where the two commits were committed at different times, but pushed at the same time The commits in question were in fact committed at the same time, as the result of a rebase prior to pushing to my local branch. So the CommitDate was the same (down to the second anyway, which is all I can see from `git log`). They were also pushed at the same time. I don't know whether commit time being the same or the fact that they were pushed at the same time was the problem. ------------- PR: https://git.openjdk.java.net/skara/pull/1306 From gli at openjdk.java.net Mon Apr 25 23:58:49 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Mon, 25 Apr 2022 23:58:49 GMT Subject: RFR: 1408: GitLabMergeRequest#reviews sometimes finds the wrong commit HASH In-Reply-To: References: Message-ID: On Mon, 25 Apr 2022 23:48:11 GMT, Kevin Rushforth wrote: > The commits in question were in fact committed at the same time This makes sense. ------------- PR: https://git.openjdk.java.net/skara/pull/1306 From gli at openjdk.java.net Tue Apr 26 11:32:11 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Tue, 26 Apr 2022 11:32:11 GMT Subject: RFR: 1411: The JEP link warns that the issue isn't open Message-ID: <46uRsioc9mgHo7NiREepgJdGBoDPBqh8QMZ6BXXKY14=.99541344-eefd-461f-b891-4b8e39d2b031@github.com> Hi all, The JEP link shouldn't warn that JEP issue isn't open. This is similar to the CSR link[1]. An example at palyground[2]. This patch excludes the JEP issue and adds a test case. Thanks for taking the time to review. Best Regards, -- Guoxiong [1] https://bugs.openjdk.java.net/browse/SKARA-1265 [2] https://github.com/openjdk/playground/pull/94 ------------- Commit messages: - 1411: The JEP link warns that the issue isn't open Changes: https://git.openjdk.java.net/skara/pull/1307/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1307&range=00 Issue: https://bugs.openjdk.java.net/browse/SKARA-1411 Stats: 17 lines in 2 files changed: 16 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/skara/pull/1307.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1307/head:pull/1307 PR: https://git.openjdk.java.net/skara/pull/1307 From erikj at openjdk.java.net Tue Apr 26 12:51:22 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 26 Apr 2022 12:51:22 GMT Subject: RFR: 1411: The JEP link warns that the issue isn't open In-Reply-To: <46uRsioc9mgHo7NiREepgJdGBoDPBqh8QMZ6BXXKY14=.99541344-eefd-461f-b891-4b8e39d2b031@github.com> References: <46uRsioc9mgHo7NiREepgJdGBoDPBqh8QMZ6BXXKY14=.99541344-eefd-461f-b891-4b8e39d2b031@github.com> Message-ID: On Tue, 26 Apr 2022 11:27:38 GMT, Guoxiong Li wrote: > Hi all, > > The JEP link shouldn't warn that JEP issue isn't open. This is similar to the CSR link[1]. An example at playground[2]. > > This patch excludes the JEP issue and adds a test case. > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong > > [1] https://bugs.openjdk.java.net/browse/SKARA-1265 > [2] https://github.com/openjdk/playground/pull/94 Marked as reviewed by erikj (Lead). ------------- PR: https://git.openjdk.java.net/skara/pull/1307 From gli at openjdk.java.net Tue Apr 26 13:24:01 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Tue, 26 Apr 2022 13:24:01 GMT Subject: RFR: 1118: The Skara PR bot should not block on a CSR if not enabled for a repo Message-ID: <_2zDu99u_ja1C3hOKD2UVBRlRvXh5UPq5QdaOgGhKM4=.1c371438-821f-455d-a673-5bc6643dd321@github.com> Hi all, This patch adds a config item `enable-csr` for the PullRequestbot and then the `CSRCommand` firstly checks whether the csr is enabled. If not enabled, the `CSRCommand` will reply a message about it. Thanks for taking the time to review. Best Regards, -- Guoxion ------------- Commit messages: - 1118: The Skara PR bot should not block on a CSR if not enabled for a repo Changes: https://git.openjdk.java.net/skara/pull/1308/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1308&range=00 Issue: https://bugs.openjdk.java.net/browse/SKARA-1118 Stats: 69 lines in 5 files changed: 62 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/skara/pull/1308.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1308/head:pull/1308 PR: https://git.openjdk.java.net/skara/pull/1308 From gli at openjdk.java.net Tue Apr 26 13:28:42 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Tue, 26 Apr 2022 13:28:42 GMT Subject: RFR: 1118: The Skara PR bot should not block on a CSR if not enabled for a repo In-Reply-To: <_2zDu99u_ja1C3hOKD2UVBRlRvXh5UPq5QdaOgGhKM4=.1c371438-821f-455d-a673-5bc6643dd321@github.com> References: <_2zDu99u_ja1C3hOKD2UVBRlRvXh5UPq5QdaOgGhKM4=.1c371438-821f-455d-a673-5bc6643dd321@github.com> Message-ID: On Tue, 26 Apr 2022 13:20:08 GMT, Guoxiong Li wrote: > Hi all, > > This patch adds a config item `enable-csr` for the PullRequestbot and then the `CSRCommand` firstly checks whether the csr is enabled. If not enabled, the `CSRCommand` will reply a message about it. > > Thanks for taking the time to review. > > Best Regards, > -- Guoxion When solving this issue, I found the items `two-reviewers` and `24h` seem not be configurated in the JDK project. Because I had not seen the related hints in the PRs of the JDK project. The related code is shown below for convinence. // file: PullRequestBotFactory if (repo.value().contains("two-reviewers")) { var labels = repo.value().get("two-reviewers") .stream() .map(label -> label.asString()) .collect(Collectors.toSet()); botBuilder.twoReviewersLabels(labels); } if (repo.value().contains("24h")) { var labels = repo.value().get("24h") .stream() .map(label -> label.asString()) .collect(Collectors.toSet()); botBuilder.twentyFourHoursLabels(labels); } // file CheckRun if (labels.stream().anyMatch(label -> workItem.bot.twoReviewersLabels().contains(label))) { message.append("\n\n"); message.append("?? One or more changes in this pull request modifies files in areas of "); message.append("the source code that often require two reviewers. Please consider if this is "); message.append("the case for this pull request, and if so, await a second reviewer to approve "); message.append("this pull request before you integrate it."); } if (labels.stream().anyMatch(label -> workItem.bot.twentyFourHoursLabels().contains(label))) { var rfrAt = pr.labelAddedAt("rfr"); if (rfrAt.isPresent() && ZonedDateTime.now().minusHours(24).isBefore(rfrAt.get())) { message.append("\n\n"); message.append("?? Applicable reviewers for one or more changes in this pull request are spread across "); message.append("multiple different time zones. Please consider waiting with integrating this pull request until it has "); message.append("been out for review for at least 24 hours to give all reviewers a chance to review the pull request."); } } ------------- PR: https://git.openjdk.java.net/skara/pull/1308 From gli at openjdk.java.net Tue Apr 26 14:33:24 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Tue, 26 Apr 2022 14:33:24 GMT Subject: RFR: 1411: The JEP link warns that the issue isn't open In-Reply-To: References: <46uRsioc9mgHo7NiREepgJdGBoDPBqh8QMZ6BXXKY14=.99541344-eefd-461f-b891-4b8e39d2b031@github.com> Message-ID: On Tue, 26 Apr 2022 12:48:36 GMT, Erik Joelsson wrote: >> Hi all, >> >> The JEP link shouldn't warn that JEP issue isn't open. This is similar to the CSR link[1]. An example at playground[2]. >> >> This patch excludes the JEP issue and adds a test case. >> Thanks for taking the time to review. >> >> Best Regards, >> -- Guoxiong >> >> [1] https://bugs.openjdk.java.net/browse/SKARA-1265 >> [2] https://github.com/openjdk/playground/pull/94 > > Marked as reviewed by erikj (Lead). @erikj79 Thanks for the review. ------------- PR: https://git.openjdk.java.net/skara/pull/1307 From erikj at openjdk.java.net Tue Apr 26 18:15:23 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 26 Apr 2022 18:15:23 GMT Subject: RFR: 282: Make the review requirements more explicit in the progress list In-Reply-To: References: Message-ID: On Mon, 25 Apr 2022 23:30:42 GMT, Guoxiong Li wrote: > I tried this way at first when I solved this issue. But then I found the ReviewersCheck doesn?t always return the TooFewReviewersIssue which means the message may miss sometimes. And if we return the message in all the issues of the ReviewersCheck, the message may also miss when the ReviewersCheck passes without any issue. Right, this would only work when the checkbox isn't checked. My biggest issue here is that you are storing mutable state in `CheckablePullRequest`. That class is currently immutable. Here is what I would suggest instead. Still move the logic for generating the reviewers description string to ReviewersConfiguration. Add a field to `PullRequestCheckIssueVisitor` for holding a Jcheck configuration. Set this field from `CheckablePullRequest::executeChecks`. The visitor is already a class that carries a mutable state, so this is kind of ok. Then in `PullRequestCheckIssueVisitor::get*Checks` explicitly modify the description for ReviewersCheck in the returned map. I would recommend a new private method that wraps the `Check::description` call and extracts the reviewer information from the conf field. ------------- PR: https://git.openjdk.java.net/skara/pull/1305 From gli at openjdk.java.net Tue Apr 26 18:18:06 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Tue, 26 Apr 2022 18:18:06 GMT Subject: Integrated: 1411: The JEP link warns that the issue isn't open In-Reply-To: <46uRsioc9mgHo7NiREepgJdGBoDPBqh8QMZ6BXXKY14=.99541344-eefd-461f-b891-4b8e39d2b031@github.com> References: <46uRsioc9mgHo7NiREepgJdGBoDPBqh8QMZ6BXXKY14=.99541344-eefd-461f-b891-4b8e39d2b031@github.com> Message-ID: On Tue, 26 Apr 2022 11:27:38 GMT, Guoxiong Li wrote: > Hi all, > > The JEP link shouldn't warn that JEP issue isn't open. This is similar to the CSR link[1]. An example at playground[2]. > > This patch excludes the JEP issue and adds a test case. > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong > > [1] https://bugs.openjdk.java.net/browse/SKARA-1265 > [2] https://github.com/openjdk/playground/pull/94 This pull request has now been integrated. Changeset: 555b4461 Author: Guoxiong Li Committer: Erik Joelsson URL: https://git.openjdk.java.net/skara/commit/555b4461c739e1b0a61c22b14d6c599d6426571a Stats: 17 lines in 2 files changed: 16 ins; 0 del; 1 mod 1411: The JEP link warns that the issue isn't open Reviewed-by: erikj ------------- PR: https://git.openjdk.java.net/skara/pull/1307 From gli at openjdk.java.net Tue Apr 26 22:37:41 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Tue, 26 Apr 2022 22:37:41 GMT Subject: RFR: 282: Make the review requirements more explicit in the progress list [v2] In-Reply-To: References: Message-ID: > Hi all, > > This patch adds the explicit review requirements, such as ` (2 reviews required, with at least 1 Reviewer).`, to the progress list and adds some test cases. > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: Use the way provided by erik ------------- Changes: - all: https://git.openjdk.java.net/skara/pull/1305/files - new: https://git.openjdk.java.net/skara/pull/1305/files/749d62c2..75d1ea9e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=skara&pr=1305&range=01 - incr: https://webrevs.openjdk.java.net/?repo=skara&pr=1305&range=00-01 Stats: 85 lines in 4 files changed: 41 ins; 41 del; 3 mod Patch: https://git.openjdk.java.net/skara/pull/1305.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1305/head:pull/1305 PR: https://git.openjdk.java.net/skara/pull/1305 From gli at openjdk.java.net Tue Apr 26 22:37:42 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Tue, 26 Apr 2022 22:37:42 GMT Subject: RFR: 282: Make the review requirements more explicit in the progress list In-Reply-To: References: Message-ID: <76p6lBVZ-shM7-Y56RKHpe13dyv9mWcwFC9pXBJVTXI=.d7ff65d6-3517-4e69-a27a-81ea717c6a9d@github.com> On Sun, 24 Apr 2022 15:59:42 GMT, Guoxiong Li wrote: > Hi all, > > This patch adds the explicit review requirements, such as ` (2 reviews required, with at least 1 Reviewer).`, to the progress list and adds some test cases. > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong The new way makes sense. I updated the code just now. ------------- PR: https://git.openjdk.java.net/skara/pull/1305 From gli at openjdk.java.net Wed Apr 27 08:50:44 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Wed, 27 Apr 2022 08:50:44 GMT Subject: RFR: 282: Make the review requirements more explicit in the progress list [v3] In-Reply-To: References: Message-ID: > Hi all, > > This patch adds the explicit review requirements, such as ` (2 reviews required, with at least 1 Reviewer).`, to the progress list and adds some test cases. > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: Add null check ------------- Changes: - all: https://git.openjdk.java.net/skara/pull/1305/files - new: https://git.openjdk.java.net/skara/pull/1305/files/75d1ea9e..074ec271 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=skara&pr=1305&range=02 - incr: https://webrevs.openjdk.java.net/?repo=skara&pr=1305&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/skara/pull/1305.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1305/head:pull/1305 PR: https://git.openjdk.java.net/skara/pull/1305 From lgxbslgx at gmail.com Fri Apr 29 00:52:38 2022 From: lgxbslgx at gmail.com (Guoxiong Li) Date: Fri, 29 Apr 2022 08:52:38 +0800 Subject: [Investigation] Add JEP check to the PR In-Reply-To: References: <20220413090632.745851236@eggemoggin.niobe.net> Message-ID: FYI: the new command `jep` [1] is now available in the JDK project[2]. Please try it, and give feedback if you find a bug or have a suggestion. [1] https://wiki.openjdk.java.net/display/SKARA/Pull+Request+Commands#PullRequestCommands-/jep [2] https://github.com/openjdk/jdk From rwestrel at redhat.com Fri Apr 29 07:55:04 2022 From: rwestrel at redhat.com (Roland Westrelin) Date: Fri, 29 Apr 2022 09:55:04 +0200 Subject: Dependent pull requests: inacurrate bot comment Message-ID: <87fslwb9yf.fsf@redhat.com> I have this dependent pull request: https://github.com/openjdk/jdk11u-dev/pull/1049 I already integrated the PR that it depended on. The bot added this message as a result: https://github.com/openjdk/jdk11u-dev/pull/1049#issuecomment-1112959031 It says: git checkout backport-8280799 which is the branch of the already integrated PR. Shouldn't it be: git checkout backport-8281811 that is the branch of PR#1049 that needs to be updated? Roland. From lgxbslgx at gmail.com Fri Apr 29 08:44:40 2022 From: lgxbslgx at gmail.com (Guoxiong Li) Date: Fri, 29 Apr 2022 16:44:40 +0800 Subject: Dependent pull requests: inacurrate bot comment In-Reply-To: <87fslwb9yf.fsf@redhat.com> References: <87fslwb9yf.fsf@redhat.com> Message-ID: Thanks for reporting the issue. Filed https://bugs.openjdk.java.net/browse/SKARA-1418 to follow up. From erikj at openjdk.java.net Fri Apr 29 13:23:55 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 29 Apr 2022 13:23:55 GMT Subject: RFR: 1118: The Skara PR bot should not block on a CSR if not enabled for a repo In-Reply-To: <_2zDu99u_ja1C3hOKD2UVBRlRvXh5UPq5QdaOgGhKM4=.1c371438-821f-455d-a673-5bc6643dd321@github.com> References: <_2zDu99u_ja1C3hOKD2UVBRlRvXh5UPq5QdaOgGhKM4=.1c371438-821f-455d-a673-5bc6643dd321@github.com> Message-ID: On Tue, 26 Apr 2022 13:20:08 GMT, Guoxiong Li wrote: > Hi all, > > This patch adds a config item `enable-csr` for the PullRequestbot and then the `CSRCommand` firstly checks whether the csr is enabled. If not enabled, the `CSRCommand` will reply a message about it. > > Thanks for taking the time to review. > > Best Regards, > -- Guoxion Are you planning on supplying the same functionality for the /jep command? bots/pr/src/main/java/org/openjdk/skara/bots/pr/PullRequestBotBuilder.java line 53: > 51: private String confOverrideRef = Branch.defaultFor(VCS.GIT).name(); > 52: private String censusLink = null; > 53: private boolean enableCsr = true; Default should be false. bots/pr/src/main/java/org/openjdk/skara/bots/pr/PullRequestBotFactory.java line 161: > 159: botBuilder.censusLink(repo.value().get("censuslink").asString()); > 160: } > 161: if (repo.value().contains("enable-csr")) { I think the option should just be "csr". ------------- PR: https://git.openjdk.java.net/skara/pull/1308 From gli at openjdk.java.net Fri Apr 29 13:36:54 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Fri, 29 Apr 2022 13:36:54 GMT Subject: RFR: 1118: The Skara PR bot should not block on a CSR if not enabled for a repo In-Reply-To: References: <_2zDu99u_ja1C3hOKD2UVBRlRvXh5UPq5QdaOgGhKM4=.1c371438-821f-455d-a673-5bc6643dd321@github.com> Message-ID: On Fri, 29 Apr 2022 13:21:04 GMT, Erik Joelsson wrote: > Are you planning on supplying the same functionality for the /jep command? It seems the `jep` command is not used frequently as `csr`. But if someone or you think it is necessary/good to add it, I am happy to implement it. > bots/pr/src/main/java/org/openjdk/skara/bots/pr/PullRequestBotBuilder.java line 53: > >> 51: private String confOverrideRef = Branch.defaultFor(VCS.GIT).name(); >> 52: private String censusLink = null; >> 53: private boolean enableCsr = true; > > Default should be false. If default is false, we must configurate it as ture in the corresponding projects such as JDK project when deploying. If default is false and we forget to congurate it, the dev flow will be blocked. I am good to change it if you can confirm all the configuration files are changed correctly. ------------- PR: https://git.openjdk.java.net/skara/pull/1308 From erikj at openjdk.java.net Fri Apr 29 13:37:39 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 29 Apr 2022 13:37:39 GMT Subject: RFR: 282: Make the review requirements more explicit in the progress list [v3] In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 08:50:44 GMT, Guoxiong Li wrote: >> Hi all, >> >> This patch adds the explicit review requirements, such as ` (2 reviews required, with at least 1 Reviewer).`, to the progress list and adds some test cases. >> >> Thanks for taking the time to review. >> >> Best Regards, >> -- Guoxiong > > Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: > > Add null check bots/pr/src/test/java/org/openjdk/skara/bots/pr/ReviewersTests.java line 46: > 44: > 45: private static final String reviewProgressTemplate = "Change must be properly reviewed (%d reviews required, with at least %s)"; > 46: private static final String zeroReviewProgress = "Change must be properly reviewed (no reviews required)"; Please use uppercase underscore separated identifiers for constants. Suggestion: private static final String REVIEW_PROGRESS_TEMPLATE = "Change must be properly reviewed (%d reviews required, with at least %s)"; private static final String ZERO_REVIEW_PROGRESS = "Change must be properly reviewed (no reviews required)"; jcheck/src/main/java/org/openjdk/skara/jcheck/ReviewersConfiguration.java line 103: > 101: > 102: public String getReviewRequirements() { > 103: return reviewRequirements; I would probably have put the logic for generating this string right here in the getter. Are we ever calling this more than once? Could also generate it lazily. I realize this gets a lot of testing through the ReviewersTest above, but it would make sense to have cheap and quick tests of just this functionality here in the jcheck package. ------------- PR: https://git.openjdk.java.net/skara/pull/1305 From erikj at openjdk.java.net Fri Apr 29 13:52:15 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 29 Apr 2022 13:52:15 GMT Subject: RFR: 1118: The Skara PR bot should not block on a CSR if not enabled for a repo In-Reply-To: References: <_2zDu99u_ja1C3hOKD2UVBRlRvXh5UPq5QdaOgGhKM4=.1c371438-821f-455d-a673-5bc6643dd321@github.com> Message-ID: <8-euSnWG7TAqXYmNmCu9ujbO2SFcHJKU3xUTcmHlfaQ=.45d30db8-8abd-49cc-86fb-5cbfa0263329@github.com> On Fri, 29 Apr 2022 13:34:42 GMT, Guoxiong Li wrote: > > Are you planning on supplying the same functionality for the /jep command? > > It seems the `jep` command is not used frequently as `csr`. But if someone or you think it is necessary/good to add it, I am happy to implement it. I think it would be useful. >> bots/pr/src/main/java/org/openjdk/skara/bots/pr/PullRequestBotBuilder.java line 53: >> >>> 51: private String confOverrideRef = Branch.defaultFor(VCS.GIT).name(); >>> 52: private String censusLink = null; >>> 53: private boolean enableCsr = true; >> >> Default should be false. > > If default is false, we must configurate it as ture in the corresponding projects such as JDK project when deploying. If default is false and we forget to congurate it, the dev flow will be blocked. I am good to change it if you can confirm all the configuration files are changed correctly. Yes, I will need to update the configuration, that's fine. The set of repositories we have with CSR bot configured is very low compared to the total number of repos. It makes much more sense to have two positive configuration options that need to be in sync. ------------- PR: https://git.openjdk.java.net/skara/pull/1308 From gli at openjdk.java.net Fri Apr 29 15:04:11 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Fri, 29 Apr 2022 15:04:11 GMT Subject: RFR: 282: Make the review requirements more explicit in the progress list [v4] In-Reply-To: References: Message-ID: <9BRiBMdjGFAzGJN-4ZqCAXYuyWQHqln4sZH5J85sGKg=.c146f935-1360-4f9d-adfc-a88393323d71@github.com> > Hi all, > > This patch adds the explicit review requirements, such as ` (2 reviews required, with at least 1 Reviewer).`, to the progress list and adds some test cases. > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: Fix the names of the static variables. Initialize lazily. Add test. ------------- Changes: - all: https://git.openjdk.java.net/skara/pull/1305/files - new: https://git.openjdk.java.net/skara/pull/1305/files/074ec271..535ea83c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=skara&pr=1305&range=03 - incr: https://webrevs.openjdk.java.net/?repo=skara&pr=1305&range=02-03 Stats: 198 lines in 3 files changed: 140 ins; 21 del; 37 mod Patch: https://git.openjdk.java.net/skara/pull/1305.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1305/head:pull/1305 PR: https://git.openjdk.java.net/skara/pull/1305 From gli at openjdk.java.net Fri Apr 29 15:04:13 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Fri, 29 Apr 2022 15:04:13 GMT Subject: RFR: 282: Make the review requirements more explicit in the progress list [v3] In-Reply-To: References: Message-ID: On Fri, 29 Apr 2022 13:26:45 GMT, Erik Joelsson wrote: >> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: >> >> Add null check > > bots/pr/src/test/java/org/openjdk/skara/bots/pr/ReviewersTests.java line 46: > >> 44: >> 45: private static final String reviewProgressTemplate = "Change must be properly reviewed (%d reviews required, with at least %s)"; >> 46: private static final String zeroReviewProgress = "Change must be properly reviewed (no reviews required)"; > > Please use uppercase underscore separated identifiers for constants. > > Suggestion: > > private static final String REVIEW_PROGRESS_TEMPLATE = "Change must be properly reviewed (%d reviews required, with at least %s)"; > private static final String ZERO_REVIEW_PROGRESS = "Change must be properly reviewed (no reviews required)"; Fixed. > I would probably have put the logic for generating this string right here in the getter. Fixed. Please note the field `reviewRequirements` is not `final` now. > I realize this gets a lot of testing through the ReviewersTest above, but it would make sense to have cheap and quick tests of just this functionality here in the jcheck package. Added tests. ------------- PR: https://git.openjdk.java.net/skara/pull/1305 From gli at openjdk.java.net Fri Apr 29 15:16:24 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Fri, 29 Apr 2022 15:16:24 GMT Subject: RFR: 1118: The Skara PR bot should not block on a CSR if not enabled for a repo [v2] In-Reply-To: <_2zDu99u_ja1C3hOKD2UVBRlRvXh5UPq5QdaOgGhKM4=.1c371438-821f-455d-a673-5bc6643dd321@github.com> References: <_2zDu99u_ja1C3hOKD2UVBRlRvXh5UPq5QdaOgGhKM4=.1c371438-821f-455d-a673-5bc6643dd321@github.com> Message-ID: <1jGT8JeccM6eXI3Gjh4CWysG5i-aJ8-tvY9RlBe5ty0=.90c9f8bb-63dd-4c4f-aacb-ab8a5cde197d@github.com> > Hi all, > > This patch adds a config item `enable-csr` for the PullRequestbot and then the `CSRCommand` firstly checks whether the csr is enabled. If not enabled, the `CSRCommand` will reply a message about it. > > Thanks for taking the time to review. > > Best Regards, > -- Guoxion Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: Change config name and default value. ------------- Changes: - all: https://git.openjdk.java.net/skara/pull/1308/files - new: https://git.openjdk.java.net/skara/pull/1308/files/f94daaa0..3e6d8064 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=skara&pr=1308&range=01 - incr: https://webrevs.openjdk.java.net/?repo=skara&pr=1308&range=00-01 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/skara/pull/1308.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1308/head:pull/1308 PR: https://git.openjdk.java.net/skara/pull/1308 From gli at openjdk.java.net Fri Apr 29 15:16:24 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Fri, 29 Apr 2022 15:16:24 GMT Subject: RFR: 1118: The Skara PR bot should not block on a CSR if not enabled for a repo [v2] In-Reply-To: <8-euSnWG7TAqXYmNmCu9ujbO2SFcHJKU3xUTcmHlfaQ=.45d30db8-8abd-49cc-86fb-5cbfa0263329@github.com> References: <_2zDu99u_ja1C3hOKD2UVBRlRvXh5UPq5QdaOgGhKM4=.1c371438-821f-455d-a673-5bc6643dd321@github.com> <8-euSnWG7TAqXYmNmCu9ujbO2SFcHJKU3xUTcmHlfaQ=.45d30db8-8abd-49cc-86fb-5cbfa0263329@github.com> Message-ID: On Fri, 29 Apr 2022 13:47:41 GMT, Erik Joelsson wrote: > I think it would be useful. Filed https://bugs.openjdk.java.net/browse/SKARA-1419 to follow up. >> If default is false, we must configurate it as ture in the corresponding projects such as JDK project when deploying. If default is false and we forget to congurate it, the dev flow will be blocked. I am good to change it if you can confirm all the configuration files are changed correctly. > > Yes, I will need to update the configuration, that's fine. The set of repositories we have with CSR bot configured is very low compared to the total number of repos. It makes much more sense to have two positive configuration options that need to be in sync. Fixed. ------------- PR: https://git.openjdk.java.net/skara/pull/1308 From gli at openjdk.java.net Fri Apr 29 15:16:25 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Fri, 29 Apr 2022 15:16:25 GMT Subject: RFR: 1118: The Skara PR bot should not block on a CSR if not enabled for a repo [v2] In-Reply-To: References: <_2zDu99u_ja1C3hOKD2UVBRlRvXh5UPq5QdaOgGhKM4=.1c371438-821f-455d-a673-5bc6643dd321@github.com> Message-ID: On Fri, 29 Apr 2022 13:19:51 GMT, Erik Joelsson wrote: >> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: >> >> Change config name and default value. > > bots/pr/src/main/java/org/openjdk/skara/bots/pr/PullRequestBotFactory.java line 161: > >> 159: botBuilder.censusLink(repo.value().get("censuslink").asString()); >> 160: } >> 161: if (repo.value().contains("enable-csr")) { > > I think the option should just be "csr". Fixed. ------------- PR: https://git.openjdk.java.net/skara/pull/1308 From gli at openjdk.java.net Fri Apr 29 15:25:03 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Fri, 29 Apr 2022 15:25:03 GMT Subject: RFR: 1418: Dependent pull requests: inacurrate bot comment Message-ID: Hi all, The patch fixes the comment when the dependent pull request was integrated and revises the corresponding test case. Thanks for taking the time to review. Best Regards, -- Guoxiong ------------- Commit messages: - 1418: Dependent pull requests: inacurrate bot comment Changes: https://git.openjdk.java.net/skara/pull/1309/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1309&range=00 Issue: https://bugs.openjdk.java.net/browse/SKARA-1418 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/skara/pull/1309.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1309/head:pull/1309 PR: https://git.openjdk.java.net/skara/pull/1309 From gli at openjdk.java.net Fri Apr 29 15:52:34 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Fri, 29 Apr 2022 15:52:34 GMT Subject: RFR: 1118: The Skara PR bot should not block on a CSR if not enabled for a repo [v3] In-Reply-To: <_2zDu99u_ja1C3hOKD2UVBRlRvXh5UPq5QdaOgGhKM4=.1c371438-821f-455d-a673-5bc6643dd321@github.com> References: <_2zDu99u_ja1C3hOKD2UVBRlRvXh5UPq5QdaOgGhKM4=.1c371438-821f-455d-a673-5bc6643dd321@github.com> Message-ID: > Hi all, > > This patch adds a config item `enable-csr` for the PullRequestbot and then the `CSRCommand` firstly checks whether the csr is enabled. If not enabled, the `CSRCommand` will reply a message about it. > > Thanks for taking the time to review. > > Best Regards, > -- Guoxion Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: Fix tests ------------- Changes: - all: https://git.openjdk.java.net/skara/pull/1308/files - new: https://git.openjdk.java.net/skara/pull/1308/files/3e6d8064..d871f1bd Webrevs: - full: https://webrevs.openjdk.java.net/?repo=skara&pr=1308&range=02 - incr: https://webrevs.openjdk.java.net/?repo=skara&pr=1308&range=01-02 Stats: 12 lines in 2 files changed: 0 ins; 0 del; 12 mod Patch: https://git.openjdk.java.net/skara/pull/1308.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1308/head:pull/1308 PR: https://git.openjdk.java.net/skara/pull/1308 From mark.reinhold at oracle.com Fri Apr 29 17:23:03 2022 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 29 Apr 2022 10:23:03 -0700 Subject: [Investigation] Add JEP check to the PR In-Reply-To: References: <20220413090632.745851236@eggemoggin.niobe.net> Message-ID: <20220429102303.177451611@eggemoggin.niobe.net> 2022/4/28 17:52:38 -0700, lgxbslgx at gmail.com: > FYI: the new command `jep` [1] is now available in the JDK project[2]. > Please try it, and give feedback if you find a bug or have a suggestion. People most commonly refer to JEPs by JEP numbers rather than JBS issue numbers. I?d therefore expect to be able to type `/jep 123` rather than have to remember to type `/jep JEP-123`, especially since the `JEP-123` notation isn?t used in any other context. Can you please remove the need to type the `JEP-` prefix? - Mark From erikj at openjdk.java.net Fri Apr 29 22:21:30 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 29 Apr 2022 22:21:30 GMT Subject: RFR: 282: Make the review requirements more explicit in the progress list [v3] In-Reply-To: References: Message-ID: On Fri, 29 Apr 2022 15:00:33 GMT, Guoxiong Li wrote: >> jcheck/src/main/java/org/openjdk/skara/jcheck/ReviewersConfiguration.java line 103: >> >>> 101: >>> 102: public String getReviewRequirements() { >>> 103: return reviewRequirements; >> >> I would probably have put the logic for generating this string right here in the getter. Are we ever calling this more than once? Could also generate it lazily. >> >> I realize this gets a lot of testing through the ReviewersTest above, but it would make sense to have cheap and quick tests of just this functionality here in the jcheck package. > >> I would probably have put the logic for generating this string right here in the getter. > > Fixed. Please note the field `reviewRequirements` is not `final` now. > >> I realize this gets a lot of testing through the ReviewersTest above, but it would make sense to have cheap and quick tests of just this functionality here in the jcheck package. > > Added tests. That's fine, thanks! I now realize that you put the space and parentheses in the string here. I think this method should just return the requirements and let the visitor add the surrounding formatting. ------------- PR: https://git.openjdk.java.net/skara/pull/1305 From erikj at openjdk.java.net Fri Apr 29 22:22:38 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 29 Apr 2022 22:22:38 GMT Subject: RFR: 1418: Dependent pull requests: inacurrate bot comment In-Reply-To: References: Message-ID: On Fri, 29 Apr 2022 15:21:05 GMT, Guoxiong Li wrote: > Hi all, > > The patch fixes the comment when the dependent pull request was integrated and revises the corresponding test case. > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong Marked as reviewed by erikj (Lead). ------------- PR: https://git.openjdk.java.net/skara/pull/1309 From erikj at openjdk.java.net Fri Apr 29 22:24:00 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 29 Apr 2022 22:24:00 GMT Subject: RFR: 1118: The Skara PR bot should not block on a CSR if not enabled for a repo [v3] In-Reply-To: References: <_2zDu99u_ja1C3hOKD2UVBRlRvXh5UPq5QdaOgGhKM4=.1c371438-821f-455d-a673-5bc6643dd321@github.com> Message-ID: <5uVmD2K4vxzcoF9_Q3BEGvtWy8wXw-WA5y-8c1TVNIw=.8acc2fe3-dd74-4889-b09b-ddf847db26aa@github.com> On Fri, 29 Apr 2022 15:52:34 GMT, Guoxiong Li wrote: >> Hi all, >> >> This patch adds a config item `enable-csr` for the PullRequestbot and then the `CSRCommand` firstly checks whether the csr is enabled. If not enabled, the `CSRCommand` will reply a message about it. >> >> Thanks for taking the time to review. >> >> Best Regards, >> -- Guoxion > > Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: > > Fix tests Marked as reviewed by erikj (Lead). ------------- PR: https://git.openjdk.java.net/skara/pull/1308 From gli at openjdk.java.net Fri Apr 29 22:30:09 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Fri, 29 Apr 2022 22:30:09 GMT Subject: RFR: 1407: GitLabMergeRequest#filesUrl returns wrong result In-Reply-To: References: Message-ID: <1TdPB9ic6kFDg997E_gyU1fjZLltm1WUsirW9BVfDEw=.453d2431-87f0-4e30-9033-4783605247a5@github.com> On Sat, 23 Apr 2022 21:22:34 GMT, Guoxiong Li wrote: > Hi all, > > The SKARA-744 [1][2] solved a problem about the link to the changes for just one commit. But it didn't solve the issue completely in GitLab. Please see the current issue [3] for more information. > > This patch revises `GitLabMergeRequest#filesUrl` to return a `version url` if it exists which can represent the changed files **from the first commit to the provided commit HASH**. A corresponding test is added and a previous test is polished. > > You can use the following config to run the new test `GitLabRestApiTest#testFilesUrl`: > > > gitlab.user= > gitlab.pat= > > gitlab.uri=https://gitlab.com > gitlab.repository=35596381 > gitlab.merge.request.id=1 > > gitlab.version.hash=60f39eb698e73cc2660f870667a54e7a53ee7018 > gitlab.version.url=https://gitlab.com/lgxbslgx/test/-/merge_requests/1/diffs?diff_id=379601911 > gitlab.nonversion.hash=c9b5a70790b13c3e7e182c9b83015f9f10d53df7 > gitlab.nonversion.url=https://gitlab.com/lgxbslgx/test/-/merge_requests/1/diffs?commit_id=c9b5a70790b13c3e7e182c9b83015f9f10d53df7 > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong > > [1] https://bugs.openjdk.java.net/browse/SKARA-744 > [2] https://git.openjdk.java.net/skara/commit/f16663b7 > [3] https://bugs.openjdk.java.net/browse/SKARA-1407 Ping for sponsor. Thanks. ------------- PR: https://git.openjdk.java.net/skara/pull/1304 From gli at openjdk.java.net Fri Apr 29 22:30:21 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Fri, 29 Apr 2022 22:30:21 GMT Subject: RFR: 1395: The "Review applies to " link is misleading In-Reply-To: <3otviio5QVDRGqEX7ott0Pa4CaTK1dml0tf1bNsabHw=.350e2297-3156-42a4-bdfb-bcddab8364c3@github.com> References: <3otviio5QVDRGqEX7ott0Pa4CaTK1dml0tf1bNsabHw=.350e2297-3156-42a4-bdfb-bcddab8364c3@github.com> Message-ID: On Sat, 23 Apr 2022 15:48:52 GMT, Guoxiong Li wrote: > Hi all, > > This trivial patch changes the `commit hash value` to a link which contains the changed files from the first commit of a PR to this `commit`. And the test case is adjusted. > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong Ping for sponsor. Thanks. ------------- PR: https://git.openjdk.java.net/skara/pull/1303 From gli at openjdk.java.net Fri Apr 29 23:38:30 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Fri, 29 Apr 2022 23:38:30 GMT Subject: RFR: 282: Make the review requirements more explicit in the progress list [v5] In-Reply-To: References: Message-ID: > Hi all, > > This patch adds the explicit review requirements, such as ` (2 reviews required, with at least 1 Reviewer).`, to the progress list and adds some test cases. > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: Move space and parentheses. ------------- Changes: - all: https://git.openjdk.java.net/skara/pull/1305/files - new: https://git.openjdk.java.net/skara/pull/1305/files/535ea83c..de3086f1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=skara&pr=1305&range=04 - incr: https://webrevs.openjdk.java.net/?repo=skara&pr=1305&range=03-04 Stats: 5 lines in 3 files changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/skara/pull/1305.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1305/head:pull/1305 PR: https://git.openjdk.java.net/skara/pull/1305 From gli at openjdk.java.net Fri Apr 29 23:38:30 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Fri, 29 Apr 2022 23:38:30 GMT Subject: RFR: 282: Make the review requirements more explicit in the progress list [v3] In-Reply-To: References: Message-ID: <3bKKJeWq1Hz5RzzzpTfv2UfST8_Img7FHW-MvUs35KA=.6d642e43-5446-4627-8403-61a167da8512@github.com> On Fri, 29 Apr 2022 22:18:07 GMT, Erik Joelsson wrote: >>> I would probably have put the logic for generating this string right here in the getter. >> >> Fixed. Please note the field `reviewRequirements` is not `final` now. >> >>> I realize this gets a lot of testing through the ReviewersTest above, but it would make sense to have cheap and quick tests of just this functionality here in the jcheck package. >> >> Added tests. > > That's fine, thanks! > > I now realize that you put the space and parentheses in the string here. I think this method should just return the requirements and let the visitor add the surrounding formatting. Fixed. ------------- PR: https://git.openjdk.java.net/skara/pull/1305 From lgxbslgx at gmail.com Fri Apr 29 23:42:40 2022 From: lgxbslgx at gmail.com (Guoxiong Li) Date: Sat, 30 Apr 2022 07:42:40 +0800 Subject: [Investigation] Add JEP check to the PR In-Reply-To: <20220429102303.177451611@eggemoggin.niobe.net> References: <20220413090632.745851236@eggemoggin.niobe.net> <20220429102303.177451611@eggemoggin.niobe.net> Message-ID: > People most commonly refer to JEPs by JEP numbers rather than JBS issue > numbers. I?d therefore expect to be able to type `/jep 123` rather than > have to remember to type `/jep JEP-123`, especially since the `JEP-123` > notation isn?t used in any other context. > > Can you please remove the need to type the `JEP-` prefix? Thanks for the suggestion. I filed https://bugs.openjdk.java.net/browse/SKARA-1422 to follow up. Best Regards, -- Guoxiong From gli at openjdk.java.net Fri Apr 29 23:47:05 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Fri, 29 Apr 2022 23:47:05 GMT Subject: RFR: 1118: The Skara PR bot should not block on a CSR if not enabled for a repo [v3] In-Reply-To: <8-euSnWG7TAqXYmNmCu9ujbO2SFcHJKU3xUTcmHlfaQ=.45d30db8-8abd-49cc-86fb-5cbfa0263329@github.com> References: <_2zDu99u_ja1C3hOKD2UVBRlRvXh5UPq5QdaOgGhKM4=.1c371438-821f-455d-a673-5bc6643dd321@github.com> <8-euSnWG7TAqXYmNmCu9ujbO2SFcHJKU3xUTcmHlfaQ=.45d30db8-8abd-49cc-86fb-5cbfa0263329@github.com> Message-ID: On Fri, 29 Apr 2022 13:47:41 GMT, Erik Joelsson wrote: >>> Are you planning on supplying the same functionality for the /jep command? >> >> It seems the `jep` command is not used frequently as `csr`. But if someone or you think it is necessary/good to add it, I am happy to implement it. > >> > Are you planning on supplying the same functionality for the /jep command? >> >> It seems the `jep` command is not used frequently as `csr`. But if someone or you think it is necessary/good to add it, I am happy to implement it. > > I think it would be useful. @erikj79 Thanks for the review. Could I get your help to sponsor this patch? ------------- PR: https://git.openjdk.java.net/skara/pull/1308 From gli at openjdk.java.net Fri Apr 29 23:47:23 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Fri, 29 Apr 2022 23:47:23 GMT Subject: RFR: 1418: Dependent pull requests: inacurrate bot comment In-Reply-To: References: Message-ID: On Fri, 29 Apr 2022 22:19:41 GMT, Erik Joelsson wrote: >> Hi all, >> >> The patch fixes the comment when the dependent pull request was integrated and revises the corresponding test case. >> >> Thanks for taking the time to review. >> >> Best Regards, >> -- Guoxiong > > Marked as reviewed by erikj (Lead). @erikj79 Thanks for the review. Could I get your help to sponsor this patch? ------------- PR: https://git.openjdk.java.net/skara/pull/1309