From ihse at openjdk.java.net  Tue Jul  6 12:34:14 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 6 Jul 2021 12:34:14 GMT
Subject: RFR: 1085: Gitlab PR has bad link to patch file [v2]
In-Reply-To: <DzS_17jzzsAOAMYknVouYoseA99Ngvs7ZedefZgFE_o=.a62689e7-e965-41ff-9528-b9faf99b29d0@github.com>
References: <DzS_17jzzsAOAMYknVouYoseA99Ngvs7ZedefZgFE_o=.a62689e7-e965-41ff-9528-b9faf99b29d0@github.com>
Message-ID: <wIpI-jvkCm2eDuuLd2MyeV6hkTDC7UyjQtZmeMPIZIM=.d01bca1d-0f86-4e11-9d39-1890061eea60@github.com>

> The link generated under the "Reviewing" header in a PR description works fine on Github, but on Gitlab, the link has a Github style form which does not work.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Stop GitLab URL mangling

-------------

Changes:
  - all: https://git.openjdk.java.net/skara/pull/1191/files
  - new: https://git.openjdk.java.net/skara/pull/1191/files/a9521e46..59f6c2aa

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=skara&pr=1191&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=skara&pr=1191&range=00-01

  Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/skara/pull/1191.diff
  Fetch: git fetch https://git.openjdk.java.net/skara pull/1191/head:pull/1191

PR: https://git.openjdk.java.net/skara/pull/1191

From ihse at openjdk.java.net  Tue Jul  6 12:41:21 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 6 Jul 2021 12:41:21 GMT
Subject: RFR: 1085: Gitlab PR has bad link to patch file [v2]
In-Reply-To: <wIpI-jvkCm2eDuuLd2MyeV6hkTDC7UyjQtZmeMPIZIM=.d01bca1d-0f86-4e11-9d39-1890061eea60@github.com>
References: <DzS_17jzzsAOAMYknVouYoseA99Ngvs7ZedefZgFE_o=.a62689e7-e965-41ff-9528-b9faf99b29d0@github.com>
 <wIpI-jvkCm2eDuuLd2MyeV6hkTDC7UyjQtZmeMPIZIM=.d01bca1d-0f86-4e11-9d39-1890061eea60@github.com>
Message-ID: <srCv8NfamgbUATpn9OlZepX5dQ6ZEZlX3BNuOyHyK9g=.a3b7280e-d22d-44db-8dce-54667c261f5c@github.com>

On Tue, 6 Jul 2021 12:34:14 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> The link generated under the "Reviewing" header in a PR description works fine on Github, but on Gitlab, the link has a Github style form which does not work.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Stop GitLab URL mangling

So, it turned out that GitLab is a bit too smart for it's own best... If it finds that a part of a URL matches a MR, it will rewrite it to "!<MR number>", e.g. "!99". So the diff URLs got converted to `!99.diff`. Which the javascript, or whatever, that should have restored the full MR URL, could not detect and rewrite back to the proper URL. *sigh* I worked around this by adding a double slash, which throw off the pattern detector.

-------------

PR: https://git.openjdk.java.net/skara/pull/1191

From erikj at openjdk.java.net  Tue Jul  6 16:15:07 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Tue, 6 Jul 2021 16:15:07 GMT
Subject: RFR: 1085: Gitlab PR has bad link to patch file [v2]
In-Reply-To: <wIpI-jvkCm2eDuuLd2MyeV6hkTDC7UyjQtZmeMPIZIM=.d01bca1d-0f86-4e11-9d39-1890061eea60@github.com>
References: <DzS_17jzzsAOAMYknVouYoseA99Ngvs7ZedefZgFE_o=.a62689e7-e965-41ff-9528-b9faf99b29d0@github.com>
 <wIpI-jvkCm2eDuuLd2MyeV6hkTDC7UyjQtZmeMPIZIM=.d01bca1d-0f86-4e11-9d39-1890061eea60@github.com>
Message-ID: <R1tC8eAujxmz23dK-gItur1EdzTZlPFxTZIeZBumXpg=.df1ab2a4-e12b-4999-a133-e5ffda40f7b2@github.com>

On Tue, 6 Jul 2021 12:34:14 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> The link generated under the "Reviewing" header in a PR description works fine on Github, but on Gitlab, the link has a Github style form which does not work.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Stop GitLab URL mangling

Marked as reviewed by erikj (Lead).

-------------

PR: https://git.openjdk.java.net/skara/pull/1191

From erikj at openjdk.java.net  Tue Jul  6 17:17:21 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Tue, 6 Jul 2021 17:17:21 GMT
Subject: Integrated: 1095: Ignore tags in pr branches when notifying
In-Reply-To: <NS1GZq6WK_rUyIy2F-_tFWV68-JhDi_puNYPV_1vGD8=.21b995da-3464-4f6d-92c7-950a80e727c5@github.com>
References: <NS1GZq6WK_rUyIy2F-_tFWV68-JhDi_puNYPV_1vGD8=.21b995da-3464-4f6d-92c7-950a80e727c5@github.com>
Message-ID: <LNseeZpzdJGuv_Vdyjy_134vNkfzGPbKjESO-eQgzhc=.640c05d6-317e-4190-b86f-1e8e8794fe49@github.com>

On Thu, 24 Jun 2021 18:44:50 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> This patch for the Notify bot adds filtering when processing new tags. Only tags that appear in branches other than the PR branches are considered. Changes in PR branches are pending review and should not be included when sending email notifications or updating bugs. See bug for more details.

This pull request has now been integrated.

Changeset: ac074bcc
Author:    Erik Joelsson <erikj at openjdk.org>
URL:       https://git.openjdk.java.net/skara/commit/ac074bcc465d8368e2c22d8cdfdfa4615e514067
Stats:     123 lines in 2 files changed: 123 ins; 0 del; 0 mod

1095: Ignore tags in pr branches when notifying

Reviewed-by: kcr

-------------

PR: https://git.openjdk.java.net/skara/pull/1193

From ihse at openjdk.java.net  Tue Jul  6 19:35:09 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 6 Jul 2021 19:35:09 GMT
Subject: Integrated: 1085: Gitlab PR has bad link to patch file
In-Reply-To: <DzS_17jzzsAOAMYknVouYoseA99Ngvs7ZedefZgFE_o=.a62689e7-e965-41ff-9528-b9faf99b29d0@github.com>
References: <DzS_17jzzsAOAMYknVouYoseA99Ngvs7ZedefZgFE_o=.a62689e7-e965-41ff-9528-b9faf99b29d0@github.com>
Message-ID: <U-Q6MiirYMAmO2PvH3MhU1wYdSaFYoP1PdvAVm9wgIQ=.d8f77917-e6ac-4ceb-b569-f3a1d467c815@github.com>

On Tue, 22 Jun 2021 11:55:10 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The link generated under the "Reviewing" header in a PR description works fine on Github, but on Gitlab, the link has a Github style form which does not work.

This pull request has now been integrated.

Changeset: 2540619f
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.java.net/skara/commit/2540619f7dfb7e6df1bf37e7de460276959b05b1
Stats:     27 lines in 6 files changed: 26 ins; 0 del; 1 mod

1085: Gitlab PR has bad link to patch file

Reviewed-by: erikj

-------------

PR: https://git.openjdk.java.net/skara/pull/1191

From erikj at openjdk.java.net  Tue Jul  6 21:00:16 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Tue, 6 Jul 2021 21:00:16 GMT
Subject: RFR: 1084: Automatically update repository labels from Skara config
Message-ID: <VT8aGDtCFAadG-lLsuSbbLBUTXcxga6ZMTnFEc_v0uo=.86166749-7740-46f6-b096-cc558e449808@github.com>

This patch adds a new WorkItem to the MailingListBridgeBot. The new LabelsUpdaterWorkItem runs once at startup and makes sure all mailing list labels configured for the repository actually exist as labels in the hosted repository (in GitHub or GitLab). I chose to implement this as a WorkItem, even though it's just run once. It will also block any other WorkItems in the bot from running until successful. By using the existing framework for this, we get automatic retries and I believe it will play better with other bots for resource usage, even though it doesn't quite fit in.

The new WorkItem also keeps the description field updated with the mailing list email address. This use of the description field was initially added manually for the main jdk repository on GitHub, but has not been kept up to date since, and has not been propagated to other repositories (jdk16 and jdk17). These description fields are both informative for the user, as well as being used by the CLI client to present information to users.

To verify the new interaction for managing labels on a repository with both GitLab and GitHub, I have implemented a new type of manual tests. They are disabled from automatic running in Gradle using the @Disabled annotation. To run them you need to provide a properties file with data about account and keys to use to access the servers. We don't want these kinds of tests to run against GitHub/GitLab automatically, but at least now there is a way to semi automatically verify that kind of functionality.

-------------

Commit messages:
 - Added test and log messages
 - SKARA-1084

Changes: https://git.openjdk.java.net/skara/pull/1194/files
 Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1194&range=00
  Issue: https://bugs.openjdk.java.net/browse/SKARA-1084
  Stats: 427 lines in 14 files changed: 420 ins; 1 del; 6 mod
  Patch: https://git.openjdk.java.net/skara/pull/1194.diff
  Fetch: git fetch https://git.openjdk.java.net/skara pull/1194/head:pull/1194

PR: https://git.openjdk.java.net/skara/pull/1194

From kcr at openjdk.java.net  Tue Jul  6 21:30:52 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Tue, 6 Jul 2021 21:30:52 GMT
Subject: RFR: 1084: Automatically update repository labels from Skara
 config
In-Reply-To: <VT8aGDtCFAadG-lLsuSbbLBUTXcxga6ZMTnFEc_v0uo=.86166749-7740-46f6-b096-cc558e449808@github.com>
References: <VT8aGDtCFAadG-lLsuSbbLBUTXcxga6ZMTnFEc_v0uo=.86166749-7740-46f6-b096-cc558e449808@github.com>
Message-ID: <CHXskxmXhH2JPL0pMIwciIkhwKL1Wqr14WP9NLAns8U=.7479698b-1aa4-4979-a9d7-633fb181e4b6@github.com>

On Tue, 6 Jul 2021 20:56:51 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> This patch adds a new WorkItem to the MailingListBridgeBot. The new LabelsUpdaterWorkItem runs once at startup and makes sure all mailing list labels configured for the repository actually exist as labels in the hosted repository (in GitHub or GitLab). I chose to implement this as a WorkItem, even though it's just run once. It will also block any other WorkItems in the bot from running until successful. By using the existing framework for this, we get automatic retries and I believe it will play better with other bots for resource usage, even though it doesn't quite fit in.
> 
> The new WorkItem also keeps the description field updated with the mailing list email address. This use of the description field was initially added manually for the main jdk repository on GitHub, but has not been kept up to date since, and has not been propagated to other repositories (jdk16 and jdk17). These description fields are both informative for the user, as well as being used by the CLI client to present information to users.
> 
> To verify the new interaction for managing labels on a repository with both GitLab and GitHub, I have implemented a new type of manual tests. They are disabled from automatic running in Gradle using the @Disabled annotation. To run them you need to provide a properties file with data about account and keys to use to access the servers. We don't want these kinds of tests to run against GitHub/GitLab automatically, but at least now there is a way to semi automatically verify that kind of functionality.

Not a complete review, but I left a couple questions inline.

bots/mlbridge/src/main/java/org/openjdk/skara/bots/mlbridge/ArchiveWorkItem.java line 65:

