From prappo at openjdk.org Thu Aug 1 10:08:28 2024 From: prappo at openjdk.org (Pavel Rappo) Date: Thu, 1 Aug 2024 10:08:28 GMT Subject: RFR: 2331: Improve review notes [v3] In-Reply-To: <7srn7Q9wlg0jflfturAf8gFX7FmBTfb9pgZjO4-KJ0o=.f0ca47fa-6b47-43e8-9e35-45fe0de06e57@github.com> References: <16pKJai8EtgEqsoyWpyKvqEesej9hRSp7ddUo52pE6k=.bd52aded-4838-4ae6-9589-defd826fd351@github.com> <7srn7Q9wlg0jflfturAf8gFX7FmBTfb9pgZjO4-KJ0o=.f0ca47fa-6b47-43e8-9e35-45fe0de06e57@github.com> Message-ID: On Wed, 24 Jul 2024 15:18:18 GMT, Kevin Rushforth wrote: >> `useStaleReviews` is baked into `reviewCoverage.covers(review)`: >> >> public boolean covers(Review review) { >> return cachedCoverage.computeIfAbsent(review, this::covers0); >> } >> >> private boolean covers0(Review review) { >> var r = review.hash(); >> // Reviews without a hash are never valid as they referred to no longer >> // existing commits. >> if (r.isEmpty() || review.verdict() != Review.Verdict.APPROVED >> || !review.targetRef().equals(pr.targetRef())) { >> return false; >> } >> if (useStaleReviews || r.get().equals(pr.headHash())) { >> return true; >> } >> if (!acceptSimpleMerges) { >> return false; >> } >> >> Here and elsewhere, `tooFewReviewers` is checked because it's decisive: if there are enough reviewers, no emoji or the word "required" should be used. > >> If there are enough reviewers, no emoji or the word "required" should be used. > > I think I now understand what you are trying to do, although I don 't think I agree with the premise. If I understand the logic (which I think I do now), here are two cases that won't do what I would expect: > > 1. `useStaleReviews=false` : if there are too few reviewers, simple merges will show a warning icon > 2. `useStaleReviews=true` : if there are enough reviewers, all other reviews will not get the warning icon > > I think 2 basically makes the warning icon useless (and 1 is a bug) @kevinrushforth ping ------------- PR Review Comment: https://git.openjdk.org/skara/pull/1679#discussion_r1699887003 From kevin.rushforth at oracle.com Thu Aug 1 13:50:34 2024 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 1 Aug 2024 06:50:34 -0700 Subject: Result: New Skara Committer: Pavel Rappo Message-ID: <6d83c82e-e326-43b3-bb98-ac8abd15a152@oracle.com> Voting for Pavel Rappo to Skara Committer [1] is now closed. Yes: 2 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. -- Kevin [1] https://mail.openjdk.org/pipermail/skara-dev/2024-July/009058.html From kcr at openjdk.org Fri Aug 2 19:33:11 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 2 Aug 2024 19:33:11 GMT Subject: RFR: 2331: Improve review notes [v3] In-Reply-To: References: <16pKJai8EtgEqsoyWpyKvqEesej9hRSp7ddUo52pE6k=.bd52aded-4838-4ae6-9589-defd826fd351@github.com> <7srn7Q9wlg0jflfturAf8gFX7FmBTfb9pgZjO4-KJ0o=.f0ca47fa-6b47-43e8-9e35-45fe0de06e57@github.com> Message-ID: On Thu, 1 Aug 2024 10:06:20 GMT, Pavel Rappo wrote: >>> If there are enough reviewers, no emoji or the word "required" should be used. >> >> I think I now understand what you are trying to do, although I don 't think I agree with the premise. If I understand the logic (which I think I do now), here are two cases that won't do what I would expect: >> >> 1. `useStaleReviews=false` : if there are too few reviewers, simple merges will show a warning icon >> 2. `useStaleReviews=true` : if there are enough reviewers, all other reviews will not get the warning icon >> >> I think 2 basically makes the warning icon useless (and 1 is a bug) > > @kevinrushforth ping Sorry for the delay. For the (now largely unused) case of `useStaleReviews=true`, I would expect no change from today's behavior: Regardless of whether or not the review criteria is met, print "?? Review applies to HASH" for all stale reviews. For the (now widely-used) case of `useStaleReviews=false`: If the review criteria is _not_ met, print "? Re-review required (review applies to HASH)" for all stale reviews; if the review criteria _is_ met, print "Review applies to HASH" with no emoji for all stale reviews. ------------- PR Review Comment: https://git.openjdk.org/skara/pull/1679#discussion_r1702246422 From zsong at openjdk.org Mon Aug 5 18:48:25 2024 From: zsong at openjdk.org (Zhao Song) Date: Mon, 5 Aug 2024 18:48:25 GMT Subject: RFR: 2340: CommitCommentsWorkItem executing in GitLab takes a lot of time. Message-ID: Currently, if a user comments under a commit named "Merge" in GitLab, the CommitCommentsWorkItem will take about 8 hours to complete. This delay occurs because the Skara bot checks all commits named "Merge" in the repository. In the previous implementation, the bot fetched all the commit comments for all candidates and then attempted to find the one with the correct ID. With my patch, the bot now fetches the commit comment for only one candidate at a time and looks for the correct ID. ------------- Commit messages: - SKARA-2340 Changes: https://git.openjdk.org/skara/pull/1682/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1682&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-2340 Stats: 9 lines in 1 file changed: 5 ins; 0 del; 4 mod Patch: https://git.openjdk.org/skara/pull/1682.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1682/head:pull/1682 PR: https://git.openjdk.org/skara/pull/1682 From zsong at openjdk.org Mon Aug 5 22:59:48 2024 From: zsong at openjdk.org (Zhao Song) Date: Mon, 5 Aug 2024 22:59:48 GMT Subject: RFR: 2348: Don't apply the logic of avoidForwardports if the issue has been resolved Message-ID: In [SKARA-2226](https://bugs.openjdk.org/browse/SKARA-2226), the issueNotifier was enhanced to avoid creating forward ports. However, there is a bug related with this feature. If the main issue has already been resolved and the fixVersion is targeted to release N-1, the issueNotifier will change the fixVersion to release N and create an open backport issue target to release N-1. The correct behavior should be to leave the main issue unchanged, create a backport target to release N, and resolve it accordingly. ------------- Commit messages: - SKARA-2348 Changes: https://git.openjdk.org/skara/pull/1683/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1683&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-2348 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/skara/pull/1683.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1683/head:pull/1683 PR: https://git.openjdk.org/skara/pull/1683 From kcr at openjdk.org Mon Aug 5 22:59:48 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 5 Aug 2024 22:59:48 GMT Subject: RFR: 2348: Don't apply the logic of avoidForwardports if the issue has been resolved In-Reply-To: References: Message-ID: On Mon, 5 Aug 2024 20:28:54 GMT, Zhao Song wrote: > In [SKARA-2226](https://bugs.openjdk.org/browse/SKARA-2226), the issueNotifier was enhanced to avoid creating forward ports. However, there is a bug related with this feature. If the main issue has already been resolved and the fixVersion is targeted to release N-1, the issueNotifier will change the fixVersion to release N and create an open backport issue target to release N-1. The correct behavior should be to leave the main issue unchanged, create a backport target to release N, and resolve it accordingly. > The correct behavior should be to leave the main issue unchanged, create a backport target to release N-1, and resolve it accordingly. That should be `N` (the main bug is already resolved as fixed in `N-1`). ------------- PR Comment: https://git.openjdk.org/skara/pull/1683#issuecomment-2270028299 From zsong at openjdk.org Mon Aug 5 22:59:56 2024 From: zsong at openjdk.org (Zhao Song) Date: Mon, 5 Aug 2024 22:59:56 GMT Subject: RFR: 2347: SKARA Bot can't find the commit in GitHub if the commit isn't in the default branch Message-ID: <8_GuuFtZpwhZ-EVOdYIouJwc648TQcd1j-OQNzMOkP4=.8d24d9a5-bec1-452d-8adc-38c62b0d4b24@github.com> When searching for a commit in GitHub, the Skara bot utilizes the /search/commits API to look for commits in the whole organization. However, this API has a limitation: it can only find commits in the default branch of each repository. Therefore, If the commit is not found using /search/commits, the bot should try to locate it in each repository. ------------- Commit messages: - SKARA-2347 Changes: https://git.openjdk.org/skara/pull/1684/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1684&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-2347 Stats: 33 lines in 1 file changed: 24 ins; 5 del; 4 mod Patch: https://git.openjdk.org/skara/pull/1684.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1684/head:pull/1684 PR: https://git.openjdk.org/skara/pull/1684 From zsong at openjdk.org Mon Aug 5 22:59:48 2024 From: zsong at openjdk.org (Zhao Song) Date: Mon, 5 Aug 2024 22:59:48 GMT Subject: RFR: 2348: Don't apply the logic of avoidForwardports if the issue has been resolved In-Reply-To: References: Message-ID: On Mon, 5 Aug 2024 22:30:19 GMT, Kevin Rushforth wrote: > > The correct behavior should be to leave the main issue unchanged, create a backport target to release N-1, and resolve it accordingly. > > That should be `N` (the main bug is already resolved as fixed in `N-1`). Ah, right, will fix it. Thanks ------------- PR Comment: https://git.openjdk.org/skara/pull/1683#issuecomment-2270041554 From prappo at openjdk.org Tue Aug 6 13:57:21 2024 From: prappo at openjdk.org (Pavel Rappo) Date: Tue, 6 Aug 2024 13:57:21 GMT Subject: RFR: 2331: Improve review notes [v3] In-Reply-To: References: <16pKJai8EtgEqsoyWpyKvqEesej9hRSp7ddUo52pE6k=.bd52aded-4838-4ae6-9589-defd826fd351@github.com> <7srn7Q9wlg0jflfturAf8gFX7FmBTfb9pgZjO4-KJ0o=.f0ca47fa-6b47-43e8-9e35-45fe0de06e57@github.com> Message-ID: On Fri, 2 Aug 2024 19:31:00 GMT, Kevin Rushforth wrote: >> @kevinrushforth ping > > Sorry for the delay. > > For the (now largely unused) case of `useStaleReviews=true`, I would expect no change from today's behavior: Regardless of whether or not the review criteria is met, print "?? Review applies to HASH" for all stale reviews. > > For the (now widely-used) case of `useStaleReviews=false`: If the review criteria is _not_ met, print "? Re-review required (review applies to HASH)" for all stale reviews; if the review criteria _is_ met, print "Review applies to HASH" with no emoji for all stale reviews. To further clarify, the algorithm you propose applies to the usual case where some commits have been added on top of those reviewed; and not to the more rare cases, where either the reviewed commit is no longer present or the PR has changed its target branch. Is that correct? ------------- PR Review Comment: https://git.openjdk.org/skara/pull/1679#discussion_r1705587719 From erikj at openjdk.org Fri Aug 9 19:46:30 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 9 Aug 2024 19:46:30 GMT Subject: RFR: 2340: CommitCommentsWorkItem executing in GitLab takes a lot of time. In-Reply-To: References: Message-ID: <7_0YfuO240PCg-fMKuZIV9dv8jRWD_YhoHZ3KoVnXM8=.a9589666-e7d5-49ba-8c9d-25ac3b1927c5@github.com> On Mon, 29 Jul 2024 17:44:54 GMT, Zhao Song wrote: > Currently, if a user comments under a commit named "Merge" in GitLab, the CommitCommentsWorkItem will take about 8 hours to complete. This delay occurs because the Skara bot checks all commits named "Merge" in the repository. > > In the previous implementation, the bot fetched all the commit comments for all candidates and then attempted to find the one with the correct ID. With my patch, the bot now fetches the commit comment for only one candidate at a time and looks for the correct ID. forge/src/main/java/org/openjdk/skara/forge/gitlab/GitLabRepository.java line 560: > 558: // eventually clear up on subsequent tries. > 559: Optional found = Optional.empty(); > 560: for (var candidate : candidates) { Are you sure this makes a difference? Streams, or at least flatMap, aren't supposed to be eager, so I was expecting the current implementation to do exactly the same thing. ------------- PR Review Comment: https://git.openjdk.org/skara/pull/1682#discussion_r1712058904 From erikj at openjdk.org Fri Aug 9 19:58:30 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 9 Aug 2024 19:58:30 GMT Subject: RFR: 2348: Don't apply the logic of avoidForwardports if the issue has been resolved In-Reply-To: References: Message-ID: On Mon, 5 Aug 2024 20:28:54 GMT, Zhao Song wrote: > In [SKARA-2226](https://bugs.openjdk.org/browse/SKARA-2226), the issueNotifier was enhanced to avoid creating forward ports. However, there is a bug related with this feature. If the main issue has already been resolved and the fixVersion is targeted to release N-1, the issueNotifier will change the fixVersion to release N and create an open backport issue target to release N-1. The correct behavior should be to leave the main issue unchanged, create a backport target to release N, and resolve it accordingly. Marked as reviewed by erikj (Lead). Could you add a testcase for this? ------------- PR Review: https://git.openjdk.org/skara/pull/1683#pullrequestreview-2230958638 PR Review: https://git.openjdk.org/skara/pull/1683#pullrequestreview-2230960143 From erikj at openjdk.org Fri Aug 9 20:08:40 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 9 Aug 2024 20:08:40 GMT Subject: RFR: 2347: SKARA Bot can't find the commit in GitHub if the commit isn't in the default branch In-Reply-To: <8_GuuFtZpwhZ-EVOdYIouJwc648TQcd1j-OQNzMOkP4=.8d24d9a5-bec1-452d-8adc-38c62b0d4b24@github.com> References: <8_GuuFtZpwhZ-EVOdYIouJwc648TQcd1j-OQNzMOkP4=.8d24d9a5-bec1-452d-8adc-38c62b0d4b24@github.com> Message-ID: <2VbMHpocBFy0ki56MzfL2EsZT117IWcIMy7wafm7SO0=.6d87d0eb-eac1-4072-ae8f-11640339e61a@github.com> On Mon, 5 Aug 2024 21:53:01 GMT, Zhao Song wrote: > When searching for a commit in GitHub, the Skara bot utilizes the /search/commits API to look for commits in the whole organization. However, this API has a limitation: it can only find commits in the default branch of each repository. Therefore, If the commit is not found using /search/commits, the bot should try to locate it in each repository. This is really unfortunate and I don't have a better suggestion for solving it. However, this implementation is risky as it's very expensive when the hash can't be found. We have to iterate through every repo in the org. This means that if the user uses the wrong hash in a "Backport " title, we can end up spending a lot of time processing that. OTOH, this is already what we do for GitLab. ------------- Marked as reviewed by erikj (Lead). PR Review: https://git.openjdk.org/skara/pull/1684#pullrequestreview-2230981423 From erikj at openjdk.org Fri Aug 9 20:26:59 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 9 Aug 2024 20:26:59 GMT Subject: RFR: 2331: Improve review notes [v3] In-Reply-To: References: <16pKJai8EtgEqsoyWpyKvqEesej9hRSp7ddUo52pE6k=.bd52aded-4838-4ae6-9589-defd826fd351@github.com> <7srn7Q9wlg0jflfturAf8gFX7FmBTfb9pgZjO4-KJ0o=.f0ca47fa-6b47-43e8-9e35-45fe0de06e57@github.com> Message-ID: <3i0wPqJAEi0ouFKnKFg-7gmHY3_6EcxGj9z1am8Ze4U=.1a068353-5756-45b1-92eb-dba06a01bc74@github.com> On Tue, 6 Aug 2024 13:55:11 GMT, Pavel Rappo wrote: >> Sorry for the delay. >> >> For the (now largely unused) case of `useStaleReviews=true`, I would expect no change from today's behavior: Regardless of whether or not the review criteria is met, print "?? Review applies to HASH" for all stale reviews. >> >> For the (now widely-used) case of `useStaleReviews=false`: If the review criteria is _not_ met, print "? Re-review required (review applies to HASH)" for all stale reviews; if the review criteria _is_ met, print "Review applies to HASH" with no emoji for all stale reviews. > > To further clarify, the algorithm you propose applies to the usual case where some commits have been added on top of those reviewed; and not to the more rare cases, where either the reviewed commit is no longer present or the PR has changed its target branch. Is that correct? I'm ok with Kevin's proposed behavior, but I'm not sure what the significance of your last question is, Pavel. Are we behaving differently today when the commit has gone missing or the branch has changed? ------------- PR Review Comment: https://git.openjdk.org/skara/pull/1679#discussion_r1712145741 From erikj at openjdk.org Fri Aug 9 20:26:59 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 9 Aug 2024 20:26:59 GMT Subject: RFR: 2331: Improve review notes [v3] In-Reply-To: <3i0wPqJAEi0ouFKnKFg-7gmHY3_6EcxGj9z1am8Ze4U=.1a068353-5756-45b1-92eb-dba06a01bc74@github.com> References: <16pKJai8EtgEqsoyWpyKvqEesej9hRSp7ddUo52pE6k=.bd52aded-4838-4ae6-9589-defd826fd351@github.com> <7srn7Q9wlg0jflfturAf8gFX7FmBTfb9pgZjO4-KJ0o=.f0ca47fa-6b47-43e8-9e35-45fe0de06e57@github.com> <3i0wPqJAEi0ouFKnKFg-7gmHY3_6EcxGj9z1am8Ze4U=.1a068353-5756-45b1-92eb-dba06a01bc74@github.com> Message-ID: On Fri, 9 Aug 2024 20:22:08 GMT, Erik Joelsson wrote: >> To further clarify, the algorithm you propose applies to the usual case where some commits have been added on top of those reviewed; and not to the more rare cases, where either the reviewed commit is no longer present or the PR has changed its target branch. Is that correct? > > I'm ok with Kevin's proposed behavior, but I'm not sure what the significance of your last question is, Pavel. Are we behaving differently today when the commit has gone missing or the branch has changed? Also, when this is all done, could you summarize the complete behavior in the bug description, or comment, similar to how Kevin presented it here? ------------- PR Review Comment: https://git.openjdk.org/skara/pull/1679#discussion_r1712151573 From erikj at openjdk.org Fri Aug 9 20:27:00 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 9 Aug 2024 20:27:00 GMT Subject: RFR: 2331: Improve review notes [v3] In-Reply-To: References: <16pKJai8EtgEqsoyWpyKvqEesej9hRSp7ddUo52pE6k=.bd52aded-4838-4ae6-9589-defd826fd351@github.com> <374hyoT1yMovFTAlSDJoOzSIFDXUxCue_NWrBdwaTGY=.5fe67047-14e9-4b94-ad23-3d595067254d@github.com> Message-ID: On Thu, 18 Jul 2024 20:21:41 GMT, Pavel Rappo wrote: >> It's just a suggestion, since you don't like it and I am ok with your pr, I will approve it now. > > Usually, making a minimally necessary change is good, and parsing end-user text is bad. In fact, I'd go to great lengths to avoid "stringly typed" code that operates on strings that are also subject to change. > > Here, I initially thought I might be violating some encapsulation boundary by bringing a dependency. Maybe I still am. If nothing else, it's not the first class imported from that package: > > import org.openjdk.skara.jcheck.JCheckConfiguration; > +import org.openjdk.skara.jcheck.TooFewReviewersIssue; I think it's ok to return the list of jcheck issues, but the variable name `issues` can be confusing as an `Issue` in the bots is usually some form of Jira Issue. I would recommend `jcheckIssues` to avoid confusion. ------------- PR Review Comment: https://git.openjdk.org/skara/pull/1679#discussion_r1712142501 From zsong at openjdk.org Fri Aug 9 22:08:01 2024 From: zsong at openjdk.org (Zhao Song) Date: Fri, 9 Aug 2024 22:08:01 GMT Subject: RFR: 2340: CommitCommentsWorkItem executing in GitLab takes a lot of time. In-Reply-To: <7_0YfuO240PCg-fMKuZIV9dv8jRWD_YhoHZ3KoVnXM8=.a9589666-e7d5-49ba-8c9d-25ac3b1927c5@github.com> References: <7_0YfuO240PCg-fMKuZIV9dv8jRWD_YhoHZ3KoVnXM8=.a9589666-e7d5-49ba-8c9d-25ac3b1927c5@github.com> Message-ID: On Fri, 9 Aug 2024 19:43:46 GMT, Erik Joelsson wrote: >> Currently, if a user comments under a commit named "Merge" in GitLab, the CommitCommentsWorkItem will take about 8 hours to complete. This delay occurs because the Skara bot checks all commits named "Merge" in the repository. >> >> In the previous implementation, the bot fetched all the commit comments for all candidates and then attempted to find the one with the correct ID. With my patch, the bot now fetches the commit comment for only one candidate at a time and looks for the correct ID. > > forge/src/main/java/org/openjdk/skara/forge/gitlab/GitLabRepository.java line 560: > >> 558: // eventually clear up on subsequent tries. >> 559: Optional found = Optional.empty(); >> 560: for (var candidate : candidates) { > > Are you sure this makes a difference? Streams, or at least flatMap, aren't supposed to be eager, so I was expecting the current implementation to do exactly the same thing. I am not sure what do you mean by eager. I think in the original implementation, it will retrieve all the commit comments before filtering, so with so many candidates, it's inefficient. ------------- PR Review Comment: https://git.openjdk.org/skara/pull/1682#discussion_r1712265094 From zsong at openjdk.org Fri Aug 9 22:09:24 2024 From: zsong at openjdk.org (Zhao Song) Date: Fri, 9 Aug 2024 22:09:24 GMT Subject: RFR: 2348: Don't apply the logic of avoidForwardports if the issue has been resolved In-Reply-To: References: Message-ID: On Fri, 9 Aug 2024 19:56:24 GMT, Erik Joelsson wrote: > Could you add a testcase for this? Sure ------------- PR Comment: https://git.openjdk.org/skara/pull/1683#issuecomment-2278812615 From zsong at openjdk.org Fri Aug 9 22:24:44 2024 From: zsong at openjdk.org (Zhao Song) Date: Fri, 9 Aug 2024 22:24:44 GMT Subject: RFR: 2340: CommitCommentsWorkItem executing in GitLab takes a lot of time In-Reply-To: References: <7_0YfuO240PCg-fMKuZIV9dv8jRWD_YhoHZ3KoVnXM8=.a9589666-e7d5-49ba-8c9d-25ac3b1927c5@github.com> Message-ID: On Fri, 9 Aug 2024 22:05:37 GMT, Zhao Song wrote: >> forge/src/main/java/org/openjdk/skara/forge/gitlab/GitLabRepository.java line 560: >> >>> 558: // eventually clear up on subsequent tries. >>> 559: Optional found = Optional.empty(); >>> 560: for (var candidate : candidates) { >> >> Are you sure this makes a difference? Streams, or at least flatMap, aren't supposed to be eager, so I was expecting the current implementation to do exactly the same thing. > > I am not sure what do you mean by eager. I think in the original implementation, it will retrieve all the commit comments before filtering, so with so many candidates, it's inefficient. Ah, I did some tests, you are right, need to think more about it ------------- PR Review Comment: https://git.openjdk.org/skara/pull/1682#discussion_r1712285914 From prappo at openjdk.org Mon Aug 12 10:19:21 2024 From: prappo at openjdk.org (Pavel Rappo) Date: Mon, 12 Aug 2024 10:19:21 GMT Subject: RFR: 2331: Improve review notes [v3] In-Reply-To: References: <16pKJai8EtgEqsoyWpyKvqEesej9hRSp7ddUo52pE6k=.bd52aded-4838-4ae6-9589-defd826fd351@github.com> <7srn7Q9wlg0jflfturAf8gFX7FmBTfb9pgZjO4-KJ0o=.f0ca47fa-6b47-43e8-9e35-45fe0de06e57@github.com> <3i0wPqJAEi0ouFKnKFg-7gmHY3_6EcxGj9z1am8Ze4U=.1a068353-5756-45b1-92eb-dba06a01bc74@github.com> Message-ID: <44lrFFb_zvAYv0sOLP_EgOABHWND9yxYCjq1RVhRFuk=.dce9a653-4c73-4137-9e3c-c196b736307b@github.com> On Fri, 9 Aug 2024 20:24:38 GMT, Erik Joelsson wrote: >> I'm ok with Kevin's proposed behavior, but I'm not sure what the significance of your last question is, Pavel. Are we behaving differently today when the commit has gone missing or the branch has changed? > > Also, when this is all done, could you summarize the complete behavior in the bug description, or comment, similar to how Kevin presented it here? > I'm not sure what the significance of your last question is, Pavel. Are we behaving differently today when the commit has gone missing or the branch has changed? In either of those two cases, in master, we display the "?" emoji and the word "required" regardless of whether the PR has been sufficiently reviewed: https://github.com/openjdk/skara/blob/45468cde2dc5273c70f728c46c6b133e3d16b55a/bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckRun.java#L602-L622 If we are trying to generally improve review notes, we perhaps should treat those two cases similarly to our main/typical case? ------------- PR Review Comment: https://git.openjdk.org/skara/pull/1679#discussion_r1713486971 From erikj at openjdk.org Mon Aug 12 13:51:09 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 12 Aug 2024 13:51:09 GMT Subject: RFR: 2331: Improve review notes [v3] In-Reply-To: <44lrFFb_zvAYv0sOLP_EgOABHWND9yxYCjq1RVhRFuk=.dce9a653-4c73-4137-9e3c-c196b736307b@github.com> References: <16pKJai8EtgEqsoyWpyKvqEesej9hRSp7ddUo52pE6k=.bd52aded-4838-4ae6-9589-defd826fd351@github.com> <7srn7Q9wlg0jflfturAf8gFX7FmBTfb9pgZjO4-KJ0o=.f0ca47fa-6b47-43e8-9e35-45fe0de06e57@github.com> <3i0wPqJAEi0ouFKnKFg-7gmHY3_6EcxGj9z1am8Ze4U=.1a068353-5756-45b1-92eb-dba06a01bc74@github.com> <44lrFFb_zvAYv0sOLP_EgOABHWND9yxYCjq 1RVhRFuk=.dce9a653-4c73-4137-9e3c-c196b736307b@github.com> Message-ID: On Mon, 12 Aug 2024 10:16:42 GMT, Pavel Rappo wrote: >> Also, when this is all done, could you summarize the complete behavior in the bug description, or comment, similar to how Kevin presented it here? > >> I'm not sure what the significance of your last question is, Pavel. Are we behaving differently today when the commit has gone missing or the branch has changed? > > In either of those two cases, in master, we display the "?" emoji and the word "required" regardless of whether the PR has been sufficiently reviewed: > > https://github.com/openjdk/skara/blob/45468cde2dc5273c70f728c46c6b133e3d16b55a/bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckRun.java#L602-L622 > > If we are trying to generally improve review notes, we perhaps should treat those two cases similarly to our main/typical case? I agree, those cases should be folded into the new behavior with regards to emojis. ------------- PR Review Comment: https://git.openjdk.org/skara/pull/1679#discussion_r1713819114 From zsong at openjdk.org Mon Aug 12 16:01:40 2024 From: zsong at openjdk.org (Zhao Song) Date: Mon, 12 Aug 2024 16:01:40 GMT Subject: Integrated: 2347: SKARA Bot can't find the commit in GitHub if the commit isn't in the default branch In-Reply-To: <8_GuuFtZpwhZ-EVOdYIouJwc648TQcd1j-OQNzMOkP4=.8d24d9a5-bec1-452d-8adc-38c62b0d4b24@github.com> References: <8_GuuFtZpwhZ-EVOdYIouJwc648TQcd1j-OQNzMOkP4=.8d24d9a5-bec1-452d-8adc-38c62b0d4b24@github.com> Message-ID: <7iNW1sLWP4B35htJct1JyfnREXSOGCqPquYoPX7WLTI=.70090ae4-169c-4357-ada8-37575b3bb9f6@github.com> On Mon, 5 Aug 2024 21:53:01 GMT, Zhao Song wrote: > When searching for a commit in GitHub, the Skara bot utilizes the /search/commits API to look for commits in the whole organization. However, this API has a limitation: it can only find commits in the default branch of each repository. Therefore, If the commit is not found using /search/commits, the bot should try to locate it in each repository. This pull request has now been integrated. Changeset: b991927e Author: Zhao Song URL: https://git.openjdk.org/skara/commit/b991927e9ab031921b9b14787c9282815b0e10a4 Stats: 33 lines in 1 file changed: 24 ins; 5 del; 4 mod 2347: SKARA Bot can't find the commit in GitHub if the commit isn't in the default branch Reviewed-by: erikj ------------- PR: https://git.openjdk.org/skara/pull/1684 From zsong at openjdk.org Mon Aug 12 16:01:40 2024 From: zsong at openjdk.org (Zhao Song) Date: Mon, 12 Aug 2024 16:01:40 GMT Subject: RFR: 2347: SKARA Bot can't find the commit in GitHub if the commit isn't in the default branch In-Reply-To: <8_GuuFtZpwhZ-EVOdYIouJwc648TQcd1j-OQNzMOkP4=.8d24d9a5-bec1-452d-8adc-38c62b0d4b24@github.com> References: <8_GuuFtZpwhZ-EVOdYIouJwc648TQcd1j-OQNzMOkP4=.8d24d9a5-bec1-452d-8adc-38c62b0d4b24@github.com> Message-ID: On Mon, 5 Aug 2024 21:53:01 GMT, Zhao Song wrote: > When searching for a commit in GitHub, the Skara bot utilizes the /search/commits API to look for commits in the whole organization. However, this API has a limitation: it can only find commits in the default branch of each repository. Therefore, If the commit is not found using /search/commits, the bot should try to locate it in each repository. Thanks for the review! ------------- PR Comment: https://git.openjdk.org/skara/pull/1684#issuecomment-2284356533 From zsong at openjdk.org Mon Aug 12 17:03:52 2024 From: zsong at openjdk.org (Zhao Song) Date: Mon, 12 Aug 2024 17:03:52 GMT Subject: RFR: 2348: Don't apply the logic of avoidForwardports if the issue has been resolved [v2] In-Reply-To: References: Message-ID: > In [SKARA-2226](https://bugs.openjdk.org/browse/SKARA-2226), the issueNotifier was enhanced to avoid creating forward ports. However, there is a bug related with this feature. If the main issue has already been resolved and the fixVersion is targeted to release N-1, the issueNotifier will change the fixVersion to release N and create an open backport issue target to release N-1. The correct behavior should be to leave the main issue unchanged, create a backport target to release N, and resolve it accordingly. Zhao Song has updated the pull request incrementally with one additional commit since the last revision: add a test ------------- Changes: - all: https://git.openjdk.org/skara/pull/1683/files - new: https://git.openjdk.org/skara/pull/1683/files/15706634..e478dac4 Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1683&range=01 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1683&range=00-01 Stats: 63 lines in 1 file changed: 63 ins; 0 del; 0 mod Patch: https://git.openjdk.org/skara/pull/1683.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1683/head:pull/1683 PR: https://git.openjdk.org/skara/pull/1683 From erikj at openjdk.org Mon Aug 12 17:40:18 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 12 Aug 2024 17:40:18 GMT Subject: RFR: 2348: Don't apply the logic of avoidForwardports if the issue has been resolved [v2] In-Reply-To: References: Message-ID: On Mon, 12 Aug 2024 17:03:52 GMT, Zhao Song wrote: >> In [SKARA-2226](https://bugs.openjdk.org/browse/SKARA-2226), the issueNotifier was enhanced to avoid creating forward ports. However, there is a bug related with this feature. If the main issue has already been resolved and the fixVersion is targeted to release N-1, the issueNotifier will change the fixVersion to release N and create an open backport issue target to release N-1. The correct behavior should be to leave the main issue unchanged, create a backport target to release N, and resolve it accordingly. > > Zhao Song has updated the pull request incrementally with one additional commit since the last revision: > > add a test Marked as reviewed by erikj (Lead). ------------- PR Review: https://git.openjdk.org/skara/pull/1683#pullrequestreview-2233667220 From zsong at openjdk.org Mon Aug 12 17:40:18 2024 From: zsong at openjdk.org (Zhao Song) Date: Mon, 12 Aug 2024 17:40:18 GMT Subject: RFR: 2348: Don't apply the logic of avoidForwardports if the issue has been resolved [v2] In-Reply-To: References: Message-ID: On Mon, 12 Aug 2024 17:03:52 GMT, Zhao Song wrote: >> In [SKARA-2226](https://bugs.openjdk.org/browse/SKARA-2226), the issueNotifier was enhanced to avoid creating forward ports. However, there is a bug related with this feature. If the main issue has already been resolved and the fixVersion is targeted to release N-1, the issueNotifier will change the fixVersion to release N and create an open backport issue target to release N-1. The correct behavior should be to leave the main issue unchanged, create a backport target to release N, and resolve it accordingly. > > Zhao Song has updated the pull request incrementally with one additional commit since the last revision: > > add a test Thanks for the review! ------------- PR Comment: https://git.openjdk.org/skara/pull/1683#issuecomment-2284575381 From zsong at openjdk.org Mon Aug 12 17:40:18 2024 From: zsong at openjdk.org (Zhao Song) Date: Mon, 12 Aug 2024 17:40:18 GMT Subject: Integrated: 2348: Don't apply the logic of avoidForwardports if the issue has been resolved In-Reply-To: References: Message-ID: On Mon, 5 Aug 2024 20:28:54 GMT, Zhao Song wrote: > In [SKARA-2226](https://bugs.openjdk.org/browse/SKARA-2226), the issueNotifier was enhanced to avoid creating forward ports. However, there is a bug related with this feature. If the main issue has already been resolved and the fixVersion is targeted to release N-1, the issueNotifier will change the fixVersion to release N and create an open backport issue target to release N-1. The correct behavior should be to leave the main issue unchanged, create a backport target to release N, and resolve it accordingly. This pull request has now been integrated. Changeset: 42229163 Author: Zhao Song URL: https://git.openjdk.org/skara/commit/4222916317b49e4f1525682cb71df83593bfc1d5 Stats: 65 lines in 2 files changed: 63 ins; 0 del; 2 mod 2348: Don't apply the logic of avoidForwardports if the issue has been resolved Reviewed-by: erikj ------------- PR: https://git.openjdk.org/skara/pull/1683 From zsong at openjdk.org Mon Aug 12 20:06:58 2024 From: zsong at openjdk.org (Zhao Song) Date: Mon, 12 Aug 2024 20:06:58 GMT Subject: RFR: 2340: CommitCommentsWorkItem executing in GitLab takes a lot of time [v2] In-Reply-To: References: Message-ID: > Currently, if a user comments under a commit named "Merge" in GitLab, the CommitCommentsWorkItem will take about 8 hours to complete. > After investigation, I think there is a bug in GitLabRepository#getCommitTitleToCommitsMap > > For GitLab repos, we need to build a hash map for mapping commit title to commits. The implementation of the map is Map>. We use LinkedHashSet here because we want the bot to check latest commits first. > > If the map has already been built, then the bot will query new commits in the repo and adds the commits into the map. However, when adding the new commit hash to the map, the bot add it to the end of the LinkedHashSet. So new commits will be checked very late. > > For commit titles like "Merge", sometimes, there can be around 50K commits in a repo. If the latest "Merge" commit is added to the tail of the LinkedHashSet, the bot must check all previous commits first, which takes a lot of time. Zhao Song has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: SKARA-2340 ------------- Changes: - all: https://git.openjdk.org/skara/pull/1682/files - new: https://git.openjdk.org/skara/pull/1682/files/9fda8d66..5eee460f Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1682&range=01 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1682&range=00-01 Stats: 25 lines in 1 file changed: 15 ins; 5 del; 5 mod Patch: https://git.openjdk.org/skara/pull/1682.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1682/head:pull/1682 PR: https://git.openjdk.org/skara/pull/1682 From zsong at openjdk.org Mon Aug 12 20:06:58 2024 From: zsong at openjdk.org (Zhao Song) Date: Mon, 12 Aug 2024 20:06:58 GMT Subject: RFR: 2340: CommitCommentsWorkItem executing in GitLab takes a lot of time In-Reply-To: References: Message-ID: On Mon, 29 Jul 2024 17:44:54 GMT, Zhao Song wrote: > Currently, if a user comments under a commit named "Merge" in GitLab, the CommitCommentsWorkItem will take about 8 hours to complete. > After investigation, I think there is a bug in GitLabRepository#getCommitTitleToCommitsMap > > For GitLab repos, we need to build a hash map for mapping commit title to commits. The implementation of the map is Map>. We use LinkedHashSet here because we want the bot to check latest commits first. > > If the map has already been built, then the bot will query new commits in the repo and adds the commits into the map. However, when adding the new commit hash to the map, the bot add it to the end of the LinkedHashSet. So new commits will be checked very late. > > For commit titles like "Merge", sometimes, there can be around 50K commits in a repo. If the latest "Merge" commit is added to the tail of the LinkedHashSet, the bot must check all previous commits first, which takes a lot of time. I have updated the PR body and pushed a new commit ------------- PR Comment: https://git.openjdk.org/skara/pull/1682#issuecomment-2284812915 From erikj at openjdk.org Mon Aug 12 22:12:29 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 12 Aug 2024 22:12:29 GMT Subject: RFR: 2340: CommitCommentsWorkItem executing in GitLab takes a lot of time [v2] In-Reply-To: References: Message-ID: On Mon, 12 Aug 2024 20:06:58 GMT, Zhao Song wrote: >> Currently, if a user comments under a commit named "Merge" in GitLab, the CommitCommentsWorkItem will take about 8 hours to complete. >> After investigation, I think there is a bug in GitLabRepository#getCommitTitleToCommitsMap >> >> For GitLab repos, we need to build a hash map for mapping commit title to commits. The implementation of the map is Map>. We use LinkedHashSet here because we want the bot to check latest commits first. >> >> If the map has already been built, then the bot will query new commits in the repo and adds the commits into the map. However, when adding the new commit hash to the map, the bot add it to the end of the LinkedHashSet. So new commits will be checked very late. >> >> For commit titles like "Merge", sometimes, there can be around 50K commits in a repo. If the latest "Merge" commit is added to the tail of the LinkedHashSet, the bot must check all previous commits first, which takes a lot of time. > > Zhao Song has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: > > SKARA-2340 forge/src/main/java/org/openjdk/skara/forge/gitlab/GitLabRepository.java line 645: > 643: var hash = new Hash(commit.get("id").asString()); > 644: var title = commit.get("title").asString(); > 645: tempCommitTitleToCommits.computeIfAbsent(title, t -> new LinkedHashSet<>()).add(hash); I read the bug description and I think I understand the problem now. The initial creation of the map iterates commits from newest to oldest, while this loop iterates from oldest to newest. Instead of creating a temporary map, couldn't we just call `LinkedHashSet::addFirst` to get the new commits added at the front in the correct order? ------------- PR Review Comment: https://git.openjdk.org/skara/pull/1682#discussion_r1714418346 From zsong at openjdk.org Mon Aug 12 22:44:11 2024 From: zsong at openjdk.org (Zhao Song) Date: Mon, 12 Aug 2024 22:44:11 GMT Subject: RFR: 2340: CommitCommentsWorkItem executing in GitLab takes a lot of time [v2] In-Reply-To: References: Message-ID: <4wb0itxNQ-6PvHJSS8jArCPSqzYuIDA_tdSPdbMBvOY=.38e94cc9-be77-4f66-9d7b-ab8b10b62515@github.com> On Mon, 12 Aug 2024 22:08:39 GMT, Erik Joelsson wrote: >> Zhao Song has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: >> >> SKARA-2340 > > forge/src/main/java/org/openjdk/skara/forge/gitlab/GitLabRepository.java line 645: > >> 643: var hash = new Hash(commit.get("id").asString()); >> 644: var title = commit.get("title").asString(); >> 645: tempCommitTitleToCommits.computeIfAbsent(title, t -> new LinkedHashSet<>()).add(hash); > > I read the bug description and I think I understand the problem now. The initial creation of the map iterates commits from newest to oldest, while this loop iterates from oldest to newest. > > Instead of creating a temporary map, couldn't we just call `LinkedHashSet::addFirst` to get the new commits added at the front in the correct order? Yes, it's better to use `LinkedHashSet::addFirst` ------------- PR Review Comment: https://git.openjdk.org/skara/pull/1682#discussion_r1714441173 From zsong at openjdk.org Mon Aug 12 22:58:55 2024 From: zsong at openjdk.org (Zhao Song) Date: Mon, 12 Aug 2024 22:58:55 GMT Subject: RFR: 2340: CommitCommentsWorkItem executing in GitLab takes a lot of time [v3] In-Reply-To: References: Message-ID: > Currently, if a user comments under a commit named "Merge" in GitLab, the CommitCommentsWorkItem will take about 8 hours to complete. > After investigation, I think there is a bug in GitLabRepository#getCommitTitleToCommitsMap > > For GitLab repos, we need to build a hash map for mapping commit title to commits. The implementation of the map is Map>. We use LinkedHashSet here because we want the bot to check latest commits first. > > If the map has already been built, then the bot will query new commits in the repo and adds the commits into the map. However, when adding the new commit hash to the map, the bot add it to the end of the LinkedHashSet. So new commits will be checked very late. > > For commit titles like "Merge", sometimes, there can be around 50K commits in a repo. If the latest "Merge" commit is added to the tail of the LinkedHashSet, the bot must check all previous commits first, which takes a lot of time. Zhao Song has updated the pull request incrementally with one additional commit since the last revision: update ------------- Changes: - all: https://git.openjdk.org/skara/pull/1682/files - new: https://git.openjdk.org/skara/pull/1682/files/5eee460f..44be25cd Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1682&range=02 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1682&range=01-02 Stats: 16 lines in 1 file changed: 1 ins; 11 del; 4 mod Patch: https://git.openjdk.org/skara/pull/1682.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1682/head:pull/1682 PR: https://git.openjdk.org/skara/pull/1682 From erikj at openjdk.org Tue Aug 13 12:42:32 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 13 Aug 2024 12:42:32 GMT Subject: RFR: 2340: CommitCommentsWorkItem executing in GitLab takes a lot of time [v3] In-Reply-To: References: Message-ID: On Mon, 12 Aug 2024 22:58:55 GMT, Zhao Song wrote: >> Currently, if a user comments under a commit named "Merge" in GitLab, the CommitCommentsWorkItem will take about 8 hours to complete. >> After investigation, I think there is a bug in GitLabRepository#getCommitTitleToCommitsMap >> >> For GitLab repos, we need to build a hash map for mapping commit title to commits. The implementation of the map is Map>. We use LinkedHashSet here because we want the bot to check latest commits first. >> >> If the map has already been built, then the bot will query new commits in the repo and adds the commits into the map. However, when adding the new commit hash to the map, the bot add it to the end of the LinkedHashSet. So new commits will be checked very late. >> >> For commit titles like "Merge", sometimes, there can be around 50K commits in a repo. If the latest "Merge" commit is added to the tail of the LinkedHashSet, the bot must check all previous commits first, which takes a lot of time. > > Zhao Song has updated the pull request incrementally with one additional commit since the last revision: > > update forge/src/main/java/org/openjdk/skara/forge/gitlab/GitLabRepository.java line 646: > 644: var hash = new Hash(commit.get("id").asString()); > 645: var title = commit.get("title").asString(); > 646: ((LinkedHashSet) commitTitleToCommits.computeIfAbsent(title, t -> new LinkedHashSet<>())).addFirst(hash); Instead of casting to LinkedHashSet, we can use the type directly in the type declaration for `commitTitleToCommits`. We can even use the new shiny `SequencedSet` interface to avoid specifying the concrete class. ------------- PR Review Comment: https://git.openjdk.org/skara/pull/1682#discussion_r1715219258 From zsong at openjdk.org Tue Aug 13 16:25:42 2024 From: zsong at openjdk.org (Zhao Song) Date: Tue, 13 Aug 2024 16:25:42 GMT Subject: RFR: 2340: CommitCommentsWorkItem executing in GitLab takes a lot of time [v3] In-Reply-To: References: Message-ID: On Tue, 13 Aug 2024 12:35:39 GMT, Erik Joelsson wrote: >> Zhao Song has updated the pull request incrementally with one additional commit since the last revision: >> >> update > > forge/src/main/java/org/openjdk/skara/forge/gitlab/GitLabRepository.java line 646: > >> 644: var hash = new Hash(commit.get("id").asString()); >> 645: var title = commit.get("title").asString(); >> 646: ((LinkedHashSet) commitTitleToCommits.computeIfAbsent(title, t -> new LinkedHashSet<>())).addFirst(hash); > > Instead of casting to LinkedHashSet, we can use the type directly in the type declaration for `commitTitleToCommits`. We can even use the new shiny `SequencedSet` interface to avoid specifying the concrete class. Sure ------------- PR Review Comment: https://git.openjdk.org/skara/pull/1682#discussion_r1715581244 From zsong at openjdk.org Tue Aug 13 16:25:42 2024 From: zsong at openjdk.org (Zhao Song) Date: Tue, 13 Aug 2024 16:25:42 GMT Subject: RFR: 2340: CommitCommentsWorkItem executing in GitLab takes a lot of time [v4] In-Reply-To: References: Message-ID: <6li32enDi8cEhRHC1Xuq8TWkQ0ITbwfMx_znbtlAnLI=.0c073be2-ea8c-45b8-a199-6984053261e5@github.com> > Currently, if a user comments under a commit named "Merge" in GitLab, the CommitCommentsWorkItem will take about 8 hours to complete. > After investigation, I think there is a bug in GitLabRepository#getCommitTitleToCommitsMap > > For GitLab repos, we need to build a hash map for mapping commit title to commits. The implementation of the map is Map>. We use LinkedHashSet here because we want the bot to check latest commits first. > > If the map has already been built, then the bot will query new commits in the repo and adds the commits into the map. However, when adding the new commit hash to the map, the bot add it to the end of the LinkedHashSet. So new commits will be checked very late. > > For commit titles like "Merge", sometimes, there can be around 50K commits in a repo. If the latest "Merge" commit is added to the tail of the LinkedHashSet, the bot must check all previous commits first, which takes a lot of time. Zhao Song has updated the pull request incrementally with one additional commit since the last revision: Use SequencedSet ------------- Changes: - all: https://git.openjdk.org/skara/pull/1682/files - new: https://git.openjdk.org/skara/pull/1682/files/44be25cd..db3c7597 Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1682&range=03 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1682&range=02-03 Stats: 6 lines in 1 file changed: 1 ins; 0 del; 5 mod Patch: https://git.openjdk.org/skara/pull/1682.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1682/head:pull/1682 PR: https://git.openjdk.org/skara/pull/1682 From erikj at openjdk.org Tue Aug 13 16:33:58 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 13 Aug 2024 16:33:58 GMT Subject: RFR: 2340: CommitCommentsWorkItem executing in GitLab takes a lot of time [v4] In-Reply-To: <6li32enDi8cEhRHC1Xuq8TWkQ0ITbwfMx_znbtlAnLI=.0c073be2-ea8c-45b8-a199-6984053261e5@github.com> References: <6li32enDi8cEhRHC1Xuq8TWkQ0ITbwfMx_znbtlAnLI=.0c073be2-ea8c-45b8-a199-6984053261e5@github.com> Message-ID: <4_V6wo9R2MDzjLYdOSGt4bagN4aXP1i29FJcqh3gpOc=.fb6bb623-3ee2-400c-8886-1e05ff72431a@github.com> On Tue, 13 Aug 2024 16:25:42 GMT, Zhao Song wrote: >> Currently, if a user comments under a commit named "Merge" in GitLab, the CommitCommentsWorkItem will take about 8 hours to complete. >> After investigation, I think there is a bug in GitLabRepository#getCommitTitleToCommitsMap >> >> For GitLab repos, we need to build a hash map for mapping commit title to commits. The implementation of the map is Map>. We use LinkedHashSet here because we want the bot to check latest commits first. >> >> If the map has already been built, then the bot will query new commits in the repo and adds the commits into the map. However, when adding the new commit hash to the map, the bot add it to the end of the LinkedHashSet. So new commits will be checked very late. >> >> For commit titles like "Merge", sometimes, there can be around 50K commits in a repo. If the latest "Merge" commit is added to the tail of the LinkedHashSet, the bot must check all previous commits first, which takes a lot of time. > > Zhao Song has updated the pull request incrementally with one additional commit since the last revision: > > Use SequencedSet Marked as reviewed by erikj (Lead). ------------- PR Review: https://git.openjdk.org/skara/pull/1682#pullrequestreview-2236046294 From zsong at openjdk.org Tue Aug 13 17:01:52 2024 From: zsong at openjdk.org (Zhao Song) Date: Tue, 13 Aug 2024 17:01:52 GMT Subject: RFR: 2340: CommitCommentsWorkItem executing in GitLab takes a lot of time [v4] In-Reply-To: <6li32enDi8cEhRHC1Xuq8TWkQ0ITbwfMx_znbtlAnLI=.0c073be2-ea8c-45b8-a199-6984053261e5@github.com> References: <6li32enDi8cEhRHC1Xuq8TWkQ0ITbwfMx_znbtlAnLI=.0c073be2-ea8c-45b8-a199-6984053261e5@github.com> Message-ID: On Tue, 13 Aug 2024 16:25:42 GMT, Zhao Song wrote: >> Currently, if a user comments under a commit named "Merge" in GitLab, the CommitCommentsWorkItem will take about 8 hours to complete. >> After investigation, I think there is a bug in GitLabRepository#getCommitTitleToCommitsMap >> >> For GitLab repos, we need to build a hash map for mapping commit title to commits. The implementation of the map is Map>. We use LinkedHashSet here because we want the bot to check latest commits first. >> >> If the map has already been built, then the bot will query new commits in the repo and adds the commits into the map. However, when adding the new commit hash to the map, the bot add it to the end of the LinkedHashSet. So new commits will be checked very late. >> >> For commit titles like "Merge", sometimes, there can be around 50K commits in a repo. If the latest "Merge" commit is added to the tail of the LinkedHashSet, the bot must check all previous commits first, which takes a lot of time. > > Zhao Song has updated the pull request incrementally with one additional commit since the last revision: > > Use SequencedSet Thanks for the suggestions and review! ------------- PR Comment: https://git.openjdk.org/skara/pull/1682#issuecomment-2286710059 From zsong at openjdk.org Tue Aug 13 17:01:53 2024 From: zsong at openjdk.org (Zhao Song) Date: Tue, 13 Aug 2024 17:01:53 GMT Subject: Integrated: 2340: CommitCommentsWorkItem executing in GitLab takes a lot of time In-Reply-To: References: Message-ID: <0PLNVF50mvuPTpUc0UxsDafdoVmkYCdTAqXRcuKpXvM=.5971d3e5-3858-44fa-aaf6-5110efe3f302@github.com> On Mon, 29 Jul 2024 17:44:54 GMT, Zhao Song wrote: > Currently, if a user comments under a commit named "Merge" in GitLab, the CommitCommentsWorkItem will take about 8 hours to complete. > After investigation, I think there is a bug in GitLabRepository#getCommitTitleToCommitsMap > > For GitLab repos, we need to build a hash map for mapping commit title to commits. The implementation of the map is Map>. We use LinkedHashSet here because we want the bot to check latest commits first. > > If the map has already been built, then the bot will query new commits in the repo and adds the commits into the map. However, when adding the new commit hash to the map, the bot add it to the end of the LinkedHashSet. So new commits will be checked very late. > > For commit titles like "Merge", sometimes, there can be around 50K commits in a repo. If the latest "Merge" commit is added to the tail of the LinkedHashSet, the bot must check all previous commits first, which takes a lot of time. This pull request has now been integrated. Changeset: ee0af93f Author: Zhao Song URL: https://git.openjdk.org/skara/commit/ee0af93f9d7fcf42689b9b94a582382ac823b9e5 Stats: 12 lines in 1 file changed: 6 ins; 0 del; 6 mod 2340: CommitCommentsWorkItem executing in GitLab takes a lot of time Reviewed-by: erikj ------------- PR: https://git.openjdk.org/skara/pull/1682 From kcr at openjdk.org Thu Aug 15 00:06:18 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 15 Aug 2024 00:06:18 GMT Subject: RFR: 2331: Improve review notes [v3] In-Reply-To: References: <16pKJai8EtgEqsoyWpyKvqEesej9hRSp7ddUo52pE6k=.bd52aded-4838-4ae6-9589-defd826fd351@github.com> <7srn7Q9wlg0jflfturAf8gFX7FmBTfb9pgZjO4-KJ0o=.f0ca47fa-6b47-43e8-9e35-45fe0de06e57@github.com> <3i0wPqJAEi0ouFKnKFg-7gmHY3_6EcxGj9z1am8Ze4U=.1a068353-5756-45b1-92eb-dba06a01bc74@github.com> <44lrFFb_zvAYv0sOLP_EgOABHWND9yxYCjq 1RVhRFuk=.dce9a653-4c73-4137-9e3c-c196b736307b@github.com> Message-ID: On Mon, 12 Aug 2024 13:48:52 GMT, Erik Joelsson wrote: >>> I'm not sure what the significance of your last question is, Pavel. Are we behaving differently today when the commit has gone missing or the branch has changed? >> >> In either of those two cases, in master, we display the "?" emoji and the word "required" regardless of whether the PR has been sufficiently reviewed: >> >> https://github.com/openjdk/skara/blob/45468cde2dc5273c70f728c46c6b133e3d16b55a/bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckRun.java#L602-L622 >> >> If we are trying to generally improve review notes, we perhaps should treat those two cases similarly to our main/typical case? > > I agree, those cases should be folded into the new behavior with regards to emojis. Yes, I agree with this. ------------- PR Review Comment: https://git.openjdk.org/skara/pull/1679#discussion_r1717652017 From prappo at openjdk.org Mon Aug 19 16:22:25 2024 From: prappo at openjdk.org (Pavel Rappo) Date: Mon, 19 Aug 2024 16:22:25 GMT Subject: RFR: 2331: Improve review notes [v4] In-Reply-To: <16pKJai8EtgEqsoyWpyKvqEesej9hRSp7ddUo52pE6k=.bd52aded-4838-4ae6-9589-defd826fd351@github.com> References: <16pKJai8EtgEqsoyWpyKvqEesej9hRSp7ddUo52pE6k=.bd52aded-4838-4ae6-9589-defd826fd351@github.com> Message-ID: > There are two variants of a note that can be added to an item in the "Reviewers" list of a PR body: > > - ? Re-review required ... > - ?? Review applies to ... > > That note may confuse or draw unneeded attention to the PR body. > > Firstly, as a result of recently integrated [SKARA-2312][], "?? Review applies to ..." is also added to an item (i.e. review) that applies to the head of the PR. Secondly, "? Re-review required (review applies to ..." may be present for some items even though a PR has the green "ready" label. > > [SKARA-2312]: https://bugs.openjdk.org/browse/SKARA-2312 Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: - Respond to feedback - Merge branch 'master' into 2331 - Don't special-case wrong target or missing commit After out-of-band conversation with @zhaosongzs, we decided to drop useStaleReviews check. - Avoid emojis and "required" when a PR is ready - Re-indent code - Don't add "Re-review required" if reviewed If review requirements are fully satisfied, don't add "Re-review required (review applies to ..." for stale reviews; instead, add "Review applies to ..." - Don't add "Review applies to" to the head of a PR ------------- Changes: - all: https://git.openjdk.org/skara/pull/1679/files - new: https://git.openjdk.org/skara/pull/1679/files/15aba4b6..cd128621 Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1679&range=03 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1679&range=02-03 Stats: 176 lines in 12 files changed: 101 ins; 19 del; 56 mod Patch: https://git.openjdk.org/skara/pull/1679.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1679/head:pull/1679 PR: https://git.openjdk.org/skara/pull/1679 From prappo at openjdk.org Mon Aug 19 16:22:25 2024 From: prappo at openjdk.org (Pavel Rappo) Date: Mon, 19 Aug 2024 16:22:25 GMT Subject: RFR: 2331: Improve review notes [v3] In-Reply-To: References: <16pKJai8EtgEqsoyWpyKvqEesej9hRSp7ddUo52pE6k=.bd52aded-4838-4ae6-9589-defd826fd351@github.com> Message-ID: On Tue, 23 Jul 2024 18:53:19 GMT, Pavel Rappo wrote: >> There are two variants of a note that can be added to an item in the "Reviewers" list of a PR body: >> >> - ? Re-review required ... >> - ?? Review applies to ... >> >> That note may confuse or draw unneeded attention to the PR body. >> >> Firstly, as a result of recently integrated [SKARA-2312][], "?? Review applies to ..." is also added to an item (i.e. review) that applies to the head of the PR. Secondly, "? Re-review required (review applies to ..." may be present for some items even though a PR has the green "ready" label. >> >> [SKARA-2312]: https://bugs.openjdk.org/browse/SKARA-2312 > > Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: > > Don't special-case wrong target or missing commit > > After out-of-band conversation with @zhaosongzs, we decided to drop > useStaleReviews check. I hope I've addressed everyone's concerns. @kevinrushforth, @erikj79, @zhaosongzs, please re-review. ------------- PR Comment: https://git.openjdk.org/skara/pull/1679#issuecomment-2296956143 From erikj at openjdk.org Mon Aug 19 17:05:10 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 19 Aug 2024 17:05:10 GMT Subject: RFR: 2331: Improve review notes [v4] In-Reply-To: References: <16pKJai8EtgEqsoyWpyKvqEesej9hRSp7ddUo52pE6k=.bd52aded-4838-4ae6-9589-defd826fd351@github.com> Message-ID: On Mon, 19 Aug 2024 16:22:25 GMT, Pavel Rappo wrote: >> There are two variants of a note that can be added to an item in the "Reviewers" list of a PR body: >> >> - ? Re-review required ... >> - ?? Review applies to ... >> >> That note may confuse or draw unneeded attention to the PR body. >> >> Firstly, as a result of recently integrated [SKARA-2312][], "?? Review applies to ..." is also added to an item (i.e. review) that applies to the head of the PR. Secondly, "? Re-review required (review applies to ..." may be present for some items even though a PR has the green "ready" label. >> >> [SKARA-2312]: https://bugs.openjdk.org/browse/SKARA-2312 > > Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: > > - Respond to feedback > - Merge branch 'master' into 2331 > - Don't special-case wrong target or missing commit > > After out-of-band conversation with @zhaosongzs, we decided to drop > useStaleReviews check. > - Avoid emojis and "required" when a PR is ready > - Re-indent code > - Don't add "Re-review required" if reviewed > > If review requirements are fully satisfied, don't add "Re-review > required (review applies to ..." for stale reviews; instead, add > "Review applies to ..." > - Don't add "Review applies to" to the head of a PR I'm ok with the review notes here, just a minor nit for code readability. ------------- PR Review: https://git.openjdk.org/skara/pull/1679#pullrequestreview-2246045393 From erikj at openjdk.org Mon Aug 19 17:05:10 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 19 Aug 2024 17:05:10 GMT Subject: RFR: 2331: Improve review notes [v4] In-Reply-To: References: <16pKJai8EtgEqsoyWpyKvqEesej9hRSp7ddUo52pE6k=.bd52aded-4838-4ae6-9589-defd826fd351@github.com> <374hyoT1yMovFTAlSDJoOzSIFDXUxCue_NWrBdwaTGY=.5fe67047-14e9-4b94-ad23-3d595067254d@github.com> Message-ID: On Fri, 9 Aug 2024 20:20:40 GMT, Erik Joelsson wrote: >> Usually, making a minimally necessary change is good, and parsing end-user text is bad. In fact, I'd go to great lengths to avoid "stringly typed" code that operates on strings that are also subject to change. >> >> Here, I initially thought I might be violating some encapsulation boundary by bringing a dependency. Maybe I still am. If nothing else, it's not the first class imported from that package: >> >> import org.openjdk.skara.jcheck.JCheckConfiguration; >> +import org.openjdk.skara.jcheck.TooFewReviewersIssue; > > I think it's ok to return the list of jcheck issues, but the variable name `issues` can be confusing as an `Issue` in the bots is usually some form of Jira Issue. I would recommend `jcheckIssues` to avoid confusion. Could you rename the variable `issues` to something more descriptive? ------------- PR Review Comment: https://git.openjdk.org/skara/pull/1679#discussion_r1722094927 From zsong at openjdk.org Mon Aug 19 17:56:23 2024 From: zsong at openjdk.org (Zhao Song) Date: Mon, 19 Aug 2024 17:56:23 GMT Subject: RFR: 2331: Improve review notes [v4] In-Reply-To: References: <16pKJai8EtgEqsoyWpyKvqEesej9hRSp7ddUo52pE6k=.bd52aded-4838-4ae6-9589-defd826fd351@github.com> Message-ID: On Mon, 19 Aug 2024 16:22:25 GMT, Pavel Rappo wrote: >> There are two variants of a note that can be added to an item in the "Reviewers" list of a PR body: >> >> - ? Re-review required ... >> - ?? Review applies to ... >> >> That note may confuse or draw unneeded attention to the PR body. >> >> Firstly, as a result of recently integrated [SKARA-2312][], "?? Review applies to ..." is also added to an item (i.e. review) that applies to the head of the PR. Secondly, "? Re-review required (review applies to ..." may be present for some items even though a PR has the green "ready" label. >> >> [SKARA-2312]: https://bugs.openjdk.org/browse/SKARA-2312 > > Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: > > - Respond to feedback > - Merge branch 'master' into 2331 > - Don't special-case wrong target or missing commit > > After out-of-band conversation with @zhaosongzs, we decided to drop > useStaleReviews check. > - Avoid emojis and "required" when a PR is ready > - Re-indent code > - Don't add "Re-review required" if reviewed > > If review requirements are fully satisfied, don't add "Re-review > required (review applies to ..." for stale reviews; instead, add > "Review applies to ..." > - Don't add "Review applies to" to the head of a PR Looks good! ------------- Marked as reviewed by zsong (Reviewer). PR Review: https://git.openjdk.org/skara/pull/1679#pullrequestreview-2246139853 From prappo at openjdk.org Mon Aug 19 19:10:28 2024 From: prappo at openjdk.org (Pavel Rappo) Date: Mon, 19 Aug 2024 19:10:28 GMT Subject: RFR: 2331: Improve review notes [v4] In-Reply-To: References: <16pKJai8EtgEqsoyWpyKvqEesej9hRSp7ddUo52pE6k=.bd52aded-4838-4ae6-9589-defd826fd351@github.com> <374hyoT1yMovFTAlSDJoOzSIFDXUxCue_NWrBdwaTGY=.5fe67047-14e9-4b94-ad23-3d595067254d@github.com> Message-ID: <-6nKv2Bg3guIjnJf4a--spjZ29iq6ijIWlAn2UVslDE=.0789fc54-96fa-4e9f-b2b3-4c08a88461c5@github.com> On Mon, 19 Aug 2024 17:00:55 GMT, Erik Joelsson wrote: >> I think it's ok to return the list of jcheck issues, but the variable name `issues` can be confusing as an `Issue` in the bots is usually some form of Jira Issue. I would recommend `jcheckIssues` to avoid confusion. > > Could you rename the variable `issues` to something more descriptive? Fair enough. I can see that "issue" is an overloaded term in the Skara domain: - org.openjdk.skara.issuetracker.Issue - org.openjdk.skara.jcheck.Issue One word, two meanings. Does `jcheckIssues` sound better to you? ------------- PR Review Comment: https://git.openjdk.org/skara/pull/1679#discussion_r1722232655 From erikj at openjdk.org Mon Aug 19 19:26:29 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 19 Aug 2024 19:26:29 GMT Subject: RFR: 2331: Improve review notes [v4] In-Reply-To: <-6nKv2Bg3guIjnJf4a--spjZ29iq6ijIWlAn2UVslDE=.0789fc54-96fa-4e9f-b2b3-4c08a88461c5@github.com> References: <16pKJai8EtgEqsoyWpyKvqEesej9hRSp7ddUo52pE6k=.bd52aded-4838-4ae6-9589-defd826fd351@github.com> <374hyoT1yMovFTAlSDJoOzSIFDXUxCue_NWrBdwaTGY=.5fe67047-14e9-4b94-ad23-3d595067254d@github.com> <-6nKv2Bg3guIjnJf4a--spjZ29iq6ijIWlAn2UVslDE=.0789fc54-96fa-4e9f-b2b3-4c08a88461c5@github.com> Message-ID: On Mon, 19 Aug 2024 19:08:22 GMT, Pavel Rappo wrote: >> Could you rename the variable `issues` to something more descriptive? > > Fair enough. I can see that "issue" is an overloaded term in the Skara domain: > > - org.openjdk.skara.issuetracker.Issue > - org.openjdk.skara.jcheck.Issue > > One word, two meanings. Does `jcheckIssues` sound better to you? Yes, I wrote just that in the previous comment from last week. :) ------------- PR Review Comment: https://git.openjdk.org/skara/pull/1679#discussion_r1722249532 From prappo at openjdk.org Mon Aug 19 20:59:36 2024 From: prappo at openjdk.org (Pavel Rappo) Date: Mon, 19 Aug 2024 20:59:36 GMT Subject: RFR: 2331: Improve review notes [v5] In-Reply-To: <16pKJai8EtgEqsoyWpyKvqEesej9hRSp7ddUo52pE6k=.bd52aded-4838-4ae6-9589-defd826fd351@github.com> References: <16pKJai8EtgEqsoyWpyKvqEesej9hRSp7ddUo52pE6k=.bd52aded-4838-4ae6-9589-defd826fd351@github.com> Message-ID: > There are two variants of a note that can be added to an item in the "Reviewers" list of a PR body: > > - ? Re-review required ... > - ?? Review applies to ... > > That note may confuse or draw unneeded attention to the PR body. > > Firstly, as a result of recently integrated [SKARA-2312][], "?? Review applies to ..." is also added to an item (i.e. review) that applies to the head of the PR. Secondly, "? Re-review required (review applies to ..." may be present for some items even though a PR has the green "ready" label. > > [SKARA-2312]: https://bugs.openjdk.org/browse/SKARA-2312 Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: Rename a variable ------------- Changes: - all: https://git.openjdk.org/skara/pull/1679/files - new: https://git.openjdk.org/skara/pull/1679/files/cd128621..f4dde9b4 Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1679&range=04 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1679&range=03-04 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/skara/pull/1679.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1679/head:pull/1679 PR: https://git.openjdk.org/skara/pull/1679 From prappo at openjdk.org Mon Aug 19 20:59:36 2024 From: prappo at openjdk.org (Pavel Rappo) Date: Mon, 19 Aug 2024 20:59:36 GMT Subject: RFR: 2331: Improve review notes [v5] In-Reply-To: References: <16pKJai8EtgEqsoyWpyKvqEesej9hRSp7ddUo52pE6k=.bd52aded-4838-4ae6-9589-defd826fd351@github.com> <374hyoT1yMovFTAlSDJoOzSIFDXUxCue_NWrBdwaTGY=.5fe67047-14e9-4b94-ad23-3d595067254d@github.com> <-6nKv2Bg3guIjnJf4a--spjZ29iq6ijIWlAn2UVslDE=.0789fc54-96fa-4e9f-b2b3-4c08a88461c5@github.com> Message-ID: On Mon, 19 Aug 2024 19:24:22 GMT, Erik Joelsson wrote: > Yes, I wrote just that in the previous comment from last week. :) D'oh. The PR has been open for quite a while, and I forgot that you asked that question. While I cannot guarantee that I didn't internalise and then forgot your question, it's good that we're now on the same page. ------------- PR Review Comment: https://git.openjdk.org/skara/pull/1679#discussion_r1722339500 From erikj at openjdk.org Mon Aug 19 21:03:29 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 19 Aug 2024 21:03:29 GMT Subject: RFR: 2331: Improve review notes [v5] In-Reply-To: References: <16pKJai8EtgEqsoyWpyKvqEesej9hRSp7ddUo52pE6k=.bd52aded-4838-4ae6-9589-defd826fd351@github.com> Message-ID: <9r7x-_jFLVidJveX-4frAVlJfoL0IWc02njeiMzMBiI=.168d3ae0-6273-4f3e-bb6f-ba35f1972948@github.com> On Mon, 19 Aug 2024 20:59:36 GMT, Pavel Rappo wrote: >> There are two variants of a note that can be added to an item in the "Reviewers" list of a PR body: >> >> - ? Re-review required ... >> - ?? Review applies to ... >> >> That note may confuse or draw unneeded attention to the PR body. >> >> Firstly, as a result of recently integrated [SKARA-2312][], "?? Review applies to ..." is also added to an item (i.e. review) that applies to the head of the PR. Secondly, "? Re-review required (review applies to ..." may be present for some items even though a PR has the green "ready" label. >> >> [SKARA-2312]: https://bugs.openjdk.org/browse/SKARA-2312 > > Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: > > Rename a variable Marked as reviewed by erikj (Lead). ------------- PR Review: https://git.openjdk.org/skara/pull/1679#pullrequestreview-2246452690 From kcr at openjdk.org Mon Aug 19 21:14:38 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 19 Aug 2024 21:14:38 GMT Subject: RFR: 2331: Improve review notes [v5] In-Reply-To: References: <16pKJai8EtgEqsoyWpyKvqEesej9hRSp7ddUo52pE6k=.bd52aded-4838-4ae6-9589-defd826fd351@github.com> Message-ID: On Mon, 19 Aug 2024 20:59:36 GMT, Pavel Rappo wrote: >> There are two variants of a note that can be added to an item in the "Reviewers" list of a PR body: >> >> - ? Re-review required ... >> - ?? Review applies to ... >> >> That note may confuse or draw unneeded attention to the PR body. >> >> Firstly, as a result of recently integrated [SKARA-2312][], "?? Review applies to ..." is also added to an item (i.e. review) that applies to the head of the PR. Secondly, "? Re-review required (review applies to ..." may be present for some items even though a PR has the green "ready" label. >> >> [SKARA-2312]: https://bugs.openjdk.org/browse/SKARA-2312 > > Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: > > Rename a variable Looks good now. ------------- Marked as reviewed by kcr (Reviewer). PR Review: https://git.openjdk.org/skara/pull/1679#pullrequestreview-2246469256 From prappo at openjdk.org Mon Aug 19 21:55:39 2024 From: prappo at openjdk.org (Pavel Rappo) Date: Mon, 19 Aug 2024 21:55:39 GMT Subject: Integrated: 2331: Improve review notes In-Reply-To: <16pKJai8EtgEqsoyWpyKvqEesej9hRSp7ddUo52pE6k=.bd52aded-4838-4ae6-9589-defd826fd351@github.com> References: <16pKJai8EtgEqsoyWpyKvqEesej9hRSp7ddUo52pE6k=.bd52aded-4838-4ae6-9589-defd826fd351@github.com> Message-ID: On Thu, 18 Jul 2024 10:52:54 GMT, Pavel Rappo wrote: > There are two variants of a note that can be added to an item in the "Reviewers" list of a PR body: > > - ? Re-review required ... > - ?? Review applies to ... > > That note may confuse or draw unneeded attention to the PR body. > > Firstly, as a result of recently integrated [SKARA-2312][], "?? Review applies to ..." is also added to an item (i.e. review) that applies to the head of the PR. Secondly, "? Re-review required (review applies to ..." may be present for some items even though a PR has the green "ready" label. > > [SKARA-2312]: https://bugs.openjdk.org/browse/SKARA-2312 This pull request has now been integrated. Changeset: c3510610 Author: Pavel Rappo URL: https://git.openjdk.org/skara/commit/c3510610eec644df9478b988fbe3bc25ab62f808 Stats: 80 lines in 3 files changed: 44 ins; 0 del; 36 mod 2331: Improve review notes Reviewed-by: zsong, erikj, kcr ------------- PR: https://git.openjdk.org/skara/pull/1679