> 63:     public boolean concurrentWith(WorkItem other) {
> 64:         if (!(other instanceof ArchiveWorkItem otherArchiveItem)) {
> 65:             if (!(other instanceof LabelsUpdaterWorkItem otherLabelsUpdaterItem)) {

Pattern-matching `instanceof` was finalized in JDK 16. Has Skara already bumped its minimum JDK to 16?

forge/src/main/java/org/openjdk/skara/forge/github/GitHubRepository.java line 591:

> 589:                 .put("name", label.name())
> 590:                 // Color is Gray and matches all current labels
> 591:                 .put("color", "ededed");

Will this overwrite the existing color scheme? For a new repo, will it always use gray for all labels?

-------------

PR: https://git.openjdk.java.net/skara/pull/1194

From erikj at openjdk.java.net  Wed Jul  7 12:32:41 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Wed, 7 Jul 2021 12:32:41 GMT
Subject: RFR: 1084: Automatically update repository labels from Skara
 config
In-Reply-To: <CHXskxmXhH2JPL0pMIwciIkhwKL1Wqr14WP9NLAns8U=.7479698b-1aa4-4979-a9d7-633fb181e4b6@github.com>
References: <VT8aGDtCFAadG-lLsuSbbLBUTXcxga6ZMTnFEc_v0uo=.86166749-7740-46f6-b096-cc558e449808@github.com>
 <CHXskxmXhH2JPL0pMIwciIkhwKL1Wqr14WP9NLAns8U=.7479698b-1aa4-4979-a9d7-633fb181e4b6@github.com>
Message-ID: <1xZccqaosaJOwxGdjdTPTwmyj4D8g7ozFanj6scq9yw=.37f74a62-a70e-4a97-9b46-ccdf5967e021@github.com>

On Tue, 6 Jul 2021 21:26:30 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> This patch adds a new WorkItem to the MailingListBridgeBot. The new LabelsUpdaterWorkItem runs once at startup and makes sure all mailing list labels configured for the repository actually exist as labels in the hosted repository (in GitHub or GitLab). I chose to implement this as a WorkItem, even though it's just run once. It will also block any other WorkItems in the bot from running until successful. By using the existing framework for this, we get automatic retries and I believe it will play better with other bots for resource usage, even though it doesn't quite fit in.
>> 
>> The new WorkItem also keeps the description field updated with the mailing list email address. This use of the description field was initially added manually for the main jdk repository on GitHub, but has not been kept up to date since, and has not been propagated to other repositories (jdk16 and jdk17). These description fields are both informative for the user, as well as being used by the CLI client to present information to users.
>> 
>> To verify the new interaction for managing labels on a repository with both GitLab and GitHub, I have implemented a new type of manual tests. They are disabled from automatic running in Gradle using the @Disabled annotation. To run them you need to provide a properties file with data about account and keys to use to access the servers. We don't want these kinds of tests to run against GitHub/GitLab automatically, but at least now there is a way to semi automatically verify that kind of functionality.
>
> bots/mlbridge/src/main/java/org/openjdk/skara/bots/mlbridge/ArchiveWorkItem.java line 65:
> 
>> 63:     public boolean concurrentWith(WorkItem other) {
>> 64:         if (!(other instanceof ArchiveWorkItem otherArchiveItem)) {
>> 65:             if (!(other instanceof LabelsUpdaterWorkItem otherLabelsUpdaterItem)) {
> 
> Pattern-matching `instanceof` was finalized in JDK 16. Has Skara already bumped its minimum JDK to 16?

We are running the Skara bots on JDK 16, but officially we are still listing JDK 14 as minimum. I don't think it's worth bumping the minimum for this.

> forge/src/main/java/org/openjdk/skara/forge/github/GitHubRepository.java line 591:
> 
>> 589:                 .put("name", label.name())
>> 590:                 // Color is Gray and matches all current labels
>> 591:                 .put("color", "ededed");
> 
> Will this overwrite the existing color scheme? For a new repo, will it always use gray for all labels?

If addLabel() is called on an existing label, then I think the color scheme will be overwritten. The intention not to change any label, just to add the ones that are missing. The updateLabel method will not change the color.

Note that the labels we are adding with this patch are just the ones for mailing lists. Do you think we need to add automation for colors for the other set of labels we use (e.g. rfr, ready, csr etc)?

-------------

PR: https://git.openjdk.java.net/skara/pull/1194

From kcr at openjdk.java.net  Wed Jul  7 15:15:45 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Wed, 7 Jul 2021 15:15:45 GMT
Subject: RFR: 1084: Automatically update repository labels from Skara
 config
In-Reply-To: <1xZccqaosaJOwxGdjdTPTwmyj4D8g7ozFanj6scq9yw=.37f74a62-a70e-4a97-9b46-ccdf5967e021@github.com>
References: <VT8aGDtCFAadG-lLsuSbbLBUTXcxga6ZMTnFEc_v0uo=.86166749-7740-46f6-b096-cc558e449808@github.com>
 <CHXskxmXhH2JPL0pMIwciIkhwKL1Wqr14WP9NLAns8U=.7479698b-1aa4-4979-a9d7-633fb181e4b6@github.com>
 <1xZccqaosaJOwxGdjdTPTwmyj4D8g7ozFanj6scq9yw=.37f74a62-a70e-4a97-9b46-ccdf5967e021@github.com>
Message-ID: <h4HulXC_dO1rraQE-9z-N8WPbXBRIV84cnqHugmKLbk=.9d8b43cb-c1a5-4ab7-a21b-34f5a2b744e5@github.com>

On Wed, 7 Jul 2021 12:30:17 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> bots/mlbridge/src/main/java/org/openjdk/skara/bots/mlbridge/ArchiveWorkItem.java line 65:
>> 
>>> 63:     public boolean concurrentWith(WorkItem other) {
>>> 64:         if (!(other instanceof ArchiveWorkItem otherArchiveItem)) {
>>> 65:             if (!(other instanceof LabelsUpdaterWorkItem otherLabelsUpdaterItem)) {
>> 
>> Pattern-matching `instanceof` was finalized in JDK 16. Has Skara already bumped its minimum JDK to 16?
>
> We are running the Skara bots on JDK 16, but officially we are still listing JDK 14 as minimum. I don't think it's worth bumping the minimum for this.

In that case, you will need to use explicit casts here rather than the pattern-matching `instanceof`.

>> forge/src/main/java/org/openjdk/skara/forge/github/GitHubRepository.java line 591:
>> 
>>> 589:                 .put("name", label.name())
>>> 590:                 // Color is Gray and matches all current labels
>>> 591:                 .put("color", "ededed");
>> 
>> Will this overwrite the existing color scheme? For a new repo, will it always use gray for all labels?
>
> If addLabel() is called on an existing label, then I think the color scheme will be overwritten. The intention not to change any label, just to add the ones that are missing. The updateLabel method will not change the color.
> 
> Note that the labels we are adding with this patch are just the ones for mailing lists. Do you think we need to add automation for colors for the other set of labels we use (e.g. rfr, ready, csr etc)?

I think if we do add automation for colors for the other set of labels, that could be done as a follow-on fix (not sure it's needed though). I mainly wanted to make sure we wouldn't overwrite the ones for rfr, ready, etc. with gray.

-------------

PR: https://git.openjdk.java.net/skara/pull/1194

From erikj at openjdk.java.net  Wed Jul  7 15:31:10 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Wed, 7 Jul 2021 15:31:10 GMT
Subject: RFR: 1084: Automatically update repository labels from Skara
 config
In-Reply-To: <h4HulXC_dO1rraQE-9z-N8WPbXBRIV84cnqHugmKLbk=.9d8b43cb-c1a5-4ab7-a21b-34f5a2b744e5@github.com>
References: <VT8aGDtCFAadG-lLsuSbbLBUTXcxga6ZMTnFEc_v0uo=.86166749-7740-46f6-b096-cc558e449808@github.com>
 <CHXskxmXhH2JPL0pMIwciIkhwKL1Wqr14WP9NLAns8U=.7479698b-1aa4-4979-a9d7-633fb181e4b6@github.com>
 <1xZccqaosaJOwxGdjdTPTwmyj4D8g7ozFanj6scq9yw=.37f74a62-a70e-4a97-9b46-ccdf5967e021@github.com>
 <h4HulXC_dO1rraQE-9z-N8WPbXBRIV84cnqHugmKLbk=.9d8b43cb-c1a5-4ab7-a21b-34f5a2b744e5@github.com>
Message-ID: <esrA3D2OIUdOW2PXCrfrtE0lLM1Y9pD6tDX6OHsAG-U=.3f314bb3-aff7-4c46-971c-1e22829e2407@github.com>

On Wed, 7 Jul 2021 15:11:26 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> We are running the Skara bots on JDK 16, but officially we are still listing JDK 14 as minimum. I don't think it's worth bumping the minimum for this.
>
> In that case, you will need to use explicit casts here rather than the pattern-matching `instanceof`.

Doh, now I understand what you mean. I must have my intellij configured incorrectly and let it just rewrite this to pattern matching style without thinking about it. Then I was out sick for a week and forgot about it.

-------------

PR: https://git.openjdk.java.net/skara/pull/1194

From erikj at openjdk.java.net  Wed Jul  7 15:50:45 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Wed, 7 Jul 2021 15:50:45 GMT
Subject: RFR: 1084: Automatically update repository labels from Skara
 config
In-Reply-To: <esrA3D2OIUdOW2PXCrfrtE0lLM1Y9pD6tDX6OHsAG-U=.3f314bb3-aff7-4c46-971c-1e22829e2407@github.com>
References: <VT8aGDtCFAadG-lLsuSbbLBUTXcxga6ZMTnFEc_v0uo=.86166749-7740-46f6-b096-cc558e449808@github.com>
 <CHXskxmXhH2JPL0pMIwciIkhwKL1Wqr14WP9NLAns8U=.7479698b-1aa4-4979-a9d7-633fb181e4b6@github.com>
 <1xZccqaosaJOwxGdjdTPTwmyj4D8g7ozFanj6scq9yw=.37f74a62-a70e-4a97-9b46-ccdf5967e021@github.com>
 <h4HulXC_dO1rraQE-9z-N8WPbXBRIV84cnqHugmKLbk=.9d8b43cb-c1a5-4ab7-a21b-34f5a2b744e5@github.com>
 <esrA3D2OIUdOW2PXCrfrtE0lLM1Y9pD6tDX6OHsAG-U=.3f314bb3-aff7-4c46-971c-1e22829e2407@github.com>
Message-ID: <GJtMnPHOeQ_tNpKL0ZSkVkaZCISIBYFhI8grNNPH70A=.f7ca089c-b050-44f8-9f97-808e963a3ef7@github.com>

On Wed, 7 Jul 2021 15:28:42 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> In that case, you will need to use explicit casts here rather than the pattern-matching `instanceof`.
>
> Doh, now I understand what you mean. I must have my intellij configured incorrectly and let it just rewrite this to pattern matching style without thinking about it. Then I was out sick for a week and forgot about it.

I changed my settings and tried compiling with JDK 14 and discovered that we already have several JDK 15 and 16 dependencies that have crept in. Given that, I think I will just bump the required version to 16 (as a separate change). Skara has always been close to the bleeding edge anyway.

-------------

PR: https://git.openjdk.java.net/skara/pull/1194

From erikj at openjdk.java.net  Wed Jul  7 16:04:54 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Wed, 7 Jul 2021 16:04:54 GMT
Subject: RFR: 1102: Document minimum required JDK version 16 for Skara
Message-ID: <wN4E308G1KxyRa_e2hA3q0ivj5HFooYtASU1kA6hwJE=.5598a3c2-655f-4918-9368-d6c3af56ed20@github.com>

Change documentation to reflect that Skara now requires JDK 16 to build.

-------------

Commit messages:
 - SKARA-1102

Changes: https://git.openjdk.java.net/skara/pull/1195/files
 Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1195&range=00
  Issue: https://bugs.openjdk.java.net/browse/SKARA-1102
  Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.java.net/skara/pull/1195.diff
  Fetch: git fetch https://git.openjdk.java.net/skara pull/1195/head:pull/1195

PR: https://git.openjdk.java.net/skara/pull/1195

From kcr at openjdk.java.net  Wed Jul  7 17:01:06 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Wed, 7 Jul 2021 17:01:06 GMT
Subject: RFR: 1084: Automatically update repository labels from Skara
 config
In-Reply-To: <VT8aGDtCFAadG-lLsuSbbLBUTXcxga6ZMTnFEc_v0uo=.86166749-7740-46f6-b096-cc558e449808@github.com>
References: <VT8aGDtCFAadG-lLsuSbbLBUTXcxga6ZMTnFEc_v0uo=.86166749-7740-46f6-b096-cc558e449808@github.com>
Message-ID: <WxMDIicCh5p1HXvDAYhorIBnEbpbdrRdHOkCkNH4XNY=.f2722955-0697-4b5e-b0d7-91d83bfc40ef@github.com>

On Tue, 6 Jul 2021 20:56:51 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> This patch adds a new WorkItem to the MailingListBridgeBot. The new LabelsUpdaterWorkItem runs once at startup and makes sure all mailing list labels configured for the repository actually exist as labels in the hosted repository (in GitHub or GitLab). I chose to implement this as a WorkItem, even though it's just run once. It will also block any other WorkItems in the bot from running until successful. By using the existing framework for this, we get automatic retries and I believe it will play better with other bots for resource usage, even though it doesn't quite fit in.
> 
> The new WorkItem also keeps the description field updated with the mailing list email address. This use of the description field was initially added manually for the main jdk repository on GitHub, but has not been kept up to date since, and has not been propagated to other repositories (jdk16 and jdk17). These description fields are both informative for the user, as well as being used by the CLI client to present information to users.
> 
> To verify the new interaction for managing labels on a repository with both GitLab and GitHub, I have implemented a new type of manual tests. They are disabled from automatic running in Gradle using the @Disabled annotation. To run them you need to provide a properties file with data about account and keys to use to access the servers. We don't want these kinds of tests to run against GitHub/GitLab automatically, but at least now there is a way to semi automatically verify that kind of functionality.

Looks good.

-------------

Marked as reviewed by kcr (Reviewer).

PR: https://git.openjdk.java.net/skara/pull/1194

From kcr at openjdk.java.net  Wed Jul  7 17:58:27 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Wed, 7 Jul 2021 17:58:27 GMT
Subject: RFR: 1102: Document minimum required JDK version 16 for Skara
In-Reply-To: <wN4E308G1KxyRa_e2hA3q0ivj5HFooYtASU1kA6hwJE=.5598a3c2-655f-4918-9368-d6c3af56ed20@github.com>
References: <wN4E308G1KxyRa_e2hA3q0ivj5HFooYtASU1kA6hwJE=.5598a3c2-655f-4918-9368-d6c3af56ed20@github.com>
Message-ID: <051AHT92y9NFxsLmhv4-obCiYOl0Ltg9tKm2udv6_9s=.125b0255-57ff-4ffc-87b1-dc954ffddfd0@github.com>

On Wed, 7 Jul 2021 16:01:38 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> Change documentation to reflect that Skara now requires JDK 16 to build.

You might also want to change the example of `openjdk-15.0.1_osx-x64_bin/jdk-15.0.1.jdk` to `openjdk-16.0.1_osx-x64_bin/jdk-16.0.1.jdk`, but otherwise looks good.

-------------

Marked as reviewed by kcr (Reviewer).

PR: https://git.openjdk.java.net/skara/pull/1195

From kcr at openjdk.java.net  Wed Jul  7 20:13:24 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Wed, 7 Jul 2021 20:13:24 GMT
Subject: RFR: 1102: Document minimum required JDK version 16 for Skara [v2]
In-Reply-To: <UoV9P5-b7wVWr7qCvva7QFbAfGMwYsUYpiMknkEcJOA=.0a2aa277-d857-4f7c-a11d-c933e475e140@github.com>
References: <wN4E308G1KxyRa_e2hA3q0ivj5HFooYtASU1kA6hwJE=.5598a3c2-655f-4918-9368-d6c3af56ed20@github.com>
 <UoV9P5-b7wVWr7qCvva7QFbAfGMwYsUYpiMknkEcJOA=.0a2aa277-d857-4f7c-a11d-c933e475e140@github.com>
Message-ID: <Y-hx2u7vqHogWPqcAu9FYoC4yZjM2ytIoJzYA1jim48=.03866cfc-5573-4349-ad15-c4aeb839c63e@github.com>

On Wed, 7 Jul 2021 20:10:51 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Change documentation to reflect that Skara now requires JDK 16 to build.
>
> Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update example

Marked as reviewed by kcr (Reviewer).

-------------

PR: https://git.openjdk.java.net/skara/pull/1195

From erikj at openjdk.java.net  Wed Jul  7 20:13:23 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Wed, 7 Jul 2021 20:13:23 GMT
Subject: RFR: 1102: Document minimum required JDK version 16 for Skara [v2]
In-Reply-To: <wN4E308G1KxyRa_e2hA3q0ivj5HFooYtASU1kA6hwJE=.5598a3c2-655f-4918-9368-d6c3af56ed20@github.com>
References: <wN4E308G1KxyRa_e2hA3q0ivj5HFooYtASU1kA6hwJE=.5598a3c2-655f-4918-9368-d6c3af56ed20@github.com>
Message-ID: <UoV9P5-b7wVWr7qCvva7QFbAfGMwYsUYpiMknkEcJOA=.0a2aa277-d857-4f7c-a11d-c933e475e140@github.com>

> Change documentation to reflect that Skara now requires JDK 16 to build.

Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision:

  Update example

-------------

Changes:
  - all: https://git.openjdk.java.net/skara/pull/1195/files
  - new: https://git.openjdk.java.net/skara/pull/1195/files/2720256b..35fa6b8c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=skara&pr=1195&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=skara&pr=1195&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/skara/pull/1195.diff
  Fetch: git fetch https://git.openjdk.java.net/skara pull/1195/head:pull/1195

PR: https://git.openjdk.java.net/skara/pull/1195

From iris at openjdk.java.net  Wed Jul  7 20:23:14 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Wed, 7 Jul 2021 20:23:14 GMT
Subject: RFR: 1102: Document minimum required JDK version 16 for Skara [v2]
In-Reply-To: <UoV9P5-b7wVWr7qCvva7QFbAfGMwYsUYpiMknkEcJOA=.0a2aa277-d857-4f7c-a11d-c933e475e140@github.com>
References: <wN4E308G1KxyRa_e2hA3q0ivj5HFooYtASU1kA6hwJE=.5598a3c2-655f-4918-9368-d6c3af56ed20@github.com>
 <UoV9P5-b7wVWr7qCvva7QFbAfGMwYsUYpiMknkEcJOA=.0a2aa277-d857-4f7c-a11d-c933e475e140@github.com>
Message-ID: <eXQ7f7hGfXyExdUyBdWqUtXhSyQL7wCGOdjDfFtT-Vw=.8ec8aa20-7e25-41d7-a89c-e25ae8bfeded@github.com>

On Wed, 7 Jul 2021 20:13:23 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Change documentation to reflect that Skara now requires JDK 16 to build.
>
> Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update example

README.md line 49:

> 47: ## Building
> 48: 
> 49: [JDK 16](http://jdk.java.net/16/) or later and [Gradle](https://gradle.org/)

How often is the minimum JDK version for Skara updated?  If it's always the last GA'd version of the JDK, perhaps that sort of phrasing should be used instead?

-------------

PR: https://git.openjdk.java.net/skara/pull/1195

From erik.joelsson at oracle.com  Thu Jul  8 18:57:31 2021
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Thu, 8 Jul 2021 11:57:31 -0700
Subject: RFR: 1102: Document minimum required JDK version 16 for Skara [v2]
In-Reply-To: <eXQ7f7hGfXyExdUyBdWqUtXhSyQL7wCGOdjDfFtT-Vw=.8ec8aa20-7e25-41d7-a89c-e25ae8bfeded@github.com>
References: <wN4E308G1KxyRa_e2hA3q0ivj5HFooYtASU1kA6hwJE=.5598a3c2-655f-4918-9368-d6c3af56ed20@github.com>
 <UoV9P5-b7wVWr7qCvva7QFbAfGMwYsUYpiMknkEcJOA=.0a2aa277-d857-4f7c-a11d-c933e475e140@github.com>
 <eXQ7f7hGfXyExdUyBdWqUtXhSyQL7wCGOdjDfFtT-Vw=.8ec8aa20-7e25-41d7-a89c-e25ae8bfeded@github.com>
Message-ID: <951fa860-dfb9-e142-e7f7-2b575bfca155@oracle.com>


On 2021-07-07 13:23, Iris Clark wrote:
> On Wed, 7 Jul 2021 20:13:23 GMT, Erik Joelsson <erikj at openjdk.org> wrote:
>
>>> Change documentation to reflect that Skara now requires JDK 16 to build.
>> Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision:
>>
>>    Update example
> README.md line 49:
>
>> 47: ## Building
>> 48:
>> 49: [JDK 16](http://jdk.java.net/16/) or later and [Gradle](https://gradle.org/)
> How often is the minimum JDK version for Skara updated?  If it's always the last GA'd version of the JDK, perhaps that sort of phrasing should be used instead?

The JDK we use by default is updated quite frequently, but the required 
JDK version has not intentionally been kept at the latest. This has been 
caused by dependencies creeping in. We can't just blindly update either 
as we have to wait for a Gradle version that supports the new JDK 
version. I think we should keep it well defined through documentation, 
but also make the build use the release flag to force compatibility with 
the documented JDK version.

I will see if I can figure out how to change that in Gradle.

/Erik

>
> -------------
>
> PR: https://git.openjdk.java.net/skara/pull/1195

From iris.clark at oracle.com  Thu Jul  8 19:13:28 2021
From: iris.clark at oracle.com (Iris Clark)
Date: Thu, 8 Jul 2021 19:13:28 +0000
Subject: RFR: 1102: Document minimum required JDK version 16 for Skara [v2]
In-Reply-To: <951fa860-dfb9-e142-e7f7-2b575bfca155@oracle.com>
References: <wN4E308G1KxyRa_e2hA3q0ivj5HFooYtASU1kA6hwJE=.5598a3c2-655f-4918-9368-d6c3af56ed20@github.com>
 <UoV9P5-b7wVWr7qCvva7QFbAfGMwYsUYpiMknkEcJOA=.0a2aa277-d857-4f7c-a11d-c933e475e140@github.com>
 <eXQ7f7hGfXyExdUyBdWqUtXhSyQL7wCGOdjDfFtT-Vw=.8ec8aa20-7e25-41d7-a89c-e25ae8bfeded@github.com>,
 <951fa860-dfb9-e142-e7f7-2b575bfca155@oracle.com>
Message-ID: <MN2PR10MB436672462828C42C2FCA91DAFB199@MN2PR10MB4366.namprd10.prod.outlook.com>

Hi, Erik.

Thanks for the explanation.  I can't say that I'm surprised. I agree that the documentation should continue to explicitly declare the version number.  I hope you find a solution in Gradle.

Best,
Iris


________________________________
From: erik.joelsson at oracle.com <erik.joelsson at oracle.com>
Sent: Thursday, July 8, 2021 11:57 AM
To: Iris Clark <iris at openjdk.java.net>; skara-dev at openjdk.java.net <skara-dev at openjdk.java.net>
Subject: Re: RFR: 1102: Document minimum required JDK version 16 for Skara [v2]


On 2021-07-07 13:23, Iris Clark wrote:
> On Wed, 7 Jul 2021 20:13:23 GMT, Erik Joelsson <erikj at openjdk.org> wrote:
>
>>> Change documentation to reflect that Skara now requires JDK 16 to build.
>> Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision:
>>
>>    Update example
> README.md line 49:
>
>> 47: ## Building
>> 48:
>> 49: [JDK 16](http://jdk.java.net/16/) or later and [Gradle](https://gradle.org/)
> How often is the minimum JDK version for Skara updated?  If it's always the last GA'd version of the JDK, perhaps that sort of phrasing should be used instead?

The JDK we use by default is updated quite frequently, but the required
JDK version has not intentionally been kept at the latest. This has been
caused by dependencies creeping in. We can't just blindly update either
as we have to wait for a Gradle version that supports the new JDK
version. I think we should keep it well defined through documentation,
but also make the build use the release flag to force compatibility with
the documented JDK version.

I will see if I can figure out how to change that in Gradle.

/Erik

>
> -------------
>
> PR: https://git.openjdk.java.net/skara/pull/1195

From iris at openjdk.java.net  Thu Jul  8 19:14:52 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Thu, 8 Jul 2021 19:14:52 GMT
Subject: RFR: 1102: Document minimum required JDK version 16 for Skara [v2]
In-Reply-To: <eXQ7f7hGfXyExdUyBdWqUtXhSyQL7wCGOdjDfFtT-Vw=.8ec8aa20-7e25-41d7-a89c-e25ae8bfeded@github.com>
References: <wN4E308G1KxyRa_e2hA3q0ivj5HFooYtASU1kA6hwJE=.5598a3c2-655f-4918-9368-d6c3af56ed20@github.com>
 <UoV9P5-b7wVWr7qCvva7QFbAfGMwYsUYpiMknkEcJOA=.0a2aa277-d857-4f7c-a11d-c933e475e140@github.com>
 <eXQ7f7hGfXyExdUyBdWqUtXhSyQL7wCGOdjDfFtT-Vw=.8ec8aa20-7e25-41d7-a89c-e25ae8bfeded@github.com>
Message-ID: <XzqhuZfTIqfszkikF2rlmVhRFbURGEEFS0s0bk8lOqM=.b51759ef-fd99-498a-9708-8428d4e55e82@github.com>

On Wed, 7 Jul 2021 20:20:52 GMT, Iris Clark <iris at openjdk.org> wrote:

>> Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update example
>
> README.md line 49:
> 
>> 47: ## Building
>> 48: 
>> 49: [JDK 16](http://jdk.java.net/16/) or later and [Gradle](https://gradle.org/)
> 
> How often is the minimum JDK version for Skara updated?  If it's always the last GA'd version of the JDK, perhaps that sort of phrasing should be used instead?

Thanks for the explanation:  https://mail.openjdk.java.net/pipermail/skara-dev/2021-July/005097.html

I agree that the JDK version needs to remain explicit.

-------------

PR: https://git.openjdk.java.net/skara/pull/1195

From iris at openjdk.java.net  Thu Jul  8 19:14:51 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Thu, 8 Jul 2021 19:14:51 GMT
Subject: RFR: 1102: Document minimum required JDK version 16 for Skara [v2]
In-Reply-To: <UoV9P5-b7wVWr7qCvva7QFbAfGMwYsUYpiMknkEcJOA=.0a2aa277-d857-4f7c-a11d-c933e475e140@github.com>
References: <wN4E308G1KxyRa_e2hA3q0ivj5HFooYtASU1kA6hwJE=.5598a3c2-655f-4918-9368-d6c3af56ed20@github.com>
 <UoV9P5-b7wVWr7qCvva7QFbAfGMwYsUYpiMknkEcJOA=.0a2aa277-d857-4f7c-a11d-c933e475e140@github.com>
Message-ID: <nGACgct3bXi93NvbrVi92ZivvkLvWKNHHBUUA9gT03Q=.a7b5a06e-eb55-45ad-b082-0f8e0078ab18@github.com>

On Wed, 7 Jul 2021 20:13:23 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Change documentation to reflect that Skara now requires JDK 16 to build.
>
> Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update example

Marked as reviewed by iris (no project role).

-------------

PR: https://git.openjdk.java.net/skara/pull/1195

From erikj at openjdk.java.net  Thu Jul  8 19:30:52 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Thu, 8 Jul 2021 19:30:52 GMT
Subject: RFR: 1102: Document minimum required JDK version 16 for Skara [v3]
In-Reply-To: <wN4E308G1KxyRa_e2hA3q0ivj5HFooYtASU1kA6hwJE=.5598a3c2-655f-4918-9368-d6c3af56ed20@github.com>
References: <wN4E308G1KxyRa_e2hA3q0ivj5HFooYtASU1kA6hwJE=.5598a3c2-655f-4918-9368-d6c3af56ed20@github.com>
Message-ID: <1SplX_A-UVMrP9Opj8ZdZf754M2TyHna58WST5sGBXY=.8d10c113-05c5-4d35-9bff-8b405ce5e303@github.com>

> Change documentation to reflect that Skara now requires JDK 16 to build.

Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision:

  Force 'release 16' for all java compilations

-------------

Changes:
  - all: https://git.openjdk.java.net/skara/pull/1195/files
  - new: https://git.openjdk.java.net/skara/pull/1195/files/35fa6b8c..373473af

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=skara&pr=1195&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=skara&pr=1195&range=01-02

  Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/skara/pull/1195.diff
  Fetch: git fetch https://git.openjdk.java.net/skara pull/1195/head:pull/1195

PR: https://git.openjdk.java.net/skara/pull/1195

From erikj at openjdk.java.net  Thu Jul  8 19:33:29 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Thu, 8 Jul 2021 19:33:29 GMT
Subject: RFR: 1102: Document minimum required JDK version 16 for Skara [v3]
In-Reply-To: <1SplX_A-UVMrP9Opj8ZdZf754M2TyHna58WST5sGBXY=.8d10c113-05c5-4d35-9bff-8b405ce5e303@github.com>
References: <wN4E308G1KxyRa_e2hA3q0ivj5HFooYtASU1kA6hwJE=.5598a3c2-655f-4918-9368-d6c3af56ed20@github.com>
 <1SplX_A-UVMrP9Opj8ZdZf754M2TyHna58WST5sGBXY=.8d10c113-05c5-4d35-9bff-8b405ce5e303@github.com>
Message-ID: <HLQADQMLE-ImqYpcxLdC9Oj2QaC3pPC8nxCnT8aEkpY=.44d26062-a04d-43e5-aa65-32c2f059815d@github.com>

On Thu, 8 Jul 2021 19:30:52 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Change documentation to reflect that Skara now requires JDK 16 to build.
>
> Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Force 'release 16' for all java compilations

Added 'release 16' for all Java compilation in Gradle. Verified that setting it to 15 triggered the same compilation errors I saw in Intellij when setting it to 15 there.

-------------

PR: https://git.openjdk.java.net/skara/pull/1195

From kcr at openjdk.java.net  Thu Jul  8 20:07:55 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 8 Jul 2021 20:07:55 GMT
Subject: RFR: 1102: Document minimum required JDK version 16 for Skara [v3]
In-Reply-To: <1SplX_A-UVMrP9Opj8ZdZf754M2TyHna58WST5sGBXY=.8d10c113-05c5-4d35-9bff-8b405ce5e303@github.com>
References: <wN4E308G1KxyRa_e2hA3q0ivj5HFooYtASU1kA6hwJE=.5598a3c2-655f-4918-9368-d6c3af56ed20@github.com>
 <1SplX_A-UVMrP9Opj8ZdZf754M2TyHna58WST5sGBXY=.8d10c113-05c5-4d35-9bff-8b405ce5e303@github.com>
Message-ID: <6DOYQewZdIMdCSWLFGEdggClno63lnO4iNHyeZ6Fys0=.3f99e383-899a-4558-b68c-e0a7fd1ec81e@github.com>

On Thu, 8 Jul 2021 19:30:52 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Change documentation to reflect that Skara now requires JDK 16 to build.
>
> Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Force 'release 16' for all java compilations

Good idea to set `--release 16`

-------------

Marked as reviewed by kcr (Reviewer).

PR: https://git.openjdk.java.net/skara/pull/1195

From ludvig.j.janiuk at oracle.com  Fri Jul  9 12:22:20 2021
From: ludvig.j.janiuk at oracle.com (Ludvig Janiuk)
Date: Fri, 9 Jul 2021 12:22:20 +0000
Subject: GitRepository.fetch loops forever 
In-Reply-To: <BY5PR10MB3812B8CFE8F02CBB0A0D0AA4DE189@BY5PR10MB3812.namprd10.prod.outlook.com>
References: <BY5PR10MB3812B8CFE8F02CBB0A0D0AA4DE189@BY5PR10MB3812.namprd10.prod.outlook.com>
Message-ID: <BY5PR10MB38121310CDB240ED9977416FDE189@BY5PR10MB3812.namprd10.prod.outlook.com>

Discovered this while running `git skara backport --from <remote-address> <sha>` with a <remote-address> that was, by my mistake, a different repository. The behavior was that I saw a message "Fetching ..." forever. While of course I made a mistake, the skara tooling should exit when the underlying git command exits with an error, and propagate the message to the user, I think.

Best regards,
//Ludvig Janiuk

From erik.joelsson at oracle.com  Fri Jul  9 17:51:02 2021
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Fri, 9 Jul 2021 10:51:02 -0700
Subject: GitRepository.fetch loops forever
In-Reply-To: <BY5PR10MB38121310CDB240ED9977416FDE189@BY5PR10MB3812.namprd10.prod.outlook.com>
References: <BY5PR10MB3812B8CFE8F02CBB0A0D0AA4DE189@BY5PR10MB3812.namprd10.prod.outlook.com>
 <BY5PR10MB38121310CDB240ED9977416FDE189@BY5PR10MB3812.namprd10.prod.outlook.com>
Message-ID: <bd7cabbf-3146-3b48-1334-1540ed11d02b@oracle.com>

Hello Ludvig,

Please file a bug in https://bugs.openjdk.java.net/ on project SKARA.

/Erik

On 2021-07-09 05:22, Ludvig Janiuk wrote:
> Discovered this while running `git skara backport --from <remote-address> <sha>` with a <remote-address> that was, by my mistake, a different repository. The behavior was that I saw a message "Fetching ..." forever. While of course I made a mistake, the skara tooling should exit when the underlying git command exits with an error, and propagate the message to the user, I think.
>
> Best regards,
> //Ludvig Janiuk

From erikj at openjdk.java.net  Fri Jul  9 19:42:09 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Fri, 9 Jul 2021 19:42:09 GMT
Subject: Integrated: 1102: Document minimum required JDK version 16 for Skara
In-Reply-To: <wN4E308G1KxyRa_e2hA3q0ivj5HFooYtASU1kA6hwJE=.5598a3c2-655f-4918-9368-d6c3af56ed20@github.com>
References: <wN4E308G1KxyRa_e2hA3q0ivj5HFooYtASU1kA6hwJE=.5598a3c2-655f-4918-9368-d6c3af56ed20@github.com>
Message-ID: <8WciJ2-ArHEeUhZDDTBJbui-RWNgpZajiCmF_TFQ-AM=.492ae2b3-834d-44b6-81c3-7ebfacab4fe5@github.com>

On Wed, 7 Jul 2021 16:01:38 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> Change documentation to reflect that Skara now requires JDK 16 to build.

This pull request has now been integrated.

Changeset: 2ae00f87
Author:    Erik Joelsson <erikj at openjdk.org>
URL:       https://git.openjdk.java.net/skara/commit/2ae00f87b1670ce30b4b17b1f96acf6f3266c05b
Stats:     11 lines in 2 files changed: 4 ins; 0 del; 7 mod

1102: Document minimum required JDK version 16 for Skara

Reviewed-by: kcr, iris

-------------

PR: https://git.openjdk.java.net/skara/pull/1195

From erikj at openjdk.java.net  Fri Jul  9 20:47:49 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Fri, 9 Jul 2021 20:47:49 GMT
Subject: Integrated: 1084: Automatically update repository labels from Skara
 config
In-Reply-To: <VT8aGDtCFAadG-lLsuSbbLBUTXcxga6ZMTnFEc_v0uo=.86166749-7740-46f6-b096-cc558e449808@github.com>
References: <VT8aGDtCFAadG-lLsuSbbLBUTXcxga6ZMTnFEc_v0uo=.86166749-7740-46f6-b096-cc558e449808@github.com>
Message-ID: <_PHo4yyZI0LzkbdDp0M9YLC90fZtbsQvUzTbs_kY4mk=.f1d99372-f815-4784-a50f-107590bebf50@github.com>

On Tue, 6 Jul 2021 20:56:51 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> This patch adds a new WorkItem to the MailingListBridgeBot. The new LabelsUpdaterWorkItem runs once at startup and makes sure all mailing list labels configured for the repository actually exist as labels in the hosted repository (in GitHub or GitLab). I chose to implement this as a WorkItem, even though it's just run once. It will also block any other WorkItems in the bot from running until successful. By using the existing framework for this, we get automatic retries and I believe it will play better with other bots for resource usage, even though it doesn't quite fit in.
> 
> The new WorkItem also keeps the description field updated with the mailing list email address. This use of the description field was initially added manually for the main jdk repository on GitHub, but has not been kept up to date since, and has not been propagated to other repositories (jdk16 and jdk17). These description fields are both informative for the user, as well as being used by the CLI client to present information to users.
> 
> To verify the new interaction for managing labels on a repository with both GitLab and GitHub, I have implemented a new type of manual tests. They are disabled from automatic running in Gradle using the @Disabled annotation. To run them you need to provide a properties file with data about account and keys to use to access the servers. We don't want these kinds of tests to run against GitHub/GitLab automatically, but at least now there is a way to semi automatically verify that kind of functionality.

This pull request has now been integrated.

Changeset: 6c33395f
Author:    Erik Joelsson <erikj at openjdk.org>
URL:       https://git.openjdk.java.net/skara/commit/6c33395fe2f8fa8569a14b015dd2487144c59061
Stats:     427 lines in 14 files changed: 420 ins; 1 del; 6 mod

1084: Automatically update repository labels from Skara config

Reviewed-by: kcr

-------------

PR: https://git.openjdk.java.net/skara/pull/1194

From erikj at openjdk.java.net  Tue Jul 13 09:26:00 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Tue, 13 Jul 2021 09:26:00 GMT
Subject: RFR: 1108: Fix label updater for gitlab
Message-ID: <EHu0sI8ekdgACJYmknPQfMb1uPomYULiQMToYu0lHno=.4b2fde80-1052-4d00-95f4-2181385d5faf@github.com>

When deploying SKARA-1084 I discovered that gitlab doesn't accept '<' or '>' in label descriptions. The email address toString() method returns the email inside those characters. I don't think we need to store that in the description so simply switch to adding the .address() instead.

-------------

Commit messages:
 - SKARA-1108

Changes: https://git.openjdk.java.net/skara/pull/1196/files
 Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1196&range=00
  Issue: https://bugs.openjdk.java.net/browse/SKARA-1108
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/skara/pull/1196.diff
  Fetch: git fetch https://git.openjdk.java.net/skara pull/1196/head:pull/1196

PR: https://git.openjdk.java.net/skara/pull/1196

From erikj at openjdk.java.net  Tue Jul 13 09:30:47 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Tue, 13 Jul 2021 09:30:47 GMT
Subject: RFR: 1108: Fix label updater for gitlab
In-Reply-To: <EHu0sI8ekdgACJYmknPQfMb1uPomYULiQMToYu0lHno=.4b2fde80-1052-4d00-95f4-2181385d5faf@github.com>
References: <EHu0sI8ekdgACJYmknPQfMb1uPomYULiQMToYu0lHno=.4b2fde80-1052-4d00-95f4-2181385d5faf@github.com>
Message-ID: <mCuUURyo2b9zEc5sZKT8hOyEWhV2lYwcRqfwWt20tzU=.932dbe19-0e2b-49ae-bea9-6358bd15d50a@github.com>

On Tue, 13 Jul 2021 09:22:01 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> When deploying SKARA-1084 I discovered that gitlab doesn't accept '<' or '>' in label descriptions. The email address toString() method returns the email inside those characters. I don't think we need to store that in the description so simply switch to adding the .address() instead.

Also fixed a log message.

-------------

PR: https://git.openjdk.java.net/skara/pull/1196

From kcr at openjdk.java.net  Tue Jul 13 12:08:11 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Tue, 13 Jul 2021 12:08:11 GMT
Subject: RFR: 1108: Fix label updater for gitlab
In-Reply-To: <EHu0sI8ekdgACJYmknPQfMb1uPomYULiQMToYu0lHno=.4b2fde80-1052-4d00-95f4-2181385d5faf@github.com>
References: <EHu0sI8ekdgACJYmknPQfMb1uPomYULiQMToYu0lHno=.4b2fde80-1052-4d00-95f4-2181385d5faf@github.com>
Message-ID: <Qgbjl2gphuSL2E4m0_ypYbLc5yejitv6owoNL6YKxgU=.2263984e-f4cb-4f17-8642-b1d9ec1fa657@github.com>

On Tue, 13 Jul 2021 09:22:01 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> When deploying SKARA-1084 I discovered that gitlab doesn't accept '<' or '>' in label descriptions. The email address toString() method returns the email inside those characters. I don't think we need to store that in the description so simply switch to adding the .address() instead.

Marked as reviewed by kcr (Reviewer).

Looks like there are failing tests.

-------------

PR: https://git.openjdk.java.net/skara/pull/1196Changes requested by kcr (Reviewer).

From erikj at openjdk.java.net  Tue Jul 13 13:56:38 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Tue, 13 Jul 2021 13:56:38 GMT
Subject: RFR: 1108: Fix label updater for gitlab [v2]
In-Reply-To: <EHu0sI8ekdgACJYmknPQfMb1uPomYULiQMToYu0lHno=.4b2fde80-1052-4d00-95f4-2181385d5faf@github.com>
References: <EHu0sI8ekdgACJYmknPQfMb1uPomYULiQMToYu0lHno=.4b2fde80-1052-4d00-95f4-2181385d5faf@github.com>
Message-ID: <RLqfuOr6W8rJiEefWrCY238CXKlPvvyO-r7LoRZWkB4=.4b687447-e697-4fad-9df0-bf07490627e6@github.com>

> When deploying SKARA-1084 I discovered that gitlab doesn't accept '<' or '>' in label descriptions. The email address toString() method returns the email inside those characters. I don't think we need to store that in the description so simply switch to adding the .address() instead.

Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision:

  Update test

-------------

Changes:
  - all: https://git.openjdk.java.net/skara/pull/1196/files
  - new: https://git.openjdk.java.net/skara/pull/1196/files/ce5cc670..fb7c65b1

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=skara&pr=1196&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=skara&pr=1196&range=00-01

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/skara/pull/1196.diff
  Fetch: git fetch https://git.openjdk.java.net/skara pull/1196/head:pull/1196

PR: https://git.openjdk.java.net/skara/pull/1196

From erikj at openjdk.java.net  Tue Jul 13 13:59:06 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Tue, 13 Jul 2021 13:59:06 GMT
Subject: RFR: 1108: Fix label updater for gitlab [v2]
In-Reply-To: <Qgbjl2gphuSL2E4m0_ypYbLc5yejitv6owoNL6YKxgU=.2263984e-f4cb-4f17-8642-b1d9ec1fa657@github.com>
References: <EHu0sI8ekdgACJYmknPQfMb1uPomYULiQMToYu0lHno=.4b2fde80-1052-4d00-95f4-2181385d5faf@github.com>
 <Qgbjl2gphuSL2E4m0_ypYbLc5yejitv6owoNL6YKxgU=.2263984e-f4cb-4f17-8642-b1d9ec1fa657@github.com>
Message-ID: <UVhyJgRcLaiGKYPqA-Xx8q8dBVVI08ZEosvf0KPoBJo=.02190065-8f64-40a3-8294-dab7a3e61ac3@github.com>

On Tue, 13 Jul 2021 12:05:51 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Looks like there are failing tests.

There were indeed. I've now updated the tests for the change I made.

-------------

PR: https://git.openjdk.java.net/skara/pull/1196

From kcr at openjdk.java.net  Tue Jul 13 14:16:15 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Tue, 13 Jul 2021 14:16:15 GMT
Subject: RFR: 1108: Fix label updater for gitlab [v2]
In-Reply-To: <RLqfuOr6W8rJiEefWrCY238CXKlPvvyO-r7LoRZWkB4=.4b687447-e697-4fad-9df0-bf07490627e6@github.com>
References: <EHu0sI8ekdgACJYmknPQfMb1uPomYULiQMToYu0lHno=.4b2fde80-1052-4d00-95f4-2181385d5faf@github.com>
 <RLqfuOr6W8rJiEefWrCY238CXKlPvvyO-r7LoRZWkB4=.4b687447-e697-4fad-9df0-bf07490627e6@github.com>
Message-ID: <5wmy509mrSRMdbZ0L67y-9w23xG6ZpVTdn4EG_sELtY=.92c9df95-605f-426b-845f-1d83119f0d66@github.com>

On Tue, 13 Jul 2021 13:56:38 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> When deploying SKARA-1084 I discovered that gitlab doesn't accept '<' or '>' in label descriptions. The email address toString() method returns the email inside those characters. I don't think we need to store that in the description so simply switch to adding the .address() instead.
>
> Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test

Looks good.

-------------

Marked as reviewed by kcr (Reviewer).

PR: https://git.openjdk.java.net/skara/pull/1196

From erikj at openjdk.java.net  Tue Jul 13 15:11:26 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Tue, 13 Jul 2021 15:11:26 GMT
Subject: Integrated: 1108: Fix label updater for gitlab
In-Reply-To: <EHu0sI8ekdgACJYmknPQfMb1uPomYULiQMToYu0lHno=.4b2fde80-1052-4d00-95f4-2181385d5faf@github.com>
References: <EHu0sI8ekdgACJYmknPQfMb1uPomYULiQMToYu0lHno=.4b2fde80-1052-4d00-95f4-2181385d5faf@github.com>
Message-ID: <hv51c7sV4tIwY98qsHlTezIGTXFjklbIMRIEXNBUXZ0=.15c4a411-0af0-4bc1-a490-be5dc5da2496@github.com>

On Tue, 13 Jul 2021 09:22:01 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> When deploying SKARA-1084 I discovered that gitlab doesn't accept '<' or '>' in label descriptions. The email address toString() method returns the email inside those characters. I don't think we need to store that in the description so simply switch to adding the .address() instead.

This pull request has now been integrated.

Changeset: 68fc5e4b
Author:    Erik Joelsson <erikj at openjdk.org>
URL:       https://git.openjdk.java.net/skara/commit/68fc5e4b6801291258f462a572d82c59108fd33e
Stats:     6 lines in 2 files changed: 0 ins; 0 del; 6 mod

1108: Fix label updater for gitlab

Reviewed-by: kcr

-------------

PR: https://git.openjdk.java.net/skara/pull/1196

From erikj at openjdk.java.net  Wed Jul 14 10:18:41 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Wed, 14 Jul 2021 10:18:41 GMT
Subject: RFR: 1101: git webrev for mercurial should ignore config defaults for
 mercurial commands
Message-ID: <SNZ-CixTQoHKsdQQxMUdcYKk09XYCgySd5ArCjyjGW4=.f6236faf-1812-4959-9e29-83e9b409e6e9@github.com>

This patch adds --config defaults.log= to the mercurial command used to resolve a revset to a hash. Since this is a very particular use of the log command, we need to be in full control of all options passed to it.

There are likely several other situations like this that should be fixed, but I would rather not spend the time right now trying to implement a general overhaul for handling all of them.

-------------

Commit messages:
 - SKARA-1101

Changes: https://git.openjdk.java.net/skara/pull/1197/files
 Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1197&range=00
  Issue: https://bugs.openjdk.java.net/browse/SKARA-1101
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/skara/pull/1197.diff
  Fetch: git fetch https://git.openjdk.java.net/skara pull/1197/head:pull/1197

PR: https://git.openjdk.java.net/skara/pull/1197

From kcr at openjdk.java.net  Wed Jul 14 11:59:07 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Wed, 14 Jul 2021 11:59:07 GMT
Subject: RFR: 1101: git webrev for mercurial should ignore config defaults
 for mercurial commands
In-Reply-To: <SNZ-CixTQoHKsdQQxMUdcYKk09XYCgySd5ArCjyjGW4=.f6236faf-1812-4959-9e29-83e9b409e6e9@github.com>
References: <SNZ-CixTQoHKsdQQxMUdcYKk09XYCgySd5ArCjyjGW4=.f6236faf-1812-4959-9e29-83e9b409e6e9@github.com>
Message-ID: <ePQKZM6-Foj_8RMsZWbx9tPmmSXp6zbO0MFO_Ogg8gg=.d6c187da-83ee-437a-a46c-d4985eb599ce@github.com>

On Wed, 14 Jul 2021 10:15:08 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> This patch adds --config defaults.log= to the mercurial command used to resolve a revset to a hash. Since this is a very particular use of the log command, we need to be in full control of all options passed to it.
> 
> There are likely several other situations like this that should be fixed, but I would rather not spend the time right now trying to implement a general overhaul for handling all of them.

Marked as reviewed by kcr (Reviewer).

-------------

PR: https://git.openjdk.java.net/skara/pull/1197

From erikj at openjdk.java.net  Wed Jul 14 13:35:49 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Wed, 14 Jul 2021 13:35:49 GMT
Subject: RFR: 1026: Skara bot doesn't update Progress checklist for clean
 backports to show that it is properly reviewed
Message-ID: <ckMfgx1spxCC9S514VYjFzws8ZounlLh3GFu92nfZuk=.28f7c354-bcef-46b7-8b86-1153e3a377ac@github.com>

When a backport is considered clean, no review is required. This should be reflected in the progress list in the PR body. This patch simply removes the "Change must be properly reviewed" line in that case.

-------------

Commit messages:
 - Add check in test for non clean backport
 - SKARA-1026

Changes: https://git.openjdk.java.net/skara/pull/1198/files
 Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1198&range=00
  Issue: https://bugs.openjdk.java.net/browse/SKARA-1026
  Stats: 21 lines in 4 files changed: 13 ins; 0 del; 8 mod
  Patch: https://git.openjdk.java.net/skara/pull/1198.diff
  Fetch: git fetch https://git.openjdk.java.net/skara pull/1198/head:pull/1198

PR: https://git.openjdk.java.net/skara/pull/1198

From kcr at openjdk.java.net  Wed Jul 14 13:52:11 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Wed, 14 Jul 2021 13:52:11 GMT
Subject: RFR: 1026: Skara bot doesn't update Progress checklist for clean
 backports to show that it is properly reviewed
In-Reply-To: <ckMfgx1spxCC9S514VYjFzws8ZounlLh3GFu92nfZuk=.28f7c354-bcef-46b7-8b86-1153e3a377ac@github.com>
References: <ckMfgx1spxCC9S514VYjFzws8ZounlLh3GFu92nfZuk=.28f7c354-bcef-46b7-8b86-1153e3a377ac@github.com>
Message-ID: <yYMuIxzrwMSgsAlBpJ7fltqnMzBmHeFI5c9ggcM22UM=.bb62fdcc-166e-40fc-8fcd-f6b9f9a84956@github.com>

On Wed, 14 Jul 2021 13:32:10 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> When a backport is considered clean, no review is required. This should be reflected in the progress list in the PR body. This patch simply removes the "Change must be properly reviewed" line in that case.

Looks good. I left one minor comment on the name of the new method.

bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckRun.java line 344:

> 342: 
> 343:     private String getChecksList(PullRequestCheckIssueVisitor visitor, boolean isCleanBackport) {
> 344:         var checks = isCleanBackport ? visitor.getReadyForReviewChecks() : visitor.getChecks();

I find the name of the new method a little confusing. A clean backport is ready for integration not for review. Maybe just `getReadyChecks` or `getChecksClean`? I'll leave it up to you.

-------------

Marked as reviewed by kcr (Reviewer).

PR: https://git.openjdk.java.net/skara/pull/1198

From erikj at openjdk.java.net  Wed Jul 14 15:13:17 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Wed, 14 Jul 2021 15:13:17 GMT
Subject: RFR: 1026: Skara bot doesn't update Progress checklist for clean
 backports to show that it is properly reviewed [v2]
In-Reply-To: <ckMfgx1spxCC9S514VYjFzws8ZounlLh3GFu92nfZuk=.28f7c354-bcef-46b7-8b86-1153e3a377ac@github.com>
References: <ckMfgx1spxCC9S514VYjFzws8ZounlLh3GFu92nfZuk=.28f7c354-bcef-46b7-8b86-1153e3a377ac@github.com>
Message-ID: <WJlOKxzR3VhbW33qxiCecZWldwsw_uFYBPpPA0eRBng=.dd931cae-56d3-4dfe-b06a-ee1c53cc2545@github.com>

> When a backport is considered clean, no review is required. This should be reflected in the progress list in the PR body. This patch simply removes the "Change must be properly reviewed" line in that case.

Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision:

  Add comments

-------------

Changes:
  - all: https://git.openjdk.java.net/skara/pull/1198/files
  - new: https://git.openjdk.java.net/skara/pull/1198/files/24cfb888..9c266f63

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=skara&pr=1198&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=skara&pr=1198&range=00-01

  Stats: 7 lines in 1 file changed: 7 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/skara/pull/1198.diff
  Fetch: git fetch https://git.openjdk.java.net/skara pull/1198/head:pull/1198

PR: https://git.openjdk.java.net/skara/pull/1198

From erikj at openjdk.java.net  Wed Jul 14 15:13:18 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Wed, 14 Jul 2021 15:13:18 GMT
Subject: RFR: 1026: Skara bot doesn't update Progress checklist for clean
 backports to show that it is properly reviewed [v2]
In-Reply-To: <yYMuIxzrwMSgsAlBpJ7fltqnMzBmHeFI5c9ggcM22UM=.bb62fdcc-166e-40fc-8fcd-f6b9f9a84956@github.com>
References: <ckMfgx1spxCC9S514VYjFzws8ZounlLh3GFu92nfZuk=.28f7c354-bcef-46b7-8b86-1153e3a377ac@github.com>
 <yYMuIxzrwMSgsAlBpJ7fltqnMzBmHeFI5c9ggcM22UM=.bb62fdcc-166e-40fc-8fcd-f6b9f9a84956@github.com>
Message-ID: <eYGU6SOf4X488lKUd3UdyycfQkd57aAgkyumGX7YRGg=.7e0d471d-6dfb-4671-87fd-02f53fc8a4e2@github.com>

On Wed, 14 Jul 2021 13:48:07 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add comments
>
> bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckRun.java line 344:
> 
>> 342: 
>> 343:     private String getChecksList(PullRequestCheckIssueVisitor visitor, boolean isCleanBackport) {
>> 344:         var checks = isCleanBackport ? visitor.getReadyForReviewChecks() : visitor.getChecks();
> 
> I find the name of the new method a little confusing. A clean backport is ready for integration not for review. Maybe just `getReadyChecks` or `getChecksClean`? I'll leave it up to you.

I understand the confusion. I chose the name to fit in with the current model and naming. When CheckRun evaluates if a cleanBackport PR is ready for integration, it calls PullRequestCheckIssueVisitor.isReadyForReview() (instead of .messages().isEmpty()). So the state we are checking for in the visitor is already named "readyForReview". The new method builds on that and returns the checks that were used to decide if it was readyForReview.

-------------

PR: https://git.openjdk.java.net/skara/pull/1198

From erikj at openjdk.java.net  Wed Jul 14 15:13:19 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Wed, 14 Jul 2021 15:13:19 GMT
Subject: RFR: 1026: Skara bot doesn't update Progress checklist for clean
 backports to show that it is properly reviewed [v2]
In-Reply-To: <eYGU6SOf4X488lKUd3UdyycfQkd57aAgkyumGX7YRGg=.7e0d471d-6dfb-4671-87fd-02f53fc8a4e2@github.com>
References: <ckMfgx1spxCC9S514VYjFzws8ZounlLh3GFu92nfZuk=.28f7c354-bcef-46b7-8b86-1153e3a377ac@github.com>
 <yYMuIxzrwMSgsAlBpJ7fltqnMzBmHeFI5c9ggcM22UM=.bb62fdcc-166e-40fc-8fcd-f6b9f9a84956@github.com>
 <eYGU6SOf4X488lKUd3UdyycfQkd57aAgkyumGX7YRGg=.7e0d471d-6dfb-4671-87fd-02f53fc8a4e2@github.com>
Message-ID: <1ABEV3tmZfFOvlLYJKXwHG51nJyX40xvKMVv-DzevGo=.ba7f1512-863d-46ed-a2c6-3acb48f88b32@github.com>

On Wed, 14 Jul 2021 15:09:25 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckRun.java line 344:
>> 
>>> 342: 
>>> 343:     private String getChecksList(PullRequestCheckIssueVisitor visitor, boolean isCleanBackport) {
>>> 344:         var checks = isCleanBackport ? visitor.getReadyForReviewChecks() : visitor.getChecks();
>> 
>> I find the name of the new method a little confusing. A clean backport is ready for integration not for review. Maybe just `getReadyChecks` or `getChecksClean`? I'll leave it up to you.
>
> I understand the confusion. I chose the name to fit in with the current model and naming. When CheckRun evaluates if a cleanBackport PR is ready for integration, it calls PullRequestCheckIssueVisitor.isReadyForReview() (instead of .messages().isEmpty()). So the state we are checking for in the visitor is already named "readyForReview". The new method builds on that and returns the checks that were used to decide if it was readyForReview.

I should add that the CheckRun knows about clean backports, while the visitor does not, it just evaluates Jcheck checks and reports on the outcome.

-------------

PR: https://git.openjdk.java.net/skara/pull/1198

From kcr at openjdk.java.net  Wed Jul 14 15:22:11 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Wed, 14 Jul 2021 15:22:11 GMT
Subject: RFR: 1026: Skara bot doesn't update Progress checklist for clean
 backports to show that it is properly reviewed [v2]
In-Reply-To: <WJlOKxzR3VhbW33qxiCecZWldwsw_uFYBPpPA0eRBng=.dd931cae-56d3-4dfe-b06a-ee1c53cc2545@github.com>
References: <ckMfgx1spxCC9S514VYjFzws8ZounlLh3GFu92nfZuk=.28f7c354-bcef-46b7-8b86-1153e3a377ac@github.com>
 <WJlOKxzR3VhbW33qxiCecZWldwsw_uFYBPpPA0eRBng=.dd931cae-56d3-4dfe-b06a-ee1c53cc2545@github.com>
Message-ID: <Cg-WgH9_Bf67lTsgctAqiKeRFXOhzDUgHhoO7FsW0Cc=.3c5a70e0-b510-42fa-8c87-4be24fdc8b93@github.com>

On Wed, 14 Jul 2021 15:13:17 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> When a backport is considered clean, no review is required. This should be reflected in the progress list in the PR body. This patch simply removes the "Change must be properly reviewed" line in that case.
>
> Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comments

Marked as reviewed by kcr (Reviewer).

-------------

PR: https://git.openjdk.java.net/skara/pull/1198

From kcr at openjdk.java.net  Wed Jul 14 15:22:12 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Wed, 14 Jul 2021 15:22:12 GMT
Subject: RFR: 1026: Skara bot doesn't update Progress checklist for clean
 backports to show that it is properly reviewed [v2]
In-Reply-To: <1ABEV3tmZfFOvlLYJKXwHG51nJyX40xvKMVv-DzevGo=.ba7f1512-863d-46ed-a2c6-3acb48f88b32@github.com>
References: <ckMfgx1spxCC9S514VYjFzws8ZounlLh3GFu92nfZuk=.28f7c354-bcef-46b7-8b86-1153e3a377ac@github.com>
 <yYMuIxzrwMSgsAlBpJ7fltqnMzBmHeFI5c9ggcM22UM=.bb62fdcc-166e-40fc-8fcd-f6b9f9a84956@github.com>
 <eYGU6SOf4X488lKUd3UdyycfQkd57aAgkyumGX7YRGg=.7e0d471d-6dfb-4671-87fd-02f53fc8a4e2@github.com>
 <1ABEV3tmZfFOvlLYJKXwHG51nJyX40xvKMVv-DzevGo=.ba7f1512-863d-46ed-a2c6-3acb48f88b32@github.com>
Message-ID: <bwN-qd19Af9UUQqmI9QjjXiU1i5ZpiD9mSxhLoMiqQE=.a3b98c90-d075-4e0e-b73f-4e4ee15bdaaf@github.com>

On Wed, 14 Jul 2021 15:10:20 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> I understand the confusion. I chose the name to fit in with the current model and naming. When CheckRun evaluates if a cleanBackport PR is ready for integration, it calls PullRequestCheckIssueVisitor.isReadyForReview() (instead of .messages().isEmpty()). So the state we are checking for in the visitor is already named "readyForReview". The new method builds on that and returns the checks that were used to decide if it was readyForReview.
>
> I should add that the CheckRun knows about clean backports, while the visitor does not, it just evaluates Jcheck checks and reports on the outcome.

OK, thanks for the explanation.

-------------

PR: https://git.openjdk.java.net/skara/pull/1198

From erikj at openjdk.java.net  Thu Jul 15 07:14:48 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Thu, 15 Jul 2021 07:14:48 GMT
Subject: Integrated: 1101: git webrev for mercurial should ignore config
 defaults for mercurial commands
In-Reply-To: <SNZ-CixTQoHKsdQQxMUdcYKk09XYCgySd5ArCjyjGW4=.f6236faf-1812-4959-9e29-83e9b409e6e9@github.com>
References: <SNZ-CixTQoHKsdQQxMUdcYKk09XYCgySd5ArCjyjGW4=.f6236faf-1812-4959-9e29-83e9b409e6e9@github.com>
Message-ID: <tXgblpCvy6tCL6h8gAKApLoOc4L0nZpBeBEUUWbW2rU=.98e70633-194a-4763-aaca-721c158dfbd7@github.com>

On Wed, 14 Jul 2021 10:15:08 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> This patch adds --config defaults.log= to the mercurial command used to resolve a revset to a hash. Since this is a very particular use of the log command, we need to be in full control of all options passed to it.
> 
> There are likely several other situations like this that should be fixed, but I would rather not spend the time right now trying to implement a general overhaul for handling all of them.

This pull request has now been integrated.

Changeset: 36fdc9bd
Author:    Erik Joelsson <erikj at openjdk.org>
URL:       https://git.openjdk.java.net/skara/commit/36fdc9bdda4d020254fe371ee03bd6a2425e0a50
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

1101: git webrev for mercurial should ignore config defaults for mercurial commands

Reviewed-by: kcr

-------------

PR: https://git.openjdk.java.net/skara/pull/1197

From erikj at openjdk.java.net  Thu Jul 15 07:15:52 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Thu, 15 Jul 2021 07:15:52 GMT
Subject: Integrated: 1026: Skara bot doesn't update Progress checklist for
 clean backports to show that it is properly reviewed
In-Reply-To: <ckMfgx1spxCC9S514VYjFzws8ZounlLh3GFu92nfZuk=.28f7c354-bcef-46b7-8b86-1153e3a377ac@github.com>
References: <ckMfgx1spxCC9S514VYjFzws8ZounlLh3GFu92nfZuk=.28f7c354-bcef-46b7-8b86-1153e3a377ac@github.com>
Message-ID: <nABn9XLMHRw2Sa7FZzjSyxIdXYNn1QybCxjeUsmptu4=.66678327-51c0-4bc4-9aa8-5b807beb9c73@github.com>

On Wed, 14 Jul 2021 13:32:10 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> When a backport is considered clean, no review is required. This should be reflected in the progress list in the PR body. This patch simply removes the "Change must be properly reviewed" line in that case.

This pull request has now been integrated.

Changeset: be4ddfd1
Author:    Erik Joelsson <erikj at openjdk.org>
URL:       https://git.openjdk.java.net/skara/commit/be4ddfd1d44c2ebf3ce2f910e602a949097ba79c
Stats:     28 lines in 4 files changed: 20 ins; 0 del; 8 mod

1026: Skara bot doesn't update Progress checklist for clean backports to show that it is properly reviewed

Reviewed-by: kcr

-------------

PR: https://git.openjdk.java.net/skara/pull/1198

From erikj at openjdk.java.net  Thu Jul 15 08:15:28 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Thu, 15 Jul 2021 08:15:28 GMT
Subject: RFR: 1040: Crash in webrev command
Message-ID: <wNuPRV0XVWdNvq1CH9pCKXWMThkFO3Wz2e_cWFJL3AA=.7e2e0955-7ca7-48aa-bf60-fd4c5d61476c@github.com>

Validate the file input to GitWebrev.

-------------

Commit messages:
 - SKARA-1040

Changes: https://git.openjdk.java.net/skara/pull/1199/files
 Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1199&range=00
  Issue: https://bugs.openjdk.java.net/browse/SKARA-1040
  Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/skara/pull/1199.diff
  Fetch: git fetch https://git.openjdk.java.net/skara pull/1199/head:pull/1199

PR: https://git.openjdk.java.net/skara/pull/1199

From erikj at openjdk.java.net  Thu Jul 15 09:17:30 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Thu, 15 Jul 2021 09:17:30 GMT
Subject: RFR: 1050: Gitlab MR stuck on missing issue when unbreakable space in
 PR title
Message-ID: <3JFJZ2U7B7EiSXl0zZEz5Q501WeAcX9sSVpMB8iMWro=.27e7f4ba-1c18-4d28-b0ef-19e237a8c2c0@github.com>

This patch makes the PR title parser able to handle non-breakable space between the bug ID and the bug title. If a user manages to get one of those in there, we currently end up in a limbo state that is very tricky to diagnose.

-------------

Commit messages:
 - SKARA-1050

Changes: https://git.openjdk.java.net/skara/pull/1200/files
 Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1200&range=00
  Issue: https://bugs.openjdk.java.net/browse/SKARA-1050
  Stats: 50 lines in 2 files changed: 49 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/skara/pull/1200.diff
  Fetch: git fetch https://git.openjdk.java.net/skara pull/1200/head:pull/1200

PR: https://git.openjdk.java.net/skara/pull/1200

From erikj at openjdk.java.net  Thu Jul 15 11:18:49 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Thu, 15 Jul 2021 11:18:49 GMT
Subject: RFR: 1091: "PR body must not be empty" check pointless for clean
 backports
Message-ID: <bfUd-pCm1w9HF61NnqGatXCB2oOgBcrngkuSA849x4k=.bb0a14c5-4f95-458a-955b-c471b6254bb6@github.com>

This patch removes the requirement to write something in the PR body for clean backports. Most of the time there really is nothing to add in that case.

-------------

Commit messages:
 - SKARA-1091

Changes: https://git.openjdk.java.net/skara/pull/1201/files
 Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1201&range=00
  Issue: https://bugs.openjdk.java.net/browse/SKARA-1091
  Stats: 23 lines in 3 files changed: 9 ins; 6 del; 8 mod
  Patch: https://git.openjdk.java.net/skara/pull/1201.diff
  Fetch: git fetch https://git.openjdk.java.net/skara pull/1201/head:pull/1201

PR: https://git.openjdk.java.net/skara/pull/1201

From kcr at openjdk.java.net  Thu Jul 15 11:58:26 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 15 Jul 2021 11:58:26 GMT
Subject: RFR: 1091: "PR body must not be empty" check pointless for clean
 backports
In-Reply-To: <bfUd-pCm1w9HF61NnqGatXCB2oOgBcrngkuSA849x4k=.bb0a14c5-4f95-458a-955b-c471b6254bb6@github.com>
References: <bfUd-pCm1w9HF61NnqGatXCB2oOgBcrngkuSA849x4k=.bb0a14c5-4f95-458a-955b-c471b6254bb6@github.com>
Message-ID: <s5eQt-DsWeQWNT4P4mFfjZa1VBqSZOF4ru2OVtgFl8A=.e9899971-878a-48e6-8bed-5722eca51fef@github.com>

On Thu, 15 Jul 2021 11:15:35 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> This patch removes the requirement to write something in the PR body for clean backports. Most of the time there really is nothing to add in that case.

Looks good. I left one question inline, but presume the answer is "no problem".

bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckRun.java line 892:

> 890:             var isCleanBackport = false;
> 891:             if (original.isPresent()) {
> 892:                 isCleanBackport = updateClean(original.get());

This looks fine as long as there is no problem calling `backportedFrom()` and `updateClean()` earlier than was done previously.

-------------

Marked as reviewed by kcr (Reviewer).

PR: https://git.openjdk.java.net/skara/pull/1201

From kcr at openjdk.java.net  Thu Jul 15 12:08:03 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 15 Jul 2021 12:08:03 GMT
Subject: RFR: 1050: Gitlab MR stuck on missing issue when unbreakable
 space in PR title
In-Reply-To: <3JFJZ2U7B7EiSXl0zZEz5Q501WeAcX9sSVpMB8iMWro=.27e7f4ba-1c18-4d28-b0ef-19e237a8c2c0@github.com>
References: <3JFJZ2U7B7EiSXl0zZEz5Q501WeAcX9sSVpMB8iMWro=.27e7f4ba-1c18-4d28-b0ef-19e237a8c2c0@github.com>
Message-ID: <octug0M99PjQkAQEZ9r7Eqs_-XY9vzrF6vnbBA6JfUE=.0aadf811-0d7f-4a08-bf68-e1f80ae72b22@github.com>

On Thu, 15 Jul 2021 09:14:05 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> This patch makes the PR title parser able to handle non-breakable space between the bug ID and the bug title. If a user manages to get one of those in there, we currently end up in a limbo state that is very tricky to diagnose.

Marked as reviewed by kcr (Reviewer).

-------------

PR: https://git.openjdk.java.net/skara/pull/1200

From erikj at openjdk.java.net  Thu Jul 15 12:11:31 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Thu, 15 Jul 2021 12:11:31 GMT
Subject: RFR: 1091: "PR body must not be empty" check pointless for clean
 backports
In-Reply-To: <s5eQt-DsWeQWNT4P4mFfjZa1VBqSZOF4ru2OVtgFl8A=.e9899971-878a-48e6-8bed-5722eca51fef@github.com>
References: <bfUd-pCm1w9HF61NnqGatXCB2oOgBcrngkuSA849x4k=.bb0a14c5-4f95-458a-955b-c471b6254bb6@github.com>
 <s5eQt-DsWeQWNT4P4mFfjZa1VBqSZOF4ru2OVtgFl8A=.e9899971-878a-48e6-8bed-5722eca51fef@github.com>
Message-ID: <DlMbt2kUrhuQctAqZGOMaxwYXwZ_q-Hb9GcFd20rymU=.c79c00a5-b745-455c-9a2f-3f03eba92713@github.com>

On Thu, 15 Jul 2021 11:54:39 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> This patch removes the requirement to write something in the PR body for clean backports. Most of the time there really is nothing to add in that case.
>
> bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckRun.java line 892:
> 
>> 890:             var isCleanBackport = false;
>> 891:             if (original.isPresent()) {
>> 892:                 isCleanBackport = updateClean(original.get());
> 
> This looks fine as long as there is no problem calling `backportedFrom()` and `updateClean()` earlier than was done previously.

Indeed. I have checked this as well as I can and the tests are passing. I can't see any issue with running it earlier.

-------------

PR: https://git.openjdk.java.net/skara/pull/1201

From kcr at openjdk.java.net  Thu Jul 15 12:12:18 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 15 Jul 2021 12:12:18 GMT
Subject: RFR: 1040: Crash in webrev command
In-Reply-To: <wNuPRV0XVWdNvq1CH9pCKXWMThkFO3Wz2e_cWFJL3AA=.7e2e0955-7ca7-48aa-bf60-fd4c5d61476c@github.com>
References: <wNuPRV0XVWdNvq1CH9pCKXWMThkFO3Wz2e_cWFJL3AA=.7e2e0955-7ca7-48aa-bf60-fd4c5d61476c@github.com>
Message-ID: <vngbp9NiM2ZcNK7_hsZaCsbjPQmLaARIf38_XbcXLts=.1d8dd3aa-ad0d-425d-8af4-e105e83fbc95@github.com>

On Thu, 15 Jul 2021 08:11:48 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> Validate the file input to GitWebrev.

Marked as reviewed by kcr (Reviewer).

-------------

PR: https://git.openjdk.java.net/skara/pull/1199

From erikj at openjdk.java.net  Thu Jul 15 13:34:14 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Thu, 15 Jul 2021 13:34:14 GMT
Subject: RFR: 1058: The mlbridge bot occasionally posts the same comments
 twice on Github
Message-ID: <9gkRV01Z4dH9VmhhEV1ks6kOqkTTIz5-V6I8I0S0owg=.d9e8a4a1-d390-488b-a9a2-a0ff002d722b@github.com>

This patch (hopefully) fixes an issue where sometimes the mlbridge bot would post the same email as comment twice in a PR. This happens because two instances of the CommentPosterWorkItem are running at the same time for the same PullRequest.

This is supposed to be protected by the method "concurrentWith(WorkItem other)". In this particular case, the check is faulty. It checks if the PullRequest object in this WorkItem is equal to the object in the other WorkItem. This is default Object equality, and there is definitely no guarantee that they both contain the exact same object.

Looking around in other implementations of this method, there is mix of how stringent the checks are, some only check if the PullRequest.id() field is the same, but most also check something about the HostedRepository to which the PR belongs (either name or url). I think calculating the url seems a bit expensive for an equals check.

I propose a new method on the PullRequest interface: "isSame(PullRequest other)". This isn't trying to be an equals, as that's a bit hard to define (and I don't want to get into implementing hashCode at this time), but will just return true if both PullRequest instances are logically referring to the same hosted pull request. I have replaced all uses of PullRequest.equals() and PullRequest.id().equals() with this new method for consistency.

-------------

Commit messages:
 - SKARA-1058

Changes: https://git.openjdk.java.net/skara/pull/1202/files
 Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1202&range=00
  Issue: https://bugs.openjdk.java.net/browse/SKARA-1058
  Stats: 38 lines in 10 files changed: 9 ins; 18 del; 11 mod
  Patch: https://git.openjdk.java.net/skara/pull/1202.diff
  Fetch: git fetch https://git.openjdk.java.net/skara pull/1202/head:pull/1202

PR: https://git.openjdk.java.net/skara/pull/1202

From kcr at openjdk.java.net  Thu Jul 15 13:54:00 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 15 Jul 2021 13:54:00 GMT
Subject: RFR: 1058: The mlbridge bot occasionally posts the same comments
 twice on Github
In-Reply-To: <9gkRV01Z4dH9VmhhEV1ks6kOqkTTIz5-V6I8I0S0owg=.d9e8a4a1-d390-488b-a9a2-a0ff002d722b@github.com>
References: <9gkRV01Z4dH9VmhhEV1ks6kOqkTTIz5-V6I8I0S0owg=.d9e8a4a1-d390-488b-a9a2-a0ff002d722b@github.com>
Message-ID: <QX3voD8zpHET6Gvl-xkzPZoS8TIuBL2oir-ybMZ_0q8=.c3c2179f-bbf2-4d8b-ad01-664503defc61@github.com>

On Thu, 15 Jul 2021 13:30:57 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> This patch (hopefully) fixes an issue where sometimes the mlbridge bot would post the same email as comment twice in a PR. This happens because two instances of the CommentPosterWorkItem are running at the same time for the same PullRequest.
> 
> This is supposed to be protected by the method "concurrentWith(WorkItem other)". In this particular case, the check is faulty. It checks if the PullRequest object in this WorkItem is equal to the object in the other WorkItem. This is default Object equality, and there is definitely no guarantee that they both contain the exact same object.
> 
> Looking around in other implementations of this method, there is mix of how stringent the checks are, some only check if the PullRequest.id() field is the same, but most also check something about the HostedRepository to which the PR belongs (either name or url). I think calculating the url seems a bit expensive for an equals check.
> 
> I propose a new method on the PullRequest interface: "isSame(PullRequest other)". This isn't trying to be an equals, as that's a bit hard to define (and I don't want to get into implementing hashCode at this time), but will just return true if both PullRequest instances are logically referring to the same hosted pull request. I have replaced all uses of PullRequest.equals() and PullRequest.id().equals() with this new method for consistency.

Looks good.

-------------

Marked as reviewed by kcr (Reviewer).

PR: https://git.openjdk.java.net/skara/pull/1202

From erikj at openjdk.java.net  Thu Jul 15 16:44:54 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Thu, 15 Jul 2021 16:44:54 GMT
Subject: RFR: 1068: [Backport] Bot finds original commit in wrong repository
Message-ID: <n7JmEFP2a4rcrdXziGioH_CiS0Y_3VnKtQkkwHqIE-8=.feecf815-4bb7-422f-be71-0c7e199b7440@github.com>

When the PR bot searches for the original commit for a backport it's more or less random from which repository it will be found. Whatever it finds is posted as a link in a PR comment, and if it points to something weird, that can be confusing (though not strictly incorrect as the change will be the exact same regardless of which repo it is in).

The search feature already has what looks to be a configurable way to limit searching to a set of organizations. Unfortunately, that feature was never used and is currently broken for Github (for Gitlab it's already in use as it's required for the search method we use). Because of this, we usually pick a match from adoptium or SAP today. This patch fixes this for Github (where the query separator is space, not '+'), and I intend to limit the organizations to "openjdk" when deploying this fix.

In addition to this, it would be nice if the exact repo that gets picked is the "correct" one. Unfortunately, there is no really good definition of what the correct repo would be in all cases, and it would be even trickier to implement this in a good way. As an approximate workaround, I've added sorting on repository name length, so we always pick the repo with the shortest name. I believe this will at least give us a better answer than "random" in most cases for a relatively modest cost in performance.

I have experimented with this patch in staging with the playground repo and the behavior I've seen so far is good.

-------------

Commit messages:
 - Also sort for gitlab
 - Prioritize repo with shortest name in hash search result
 - Remove + from github query string

Changes: https://git.openjdk.java.net/skara/pull/1203/files
 Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1203&range=00
  Issue: https://bugs.openjdk.java.net/browse/SKARA-1068
  Stats: 15 lines in 2 files changed: 10 ins; 0 del; 5 mod
  Patch: https://git.openjdk.java.net/skara/pull/1203.diff
  Fetch: git fetch https://git.openjdk.java.net/skara pull/1203/head:pull/1203

PR: https://git.openjdk.java.net/skara/pull/1203

From kcr at openjdk.java.net  Thu Jul 15 17:52:09 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 15 Jul 2021 17:52:09 GMT
Subject: RFR: 1068: [Backport] Bot finds original commit in wrong
 repository
In-Reply-To: <n7JmEFP2a4rcrdXziGioH_CiS0Y_3VnKtQkkwHqIE-8=.feecf815-4bb7-422f-be71-0c7e199b7440@github.com>
References: <n7JmEFP2a4rcrdXziGioH_CiS0Y_3VnKtQkkwHqIE-8=.feecf815-4bb7-422f-be71-0c7e199b7440@github.com>
Message-ID: <m0ir6Q7ufWzeuyvQpkyWm6MJcC24wZ3LwE7jkm7BV3M=.be03e72d-f128-4f79-a1fd-4be358c69d4e@github.com>

On Thu, 15 Jul 2021 16:41:35 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> When the PR bot searches for the original commit for a backport it's more or less random from which repository it will be found. Whatever it finds is posted as a link in a PR comment, and if it points to something weird, that can be confusing (though not strictly incorrect as the change will be the exact same regardless of which repo it is in).
> 
> The search feature already has what looks to be a configurable way to limit searching to a set of organizations. Unfortunately, that feature was never used and is currently broken for Github (for Gitlab it's already in use as it's required for the search method we use). Because of this, we usually pick a match from adoptium or SAP today. This patch fixes this for Github (where the query separator is space, not '+'), and I intend to limit the organizations to "openjdk" when deploying this fix.
> 
> In addition to this, it would be nice if the exact repo that gets picked is the "correct" one. Unfortunately, there is no really good definition of what the correct repo would be in all cases, and it would be even trickier to implement this in a good way. As an approximate workaround, I've added sorting on repository name length, so we always pick the repo with the shortest name. I believe this will at least give us a better answer than "random" in most cases for a relatively modest cost in performance.
> 
> I have experimented with this patch in staging with the playground repo and the behavior I've seen so far is good.

It looks good. I presume you have tested it? Especially since there aren't any new unit tests added.

-------------

Marked as reviewed by kcr (Reviewer).

PR: https://git.openjdk.java.net/skara/pull/1203

From erikj at openjdk.java.net  Fri Jul 16 06:31:23 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Fri, 16 Jul 2021 06:31:23 GMT
Subject: RFR: 1068: [Backport] Bot finds original commit in wrong
 repository
In-Reply-To: <m0ir6Q7ufWzeuyvQpkyWm6MJcC24wZ3LwE7jkm7BV3M=.be03e72d-f128-4f79-a1fd-4be358c69d4e@github.com>
References: <n7JmEFP2a4rcrdXziGioH_CiS0Y_3VnKtQkkwHqIE-8=.feecf815-4bb7-422f-be71-0c7e199b7440@github.com>
 <m0ir6Q7ufWzeuyvQpkyWm6MJcC24wZ3LwE7jkm7BV3M=.be03e72d-f128-4f79-a1fd-4be358c69d4e@github.com>
Message-ID: <F2DLu9nTgyBJXSdnn24zBk6ok-lEJ5PSRAYaMgXoUeM=.9664f0c5-3e84-4f18-ae63-8820b37e3247@github.com>

On Thu, 15 Jul 2021 17:49:38 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> It looks good. I presume you have tested it? Especially since there aren't any new unit tests added.

I have tested it manually in the playground repo by deploying to staging yes. I could have written new manual junit tests I suppose. If I think I have time for that today I will, but otherwise I would rather get these changes live this week.

-------------

PR: https://git.openjdk.java.net/skara/pull/1203

From erikj at openjdk.java.net  Fri Jul 16 07:02:40 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Fri, 16 Jul 2021 07:02:40 GMT
Subject: Integrated: 1040: Crash in webrev command
In-Reply-To: <wNuPRV0XVWdNvq1CH9pCKXWMThkFO3Wz2e_cWFJL3AA=.7e2e0955-7ca7-48aa-bf60-fd4c5d61476c@github.com>
References: <wNuPRV0XVWdNvq1CH9pCKXWMThkFO3Wz2e_cWFJL3AA=.7e2e0955-7ca7-48aa-bf60-fd4c5d61476c@github.com>
Message-ID: <Qm5HERBdwromEkokEhttx0bgGCAfFPXAnBZHrzHQnx4=.835102ec-a950-46ba-b2ea-b80b1cd12626@github.com>

On Thu, 15 Jul 2021 08:11:48 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> Validate the file input to GitWebrev.

This pull request has now been integrated.

Changeset: db61a394
Author:    Erik Joelsson <erikj at openjdk.org>
URL:       https://git.openjdk.java.net/skara/commit/db61a394d4b579f1c32561e2c8e0dbd82a1d13cc
Stats:     4 lines in 1 file changed: 3 ins; 0 del; 1 mod

1040: Crash in webrev command

Reviewed-by: kcr

-------------

PR: https://git.openjdk.java.net/skara/pull/1199

From erikj at openjdk.java.net  Fri Jul 16 07:04:14 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Fri, 16 Jul 2021 07:04:14 GMT
Subject: Integrated: 1050: Gitlab MR stuck on missing issue when unbreakable
 space in PR title
In-Reply-To: <3JFJZ2U7B7EiSXl0zZEz5Q501WeAcX9sSVpMB8iMWro=.27e7f4ba-1c18-4d28-b0ef-19e237a8c2c0@github.com>
References: <3JFJZ2U7B7EiSXl0zZEz5Q501WeAcX9sSVpMB8iMWro=.27e7f4ba-1c18-4d28-b0ef-19e237a8c2c0@github.com>
Message-ID: <gBevMhYCKvHI8hN_EHkq19ycGwnOXhGIy_8tmo35yVA=.cd5cfe4d-e584-4b9d-bfc4-af7d64e09e1b@github.com>

On Thu, 15 Jul 2021 09:14:05 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> This patch makes the PR title parser able to handle non-breakable space between the bug ID and the bug title. If a user manages to get one of those in there, we currently end up in a limbo state that is very tricky to diagnose.

This pull request has now been integrated.

Changeset: 9b0ca380
Author:    Erik Joelsson <erikj at openjdk.org>
URL:       https://git.openjdk.java.net/skara/commit/9b0ca3802811a7025b8847cb97ceaac334bd1256
Stats:     50 lines in 2 files changed: 49 ins; 0 del; 1 mod

1050: Gitlab MR stuck on missing issue when unbreakable space in PR title

Reviewed-by: kcr

-------------

PR: https://git.openjdk.java.net/skara/pull/1200

From erikj at openjdk.java.net  Fri Jul 16 07:04:26 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Fri, 16 Jul 2021 07:04:26 GMT
Subject: Integrated: 1091: "PR body must not be empty" check pointless for
 clean backports
In-Reply-To: <bfUd-pCm1w9HF61NnqGatXCB2oOgBcrngkuSA849x4k=.bb0a14c5-4f95-458a-955b-c471b6254bb6@github.com>
References: <bfUd-pCm1w9HF61NnqGatXCB2oOgBcrngkuSA849x4k=.bb0a14c5-4f95-458a-955b-c471b6254bb6@github.com>
Message-ID: <1Dz3pKigbg3-Ov7dzyY8hKrMwx0bNPZpZJNJOTSbcyA=.eca75774-be7f-4a2b-ab30-c5510b9fc916@github.com>

On Thu, 15 Jul 2021 11:15:35 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> This patch removes the requirement to write something in the PR body for clean backports. Most of the time there really is nothing to add in that case.

This pull request has now been integrated.

Changeset: a9de6a64
Author:    Erik Joelsson <erikj at openjdk.org>
URL:       https://git.openjdk.java.net/skara/commit/a9de6a64e76f881a481b891f44a6116aa73ede77
Stats:     23 lines in 3 files changed: 9 ins; 6 del; 8 mod

1091: "PR body must not be empty" check pointless for clean backports

Reviewed-by: kcr

-------------

PR: https://git.openjdk.java.net/skara/pull/1201

From erikj at openjdk.java.net  Fri Jul 16 07:05:33 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Fri, 16 Jul 2021 07:05:33 GMT
Subject: Integrated: 1058: The mlbridge bot occasionally posts the same
 comments twice on Github
In-Reply-To: <9gkRV01Z4dH9VmhhEV1ks6kOqkTTIz5-V6I8I0S0owg=.d9e8a4a1-d390-488b-a9a2-a0ff002d722b@github.com>
References: <9gkRV01Z4dH9VmhhEV1ks6kOqkTTIz5-V6I8I0S0owg=.d9e8a4a1-d390-488b-a9a2-a0ff002d722b@github.com>
Message-ID: <osuIQRKFwwi4QLPHmuYdZoZlrLEfdZmwZxpb1MBpvLM=.7e5027ad-e8fa-40df-852b-16b4c96c6b92@github.com>

On Thu, 15 Jul 2021 13:30:57 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> This patch (hopefully) fixes an issue where sometimes the mlbridge bot would post the same email as comment twice in a PR. This happens because two instances of the CommentPosterWorkItem are running at the same time for the same PullRequest.
> 
> This is supposed to be protected by the method "concurrentWith(WorkItem other)". In this particular case, the check is faulty. It checks if the PullRequest object in this WorkItem is equal to the object in the other WorkItem. This is default Object equality, and there is definitely no guarantee that they both contain the exact same object.
> 
> Looking around in other implementations of this method, there is mix of how stringent the checks are, some only check if the PullRequest.id() field is the same, but most also check something about the HostedRepository to which the PR belongs (either name or url). I think calculating the url seems a bit expensive for an equals check.
> 
> I propose a new method on the PullRequest interface: "isSame(PullRequest other)". This isn't trying to be an equals, as that's a bit hard to define (and I don't want to get into implementing hashCode at this time), but will just return true if both PullRequest instances are logically referring to the same hosted pull request. I have replaced all uses of PullRequest.equals() and PullRequest.id().equals() with this new method for consistency.

This pull request has now been integrated.

Changeset: fd42d900
Author:    Erik Joelsson <erikj at openjdk.org>
URL:       https://git.openjdk.java.net/skara/commit/fd42d900459c2e1c9301ab341ad6f081cc0bf4b2
Stats:     38 lines in 10 files changed: 9 ins; 18 del; 11 mod

1058: The mlbridge bot occasionally posts the same comments twice on Github

Reviewed-by: kcr

-------------

PR: https://git.openjdk.java.net/skara/pull/1202

From erikj at openjdk.java.net  Fri Jul 16 07:06:11 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Fri, 16 Jul 2021 07:06:11 GMT
Subject: Integrated: 1068: [Backport] Bot finds original commit in wrong
 repository
In-Reply-To: <n7JmEFP2a4rcrdXziGioH_CiS0Y_3VnKtQkkwHqIE-8=.feecf815-4bb7-422f-be71-0c7e199b7440@github.com>
References: <n7JmEFP2a4rcrdXziGioH_CiS0Y_3VnKtQkkwHqIE-8=.feecf815-4bb7-422f-be71-0c7e199b7440@github.com>
Message-ID: <ZqddDCrUExTMfqSqgJ2S53-MHVBZ6KgpQY4LgMs5n4o=.92c02969-2ed6-4b6d-a3d6-0262454266e6@github.com>

On Thu, 15 Jul 2021 16:41:35 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> When the PR bot searches for the original commit for a backport it's more or less random from which repository it will be found. Whatever it finds is posted as a link in a PR comment, and if it points to something weird, that can be confusing (though not strictly incorrect as the change will be the exact same regardless of which repo it is in).
> 
> The search feature already has what looks to be a configurable way to limit searching to a set of organizations. Unfortunately, that feature was never used and is currently broken for Github (for Gitlab it's already in use as it's required for the search method we use). Because of this, we usually pick a match from adoptium or SAP today. This patch fixes this for Github (where the query separator is space, not '+'), and I intend to limit the organizations to "openjdk" when deploying this fix.
> 
> In addition to this, it would be nice if the exact repo that gets picked is the "correct" one. Unfortunately, there is no really good definition of what the correct repo would be in all cases, and it would be even trickier to implement this in a good way. As an approximate workaround, I've added sorting on repository name length, so we always pick the repo with the shortest name. I believe this will at least give us a better answer than "random" in most cases for a relatively modest cost in performance.
> 
> I have experimented with this patch in staging with the playground repo and the behavior I've seen so far is good.

This pull request has now been integrated.

Changeset: e98965d4
Author:    Erik Joelsson <erikj at openjdk.org>
URL:       https://git.openjdk.java.net/skara/commit/e98965d49dc3836ec99967aabd9f2e7848723c0b
Stats:     15 lines in 2 files changed: 10 ins; 0 del; 5 mod

1068: [Backport] Bot finds original commit in wrong repository

Reviewed-by: kcr

-------------

PR: https://git.openjdk.java.net/skara/pull/1203

From erikj at openjdk.java.net  Fri Jul 16 11:05:31 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Fri, 16 Jul 2021 11:05:31 GMT
Subject: RFR: 1111: Backport command need better matching of target repo
Message-ID: <5zpvudB5ePtwqGe6Afhffaiqa2y7V9FWrXXR8D4RiZM=.aef12434-9503-4efc-a7b2-cfe61c264129@github.com>

This patch improves the /backport commit command, making it smarter when trying to find the target repository from the argument given by the user. Instead of trying to piece it together based on the namespace (organization/group) of the current repository, it goes straight to the forks configuration and tries to match the repo from there. We can only do backports if there is a valid fork configuration anyway.

In addition to this, I'm also changing the error message you get when you enter an invalid target repo. The list now includes the namespace prefix for each repo, and a note that supplying it is optional.

-------------

Commit messages:
 - SKARA-1111

Changes: https://git.openjdk.java.net/skara/pull/1204/files
 Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1204&range=00
  Issue: https://bugs.openjdk.java.net/browse/SKARA-1111
  Stats: 48 lines in 4 files changed: 10 ins; 17 del; 21 mod
  Patch: https://git.openjdk.java.net/skara/pull/1204.diff
  Fetch: git fetch https://git.openjdk.java.net/skara pull/1204/head:pull/1204

PR: https://git.openjdk.java.net/skara/pull/1204

From erikj at openjdk.java.net  Fri Jul 16 13:22:53 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Fri, 16 Jul 2021 13:22:53 GMT
Subject: RFR: 1048: Missing integration comment causes mlbridge to throw
 exceptions
Message-ID: <4JLVt1HtU-EPf72CyI_ddNzHU9UZ9_ERJBE8rTZucIY=.40c94aaf-a9a0-4323-8fcb-ab4caef555d6@github.com>

This patch changes the mlbridge bot to stop throwing errors when it encounters a PR marked as integrated but without the integration comment (which contains the information about the commit hash needed for the email). Instead, it's just logged and no action is taken. When the comment is eventually added, the bot will run again and the email will be sent.

The ordering of actions from the PR bot must unfortunately be like it is, with the comment added last.

-------------

Commit messages:
 - SKARA-1048

Changes: https://git.openjdk.java.net/skara/pull/1205/files
 Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1205&range=00
  Issue: https://bugs.openjdk.java.net/browse/SKARA-1048
  Stats: 13 lines in 2 files changed: 10 ins; 1 del; 2 mod
  Patch: https://git.openjdk.java.net/skara/pull/1205.diff
  Fetch: git fetch https://git.openjdk.java.net/skara pull/1205/head:pull/1205

PR: https://git.openjdk.java.net/skara/pull/1205

From kcr at openjdk.java.net  Fri Jul 16 13:59:26 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 16 Jul 2021 13:59:26 GMT
Subject: RFR: 1048: Missing integration comment causes mlbridge to throw
 exceptions
In-Reply-To: <4JLVt1HtU-EPf72CyI_ddNzHU9UZ9_ERJBE8rTZucIY=.40c94aaf-a9a0-4323-8fcb-ab4caef555d6@github.com>
References: <4JLVt1HtU-EPf72CyI_ddNzHU9UZ9_ERJBE8rTZucIY=.40c94aaf-a9a0-4323-8fcb-ab4caef555d6@github.com>
Message-ID: <gtqcCHLAl_fqDHVMIgT7cH7OXTx8dRwe81oGEr_0rsY=.02381e80-30bf-4486-ad61-24be0e2b9ad7@github.com>

On Fri, 16 Jul 2021 13:19:22 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> This patch changes the mlbridge bot to stop throwing errors when it encounters a PR marked as integrated but without the integration comment (which contains the information about the commit hash needed for the email). Instead, it's just logged and no action is taken. When the comment is eventually added, the bot will run again and the email will be sent.
> 
> The ordering of actions from the PR bot must unfortunately be like it is, with the comment added last.

Marked as reviewed by kcr (Reviewer).

-------------

PR: https://git.openjdk.java.net/skara/pull/1205

From kcr at openjdk.java.net  Fri Jul 16 14:03:51 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 16 Jul 2021 14:03:51 GMT
Subject: RFR: 1111: Backport command needs better matching of target repo
In-Reply-To: <5zpvudB5ePtwqGe6Afhffaiqa2y7V9FWrXXR8D4RiZM=.aef12434-9503-4efc-a7b2-cfe61c264129@github.com>
References: <5zpvudB5ePtwqGe6Afhffaiqa2y7V9FWrXXR8D4RiZM=.aef12434-9503-4efc-a7b2-cfe61c264129@github.com>
Message-ID: <X8M87NXrm5pFGa7ybWQvlzfq1vaKrCLBGivFRmsL1C0=.31634a80-04dc-4d73-8eb4-79cf27f4195e@github.com>

On Fri, 16 Jul 2021 11:01:48 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> This patch improves the /backport commit command, making it smarter when trying to find the target repository from the argument given by the user. Instead of trying to piece it together based on the namespace (organization/group) of the current repository, it goes straight to the forks configuration and tries to match the repo from there. We can only do backports if there is a valid fork configuration anyway.
> 
> In addition to this, I'm also changing the error message you get when you enter an invalid target repo. The list now includes the namespace prefix for each repo, and a note that supplying it is optional.

Looks good.

-------------

Marked as reviewed by kcr (Reviewer).

PR: https://git.openjdk.java.net/skara/pull/1204

From christoph.langer at sap.com  Tue Jul 20 06:23:10 2021
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 20 Jul 2021 06:23:10 +0000
Subject: GitHub/Mailing list communication defunct?
Message-ID: <AM4PR02MB3138AF92E64168422275C4A48AE29@AM4PR02MB3138.eurprd02.prod.outlook.com>

Hi,

I just recognized that all of a sudden the traffic on the OpenJDK mailing lists dropped... First I thought it's an issue with my account but looking at the pipermail archives, I don't find any mails after e.g. some time yesterday. And I guess there's still the usual activity on GitHub...

Are you aware of an issue?

Thanks & Best regards
Christoph


From david.holmes at oracle.com  Tue Jul 20 06:52:44 2021
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 20 Jul 2021 16:52:44 +1000
Subject: GitHub/Mailing list communication defunct?
In-Reply-To: <AM4PR02MB3138AF92E64168422275C4A48AE29@AM4PR02MB3138.eurprd02.prod.outlook.com>
References: <AM4PR02MB3138AF92E64168422275C4A48AE29@AM4PR02MB3138.eurprd02.prod.outlook.com>
Message-ID: <d9fb728e-b088-3a81-f421-7af9f37fd5b1@oracle.com>

Hi Christoph,

Yes there is awareness of the issue. The fact this email actually got 
through suggests the problem has been addressed and things should start 
returning to normal.

Cheers,
David

On 20/07/2021 4:23 pm, Langer, Christoph wrote:
> Hi,
> 
> I just recognized that all of a sudden the traffic on the OpenJDK mailing lists dropped... First I thought it's an issue with my account but looking at the pipermail archives, I don't find any mails after e.g. some time yesterday. And I guess there's still the usual activity on GitHub...
> 
> Are you aware of an issue?
> 
> Thanks & Best regards
> Christoph
> 

From christoph.langer at sap.com  Tue Jul 20 06:57:30 2021
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 20 Jul 2021 06:57:30 +0000
Subject: GitHub/Mailing list communication defunct?
In-Reply-To: <d9fb728e-b088-3a81-f421-7af9f37fd5b1@oracle.com>
References: <AM4PR02MB3138AF92E64168422275C4A48AE29@AM4PR02MB3138.eurprd02.prod.outlook.com>
 <d9fb728e-b088-3a81-f421-7af9f37fd5b1@oracle.com>
Message-ID: <AM4PR02MB3138224681F2EC30FDFD12F68AE29@AM4PR02MB3138.eurprd02.prod.outlook.com>

Hi David,

thanks for getting back on that.

It appears to me that the mailing lists itself are working ok and you can use them via direct mail. What doesn't work is the mails originating from GitHub. So, doesn't look like things are returning to normal yet...

Best regards
Christoph

> -----Original Message-----
> From: David Holmes <david.holmes at oracle.com>
> Sent: Dienstag, 20. Juli 2021 08:53
> To: Langer, Christoph <christoph.langer at sap.com>; ops at openjdk.java.net;
> skara-dev at openjdk.java.net; jdk-dev at openjdk.java.net
> Subject: Re: GitHub/Mailing list communication defunct?
> 
> Hi Christoph,
> 
> Yes there is awareness of the issue. The fact this email actually got
> through suggests the problem has been addressed and things should start
> returning to normal.
> 
> Cheers,
> David
> 
> On 20/07/2021 4:23 pm, Langer, Christoph wrote:
> > Hi,
> >
> > I just recognized that all of a sudden the traffic on the OpenJDK mailing lists
> dropped... First I thought it's an issue with my account but looking at the
> pipermail archives, I don't find any mails after e.g. some time yesterday. And
> I guess there's still the usual activity on GitHub...
> >
> > Are you aware of an issue?
> >
> > Thanks & Best regards
> > Christoph
> >

From christoph.langer at sap.com  Wed Jul 21 15:07:28 2021
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 21 Jul 2021 15:07:28 +0000
Subject: GitHub/Mailing list communication defunct?
In-Reply-To: <AM4PR02MB3138AF92E64168422275C4A48AE29@AM4PR02MB3138.eurprd02.prod.outlook.com>
References: <AM4PR02MB3138AF92E64168422275C4A48AE29@AM4PR02MB3138.eurprd02.prod.outlook.com>
Message-ID: <AM4PR02MB3138D37FD95D31D074AF61F78AE39@AM4PR02MB3138.eurprd02.prod.outlook.com>

Hi,

there's still no traffic on the mailing lists...

It would be much appreciated if you could share an update on the status.

Thanks
Christoph

From: Langer, Christoph
Sent: Dienstag, 20. Juli 2021 08:23
To: ops at openjdk.java.net; skara-dev at openjdk.java.net; jdk-dev at openjdk.java.net
Subject: GitHub/Mailing list communication defunct?

Hi,

I just recognized that all of a sudden the traffic on the OpenJDK mailing lists dropped... First I thought it's an issue with my account but looking at the pipermail archives, I don't find any mails after e.g. some time yesterday. And I guess there's still the usual activity on GitHub...

Are you aware of an issue?

Thanks & Best regards
Christoph


From christoph.langer at sap.com  Wed Jul 21 21:20:52 2021
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 21 Jul 2021 21:20:52 +0000
Subject: Backporting a set of patches in a single commit
Message-ID: <AM4PR02MB3138D40C6ADBFE8BB37AE1688AE39@AM4PR02MB3138.eurprd02.prod.outlook.com>

Hi Skara Team,

after gathering the first significant experiences with the backport process using GitHub/Skara, I find that there is one use case which works considerably worse than before. It is when you want to backport a set of patches that must be pushed together. Imagine you have a patch, then a build fix and then maybe another test fix. So as to not break builds and tests, you will want to push them together in one go. You could now add those 3 commits into one PR. But when you integrate, the 3 commits get squashed which is contrary to the usual way of backporting which tries to preserve individual commits. Alternatively, you could file 3 separate PRs. This, however, often bears the problem that the PRs might be dependent on each other. So any individual backport PR could possibly only be opened and reviewed after its predecessor was integrated. Which will leave the repo in a bad state for a while.

So what can we do here? Shall we change the paradigm and allow more squashing? Or did you already think of a better workflow? I think there is a feature of Skara called dependent PRs. Could that be used here? Or could maybe the backport bot recognize individual commits to preserve?

Thanks in advance for sharing your thoughts.

Best regards
Christoph


From david.holmes at oracle.com  Wed Jul 21 21:29:30 2021
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 22 Jul 2021 07:29:30 +1000
Subject: GitHub/Mailing list communication defunct?
In-Reply-To: <AM4PR02MB3138D37FD95D31D074AF61F78AE39@AM4PR02MB3138.eurprd02.prod.outlook.com>
References: <AM4PR02MB3138AF92E64168422275C4A48AE29@AM4PR02MB3138.eurprd02.prod.outlook.com>
 <AM4PR02MB3138D37FD95D31D074AF61F78AE39@AM4PR02MB3138.eurprd02.prod.outlook.com>
Message-ID: <095fc050-dbb1-107d-eac9-89c974ba42b8@oracle.com>

Hi Christoph,

On 22/07/2021 1:07 am, Langer, Christoph wrote:
> Hi,
> 
> there's still no traffic on the mailing lists...
> 
> It would be much appreciated if you could share an update on the status.

There was no update to share I'm afraid but it has now been resolved.

It seems likely that the missing mail is gone forever unfortunately.

Cheers,
David

> Thanks
> Christoph
> 
> From: Langer, Christoph
> Sent: Dienstag, 20. Juli 2021 08:23
> To: ops at openjdk.java.net; skara-dev at openjdk.java.net; jdk-dev at openjdk.java.net
> Subject: GitHub/Mailing list communication defunct?
> 
> Hi,
> 
> I just recognized that all of a sudden the traffic on the OpenJDK mailing lists dropped... First I thought it's an issue with my account but looking at the pipermail archives, I don't find any mails after e.g. some time yesterday. And I guess there's still the usual activity on GitHub...
> 
> Are you aware of an issue?
> 
> Thanks & Best regards
> Christoph
> 

From tim.bell at oracle.com  Wed Jul 21 21:33:57 2021
From: tim.bell at oracle.com (tim.bell at oracle.com)
Date: Wed, 21 Jul 2021 14:33:57 -0700
Subject: GitHub/Mailing list communication defunct?
In-Reply-To: <095fc050-dbb1-107d-eac9-89c974ba42b8@oracle.com>
References: <AM4PR02MB3138AF92E64168422275C4A48AE29@AM4PR02MB3138.eurprd02.prod.outlook.com>
 <AM4PR02MB3138D37FD95D31D074AF61F78AE39@AM4PR02MB3138.eurprd02.prod.outlook.com>
 <095fc050-dbb1-107d-eac9-89c974ba42b8@oracle.com>
Message-ID: <f4e3b351-9eb9-32ba-c78c-ed560d90536f@oracle.com>

> just recognized that all of a sudden the traffic on the OpenJDK 
> mailing lists dropped

About an hour ago we corrected a problem on the Skara server processing 
external (EG: github) messages.? Message traffic should be flowing again.

Messages for events during the outage are lost.? We will be holding a 
port-mortem to investigate why this outage was not noticed sooner, and 
why there was a data loss.

Tim


On 7/21/21 14:29, David Holmes wrote:
> Hi Christoph,
>
> On 22/07/2021 1:07 am, Langer, Christoph wrote:
>> Hi,
>>
>> there's still no traffic on the mailing lists...
>>
>> It would be much appreciated if you could share an update on the status.
>
> There was no update to share I'm afraid but it has now been resolved.
>
> It seems likely that the missing mail is gone forever unfortunately.
>
> Cheers,
> David
>
>> Thanks
>> Christoph
>>
>> From: Langer, Christoph
>> Sent: Dienstag, 20. Juli 2021 08:23
>> To: ops at openjdk.java.net; skara-dev at openjdk.java.net; 
>> jdk-dev at openjdk.java.net
>> Subject: GitHub/Mailing list communication defunct?
>>
>> Hi,
>>
>> I just recognized that all of a sudden the traffic on the OpenJDK 
>> mailing lists dropped... First I thought it's an issue with my 
>> account but looking at the pipermail archives, I don't find any mails 
>> after e.g. some time yesterday. And I guess there's still the usual 
>> activity on GitHub...
>>
>> Are you aware of an issue?
>>
>> Thanks & Best regards
>> Christoph
>>


From kevin.rushforth at oracle.com  Wed Jul 21 21:36:48 2021
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Wed, 21 Jul 2021 14:36:48 -0700
Subject: [External] : Backporting a set of patches in a single commit
In-Reply-To: <AM4PR02MB3138D40C6ADBFE8BB37AE1688AE39@AM4PR02MB3138.eurprd02.prod.outlook.com>
References: <AM4PR02MB3138D40C6ADBFE8BB37AE1688AE39@AM4PR02MB3138.eurprd02.prod.outlook.com>
Message-ID: <016d954f-f377-cbd9-09a2-3f628c6c9dfd@oracle.com>

Hi Christoph,

Yes, I think one solution would be to enable the dependent pull request 
feature of Skara for your repo. It's already being used by the jdk 
project. Since it is already implemented and tested (at least for 
original fixes, but I can't think of anything that would preclude it for 
backports), it would be easy to set up so you could try it and see if it 
met your needs.

FWIW, I ran into this in a couple cases myself when backporting fixes to 
jfx11u after the Skara switch. I ended up testing them in a branch where 
I pulled in the relevant fixes I needed, and then did them as separate 
PRs in the right order. Since they were clean it took only a few extra 
minutes. It was the testing that took all the time anyway, but I 
couldn't help thinking that dependent pull requests would have made it 
easier.

-- Kevin


On 7/21/2021 2:20 PM, Langer, Christoph wrote:
>
> Hi Skara Team,
>
> after gathering the first significant experiences with the backport 
> process using GitHub/Skara, I find that there is one use case which 
> works considerably worse than before. It is when you want to backport 
> a set of patches that must be pushed together. Imagine you have a 
> patch, then a build fix and then maybe another test fix. So as to not 
> break builds and tests, you will want to push them together in one go. 
> You could now add those 3 commits into one PR. But when you integrate, 
> the 3 commits get squashed which is contrary to the usual way of 
> backporting which tries to preserve individual commits. Alternatively, 
> you could file 3 separate PRs. This, however, often bears the problem 
> that the PRs might be dependent on each other. So any individual 
> backport PR could possibly only be opened and reviewed after its 
> predecessor was integrated. Which will leave the repo in a bad state 
> for a while.
>
> So what can we do here? Shall we change the paradigm and allow more 
> squashing? Or did you already think of a better workflow? I think 
> there is a feature of Skara called dependent PRs. Could that be used 
> here? Or could maybe the backport bot recognize individual commits to 
> preserve?
>
> Thanks in advance for sharing your thoughts.
>
> Best regards
>
> Christoph
>


From christoph.langer at sap.com  Thu Jul 22 11:07:27 2021
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 22 Jul 2021 11:07:27 +0000
Subject: GitHub/Mailing list communication defunct?
In-Reply-To: <f4e3b351-9eb9-32ba-c78c-ed560d90536f@oracle.com>
References: <AM4PR02MB3138AF92E64168422275C4A48AE29@AM4PR02MB3138.eurprd02.prod.outlook.com>
 <AM4PR02MB3138D37FD95D31D074AF61F78AE39@AM4PR02MB3138.eurprd02.prod.outlook.com>
 <095fc050-dbb1-107d-eac9-89c974ba42b8@oracle.com>
 <f4e3b351-9eb9-32ba-c78c-ed560d90536f@oracle.com>
Message-ID: <AM4PR02MB3138F4E884F17C668EDF6E418AE49@AM4PR02MB3138.eurprd02.prod.outlook.com>

Hi Tim and David,

thanks for fixing this. I guess it?s not too much of an issue that events were lost. But glad that it works again. ??

Best regards
Christoph

From: tim.bell at oracle.com <tim.bell at oracle.com>
Sent: Mittwoch, 21. Juli 2021 23:34
To: David Holmes <david.holmes at oracle.com>; Langer, Christoph <christoph.langer at sap.com>; ops at openjdk.java.net; skara-dev at openjdk.java.net; jdk-dev at openjdk.java.net
Subject: Re: GitHub/Mailing list communication defunct?

just recognized that all of a sudden the traffic on the OpenJDK mailing lists dropped

About an hour ago we corrected a problem on the Skara server processing external (EG: github) messages.  Message traffic should be flowing again.

Messages for events during the outage are lost.  We will be holding a port-mortem to investigate why this outage was not noticed sooner, and why there was a data loss.

Tim

On 7/21/21 14:29, David Holmes wrote:
Hi Christoph,

On 22/07/2021 1:07 am, Langer, Christoph wrote:

Hi,

there's still no traffic on the mailing lists...

It would be much appreciated if you could share an update on the status.

There was no update to share I'm afraid but it has now been resolved.

It seems likely that the missing mail is gone forever unfortunately.

Cheers,
David


Thanks
Christoph

From: Langer, Christoph
Sent: Dienstag, 20. Juli 2021 08:23
To: ops at openjdk.java.net<mailto:ops at openjdk.java.net>; skara-dev at openjdk.java.net<mailto:skara-dev at openjdk.java.net>; jdk-dev at openjdk.java.net<mailto:jdk-dev at openjdk.java.net>
Subject: GitHub/Mailing list communication defunct?

Hi,

I just recognized that all of a sudden the traffic on the OpenJDK mailing lists dropped... First I thought it's an issue with my account but looking at the pipermail archives, I don't find any mails after e.g. some time yesterday. And I guess there's still the usual activity on GitHub...

Are you aware of an issue?

Thanks & Best regards
Christoph


From rahul4talk at gmail.com  Thu Jul 22 12:57:53 2021
From: rahul4talk at gmail.com (Rahul Yadav)
Date: Thu, 22 Jul 2021 13:57:53 +0100
Subject: Fwd: OpenJDK Contributors list & commit history
In-Reply-To: <CA+3zrvTBvKTEpHhEkiDHnPStUTR2Eu3OYX-B1fwnZaGMd_9c1Q@mail.gmail.com>
References: <CA+3zrvTBvKTEpHhEkiDHnPStUTR2Eu3OYX-B1fwnZaGMd_9c1Q@mail.gmail.com>
Message-ID: <CA+3zrvQyhfVsmq+wNi+zKL7zjXAqOPpf35OhnVNqxpYj7_DTkA@mail.gmail.com>

Hi Folks,

Until recently, i was on the contributors list on
https://github.com/openjdk/jdk project, and was able to view my commits and
history by just clicking on contributors link on the index page at jdk repo.


   - I cannot see my name in the contributors list anymore and not able to
   view my commit history directly, although when i query the url for commit
   history, i.e *https://github.com/openjdk/jdk/commits?author=rhyadav
   <https://github.com/openjdk/jdk/commits?author=rhyadav>*. But i don't
   see my name in the contributors list
   - Some of the commits that used to show up earlier, don't show up now, i
   can only see half of my commits, the commits that were sponsored( when i
   was an author) are not showing up. The commits i have done as a "committer"
   are the only ones i can see.
   - The only thing that's changes recently is my primary email on the
   linked Github account is not an Oracle.com id( as i'm not part of Oracle
   now) and my personal email id is the primary.
   - I am not able to open any jira issues as my primary email(on Github)
   is not recognized.

Github : *https://github.com/rhyadav <https://github.com/rhyadav>*

Request assistance with the above


Thanks
Rahul

From lgxbslgx at gmail.com  Thu Jul 22 14:15:14 2021
From: lgxbslgx at gmail.com (Guoxiong Li)
Date: Thu, 22 Jul 2021 22:15:14 +0800
Subject: OpenJDK Contributors list & commit history
In-Reply-To: <CA+3zrvQyhfVsmq+wNi+zKL7zjXAqOPpf35OhnVNqxpYj7_DTkA@mail.gmail.com>
References: <CA+3zrvTBvKTEpHhEkiDHnPStUTR2Eu3OYX-B1fwnZaGMd_9c1Q@mail.gmail.com>
 <CA+3zrvQyhfVsmq+wNi+zKL7zjXAqOPpf35OhnVNqxpYj7_DTkA@mail.gmail.com>
Message-ID: <CAPSsVqj-K-ODuP7bYKOrF9nbXRfuzepcNr7va6dbbUk2sAJLpg@mail.gmail.com>

Hi Rahul,

It seems to be an issue on Github.
Github can't identify the `author` field of the commit logs sometimes.
You may need to contact the registrar at openjdk.java.net to revise your email.

Considering Github's problem, when we count somebody's contributions,
we can search the `author-name` of the project instead of the `author` of
commit logs.
As your situation, you can search your contributions in the jdk project
by using `author-name:"Rahul Yadav"`, which is shown as the following link.

https://github.com/openjdk/jdk/search?q=author-name%3A%22Rahul+Yadav%22&type=commits

Best Regards,
-- Guoxiong

From rahul4talk at gmail.com  Thu Jul 22 15:09:18 2021
From: rahul4talk at gmail.com (Rahul Yadav)
Date: Thu, 22 Jul 2021 16:09:18 +0100
Subject: OpenJDK Contributors list & commit history
In-Reply-To: <CAPSsVqj-K-ODuP7bYKOrF9nbXRfuzepcNr7va6dbbUk2sAJLpg@mail.gmail.com>
References: <CA+3zrvTBvKTEpHhEkiDHnPStUTR2Eu3OYX-B1fwnZaGMd_9c1Q@mail.gmail.com>
 <CA+3zrvQyhfVsmq+wNi+zKL7zjXAqOPpf35OhnVNqxpYj7_DTkA@mail.gmail.com>
 <CAPSsVqj-K-ODuP7bYKOrF9nbXRfuzepcNr7va6dbbUk2sAJLpg@mail.gmail.com>
Message-ID: <CA+3zrvS_uF_5khbsSN_+wdzZg1u3Q-4tCeCmMDn5bEMPdvMEsw@mail.gmail.com>

Thank you, will do


Rahul

On Thu, Jul 22, 2021 at 3:15 PM Guoxiong Li <lgxbslgx at gmail.com> wrote:

> Hi Rahul,
>
> It seems to be an issue on Github.
> Github can't identify the `author` field of the commit logs sometimes.
> You may need to contact the registrar at openjdk.java.net to revise your
> email.
>
> Considering Github's problem, when we count somebody's contributions,
> we can search the `author-name` of the project instead of the `author` of
> commit logs.
> As your situation, you can search your contributions in the jdk project
> by using `author-name:"Rahul Yadav"`, which is shown as the following link.
>
>
> https://github.com/openjdk/jdk/search?q=author-name%3A%22Rahul+Yadav%22&type=commits
>
> Best Regards,
> -- Guoxiong
>

From christoph.langer at sap.com  Thu Jul 22 21:37:48 2021
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 22 Jul 2021 21:37:48 +0000
Subject: [External] : Backporting a set of patches in a single commit
In-Reply-To: <016d954f-f377-cbd9-09a2-3f628c6c9dfd@oracle.com>
References: <AM4PR02MB3138D40C6ADBFE8BB37AE1688AE39@AM4PR02MB3138.eurprd02.prod.outlook.com>
 <016d954f-f377-cbd9-09a2-3f628c6c9dfd@oracle.com>
Message-ID: <AM4PR02MB3138F52B45D0342288474E298AE49@AM4PR02MB3138.eurprd02.prod.outlook.com>

Hi Kevin,

well, I think then we should try the dependent pull request feature on jdk11u-dev. Is there any drawback besides the additional branches created? Also, is there any documentation?

Thanks
Christoph

From: Kevin Rushforth <kevin.rushforth at oracle.com>
Sent: Mittwoch, 21. Juli 2021 23:37
To: Langer, Christoph <christoph.langer at sap.com>; skara-dev at openjdk.java.net; erik.joelsson at oracle.com
Cc: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
Subject: Re: [External] : Backporting a set of patches in a single commit

Hi Christoph,

Yes, I think one solution would be to enable the dependent pull request feature of Skara for your repo. It's already being used by the jdk project. Since it is already implemented and tested (at least for original fixes, but I can't think of anything that would preclude it for backports), it would be easy to set up so you could try it and see if it met your needs.

FWIW, I ran into this in a couple cases myself when backporting fixes to jfx11u after the Skara switch. I ended up testing them in a branch where I pulled in the relevant fixes I needed, and then did them as separate PRs in the right order. Since they were clean it took only a few extra minutes. It was the testing that took all the time anyway, but I couldn't help thinking that dependent pull requests would have made it easier.

-- Kevin

On 7/21/2021 2:20 PM, Langer, Christoph wrote:
Hi Skara Team,

after gathering the first significant experiences with the backport process using GitHub/Skara, I find that there is one use case which works considerably worse than before. It is when you want to backport a set of patches that must be pushed together. Imagine you have a patch, then a build fix and then maybe another test fix. So as to not break builds and tests, you will want to push them together in one go. You could now add those 3 commits into one PR. But when you integrate, the 3 commits get squashed which is contrary to the usual way of backporting which tries to preserve individual commits. Alternatively, you could file 3 separate PRs. This, however, often bears the problem that the PRs might be dependent on each other. So any individual backport PR could possibly only be opened and reviewed after its predecessor was integrated. Which will leave the repo in a bad state for a while.

So what can we do here? Shall we change the paradigm and allow more squashing? Or did you already think of a better workflow? I think there is a feature of Skara called dependent PRs. Could that be used here? Or could maybe the backport bot recognize individual commits to preserve?

Thanks in advance for sharing your thoughts.

Best regards
Christoph



From kevin.rushforth at oracle.com  Thu Jul 22 22:45:04 2021
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Thu, 22 Jul 2021 15:45:04 -0700
Subject: [External] : Backporting a set of patches in a single commit
In-Reply-To: <AM4PR02MB3138F52B45D0342288474E298AE49@AM4PR02MB3138.eurprd02.prod.outlook.com>
References: <AM4PR02MB3138D40C6ADBFE8BB37AE1688AE39@AM4PR02MB3138.eurprd02.prod.outlook.com>
 <016d954f-f377-cbd9-09a2-3f628c6c9dfd@oracle.com>
 <AM4PR02MB3138F52B45D0342288474E298AE49@AM4PR02MB3138.eurprd02.prod.outlook.com>
Message-ID: <41479c05-20d8-3bdc-a7cb-c5e5d0d0a91d@oracle.com>

The only drawback I'm aware of is the bit of extra noise caused by the 
automatically created "pr/NNNN" branches. If you don't have a dependent 
PR (which most aren't in my experience), then you can ignore it. If you 
do, then the branch is there and ready for you to use.

I will look for a write-up, but I don't see one, so I don't know for 
sure whether Erik H finished docuementing it. The best source of 
documentation I know of is the "New Skara feature: dependent pull 
requests" [1] email that Erik H sent in March announcing the feature.

If you want us to enable it, we can enable this some time next week.

-- Kevin

[1] https://mail.openjdk.java.net/pipermail/skara-dev/2021-March/004528.html


On 7/22/2021 2:37 PM, Langer, Christoph wrote:
>
> Hi Kevin,
>
> well, I think then we should try the dependent pull request feature on 
> jdk11u-dev. Is there any drawback besides the additional branches 
> created? Also, is there any documentation?
>
> Thanks
>
> Christoph
>
> *From:* Kevin Rushforth <kevin.rushforth at oracle.com>
> *Sent:* Mittwoch, 21. Juli 2021 23:37
> *To:* Langer, Christoph <christoph.langer at sap.com>; 
> skara-dev at openjdk.java.net; erik.joelsson at oracle.com
> *Cc:* Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> *Subject:* Re: [External] : Backporting a set of patches in a single 
> commit
>
> Hi Christoph,
>
> Yes, I think one solution would be to enable the dependent pull 
> request feature of Skara for your repo. It's already being used by the 
> jdk project. Since it is already implemented and tested (at least for 
> original fixes, but I can't think of anything that would preclude it 
> for backports), it would be easy to set up so you could try it and see 
> if it met your needs.
>
> FWIW, I ran into this in a couple cases myself when backporting fixes 
> to jfx11u after the Skara switch. I ended up testing them in a branch 
> where I pulled in the relevant fixes I needed, and then did them as 
> separate PRs in the right order. Since they were clean it took only a 
> few extra minutes. It was the testing that took all the time anyway, 
> but I couldn't help thinking that dependent pull requests would have 
> made it easier.
>
> -- Kevin
>
> On 7/21/2021 2:20 PM, Langer, Christoph wrote:
>
>     Hi Skara Team,
>
>     after gathering the first significant experiences with the
>     backport process using GitHub/Skara, I find that there is one use
>     case which works considerably worse than before. It is when you
>     want to backport a set of patches that must be pushed together.
>     Imagine you have a patch, then a build fix and then maybe another
>     test fix. So as to not break builds and tests, you will want to
>     push them together in one go. You could now add those 3 commits
>     into one PR. But when you integrate, the 3 commits get squashed
>     which is contrary to the usual way of backporting which tries to
>     preserve individual commits. Alternatively, you could file 3
>     separate PRs. This, however, often bears the problem that the PRs
>     might be dependent on each other. So any individual backport PR
>     could possibly only be opened and reviewed after its predecessor
>     was integrated. Which will leave the repo in a bad state for a while.
>
>     So what can we do here? Shall we change the paradigm and allow
>     more squashing? Or did you already think of a better workflow? I
>     think there is a feature of Skara called dependent PRs. Could that
>     be used here? Or could maybe the backport bot recognize individual
>     commits to preserve?
>
>     Thanks in advance for sharing your thoughts.
>
>     Best regards
>
>     Christoph
>


From kevin.rushforth at oracle.com  Thu Jul 22 22:58:46 2021
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Thu, 22 Jul 2021 15:58:46 -0700
Subject: GitHub/Mailing list communication defunct?
In-Reply-To: <59dd2185-104f-3235-6d8a-5f581f6d99be@gmail.com>
References: <AM4PR02MB3138AF92E64168422275C4A48AE29@AM4PR02MB3138.eurprd02.prod.outlook.com>
 <AM4PR02MB3138D37FD95D31D074AF61F78AE39@AM4PR02MB3138.eurprd02.prod.outlook.com>
 <095fc050-dbb1-107d-eac9-89c974ba42b8@oracle.com>
 <f4e3b351-9eb9-32ba-c78c-ed560d90536f@oracle.com>
 <59dd2185-104f-3235-6d8a-5f581f6d99be@gmail.com>
Message-ID: <1ca5b885-0954-894e-f0e4-e8efc72499e6@oracle.com>

Thanks for the report. This is now being tracked as a separate issue. 
It's being looked into, but I don't know more than that.

-- Kevin


On 7/22/2021 9:21 AM, Jaikiran Pai wrote:
> FWIW, it looks like this isn't fully back to normal. From what I can 
> see in one of the PR's[1] I'm involved in, if I comment directly on 
> the PR through the github UI, a mail is now getting delivered to the 
> relevant mailing lists. So this part is back to normal now.
>
> However, if someone comments/replies directly to the mailing list 
> thread (like Bernd and I did, during this past hour[2]), those 
> comments aren't being registered in that github PR. This used to work 
> previously and seems to be broken right now.
>
> [1] https://github.com/openjdk/jdk/pull/4607
>
> [2] 
> https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-July/079994.html
>
>
> -Jaikiran
>
> On 22/07/21 3:03 am, tim.bell at oracle.com wrote:
>>> just recognized that all of a sudden the traffic on the OpenJDK 
>>> mailing lists dropped
>>
>> About an hour ago we corrected a problem on the Skara server 
>> processing external (EG: github) messages.? Message traffic should be 
>> flowing again.
>>
>> Messages for events during the outage are lost.? We will be holding a 
>> port-mortem to investigate why this outage was not noticed sooner, 
>> and why there was a data loss.
>>
>> Tim
>>
>>
>> On 7/21/21 14:29, David Holmes wrote:
>>> Hi Christoph,
>>>
>>> On 22/07/2021 1:07 am, Langer, Christoph wrote:
>>>> Hi,
>>>>
>>>> there's still no traffic on the mailing lists...
>>>>
>>>> It would be much appreciated if you could share an update on the 
>>>> status.
>>>
>>> There was no update to share I'm afraid but it has now been resolved.
>>>
>>> It seems likely that the missing mail is gone forever unfortunately.
>>>
>>> Cheers,
>>> David
>>>
>>>> Thanks
>>>> Christoph
>>>>
>>>> From: Langer, Christoph
>>>> Sent: Dienstag, 20. Juli 2021 08:23
>>>> To: ops at openjdk.java.net; skara-dev at openjdk.java.net; 
>>>> jdk-dev at openjdk.java.net
>>>> Subject: GitHub/Mailing list communication defunct?
>>>>
>>>> Hi,
>>>>
>>>> I just recognized that all of a sudden the traffic on the OpenJDK 
>>>> mailing lists dropped... First I thought it's an issue with my 
>>>> account but looking at the pipermail archives, I don't find any 
>>>> mails after e.g. some time yesterday. And I guess there's still the 
>>>> usual activity on GitHub...
>>>>
>>>> Are you aware of an issue?
>>>>
>>>> Thanks & Best regards
>>>> Christoph
>>>>
>>
>


From christoph.langer at sap.com  Fri Jul 23 05:27:30 2021
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 23 Jul 2021 05:27:30 +0000
Subject: [External] : Backporting a set of patches in a single commit
In-Reply-To: <41479c05-20d8-3bdc-a7cb-c5e5d0d0a91d@oracle.com>
References: <AM4PR02MB3138D40C6ADBFE8BB37AE1688AE39@AM4PR02MB3138.eurprd02.prod.outlook.com>
 <016d954f-f377-cbd9-09a2-3f628c6c9dfd@oracle.com>
 <AM4PR02MB3138F52B45D0342288474E298AE49@AM4PR02MB3138.eurprd02.prod.outlook.com>
 <41479c05-20d8-3bdc-a7cb-c5e5d0d0a91d@oracle.com>
Message-ID: <AM4PR02MB3138C425AA6BDC084EF9668F8AE59@AM4PR02MB3138.eurprd02.prod.outlook.com>

Hi Kevin,

thanks for the information and the link to Erik's mail. I'll request the feature for jdk11u-dev then via a separate mail to ops at o.j.n<mailto:ops at o.j.n>.

Best regards
Christoph

From: Kevin Rushforth <kevin.rushforth at oracle.com>
Sent: Freitag, 23. Juli 2021 00:45
To: Langer, Christoph <christoph.langer at sap.com>; skara-dev at openjdk.java.net; erik.joelsson at oracle.com
Cc: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
Subject: Re: [External] : Backporting a set of patches in a single commit

The only drawback I'm aware of is the bit of extra noise caused by the automatically created "pr/NNNN" branches. If you don't have a dependent PR (which most aren't in my experience), then you can ignore it. If you do, then the branch is there and ready for you to use.

I will look for a write-up, but I don't see one, so I don't know for sure whether Erik H finished docuementing it. The best source of documentation I know of is the "New Skara feature: dependent pull requests" [1] email that Erik H sent in March announcing the feature.

If you want us to enable it, we can enable this some time next week.

-- Kevin

[1] https://mail.openjdk.java.net/pipermail/skara-dev/2021-March/004528.html

On 7/22/2021 2:37 PM, Langer, Christoph wrote:
Hi Kevin,

well, I think then we should try the dependent pull request feature on jdk11u-dev. Is there any drawback besides the additional branches created? Also, is there any documentation?

Thanks
Christoph

From: Kevin Rushforth <kevin.rushforth at oracle.com><mailto:kevin.rushforth at oracle.com>
Sent: Mittwoch, 21. Juli 2021 23:37
To: Langer, Christoph <christoph.langer at sap.com><mailto:christoph.langer at sap.com>; skara-dev at openjdk.java.net<mailto:skara-dev at openjdk.java.net>; erik.joelsson at oracle.com<mailto:erik.joelsson at oracle.com>
Cc: Lindenmaier, Goetz <goetz.lindenmaier at sap.com><mailto:goetz.lindenmaier at sap.com>
Subject: Re: [External] : Backporting a set of patches in a single commit

Hi Christoph,

Yes, I think one solution would be to enable the dependent pull request feature of Skara for your repo. It's already being used by the jdk project. Since it is already implemented and tested (at least for original fixes, but I can't think of anything that would preclude it for backports), it would be easy to set up so you could try it and see if it met your needs.

FWIW, I ran into this in a couple cases myself when backporting fixes to jfx11u after the Skara switch. I ended up testing them in a branch where I pulled in the relevant fixes I needed, and then did them as separate PRs in the right order. Since they were clean it took only a few extra minutes. It was the testing that took all the time anyway, but I couldn't help thinking that dependent pull requests would have made it easier.

-- Kevin


On 7/21/2021 2:20 PM, Langer, Christoph wrote:
Hi Skara Team,

after gathering the first significant experiences with the backport process using GitHub/Skara, I find that there is one use case which works considerably worse than before. It is when you want to backport a set of patches that must be pushed together. Imagine you have a patch, then a build fix and then maybe another test fix. So as to not break builds and tests, you will want to push them together in one go. You could now add those 3 commits into one PR. But when you integrate, the 3 commits get squashed which is contrary to the usual way of backporting which tries to preserve individual commits. Alternatively, you could file 3 separate PRs. This, however, often bears the problem that the PRs might be dependent on each other. So any individual backport PR could possibly only be opened and reviewed after its predecessor was integrated. Which will leave the repo in a bad state for a while.

So what can we do here? Shall we change the paradigm and allow more squashing? Or did you already think of a better workflow? I think there is a feature of Skara called dependent PRs. Could that be used here? Or could maybe the backport bot recognize individual commits to preserve?

Thanks in advance for sharing your thoughts.

Best regards
Christoph




From david.holmes at oracle.com  Fri Jul 23 13:41:57 2021
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 23 Jul 2021 23:41:57 +1000
Subject: GitHub/Mailing list communication defunct?
In-Reply-To: <1ca5b885-0954-894e-f0e4-e8efc72499e6@oracle.com>
References: <AM4PR02MB3138AF92E64168422275C4A48AE29@AM4PR02MB3138.eurprd02.prod.outlook.com>
 <AM4PR02MB3138D37FD95D31D074AF61F78AE39@AM4PR02MB3138.eurprd02.prod.outlook.com>
 <095fc050-dbb1-107d-eac9-89c974ba42b8@oracle.com>
 <f4e3b351-9eb9-32ba-c78c-ed560d90536f@oracle.com>
 <59dd2185-104f-3235-6d8a-5f581f6d99be@gmail.com>
 <1ca5b885-0954-894e-f0e4-e8efc72499e6@oracle.com>
Message-ID: <dfc65a6d-165b-eae2-4db1-d2fb727eac1f@oracle.com>

Hi Kevin,

On 23/07/2021 8:58 am, Kevin Rushforth wrote:
> Thanks for the report. This is now being tracked as a separate issue. 
> It's being looked into, but I don't know more than that.

I'm also noticing this. Is there any update?

Thanks,
David

> -- Kevin
> 
> 
> On 7/22/2021 9:21 AM, Jaikiran Pai wrote:
>> FWIW, it looks like this isn't fully back to normal. From what I can 
>> see in one of the PR's[1] I'm involved in, if I comment directly on 
>> the PR through the github UI, a mail is now getting delivered to the 
>> relevant mailing lists. So this part is back to normal now.
>>
>> However, if someone comments/replies directly to the mailing list 
>> thread (like Bernd and I did, during this past hour[2]), those 
>> comments aren't being registered in that github PR. This used to work 
>> previously and seems to be broken right now.
>>
>> [1] https://github.com/openjdk/jdk/pull/4607
>>
>> [2] 
>> https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-July/079994.html 
>>
>>
>>
>> -Jaikiran
>>
>> On 22/07/21 3:03 am, tim.bell at oracle.com wrote:
>>>> just recognized that all of a sudden the traffic on the OpenJDK 
>>>> mailing lists dropped
>>>
>>> About an hour ago we corrected a problem on the Skara server 
>>> processing external (EG: github) messages.? Message traffic should be 
>>> flowing again.
>>>
>>> Messages for events during the outage are lost.? We will be holding a 
>>> port-mortem to investigate why this outage was not noticed sooner, 
>>> and why there was a data loss.
>>>
>>> Tim
>>>
>>>
>>> On 7/21/21 14:29, David Holmes wrote:
>>>> Hi Christoph,
>>>>
>>>> On 22/07/2021 1:07 am, Langer, Christoph wrote:
>>>>> Hi,
>>>>>
>>>>> there's still no traffic on the mailing lists...
>>>>>
>>>>> It would be much appreciated if you could share an update on the 
>>>>> status.
>>>>
>>>> There was no update to share I'm afraid but it has now been resolved.
>>>>
>>>> It seems likely that the missing mail is gone forever unfortunately.
>>>>
>>>> Cheers,
>>>> David
>>>>
>>>>> Thanks
>>>>> Christoph
>>>>>
>>>>> From: Langer, Christoph
>>>>> Sent: Dienstag, 20. Juli 2021 08:23
>>>>> To: ops at openjdk.java.net; skara-dev at openjdk.java.net; 
>>>>> jdk-dev at openjdk.java.net
>>>>> Subject: GitHub/Mailing list communication defunct?
>>>>>
>>>>> Hi,
>>>>>
>>>>> I just recognized that all of a sudden the traffic on the OpenJDK 
>>>>> mailing lists dropped... First I thought it's an issue with my 
>>>>> account but looking at the pipermail archives, I don't find any 
>>>>> mails after e.g. some time yesterday. And I guess there's still the 
>>>>> usual activity on GitHub...
>>>>>
>>>>> Are you aware of an issue?
>>>>>
>>>>> Thanks & Best regards
>>>>> Christoph
>>>>>
>>>
>>
> 

From tim.bell at oracle.com  Tue Jul 27 17:44:16 2021
From: tim.bell at oracle.com (tim.bell at oracle.com)
Date: Tue, 27 Jul 2021 10:44:16 -0700
Subject: [External] : Re: GitHub/Mailing list communication defunct?
In-Reply-To: <59dd2185-104f-3235-6d8a-5f581f6d99be@gmail.com>
References: <AM4PR02MB3138AF92E64168422275C4A48AE29@AM4PR02MB3138.eurprd02.prod.outlook.com>
 <AM4PR02MB3138D37FD95D31D074AF61F78AE39@AM4PR02MB3138.eurprd02.prod.outlook.com>
 <095fc050-dbb1-107d-eac9-89c974ba42b8@oracle.com>
 <f4e3b351-9eb9-32ba-c78c-ed560d90536f@oracle.com>
 <59dd2185-104f-3235-6d8a-5f581f6d99be@gmail.com>
Message-ID: <f73bae2e-c5b6-b31e-b84b-e02e8dc683cb@oracle.com>

Hello

> if someone comments/replies directly to the mailing list thread (like 
> Bernd and I did, during this past hour[2]), those comments aren't 
> being registered in that github PR. This used to work previously and 
> seems to be broken right now. 

We are aware of this problem and still investigating.? We don't have a 
root cause or an ETA for this.

Tim


On 7/22/21 09:21, Jaikiran Pai wrote:
> FWIW, it looks like this isn't fully back to normal. From what I can 
> see in one of the PR's[1] I'm involved in, if I comment directly on 
> the PR through the github UI, a mail is now getting delivered to the 
> relevant mailing lists. So this part is back to normal now.
>
> However, if someone comments/replies directly to the mailing list 
> thread (like Bernd and I did, during this past hour[2]), those 
> comments aren't being registered in that github PR. This used to work 
> previously and seems to be broken right now.
>
> [1] 
> https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/4607__;!!ACWV5N9M2RV99hQ!eNjD04SNNH9INHTt0cyyed12lRNw9aZfSspNKh0ILIUQCIcvka-_vJ8XHXipGIQ$ 
>
> [2] 
> https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-July/079994.html
>
>
> -Jaikiran
>
> On 22/07/21 3:03 am, tim.bell at oracle.com wrote:
>>> just recognized that all of a sudden the traffic on the OpenJDK 
>>> mailing lists dropped
>>
>> About an hour ago we corrected a problem on the Skara server 
>> processing external (EG: github) messages.? Message traffic should be 
>> flowing again.
>>
>> Messages for events during the outage are lost.? We will be holding a 
>> port-mortem to investigate why this outage was not noticed sooner, 
>> and why there was a data loss.
>>
>> Tim
>>
>>
>> On 7/21/21 14:29, David Holmes wrote:
>>> Hi Christoph,
>>>
>>> On 22/07/2021 1:07 am, Langer, Christoph wrote:
>>>> Hi,
>>>>
>>>> there's still no traffic on the mailing lists...
>>>>
>>>> It would be much appreciated if you could share an update on the 
>>>> status.
>>>
>>> There was no update to share I'm afraid but it has now been resolved.
>>>
>>> It seems likely that the missing mail is gone forever unfortunately.
>>>
>>> Cheers,
>>> David
>>>
>>>> Thanks
>>>> Christoph
>>>>
>>>> From: Langer, Christoph
>>>> Sent: Dienstag, 20. Juli 2021 08:23
>>>> To: ops at openjdk.java.net; skara-dev at openjdk.java.net; 
>>>> jdk-dev at openjdk.java.net
>>>> Subject: GitHub/Mailing list communication defunct?
>>>>
>>>> Hi,
>>>>
>>>> I just recognized that all of a sudden the traffic on the OpenJDK 
>>>> mailing lists dropped... First I thought it's an issue with my 
>>>> account but looking at the pipermail archives, I don't find any 
>>>> mails after e.g. some time yesterday. And I guess there's still the 
>>>> usual activity on GitHub...
>>>>
>>>> Are you aware of an issue?
>>>>
>>>> Thanks & Best regards
>>>> Christoph
>>>>
>>
>