From duke at openjdk.java.net  Mon Jul  1 08:44:33 2019
From: duke at openjdk.java.net (Robin Westberg via github.com)
Date: Mon, 1 Jul 2019 08:44:33 GMT
Subject: RFR: 17: Review comments not reflected on mailing lists
In-Reply-To: <rycyL2WiNQvpCXZsIpzB4n4uO8L6abRu8a1I5v1uzGc=.12712ff4-309c-4f5c-bb58-4e3c634de96b@github.com>
References: <rycyL2WiNQvpCXZsIpzB4n4uO8L6abRu8a1I5v1uzGc=.12712ff4-309c-4f5c-bb58-4e3c634de96b@github.com>
Message-ID: <fnlRwhTVEh8ucl23JGdaaffYew-ZU_ZwEg0gIVFpIdA=.4139a51d-bff7-4187-8d3d-597b720645fb@github.com>

The pull request has been updated with additional changes.

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

Added commits:
 - 52798064:	Fix GitLab integration tests

Pull request:
http://git.openjdk.java.net/skara/pull/11

Webrevs:
 - full: https://openjdk.github.io/cr/skara/11/webrev.01
 - inc: https://openjdk.github.io/cr/skara/11/webrev.00-01

Updated full patch:
http://git.openjdk.java.net/skara/pull/11.diff

Fetch command:
git fetch https://github.com/openjdk/skara.git 52798064:pr/11

From duke at openjdk.java.net  Mon Jul  1 08:49:22 2019
From: duke at openjdk.java.net (Robin Westberg via github.com)
Date: Mon, 1 Jul 2019 08:49:22 GMT
Subject: RFR: 17: Review comments not reflected on mailing lists
In-Reply-To: <QFag5Cdo992yZ4gP_mxxbMXf9TYtAkMs4nPSDFnEEOc=.42f81d50-0fb6-4609-84af-f1f8da9042bc@github.com>
References: <rycyL2WiNQvpCXZsIpzB4n4uO8L6abRu8a1I5v1uzGc=.12712ff4-309c-4f5c-bb58-4e3c634de96b@github.com>
 <QFag5Cdo992yZ4gP_mxxbMXf9TYtAkMs4nPSDFnEEOc=.42f81d50-0fb6-4609-84af-f1f8da9042bc@github.com>
Message-ID: <iyoq8gVrYHtcq5ltSwMQrI07xPAljY3bQfoPtiMe5U8=.ee3e4971-cbc5-4e83-85f5-9c270edfa797@github.com>

On Fri, 28 Jun 2019 13:14:54 GMT, Erik Duveblad via github.com <duke at openjdk.java.net> wrote:

> On Fri, 28 Jun 2019 13:11:29 GMT, Robin Westberg via github.com <duke at openjdk.java.net> wrote:
> 
>> Hi all,
>> 
>> Please review the following change that adds support for comments attached to reviews. This is not supported by GitLab CE, but is used by GitHub.
>> 
>> Best regards,
>> Robin
>> 
>> ----------------
>> 
>> Commits:
>>  - 5c9c290c:	Add support for a comment attached to a review
>> 
>> Pull request:
>> http://git.openjdk.java.net/skara/pull/11
>> 
>> Webrev:
>> https://openjdk.github.io/cr/skara/11/webrev.00
>> 
>> Patch:
>> http://git.openjdk.java.net/skara/pull/11.diff
>> 
>> Fetch command:
>> git fetch https://github.com/openjdk/skara.git 5c9c290c:pr/11
> 
> Ehm, small patch :smile: Did you run the integrations tests for GitLab CE and GitHub to test this?

???? there were actually a few GitLab CE tests failing, fixed now.

From duke at openjdk.java.net  Mon Jul  1 08:54:29 2019
From: duke at openjdk.java.net (Robin Westberg via github.com)
Date: Mon, 1 Jul 2019 08:54:29 GMT
Subject: RFR: Put the credentials lock in the remote repository
Message-ID: <_AwSqsIfcvtDHugwIBnrpLZkEpsjTABF1DhViWIWt8w=.e430b413-80d3-4bb6-ac16-f4015d4d8ff7@github.com>

Hi all,

Please review the following change that puts the credentials lock (used when running integration tests) in the remote repository instead of a local file, to allow the tests to be launched from multiple hosts.

Best regards,
Robin

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

Commits:
 - 110e4eeb:	Put the credentials lock in the remote repository so tests can be started from multiple hosts

Pull request:
http://git.openjdk.java.net/skara/pull/14

Webrev:
https://openjdk.github.io/cr/skara/14/webrev.00

Patch:
http://git.openjdk.java.net/skara/pull/14.diff

Fetch command:
git fetch https://github.com/openjdk/skara.git 110e4eeb:pr/14

From duke at openjdk.java.net  Mon Jul  1 09:19:23 2019
From: duke at openjdk.java.net (Erik Duveblad via github.com)
Date: Mon, 1 Jul 2019 09:19:23 GMT
Subject: RFR: 17: Review comments not reflected on mailing lists
In-Reply-To: <rycyL2WiNQvpCXZsIpzB4n4uO8L6abRu8a1I5v1uzGc=.12712ff4-309c-4f5c-bb58-4e3c634de96b@github.com>
References: <rycyL2WiNQvpCXZsIpzB4n4uO8L6abRu8a1I5v1uzGc=.12712ff4-309c-4f5c-bb58-4e3c634de96b@github.com>
Message-ID: <xsSGjPoDDdoFfFsq-AaoIrbb4bYZ8FHjGgQWjhneDv8=.edfdb332-24ff-4f02-859b-56b4d37ff1b5@github.com>

This PR has now been reviewed by Erik Duveblad via github.com - changes are approved.

From duke at openjdk.java.net  Mon Jul  1 09:23:54 2019
From: duke at openjdk.java.net (Erik Duveblad via github.com)
Date: Mon, 1 Jul 2019 09:23:54 GMT
Subject: RFR: Put the credentials lock in the remote repository
In-Reply-To: <_AwSqsIfcvtDHugwIBnrpLZkEpsjTABF1DhViWIWt8w=.e430b413-80d3-4bb6-ac16-f4015d4d8ff7@github.com>
References: <_AwSqsIfcvtDHugwIBnrpLZkEpsjTABF1DhViWIWt8w=.e430b413-80d3-4bb6-ac16-f4015d4d8ff7@github.com>
Message-ID: <_nYoeKFEXjHtSoSSmhYawli0bh6B1zxHpTB6DoeuwpU=.76df2680-603a-4009-be0d-47b46104ceb5@github.com>

On Mon, 1 Jul 2019 08:54:29 GMT, Robin Westberg via github.com <duke at openjdk.java.net> wrote:

> Hi all,
> 
> Please review the following change that puts the credentials lock (used when running integration tests) in the remote repository instead of a local file, to allow the tests to be launched from multiple hosts.
> 
> Best regards,
> Robin
> 
> ----------------
> 
> Commits:
>  - 110e4eeb:	Put the credentials lock in the remote repository so tests can be started from multiple hosts
> 
> Pull request:
> http://git.openjdk.java.net/skara/pull/14
> 
> Webrev:
> https://openjdk.github.io/cr/skara/14/webrev.00
> 
> Patch:
> http://git.openjdk.java.net/skara/pull/14.diff
> 
> Fetch command:
> git fetch https://github.com/openjdk/skara.git 110e4eeb:pr/14

test/src/main/java/org/openjdk/skara/test/HostCredentials.java line 85:

> 84:         public String getNamespaceName() {
> 85:             return config.get("namespace").asString();
> 86:         }

Maybe add a comment that `localRepo.push` will throw an `IOException` if the push fails?

test/src/main/java/org/openjdk/skara/test/HostCredentials.java line 100:

> 99:             var users = config.get("users").asArray();
> 100:             var pat = new PersonalAccessToken(users.get(userIndex).get("name").asString(),
> 101:                                               users.get(userIndex).get("pat").asString());

Please change the commit message comment to "Unlock" to help future debugging

From duke at openjdk.java.net  Mon Jul  1 09:23:56 2019
From: duke at openjdk.java.net (Erik Duveblad via github.com)
Date: Mon, 1 Jul 2019 09:23:56 GMT
Subject: RFR: Put the credentials lock in the remote repository
In-Reply-To: <_AwSqsIfcvtDHugwIBnrpLZkEpsjTABF1DhViWIWt8w=.e430b413-80d3-4bb6-ac16-f4015d4d8ff7@github.com>
References: <_AwSqsIfcvtDHugwIBnrpLZkEpsjTABF1DhViWIWt8w=.e430b413-80d3-4bb6-ac16-f4015d4d8ff7@github.com>
Message-ID: <Jn8kriKyb2KGCnrV-490W-tVaHRqVQnNnHYuQILss0w=.3100302d-65ce-4fc5-9d28-c9acaba4a9d6@github.com>

This PR has now been reviewed by Erik Duveblad via github.com - comment added.

From duke at openjdk.java.net  Mon Jul  1 09:26:54 2019
From: duke at openjdk.java.net (Robin Westberg via github.com)
Date: Mon, 1 Jul 2019 09:26:54 GMT
Subject: RFR: Put the credentials lock in the remote repository
In-Reply-To: <_AwSqsIfcvtDHugwIBnrpLZkEpsjTABF1DhViWIWt8w=.e430b413-80d3-4bb6-ac16-f4015d4d8ff7@github.com>
References: <_AwSqsIfcvtDHugwIBnrpLZkEpsjTABF1DhViWIWt8w=.e430b413-80d3-4bb6-ac16-f4015d4d8ff7@github.com>
Message-ID: <PEmCpFVCWRGImakXyY8FSkOcG5R2_lcs_bxC7fimigQ=.5eab964c-46fc-4acf-b7c2-d5c491cdfd4a@github.com>

This PR has now been reviewed by Robin Westberg via github.com - comment added.

From duke at openjdk.java.net  Mon Jul  1 09:26:53 2019
From: duke at openjdk.java.net (Robin Westberg via github.com)
Date: Mon, 1 Jul 2019 09:26:53 GMT
Subject: RFR: Put the credentials lock in the remote repository
In-Reply-To: <2fCpKmkmbtoXulyPqhDFK2CcKpjDhIpAznal0ceuSss=.a03dd487-d485-4fb3-984e-eda93a5738d4@github.com>
References: <_AwSqsIfcvtDHugwIBnrpLZkEpsjTABF1DhViWIWt8w=.e430b413-80d3-4bb6-ac16-f4015d4d8ff7@github.com>
 <2fCpKmkmbtoXulyPqhDFK2CcKpjDhIpAznal0ceuSss=.a03dd487-d485-4fb3-984e-eda93a5738d4@github.com>
Message-ID: <04JuBU2Bcgwgyk8pIAuo3dp9XkQfvRGdBQrSMnPIQ3w=.5d4bedeb-8ae9-4e5e-8bdd-46dff217f0b7@github.com>

On Mon, 1 Jul 2019 09:23:55 GMT, Erik Duveblad via github.com <duke at openjdk.java.net> wrote:

> On Mon, 1 Jul 2019 08:54:29 GMT, Robin Westberg via github.com <duke at openjdk.java.net> wrote:
> 
>> Hi all,
>> 
>> Please review the following change that puts the credentials lock (used when running integration tests) in the remote repository instead of a local file, to allow the tests to be launched from multiple hosts.
>> 
>> Best regards,
>> Robin
>> 
>> ----------------
>> 
>> Commits:
>>  - 110e4eeb:	Put the credentials lock in the remote repository so tests can be started from multiple hosts
>> 
>> Pull request:
>> http://git.openjdk.java.net/skara/pull/14
>> 
>> Webrev:
>> https://openjdk.github.io/cr/skara/14/webrev.00
>> 
>> Patch:
>> http://git.openjdk.java.net/skara/pull/14.diff
>> 
>> Fetch command:
>> git fetch https://github.com/openjdk/skara.git 110e4eeb:pr/14
> 
> test/src/main/java/org/openjdk/skara/test/HostCredentials.java line 100:
> 
>> 99:             var users = config.get("users").asArray();
>> 100:             var pat = new PersonalAccessToken(users.get(userIndex).get("name").asString(),
>> 101:                                               users.get(userIndex).get("pat").asString());
> 
> Please change the commit message comment to "Unlock" to help future debugging

Good point

From duke at openjdk.java.net  Mon Jul  1 09:27:24 2019
From: duke at openjdk.java.net (Robin Westberg via github.com)
Date: Mon, 1 Jul 2019 09:27:24 GMT
Subject: RFR: Put the credentials lock in the remote repository
In-Reply-To: <_nYoeKFEXjHtSoSSmhYawli0bh6B1zxHpTB6DoeuwpU=.76df2680-603a-4009-be0d-47b46104ceb5@github.com>
References: <_AwSqsIfcvtDHugwIBnrpLZkEpsjTABF1DhViWIWt8w=.e430b413-80d3-4bb6-ac16-f4015d4d8ff7@github.com>
 <_nYoeKFEXjHtSoSSmhYawli0bh6B1zxHpTB6DoeuwpU=.76df2680-603a-4009-be0d-47b46104ceb5@github.com>
Message-ID: <QhUvk0ZkLrzacKI0f4HxTC6xkXroKqISsDc6bh-4xMs=.74998e4e-cb32-4589-86dd-4af4efa1a498@github.com>

On Mon, 1 Jul 2019 09:23:54 GMT, Erik Duveblad via github.com <duke at openjdk.java.net> wrote:

> On Mon, 1 Jul 2019 08:54:29 GMT, Robin Westberg via github.com <duke at openjdk.java.net> wrote:
> 
>> Hi all,
>> 
>> Please review the following change that puts the credentials lock (used when running integration tests) in the remote repository instead of a local file, to allow the tests to be launched from multiple hosts.
>> 
>> Best regards,
>> Robin
>> 
>> ----------------
>> 
>> Commits:
>>  - 110e4eeb:	Put the credentials lock in the remote repository so tests can be started from multiple hosts
>> 
>> Pull request:
>> http://git.openjdk.java.net/skara/pull/14
>> 
>> Webrev:
>> https://openjdk.github.io/cr/skara/14/webrev.00
>> 
>> Patch:
>> http://git.openjdk.java.net/skara/pull/14.diff
>> 
>> Fetch command:
>> git fetch https://github.com/openjdk/skara.git 110e4eeb:pr/14
> 
> test/src/main/java/org/openjdk/skara/test/HostCredentials.java line 85:
> 
>> 84:         public String getNamespaceName() {
>> 85:             return config.get("namespace").asString();
>> 86:         }
> 
> Maybe add a comment that `localRepo.push` will throw an `IOException` if the push fails?

Can clarify the existing comment

From duke at openjdk.java.net  Mon Jul  1 09:28:00 2019
From: duke at openjdk.java.net (Robin Westberg via github.com)
Date: Mon, 1 Jul 2019 09:28:00 GMT
Subject: RFR: Put the credentials lock in the remote repository
In-Reply-To: <_AwSqsIfcvtDHugwIBnrpLZkEpsjTABF1DhViWIWt8w=.e430b413-80d3-4bb6-ac16-f4015d4d8ff7@github.com>
References: <_AwSqsIfcvtDHugwIBnrpLZkEpsjTABF1DhViWIWt8w=.e430b413-80d3-4bb6-ac16-f4015d4d8ff7@github.com>
Message-ID: <tW6cnjSvsux1ATv40zQ1HpeGCadlHLpfBZe0JZgO_U8=.3e7c7b77-b567-4498-b5f2-7659006b332b@github.com>

The pull request has been updated with additional changes.

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

Added commits:
 - 376da882:	Review updates

Pull request:
http://git.openjdk.java.net/skara/pull/14

Webrevs:
 - full: https://openjdk.github.io/cr/skara/14/webrev.01
 - inc: https://openjdk.github.io/cr/skara/14/webrev.00-01

Updated full patch:
http://git.openjdk.java.net/skara/pull/14.diff

Fetch command:
git fetch https://github.com/openjdk/skara.git 376da882:pr/14

From duke at openjdk.java.net  Mon Jul  1 09:28:55 2019
From: duke at openjdk.java.net (duke)
Date: Mon, 1 Jul 2019 09:28:55 GMT
Subject: git: openjdk/skara: 17: Review comments not reflected on mailing lists
Message-ID: <e8773ace-a17b-49ef-8a32-2497b4141952@openjdk.java.net>

Changeset: 3565522e
Author:    Robin Westberg <rwestberg at openjdk.org>
Date:      2019-07-01 09:28:24 +0000
URL:       http://git.openjdk.java.net/skara/commit/3565522e

17: Review comments not reflected on mailing lists

Reviewed-by: ehelin

! bots/mlbridge/src/main/java/org/openjdk/skara/bots/mlbridge/ArchiveWorkItem.java
! bots/mlbridge/src/test/java/org/openjdk/skara/bots/mlbridge/MailingListBridgeBotTests.java
! bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckRun.java
! bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckWorkItem.java
! bots/pr/src/main/java/org/openjdk/skara/bots/pr/PullRequestInstance.java
! bots/pr/src/main/java/org/openjdk/skara/bots/pr/ReviewTracker.java
! bots/pr/src/test/java/org/openjdk/skara/bots/pr/CheckTests.java
! bots/pr/src/test/java/org/openjdk/skara/bots/pr/ContributorTests.java
! bots/pr/src/test/java/org/openjdk/skara/bots/pr/IntegrateTests.java
! bots/pr/src/test/java/org/openjdk/skara/bots/pr/MergeTests.java
! bots/pr/src/test/java/org/openjdk/skara/bots/pr/SponsorTests.java
! bots/pr/src/test/java/org/openjdk/skara/bots/pr/VetoTests.java
! host/src/main/java/org/openjdk/skara/host/PullRequest.java
! host/src/main/java/org/openjdk/skara/host/Review.java
! host/src/main/java/org/openjdk/skara/host/github/GitHubPullRequest.java
! host/src/main/java/org/openjdk/skara/host/gitlab/GitLabMergeRequest.java
! test/src/main/java/org/openjdk/skara/test/TestPullRequest.java



From duke at openjdk.java.net  Mon Jul  1 09:41:59 2019
From: duke at openjdk.java.net (Erik Duveblad via github.com)
Date: Mon, 1 Jul 2019 09:41:59 GMT
Subject: RFR: 32: GitRepository::show does not work with executable files
Message-ID: <KN5_y5PuzxPqYTeqFV74YJuDTGGX82j-ftH-Ju2NuCM=.bdc6c41c-6eb3-4a3f-bd5e-aa18a60740b8@github.com>

Hi all,

this small patch fixes a bug that `GitRepository::show` did not work with executable files. I also added unit test for the scenario.

Testing: passes `sh gradlew test` on Linux x86-64

Thanks,
Erik

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

Commits:
 - df788d23:	32: GitRepository::show does not work with executable files

Pull request:
http://git.openjdk.java.net/skara/pull/15

Webrev:
https://openjdk.github.io/cr/skara/15/webrev.00

Patch:
http://git.openjdk.java.net/skara/pull/15.diff

Fetch command:
git fetch https://github.com/openjdk/skara.git df788d23:pr/15

From duke at openjdk.java.net  Mon Jul  1 09:42:53 2019
From: duke at openjdk.java.net (Erik Duveblad via github.com)
Date: Mon, 1 Jul 2019 09:42:53 GMT
Subject: RFR: Put the credentials lock in the remote repository
In-Reply-To: <_AwSqsIfcvtDHugwIBnrpLZkEpsjTABF1DhViWIWt8w=.e430b413-80d3-4bb6-ac16-f4015d4d8ff7@github.com>
References: <_AwSqsIfcvtDHugwIBnrpLZkEpsjTABF1DhViWIWt8w=.e430b413-80d3-4bb6-ac16-f4015d4d8ff7@github.com>
Message-ID: <jjtb6eM93TIOBocZek-aNE8u6xABLBwvSYb7yu_sZkg=.da52d1c5-37e5-460c-bb43-e9020a53da00@github.com>

The PR reviewed by Erik Duveblad via github.com has now been updated - changes are approved.

From duke at openjdk.java.net  Mon Jul  1 09:49:48 2019
From: duke at openjdk.java.net (Robin Westberg via github.com)
Date: Mon, 1 Jul 2019 09:49:48 GMT
Subject: RFR: 32: GitRepository::show does not work with executable files
In-Reply-To: <KN5_y5PuzxPqYTeqFV74YJuDTGGX82j-ftH-Ju2NuCM=.bdc6c41c-6eb3-4a3f-bd5e-aa18a60740b8@github.com>
References: <KN5_y5PuzxPqYTeqFV74YJuDTGGX82j-ftH-Ju2NuCM=.bdc6c41c-6eb3-4a3f-bd5e-aa18a60740b8@github.com>
Message-ID: <nyCMbQD783A3M1tQ-nKzeINUp7UDbca4TvwHARRBQ6k=.17f9e559-d5c3-4b85-be33-a5773a5a6a2e@github.com>

This PR has now been reviewed by Robin Westberg via github.com - changes are approved.

From duke at openjdk.java.net  Mon Jul  1 09:50:50 2019
From: duke at openjdk.java.net (duke)
Date: Mon, 1 Jul 2019 09:50:50 GMT
Subject: git: openjdk/skara: 32: GitRepository::show does not work with
 executable files
Message-ID: <24d440d1-49a3-456b-8c1f-f4098fae381c@openjdk.java.net>

Changeset: 728cfa13
Author:    Erik Helin <ehelin at openjdk.org>
Date:      2019-07-01 09:50:19 +0000
URL:       http://git.openjdk.java.net/skara/commit/728cfa13

32: GitRepository::show does not work with executable files

Reviewed-by: rwestberg

! vcs/src/main/java/org/openjdk/skara/vcs/git/GitRepository.java
! vcs/src/test/java/org/openjdk/skara/vcs/RepositoryTests.java
! webrev/src/main/java/org/openjdk/skara/webrev/ModifiedFileView.java



From duke at openjdk.java.net  Mon Jul  1 10:58:54 2019
From: duke at openjdk.java.net (Marcus Hirt via github.com)
Date: Mon, 1 Jul 2019 10:58:54 GMT
Subject: RFR: Adding project explanation
Message-ID: <ViC3miWf_AcGfJFNmyxkETrL0CWEIyBnIvtvdWd802o=.759b9a05-adf5-4f1b-8c98-2d80ff6c0097@github.com>

..as suggested in the Twitter discussion. :)

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

Commits:
 - 4578553b:	Adding project explanation

Pull request:
http://git.openjdk.java.net/skara/pull/16

Webrev:
https://openjdk.github.io/cr/skara/16/webrev.00

Patch:
http://git.openjdk.java.net/skara/pull/16.diff

Fetch command:
git fetch https://github.com/openjdk/skara.git 4578553b:pr/16

From duke at openjdk.java.net  Mon Jul  1 11:13:26 2019
From: duke at openjdk.java.net (Marcus Hirt via github.com)
Date: Mon, 1 Jul 2019 11:13:26 GMT
Subject: RFR: Adding project explanation
In-Reply-To: <ViC3miWf_AcGfJFNmyxkETrL0CWEIyBnIvtvdWd802o=.759b9a05-adf5-4f1b-8c98-2d80ff6c0097@github.com>
References: <ViC3miWf_AcGfJFNmyxkETrL0CWEIyBnIvtvdWd802o=.759b9a05-adf5-4f1b-8c98-2d80ff6c0097@github.com>
Message-ID: <LkJQ8Bvnt-v26fkJz-d3nUO8hzp2N2nifF2jRUe1Mxk=.30153020-aa64-49d5-9172-4fba61f5841c@github.com>

The pull request has been updated with additional changes.

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

Added commits:
 - 6e020c80:	Adding line breaks

Pull request:
http://git.openjdk.java.net/skara/pull/16

Webrevs:
 - full: https://openjdk.github.io/cr/skara/16/webrev.01
 - inc: https://openjdk.github.io/cr/skara/16/webrev.00-01

Updated full patch:
http://git.openjdk.java.net/skara/pull/16.diff

Fetch command:
git fetch https://github.com/openjdk/skara.git 6e020c80:pr/16

From duke at openjdk.java.net  Mon Jul  1 11:32:53 2019
From: duke at openjdk.java.net (Hendrik Ebbers via github.com)
Date: Mon, 1 Jul 2019 11:32:53 GMT
Subject: RFR: Code of conduction added
Message-ID: <WCnxs-gzw4UxPyWCI7XgoYkPGPwYDwRg_QWQ2n9Wflw=.c40b94be-8aa5-4102-8799-1c49b22ea850@github.com>

I added a code of conduction that is based on http://contributor-covenant.org
I think it makes always sense to have such file and with OpenJDK moving to GitHub it could easily be added to each repo. 

Only open point is the team mail address that should be added to the document (see TODO_MAIL_ADRESS). If you add the mail address as a comment in this PR I can add it.

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

Commits:
 - 67b603b3:	Code of conduction added

Pull request:
http://git.openjdk.java.net/skara/pull/17

Webrev:
https://openjdk.github.io/cr/skara/17/webrev.00

Patch:
http://git.openjdk.java.net/skara/pull/17.diff

Fetch command:
git fetch https://github.com/openjdk/skara.git 67b603b3:pr/17

From duke at openjdk.java.net  Mon Jul  1 12:57:19 2019
From: duke at openjdk.java.net (duke)
Date: Mon, 1 Jul 2019 12:57:19 GMT
Subject: git: openjdk/skara: Put the credentials lock in the remote repository
Message-ID: <f75471dd-96b6-4794-b6db-5c82b5dc8169@openjdk.java.net>

Changeset: c704f49f
Author:    Robin Westberg <rwestberg at openjdk.org>
Date:      2019-07-01 12:56:49 +0000
URL:       http://git.openjdk.java.net/skara/commit/c704f49f

Put the credentials lock in the remote repository

Reviewed-by: ehelin

! build.gradle
! test/src/main/java/org/openjdk/skara/test/HostCredentials.java



From duke at openjdk.java.net  Mon Jul  1 13:38:23 2019
From: duke at openjdk.java.net (Erik Duveblad via github.com)
Date: Mon, 1 Jul 2019 13:38:23 GMT
Subject: RFR: Adding project explanation
In-Reply-To: <ViC3miWf_AcGfJFNmyxkETrL0CWEIyBnIvtvdWd802o=.759b9a05-adf5-4f1b-8c98-2d80ff6c0097@github.com>
References: <ViC3miWf_AcGfJFNmyxkETrL0CWEIyBnIvtvdWd802o=.759b9a05-adf5-4f1b-8c98-2d80ff6c0097@github.com>
Message-ID: <Trz8ksRvquYdtzaA_IYYefuHLfohQrbQwQ1NryPjWFU=.cf7f2097-ad27-4b76-a936-2dc8bdc529c6@github.com>

On Mon, 1 Jul 2019 10:58:54 GMT, Marcus Hirt via github.com <duke at openjdk.java.net> wrote:

> ...as suggested in the Twitter discussion. :)
> 
> ----------------
> 
> Commits:
>  - 4578553b:	Adding project explanation
> 
> Pull request:
> http://git.openjdk.java.net/skara/pull/16
> 
> Webrev:
> https://openjdk.github.io/cr/skara/16/webrev.00
> 
> Patch:
> http://git.openjdk.java.net/skara/pull/16.diff
> 
> Fetch command:
> git fetch https://github.com/openjdk/skara.git 4578553b:pr/16

:tada: :rofl:

From duke at openjdk.java.net  Mon Jul  1 13:48:29 2019
From: duke at openjdk.java.net (Erik Duveblad via github.com)
Date: Mon, 1 Jul 2019 13:48:29 GMT
Subject: RFR: 34: Simplify Gradle proxy plugin
Message-ID: <ofoqazA9zXOTGGzvvLFZOnfnUOWaaz2VyfKtnfqk24o=.9196306f-10a2-4900-b71d-9b2b2a47a9db@github.com>

Hi all,

this small patch simplifies hows the `no_proxy` environment variable is handle in the Gradle proxy plugin.

Thanks,
Erik

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

Commits:
 - 7d24a6ef:	34: Simplify Gradle proxy plugin

Pull request:
http://git.openjdk.java.net/skara/pull/18

Webrev:
https://openjdk.github.io/cr/skara/18/webrev.00

Patch:
http://git.openjdk.java.net/skara/pull/18.diff

Fetch command:
git fetch https://github.com/openjdk/skara.git 7d24a6ef:pr/18

From duke at openjdk.java.net  Mon Jul  1 13:54:59 2019
From: duke at openjdk.java.net (Robin Westberg via github.com)
Date: Mon, 1 Jul 2019 13:54:59 GMT
Subject: RFR: 20: Do not send emails that a reviewer has added a comment
Message-ID: <FTzuvLjxgTeSC6BSfSwTX8wIgDWX1rUHzkp2wUeMIgY=.9bf2913d-2a01-4a4c-abf6-9134732a8b59@github.com>

Hi all,

Please review the following change that stops adding PR comments when a review is updated, if the host supports attaching comments directly to reviews (such as GitHub, but not GitLab CE).

Best regards,
Robin

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

Commits:
 - 68dafb3d:	Fix build issue
 - 3850348e:	Skip non-relevant test
 - 4d54d9e1:	Posting a PR comment when a review is found is only useful on GitLab CE

Pull request:
http://git.openjdk.java.net/skara/pull/19

Webrev:
https://openjdk.github.io/cr/skara/19/webrev.00

Patch:
http://git.openjdk.java.net/skara/pull/19.diff

Fetch command:
git fetch https://github.com/openjdk/skara.git 68dafb3d:pr/19

From duke at openjdk.java.net  Mon Jul  1 13:55:24 2019
From: duke at openjdk.java.net (Robin Westberg via github.com)
Date: Mon, 1 Jul 2019 13:55:24 GMT
Subject: RFR: 34: Simplify Gradle proxy plugin
In-Reply-To: <ofoqazA9zXOTGGzvvLFZOnfnUOWaaz2VyfKtnfqk24o=.9196306f-10a2-4900-b71d-9b2b2a47a9db@github.com>
References: <ofoqazA9zXOTGGzvvLFZOnfnUOWaaz2VyfKtnfqk24o=.9196306f-10a2-4900-b71d-9b2b2a47a9db@github.com>
Message-ID: <Ic_oBQVJZmTn4XmakDbmvgkAhK2tBxJSxq7yBUsNrK0=.6964425c-5a9f-4e44-a74e-e2cf7d20fa59@github.com>

This PR has now been reviewed by Robin Westberg via github.com - changes are approved.

From neugens at redhat.com  Mon Jul  1 13:59:19 2019
From: neugens at redhat.com (Mario Torre)
Date: Mon, 1 Jul 2019 15:59:19 +0200
Subject: RFR: Adding project explanation
In-Reply-To: <Trz8ksRvquYdtzaA_IYYefuHLfohQrbQwQ1NryPjWFU=.cf7f2097-ad27-4b76-a936-2dc8bdc529c6@github.com>
References: <ViC3miWf_AcGfJFNmyxkETrL0CWEIyBnIvtvdWd802o=.759b9a05-adf5-4f1b-8c98-2d80ff6c0097@github.com>
 <Trz8ksRvquYdtzaA_IYYefuHLfohQrbQwQ1NryPjWFU=.cf7f2097-ad27-4b76-a936-2dc8bdc529c6@github.com>
Message-ID: <CAJwKKma+RbNPkCiRhm6ezbhX0k9y2L+Fd=_7_tdZ5en0rFWNcg@mail.gmail.com>

> > ...as suggested in the Twitter discussion. :)
> :tada: :rofl:

Awesome, so now not only we need to track github as a whole, but also
twitter to get proper context for changesets! :)

I still think that the old good mailing list are the way to go ;)

Cheers,
Mario

-- 
Mario Torre
Associate Manager, Software Engineering
Red Hat GmbH <https://www.redhat.com>
9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898

From duke at openjdk.java.net  Mon Jul  1 14:07:24 2019
From: duke at openjdk.java.net (Erik Duveblad via github.com)
Date: Mon, 1 Jul 2019 14:07:24 GMT
Subject: RFR: 20: Do not send emails that a reviewer has added a comment
In-Reply-To: <FTzuvLjxgTeSC6BSfSwTX8wIgDWX1rUHzkp2wUeMIgY=.9bf2913d-2a01-4a4c-abf6-9134732a8b59@github.com>
References: <FTzuvLjxgTeSC6BSfSwTX8wIgDWX1rUHzkp2wUeMIgY=.9bf2913d-2a01-4a4c-abf6-9134732a8b59@github.com>
Message-ID: <Nkl03iYpjvW0KJe5J8ae3ObSj3VChQXawTs_X9828Ak=.372e1fe1-169f-4bbd-93d5-17e515b358e8@github.com>

This PR has now been reviewed by Erik Duveblad via github.com - changes are approved.

From duke at openjdk.java.net  Mon Jul  1 14:08:25 2019
From: duke at openjdk.java.net (duke)
Date: Mon, 1 Jul 2019 14:08:25 GMT
Subject: git: openjdk/skara: 20: Do not send emails that a reviewer has added
 a comment
Message-ID: <33660687-761e-41ac-b38c-a70d687ef53c@openjdk.java.net>

Changeset: 2a1e24bd
Author:    Robin Westberg <rwestberg at openjdk.org>
Date:      2019-07-01 14:07:55 +0000
URL:       http://git.openjdk.java.net/skara/commit/2a1e24bd

20: Do not send emails that a reviewer has added a comment

Reviewed-by: ehelin

! bots/mlbridge/src/test/java/org/openjdk/skara/bots/mlbridge/MailingListBridgeBotTests.java
! bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckRun.java
! bots/pr/src/test/java/org/openjdk/skara/bots/pr/CheckTests.java
! cli/src/main/java/org/openjdk/skara/cli/GitPr.java
! host/src/main/java/org/openjdk/skara/host/Host.java
! host/src/main/java/org/openjdk/skara/host/github/GitHubHost.java
! host/src/main/java/org/openjdk/skara/host/gitlab/GitLabHost.java
! test/src/main/java/org/openjdk/skara/test/TestHost.java



From duke at openjdk.java.net  Mon Jul  1 14:11:25 2019
From: duke at openjdk.java.net (duke)
Date: Mon, 1 Jul 2019 14:11:25 GMT
Subject: git: openjdk/skara: 34: Simplify Gradle proxy plugin
Message-ID: <7488c328-2e85-4124-aa3b-71b16ffb0ced@openjdk.java.net>

Changeset: 0226b40f
Author:    Erik Helin <ehelin at openjdk.org>
Date:      2019-07-01 14:10:55 +0000
URL:       http://git.openjdk.java.net/skara/commit/0226b40f

34: Simplify Gradle proxy plugin

Reviewed-by: rwestberg

! buildSrc/proxy/src/main/java/org/openjdk/skara/gradle/proxy/ProxyPlugin.java



From duke at openjdk.java.net  Mon Jul  1 14:14:24 2019
From: duke at openjdk.java.net (Marcus Hirt via github.com)
Date: Mon, 1 Jul 2019 14:14:24 GMT
Subject: RFR: Adding project explanation
In-Reply-To: <Trz8ksRvquYdtzaA_IYYefuHLfohQrbQwQ1NryPjWFU=.cf7f2097-ad27-4b76-a936-2dc8bdc529c6@github.com>
References: <ViC3miWf_AcGfJFNmyxkETrL0CWEIyBnIvtvdWd802o=.759b9a05-adf5-4f1b-8c98-2d80ff6c0097@github.com>
 <Trz8ksRvquYdtzaA_IYYefuHLfohQrbQwQ1NryPjWFU=.cf7f2097-ad27-4b76-a936-2dc8bdc529c6@github.com>
Message-ID: <cZyrRU-vzaAhoXkr_tQTB4FxNuxzbN-tgHWXB9hgjJE=.e3f19e42-9354-4750-85c1-b0757300d92e@github.com>

On Mon, 1 Jul 2019 13:38:23 GMT, Erik Duveblad via github.com <duke at openjdk.java.net> wrote:

> On Mon, 1 Jul 2019 10:58:54 GMT, Marcus Hirt via github.com <duke at openjdk.java.net> wrote:
> 
>> ...as suggested in the Twitter discussion. :)
>> 
>> ----------------
>> 
>> Commits:
>>  - 4578553b:	Adding project explanation
>> 
>> Pull request:
>> http://git.openjdk.java.net/skara/pull/16
>> 
>> Webrev:
>> https://openjdk.github.io/cr/skara/16/webrev.00
>> 
>> Patch:
>> http://git.openjdk.java.net/skara/pull/16.diff
>> 
>> Fetch command:
>> git fetch https://github.com/openjdk/skara.git 4578553b:pr/16
> 
> :tada: :rofl:

That's a great band name right there - Indecisive Bots!

From erik.helin at oracle.com  Mon Jul  1 14:45:40 2019
From: erik.helin at oracle.com (Erik Helin)
Date: Mon, 1 Jul 2019 16:45:40 +0200
Subject: RFR: Adding project explanation
In-Reply-To: <CAJwKKma+RbNPkCiRhm6ezbhX0k9y2L+Fd=_7_tdZ5en0rFWNcg@mail.gmail.com>
References: <ViC3miWf_AcGfJFNmyxkETrL0CWEIyBnIvtvdWd802o=.759b9a05-adf5-4f1b-8c98-2d80ff6c0097@github.com>
 <Trz8ksRvquYdtzaA_IYYefuHLfohQrbQwQ1NryPjWFU=.cf7f2097-ad27-4b76-a936-2dc8bdc529c6@github.com>
 <CAJwKKma+RbNPkCiRhm6ezbhX0k9y2L+Fd=_7_tdZ5en0rFWNcg@mail.gmail.com>
Message-ID: <2fee7acf-5c19-2ab3-0a1c-1b46e0b037a3@oracle.com>

On 7/1/19 3:59 PM, Mario Torre wrote:
>>> ...as suggested in the Twitter discussion. :)
>> :tada: :rofl:
> 
> Awesome, so now not only we need to track github as a whole, but also
> twitter to get proper context for changesets! :)

I was just about to ask Marcus to update the description for the patch, 
as I don't follow nor use Twitter myself.

I think it is fairly obvious that we are still tuning a few knobs and 
that Skara is under active development, making steady progress day by 
day. We did run into a (pretty hilarious) Skara bug for this PR from 
Marcus, to which I reacted with a comment containing a few emojis. The 
comment was made in response to a number of label updates by the bots, 
which is why the comment is out of context here on the mailing list.

I want to highlight that this _not_ a normal situation, label updates on 
pull requests do not in general convey enough useful information to 
merit relaying them to a mailing list (nor comment on them). We 
primarily use labels to aid people who want to sort pull requests in 
various ways. We could send label updates to the mailing list as well, 
but I think it would just annoy people (it would annoy me at least).

> I still think that the old good mailing list are the way to go ;)

We also like mailing lists! I use skara-dev all the time to keep track 
of patches, comments and discussion. I want to be very clear that the 
goal is *not* to replace the mailing lists, we continue to work very 
hard to ensure that a contributor who wishes to use the mailing lists 
and the CLI should have a great experience.

The above doesn't mean we don't have a few bugs, Robin is currently 
working on making the mailing list experience better. If you have any 
additional feedback after following skara-dev then we'd be happy to hear 
it! And as usual, if you see something you think is a bug, then please 
file one [0].

Thanks,
Erik

[0]: https://bugs.openjdk.java.net/projects/SKARA/issues

From duke at openjdk.java.net  Mon Jul  1 22:11:21 2019
From: duke at openjdk.java.net (Marcus Hirt via github.com)
Date: Mon, 1 Jul 2019 22:11:21 GMT
Subject: RFR: Adding project explanation
In-Reply-To: <cZyrRU-vzaAhoXkr_tQTB4FxNuxzbN-tgHWXB9hgjJE=.e3f19e42-9354-4750-85c1-b0757300d92e@github.com>
References: <ViC3miWf_AcGfJFNmyxkETrL0CWEIyBnIvtvdWd802o=.759b9a05-adf5-4f1b-8c98-2d80ff6c0097@github.com>
 <Trz8ksRvquYdtzaA_IYYefuHLfohQrbQwQ1NryPjWFU=.cf7f2097-ad27-4b76-a936-2dc8bdc529c6@github.com>
 <cZyrRU-vzaAhoXkr_tQTB4FxNuxzbN-tgHWXB9hgjJE=.e3f19e42-9354-4750-85c1-b0757300d92e@github.com>
Message-ID: <-MuST5mONgBhLsT7eHFFxfcAKD4UfHXIaFVGSPw-qC4=.ff125f4f-5209-47dd-b30b-d93332f5e3eb@github.com>

On Mon, 1 Jul 2019 14:14:24 GMT, Marcus Hirt via github.com <duke at openjdk.java.net> wrote:

> On Mon, 1 Jul 2019 13:38:23 GMT, Erik Duveblad via github.com <duke at openjdk.java.net> wrote:
> 
>> On Mon, 1 Jul 2019 10:58:54 GMT, Marcus Hirt via github.com <duke at openjdk.java.net> wrote:
>> 
>>> ...as suggested in the Twitter discussion. :)
>>> 
>>> ----------------
>>> 
>>> Commits:
>>>  - 4578553b:	Adding project explanation
>>> 
>>> Pull request:
>>> http://git.openjdk.java.net/skara/pull/16
>>> 
>>> Webrev:
>>> https://openjdk.github.io/cr/skara/16/webrev.00
>>> 
>>> Patch:
>>> http://git.openjdk.java.net/skara/pull/16.diff
>>> 
>>> Fetch command:
>>> git fetch https://github.com/openjdk/skara.git 4578553b:pr/16
>> 
>> :tada: :rofl:
> 
> That's a great band name right there - Indecisive Bots!

Here is the twitter discussion:
https://twitter.com/emilianbold/status/1143175227616239618?s=21

From joe.darcy at oracle.com  Mon Jul  1 23:51:29 2019
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Mon, 01 Jul 2019 16:51:29 -0700
Subject: CFV: New Skara Committer: Jorn Vernee
In-Reply-To: <eb140682-a3d8-1d45-beb9-a71f524bc315@oracle.com>
References: <eb140682-a3d8-1d45-beb9-a71f524bc315@oracle.com>
Message-ID: <5D1A9C81.5090906@oracle.com>

Vote:yes

-Joe

On 6/28/2019 12:51 AM, Erik Helin wrote:
> I hereby nominate Jorn Vernee to Skara Committer.
>
> Jorn has contributed two patches to http://git.openjdk.java.net/skara, 
> both fixing issues on Windows. This has been very helpful since no 
> other active committer in Skara is using Windows on a daily basis. 
> Jorn has demonstrated a solid understanding of Java and the Skara CLI 
> code, disciplined testing and a good understanding of OpenJDK 
> processes (he is already a committer in the Panama project).
>
> Votes are due by July 12.
>
> Only current Skara Committers [1] are eligible to vote
> on this nomination.  Votes must be cast in the open by replying
> to this mailing list.
>
> For Lazy Consensus voting instructions, see [2].
>
> Erik
>
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/projects/#committer-vote


From tim.bell at oracle.com  Tue Jul  2 00:08:02 2019
From: tim.bell at oracle.com (Tim Bell)
Date: Mon, 01 Jul 2019 17:08:02 -0700
Subject: CFV: New Skara Committer: Jorn Vernee
In-Reply-To: <eb140682-a3d8-1d45-beb9-a71f524bc315@oracle.com>
References: <eb140682-a3d8-1d45-beb9-a71f524bc315@oracle.com>
Message-ID: <5D1AA062.6030807@oracle.com>

Vote: yes

Tim

On 06/28/19 00:51, Erik Helin wrote:
> I hereby nominate Jorn Vernee to Skara Committer.


From duke at openjdk.java.net  Tue Jul  2 06:17:56 2019
From: duke at openjdk.java.net (Robin Westberg via github.com)
Date: Tue, 2 Jul 2019 06:17:56 GMT
Subject: RFR: 25: The GitHub parsePullRequestUrl method is not pattern aware
Message-ID: <9Lje23K-Ir1RrTgbHFYt9rtGJjUT_7zt3d_2-doHzs4=.55f63f8a-c073-4639-b9c9-f7a7efa4eeec@github.com>

Hi all,

Please review the following change that uses the replacement pattern for PR links when parsing them as well.

Best regards,
Robin

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

Commits:
 - aca023b1:	Use the replacement pattern for PR links when parsing them as well

Pull request:
http://git.openjdk.java.net/skara/pull/20

Webrev:
https://openjdk.github.io/cr/skara/20/webrev.00

Patch:
http://git.openjdk.java.net/skara/pull/20.diff

Fetch command:
git fetch https://github.com/openjdk/skara.git aca023b1:pr/20

From duke at openjdk.java.net  Tue Jul  2 07:08:57 2019
From: duke at openjdk.java.net (Robin Westberg via github.com)
Date: Tue, 2 Jul 2019 07:08:57 GMT
Subject: RFR: 37: Make mailing list bridge ready check configurable
Message-ID: <FRLrYn-Vi8yLVn9NiF8Vl6h_KdusJtbszzMfo5Hjwb0=.13cfb8dc-26c5-4ab7-88c2-fbfdf6819de5@github.com>

Hi all,

Please review the following change that removes the hardcoded check for the "rfr" label in the mailing list bridge bot, and instead makes it configurable.

Best regards,
Robin

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

Commits:
 - f6b5e9d3:	Make bridge ready markers configurable

Pull request:
http://git.openjdk.java.net/skara/pull/21

Webrev:
https://openjdk.github.io/cr/skara/21/webrev.00

Patch:
http://git.openjdk.java.net/skara/pull/21.diff

Fetch command:
git fetch https://github.com/openjdk/skara.git f6b5e9d3:pr/21

From duke at openjdk.java.net  Tue Jul  2 07:27:26 2019
From: duke at openjdk.java.net (Robin Westberg via github.com)
Date: Tue, 2 Jul 2019 07:27:26 GMT
Subject: RFR: 13: Add link to PR in emails to mailing list
Message-ID: <cZoe0NXrDv_Ez1BDSutB0v-2JK82RqgZBd7j4ho7omw=.743231ca-883b-482c-b42a-c3cc9a9d0b50@github.com>

Hi all,

Please review the following change that adds a note to composed emails with a link to the originating pull request.

Best regards,
Robin

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

Commits:
 - e357f7bc:	Add a note to composed emails with the link to the originating pull request

Pull request:
http://git.openjdk.java.net/skara/pull/22

Webrev:
https://openjdk.github.io/cr/skara/22/webrev.00

Patch:
http://git.openjdk.java.net/skara/pull/22.diff

Fetch command:
git fetch https://github.com/openjdk/skara.git e357f7bc:pr/22

From duke at openjdk.java.net  Tue Jul  2 07:32:23 2019
From: duke at openjdk.java.net (Erik Duveblad via github.com)
Date: Tue, 2 Jul 2019 07:32:23 GMT
Subject: RFR: 25: The GitHub parsePullRequestUrl method is not pattern
 aware
In-Reply-To: <9Lje23K-Ir1RrTgbHFYt9rtGJjUT_7zt3d_2-doHzs4=.55f63f8a-c073-4639-b9c9-f7a7efa4eeec@github.com>
References: <9Lje23K-Ir1RrTgbHFYt9rtGJjUT_7zt3d_2-doHzs4=.55f63f8a-c073-4639-b9c9-f7a7efa4eeec@github.com>
Message-ID: <pg00Hi9XhRX9jmvGXxgS5hB4vM_oUgApSMEdHyZC2BQ=.798d1689-ec48-4dd1-985c-1f8488c71bed@github.com>

On Tue, 2 Jul 2019 06:17:56 GMT, Robin Westberg via github.com <duke at openjdk.java.net> wrote:

> Hi all,
> 
> Please review the following change that uses the replacement pattern for PR links when parsing them as well.
> 
> Best regards,
> Robin
> 
> ----------------
> 
> Commits:
>  - aca023b1:	Use the replacement pattern for PR links when parsing them as well
> 
> Pull request:
> http://git.openjdk.java.net/skara/pull/20
> 
> Webrev:
> https://openjdk.github.io/cr/skara/20/webrev.00
> 
> Patch:
> http://git.openjdk.java.net/skara/pull/20.diff
> 
> Fetch command:
> git fetch https://github.com/openjdk/skara.git aca023b1:pr/20

This PR has been reviewed by Erik Duveblad via github.com - changes are approved. Review comment:

Looks good!

From duke at openjdk.java.net  Tue Jul  2 07:33:52 2019
From: duke at openjdk.java.net (Erik Duveblad via github.com)
Date: Tue, 2 Jul 2019 07:33:52 GMT
Subject: RFR: 37: Make mailing list bridge ready check configurable
In-Reply-To: <FRLrYn-Vi8yLVn9NiF8Vl6h_KdusJtbszzMfo5Hjwb0=.13cfb8dc-26c5-4ab7-88c2-fbfdf6819de5@github.com>
References: <FRLrYn-Vi8yLVn9NiF8Vl6h_KdusJtbszzMfo5Hjwb0=.13cfb8dc-26c5-4ab7-88c2-fbfdf6819de5@github.com>
Message-ID: <riM6eowaFq9E0C0SeozU_qTnxCPMLAUHuee8J1DCZRI=.a40766c4-4675-4e86-a2a1-834ae46ae7eb@github.com>

On Tue, 2 Jul 2019 07:08:57 GMT, Robin Westberg via github.com <duke at openjdk.java.net> wrote:

> Hi all,
> 
> Please review the following change that removes the hardcoded check for the "rfr" label in the mailing list bridge bot, and instead makes it configurable.
> 
> Best regards,
> Robin
> 
> ----------------
> 
> Commits:
>  - f6b5e9d3:	Make bridge ready markers configurable
> 
> Pull request:
> http://git.openjdk.java.net/skara/pull/21
> 
> Webrev:
> https://openjdk.github.io/cr/skara/21/webrev.00
> 
> Patch:
> http://git.openjdk.java.net/skara/pull/21.diff
> 
> Fetch command:
> git fetch https://github.com/openjdk/skara.git f6b5e9d3:pr/21

This PR has been reviewed by Erik Duveblad via github.com - changes are approved. Review comment:

Looks good!

From duke at openjdk.java.net  Tue Jul  2 07:35:51 2019
From: duke at openjdk.java.net (Erik Duveblad via github.com)
Date: Tue, 2 Jul 2019 07:35:51 GMT
Subject: RFR: 13: Add link to PR in emails to mailing list
In-Reply-To: <cZoe0NXrDv_Ez1BDSutB0v-2JK82RqgZBd7j4ho7omw=.743231ca-883b-482c-b42a-c3cc9a9d0b50@github.com>
References: <cZoe0NXrDv_Ez1BDSutB0v-2JK82RqgZBd7j4ho7omw=.743231ca-883b-482c-b42a-c3cc9a9d0b50@github.com>
Message-ID: <7mHYXA8EZTj9khAy7bjplnaaVxb6P-4qEboC0CP8dkY=.7688210c-3d3a-4bca-95de-c2a2e1fd9b98@github.com>

On Tue, 2 Jul 2019 07:27:26 GMT, Robin Westberg via github.com <duke at openjdk.java.net> wrote:

> Hi all,
> 
> Please review the following change that adds a note to composed emails with a link to the originating pull request.
> 
> Best regards,
> Robin
> 
> ----------------
> 
> Commits:
>  - e357f7bc:	Add a note to composed emails with the link to the originating pull request
> 
> Pull request:
> http://git.openjdk.java.net/skara/pull/22
> 
> Webrev:
> https://openjdk.github.io/cr/skara/22/webrev.00
> 
> Patch:
> http://git.openjdk.java.net/skara/pull/22.diff
> 
> Fetch command:
> git fetch https://github.com/openjdk/skara.git e357f7bc:pr/22

This PR has been reviewed by Erik Duveblad via github.com - changes are approved. Review comment:

I might have preferred using footnotes (e.g. [0]), but lets start out with this and see how it works.

From duke at openjdk.java.net  Tue Jul  2 07:37:27 2019
From: duke at openjdk.java.net (duke)
Date: Tue, 2 Jul 2019 07:37:27 GMT
Subject: git: openjdk/skara: 13: Add link to PR in emails to mailing list
Message-ID: <5a8cb488-3a86-4e68-9aac-96a36c004ca3@openjdk.java.net>

Changeset: 61fc5646
Author:    Robin Westberg <rwestberg at openjdk.org>
Date:      2019-07-02 07:36:53 +0000
URL:       http://git.openjdk.java.net/skara/commit/61fc5646

13: Add link to PR in emails to mailing list

Reviewed-by: ehelin

! bots/mlbridge/src/main/java/org/openjdk/skara/bots/mlbridge/ArchiveWorkItem.java



From duke at openjdk.java.net  Tue Jul  2 07:37:53 2019
From: duke at openjdk.java.net (duke)
Date: Tue, 2 Jul 2019 07:37:53 GMT
Subject: git: openjdk/skara: 25: The GitHub parsePullRequestUrl method is not
 pattern aware
Message-ID: <ad77a3ca-61a4-4b42-8c8a-eea6c8423b0f@openjdk.java.net>

Changeset: dc544565
Author:    Robin Westberg <rwestberg at openjdk.org>
Date:      2019-07-02 07:37:23 +0000
URL:       http://git.openjdk.java.net/skara/commit/dc544565

25: The GitHub parsePullRequestUrl method is not pattern aware

Reviewed-by: ehelin

! build.gradle
! host/src/main/java/org/openjdk/skara/host/github/GitHubRepository.java



From duke at openjdk.java.net  Tue Jul  2 07:38:24 2019
From: duke at openjdk.java.net (duke)
Date: Tue, 2 Jul 2019 07:38:24 GMT
Subject: git: openjdk/skara: 37: Make mailing list bridge ready check
 configurable
Message-ID: <2236f297-1438-4128-9ca0-625f5c481839@openjdk.java.net>

Changeset: 81550df5
Author:    Robin Westberg <rwestberg at openjdk.org>
Date:      2019-07-02 07:37:53 +0000
URL:       http://git.openjdk.java.net/skara/commit/81550df5

37: Make mailing list bridge ready check configurable

Reviewed-by: ehelin

! bots/mlbridge/src/main/java/org/openjdk/skara/bots/mlbridge/ArchiveWorkItem.java
! bots/mlbridge/src/main/java/org/openjdk/skara/bots/mlbridge/MailingListBridgeBot.java
! bots/mlbridge/src/main/java/org/openjdk/skara/bots/mlbridge/MailingListBridgeBotFactory.java
! bots/mlbridge/src/test/java/org/openjdk/skara/bots/mlbridge/MailingListArchiveReaderBotTests.java
! bots/mlbridge/src/test/java/org/openjdk/skara/bots/mlbridge/MailingListBridgeBotTests.java



From duke at openjdk.java.net  Tue Jul  2 08:55:58 2019
From: duke at openjdk.java.net (Robin Westberg via github.com)
Date: Tue, 2 Jul 2019 08:55:58 GMT
Subject: RFR: 18: The fetch command in RFR emails does not work
Message-ID: <9WjHpIUzVnQA2BFWFmDq8t8tVgBla4V7p99t6Z7QxV0=.69d124e3-c383-46b2-9b4b-6cc7c86ed8b5@github.com>

Hi all,

Please review the following change that uses a proper ref in the fetch command sent in RFR emails.

Best regards,
Robin

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

Commits:
 - 6854de36:	Make getSourceRef return a reference that can actually be fetched from the repository

Pull request:
http://git.openjdk.java.net/skara/pull/23

Webrev:
https://openjdk.github.io/cr/skara/23/webrev.00

Patch:
http://git.openjdk.java.net/skara/pull/23.diff

Fetch command:
git fetch https://github.com/openjdk/skara.git 6854de36:pr/23

From duke at openjdk.java.net  Tue Jul  2 09:14:23 2019
From: duke at openjdk.java.net (Erik Duveblad via github.com)
Date: Tue, 2 Jul 2019 09:14:23 GMT
Subject: RFR: 18: The fetch command in RFR emails does not work
In-Reply-To: <9WjHpIUzVnQA2BFWFmDq8t8tVgBla4V7p99t6Z7QxV0=.69d124e3-c383-46b2-9b4b-6cc7c86ed8b5@github.com>
References: <9WjHpIUzVnQA2BFWFmDq8t8tVgBla4V7p99t6Z7QxV0=.69d124e3-c383-46b2-9b4b-6cc7c86ed8b5@github.com>
Message-ID: <rbrTTiIthf1Q7TGHRHI31DfkbS-mu_tM7CFqjGDEwR8=.c43998a4-b8f9-4f9c-9038-baf978ad2812@github.com>

On Tue, 2 Jul 2019 08:55:58 GMT, Robin Westberg via github.com <duke at openjdk.java.net> wrote:

> Hi all,
> 
> Please review the following change that uses a proper ref in the fetch command sent in RFR emails.
> 
> Best regards,
> Robin
> 
> ----------------
> 
> Commits:
>  - 6854de36:	Make getSourceRef return a reference that can actually be fetched from the repository
> 
> Pull request:
> http://git.openjdk.java.net/skara/pull/23
> 
> Webrev:
> https://openjdk.github.io/cr/skara/23/webrev.00
> 
> Patch:
> http://git.openjdk.java.net/skara/pull/23.diff
> 
> Fetch command:
> git fetch https://github.com/openjdk/skara.git 6854de36:pr/23

This PR has been reviewed by Erik Duveblad via github.com - changes are approved. Review comment:

Looks good!

PR: http://git.openjdk.java.net/skara/pull/23

From duke at openjdk.java.net  Tue Jul  2 09:19:25 2019
From: duke at openjdk.java.net (duke)
Date: Tue, 2 Jul 2019 09:19:25 GMT
Subject: git: openjdk/skara: 18: The fetch command in RFR emails does not work
Message-ID: <2885340c-b3e9-4721-b83c-0007136d06ce@openjdk.java.net>

Changeset: fcbae436
Author:    Robin Westberg <rwestberg at openjdk.org>
Date:      2019-07-02 09:18:55 +0000
URL:       http://git.openjdk.java.net/skara/commit/fcbae436

18: The fetch command in RFR emails does not work

Reviewed-by: ehelin

! bots/mlbridge/src/main/java/org/openjdk/skara/bots/mlbridge/PullRequestInstance.java
! host/src/main/java/org/openjdk/skara/host/github/GitHubPullRequest.java
! host/src/main/java/org/openjdk/skara/host/gitlab/GitLabMergeRequest.java



From duke at openjdk.java.net  Wed Jul  3 08:22:25 2019
From: duke at openjdk.java.net (Robin Westberg via github.com)
Date: Wed, 3 Jul 2019 08:22:25 GMT
Subject: RFR: 27: Push notification email should contain ev. sponsor
Message-ID: <LjPAvgOcuRSNHnTRDAYEloA8sejy1zfBZQVMothkkZA=.e64c1acb-6ffe-4a47-a602-64e734a23312@github.com>

Hi all,

Please review the following change that adds information about sponsors to the commit notification emails.

Best regards,
Robin

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

Commits:
 - 80717aa2:	Include the committer in the notification mail when its different from the author

Pull request:
http://git.openjdk.java.net/skara/pull/24

Webrev:
https://openjdk.github.io/cr/skara/24/webrev.00

Patch:
http://git.openjdk.java.net/skara/pull/24.diff

Fetch command:
git fetch https://github.com/openjdk/skara.git pull/24/head:pull/24

From duke at openjdk.java.net  Wed Jul  3 08:42:26 2019
From: duke at openjdk.java.net (Robin Westberg via github.com)
Date: Wed, 3 Jul 2019 08:42:26 GMT
Subject: RFR: 39: Use the lastUpdated field of pull requests to avoid
 unnecessary polls
Message-ID: <krldeFmE_YYJ5T93aPFjh0BgEjdl0V7aUQox7kmDTMs=.ead93e8f-cb5b-4f9d-a8b3-d93de850d0bf@github.com>

Hi all,

Please review the following change that introduces an in-memory cache of the lastUpdated field of pull requests, to avoid unnecessary polls.

Best regards,
Robin

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

Commits:
 - 252da95f:	Add PullRequestUpdateCache

Pull request:
http://git.openjdk.java.net/skara/pull/25

Webrev:
https://openjdk.github.io/cr/skara/25/webrev.00

Patch:
http://git.openjdk.java.net/skara/pull/25.diff

Fetch command:
git fetch https://github.com/openjdk/skara.git pull/25/head:pull/25

From duke at openjdk.java.net  Wed Jul  3 08:51:19 2019
From: duke at openjdk.java.net (Erik Duveblad via github.com)
Date: Wed, 3 Jul 2019 08:51:19 GMT
Subject: RFR: 27: Push notification email should contain ev. sponsor
In-Reply-To: <LjPAvgOcuRSNHnTRDAYEloA8sejy1zfBZQVMothkkZA=.e64c1acb-6ffe-4a47-a602-64e734a23312@github.com>
References: <LjPAvgOcuRSNHnTRDAYEloA8sejy1zfBZQVMothkkZA=.e64c1acb-6ffe-4a47-a602-64e734a23312@github.com>
Message-ID: <WQdJMOFm3od_ZdcoqhKw2h4Bor7NAvZxzI7Wz6ZfEtM=.a763cfd9-cba1-44e7-b8cb-5ccb4c48b46c@github.com>

On Wed, 3 Jul 2019 08:22:25 GMT, Robin Westberg via github.com <duke at openjdk.java.net> wrote:

> Hi all,
> 
> Please review the following change that adds information about sponsors to the commit notification emails.
> 
> Best regards,
> Robin
> 
> ----------------
> 
> Commits:
>  - 80717aa2:	Include the committer in the notification mail when its different from the author
> 
> Pull request:
> http://git.openjdk.java.net/skara/pull/24
> 
> Webrev:
> https://openjdk.github.io/cr/skara/24/webrev.00
> 
> Patch:
> http://git.openjdk.java.net/skara/pull/24.diff
> 
> Fetch command:
> git fetch https://github.com/openjdk/skara.git pull/24/head:pull/24

This PR has been reviewed by Erik Duveblad via github.com - changes are approved. Review comment:

Looks good!

PR: http://git.openjdk.java.net/skara/pull/24

From duke at openjdk.java.net  Wed Jul  3 08:52:49 2019
From: duke at openjdk.java.net (Erik Duveblad via github.com)
Date: Wed, 3 Jul 2019 08:52:49 GMT
Subject: RFR: 39: Use the lastUpdated field of pull requests to avoid
 unnecessary polls
In-Reply-To: <krldeFmE_YYJ5T93aPFjh0BgEjdl0V7aUQox7kmDTMs=.ead93e8f-cb5b-4f9d-a8b3-d93de850d0bf@github.com>
References: <krldeFmE_YYJ5T93aPFjh0BgEjdl0V7aUQox7kmDTMs=.ead93e8f-cb5b-4f9d-a8b3-d93de850d0bf@github.com>
Message-ID: <vzTGd8yt5pvzRyRohCUNomtXEH-QcMkUb4CSefybxsg=.ec34b4c0-9002-4c2f-a3ec-654b712edd5c@github.com>

On Wed, 3 Jul 2019 08:42:26 GMT, Robin Westberg via github.com <duke at openjdk.java.net> wrote:

> Hi all,
> 
> Please review the following change that introduces an in-memory cache of the lastUpdated field of pull requests, to avoid unnecessary polls.
> 
> Best regards,
> Robin
> 
> ----------------
> 
> Commits:
>  - 252da95f:	Add PullRequestUpdateCache
> 
> Pull request:
> http://git.openjdk.java.net/skara/pull/25
> 
> Webrev:
> https://openjdk.github.io/cr/skara/25/webrev.00
> 
> Patch:
> http://git.openjdk.java.net/skara/pull/25.diff
> 
> Fetch command:
> git fetch https://github.com/openjdk/skara.git pull/25/head:pull/25

This PR has been reviewed by Erik Duveblad via github.com - changes are approved. Review comment:

Thanks for fixing this!

PR: http://git.openjdk.java.net/skara/pull/25

From duke at openjdk.java.net  Wed Jul  3 09:02:21 2019
From: duke at openjdk.java.net (duke)
Date: Wed, 3 Jul 2019 09:02:21 GMT
Subject: git: openjdk/skara: 39: Use the lastUpdated field of pull requests to
 avoid unnecessary polls
Message-ID: <6e92d046-b287-4e54-a50a-c462e84fe39a@openjdk.java.net>

Changeset: 8a62fc93
Author:    Robin Westberg <rwestberg at openjdk.org>
Date:      2019-07-03 09:01:51 +0000
URL:       http://git.openjdk.java.net/skara/commit/8a62fc93

39: Use the lastUpdated field of pull requests to avoid unnecessary polls

Reviewed-by: ehelin

! bots/mlbridge/src/main/java/org/openjdk/skara/bots/mlbridge/MailingListBridgeBot.java
! bots/pr/src/main/java/org/openjdk/skara/bots/pr/PullRequestBot.java
! bots/submit/src/main/java/org/openjdk/skara/bots/submit/SubmitBot.java
+ host/src/main/java/org/openjdk/skara/host/PullRequestUpdateCache.java
! test/src/main/java/org/openjdk/skara/test/TestPullRequest.java



From duke at openjdk.java.net  Wed Jul  3 09:02:51 2019
From: duke at openjdk.java.net (duke)
Date: Wed, 3 Jul 2019 09:02:51 GMT
Subject: git: openjdk/skara: 27: Push notification email should contain ev.
 sponsor
Message-ID: <ede61c00-71dc-4432-b88f-f16b83d7c535@openjdk.java.net>

Changeset: 0cfec579
Author:    Robin Westberg <rwestberg at openjdk.org>
Date:      2019-07-03 09:02:21 +0000
URL:       http://git.openjdk.java.net/skara/commit/0cfec579

27: Push notification email should contain ev. sponsor

Reviewed-by: ehelin

! bots/notify/src/main/java/org/openjdk/skara/bots/notify/MailingListUpdater.java
! bots/notify/src/test/java/org/openjdk/skara/bots/notify/UpdaterTests.java
! test/src/main/java/org/openjdk/skara/test/CheckableRepository.java



From duke at openjdk.java.net  Wed Jul  3 11:43:15 2019
From: duke at openjdk.java.net (Erik Duveblad via github.com)
Date: Wed, 3 Jul 2019 11:43:15 GMT
Subject: RFR: Adding project explanation
In-Reply-To: <ViC3miWf_AcGfJFNmyxkETrL0CWEIyBnIvtvdWd802o=.759b9a05-adf5-4f1b-8c98-2d80ff6c0097@github.com>
References: <ViC3miWf_AcGfJFNmyxkETrL0CWEIyBnIvtvdWd802o=.759b9a05-adf5-4f1b-8c98-2d80ff6c0097@github.com>
Message-ID: <ZBiRfLA_ZoyxSlQ-9xAK7nsKmeeIbNGNNFUHzj8MXKI=.06bc6207-4164-47e2-8970-8297747dde9b@github.com>

On Mon, 1 Jul 2019 10:58:54 GMT, Marcus Hirt via github.com <duke at openjdk.java.net> wrote:

> ...as suggested in the Twitter discussion. :)
> 
> ----------------
> 
> Commits:
>  - 4578553b:	Adding project explanation
> 
> Pull request:
> http://git.openjdk.java.net/skara/pull/16
> 
> Webrev:
> https://openjdk.github.io/cr/skara/16/webrev.00
> 
> Patch:
> http://git.openjdk.java.net/skara/pull/16.diff
> 
> Fetch command:
> git fetch https://github.com/openjdk/skara.git 4578553b:pr/16

README.md line 4:

> 3: The goal of Project Skara is to investigate alternative SCM and code review
> 4: options for the JDK source code, including options based upon Git rather than
> 5: Mercurial, and including options hosted by third parties.

```suggestion
options for the OpenJDK source code, including options based upon Git rather than
```

PR: http://git.openjdk.java.net/skara/pull/16

From jbvernee at xs4all.nl  Wed Jul  3 12:19:30 2019
From: jbvernee at xs4all.nl (Jorn Vernee)
Date: Wed, 03 Jul 2019 14:19:30 +0200
Subject: Tool for importing webrev patches?
Message-ID: <a331e4f44fed479265942af3d3c4a972@xs4all.nl>

Hi all,

I'm working together with someone who is using mercurial, while I'm 
using git, and they've sent in a webrev for review.

When using mercurial I would:
   1. download the attached .patch file
   2. use `hg qimport the_patch.patch` to import the patch in mq
   3. use `hg qpush` to apply the changes
   4. run the tests and/or play with the code before submitting a review.
   5. use `hg qdelete the_patch.patch` to remove the patch from mq

I'm looking to replace steps 2, 3 and 5 with a git equivalent.

The git workflow I've figured out so far is to:
   1. download the attached .patch file
   2. create a new local branch based on the one the patch is targeting
   3. switch to newly created branch
   4. use `git apply the_patch.patch` to apply the changes
   5. make a commit for the applied changes
   6. run the tests and/or play with the code before submitting a review.
   7. delete the local branch.

I think steps 2-5 could be merged into 1 using some tool (maybe even 
step 1. as well). Then, after reviewing, I just have to delete the newly 
created local branch.

Does such a tool exist in Skara already? (couldn't find it on the wiki 
[1]) Or, is there another recommended way for doing this? Is there 
interest in adding such a tool to Skara?

Thanks,
Jorn

[1] : https://wiki.openjdk.java.net/display/skara

From marcus at hirt.se  Mon Jul  1 22:21:19 2019
From: marcus at hirt.se (Marcus Hirt)
Date: Tue, 2 Jul 2019 00:21:19 +0200
Subject: Sv: RFR: Adding project explanation
In-Reply-To: <2fee7acf-5c19-2ab3-0a1c-1b46e0b037a3@oracle.com>
References: <ViC3miWf_AcGfJFNmyxkETrL0CWEIyBnIvtvdWd802o=.759b9a05-adf5-4f1b-8c98-2d80ff6c0097@github.com>
 <Trz8ksRvquYdtzaA_IYYefuHLfohQrbQwQ1NryPjWFU=.cf7f2097-ad27-4b76-a936-2dc8bdc529c6@github.com>
 <CAJwKKma+RbNPkCiRhm6ezbhX0k9y2L+Fd=_7_tdZ5en0rFWNcg@mail.gmail.com>
 <2fee7acf-5c19-2ab3-0a1c-1b46e0b037a3@oracle.com>
Message-ID: <00ba01d5305b$4eb6fcf0$ec24f6d0$@hirt.se>

Haha. I mostly wanted to take it for a spin. Seems some good came out of it too. ;) I've updated the GitHub issue with a link to the discussion on Twitter.

Kind regards,
Marcus

-----Ursprungligt meddelande-----
Fr?n: Erik Helin <erik.helin at oracle.com> 
Skickat: den 1 juli 2019 16:46
Till: Mario Torre <neugens at redhat.com>; Erik Duveblad via github.com <duke at openjdk.java.net>
Kopia: skara-dev at openjdk.java.net; marcus at hirt.se
?mne: Re: RFR: Adding project explanation

On 7/1/19 3:59 PM, Mario Torre wrote:
>>> ...as suggested in the Twitter discussion. :)
>> :tada: :rofl:
> 
> Awesome, so now not only we need to track github as a whole, but also 
> twitter to get proper context for changesets! :)

I was just about to ask Marcus to update the description for the patch, as I don't follow nor use Twitter myself.

I think it is fairly obvious that we are still tuning a few knobs and that Skara is under active development, making steady progress day by day. We did run into a (pretty hilarious) Skara bug for this PR from Marcus, to which I reacted with a comment containing a few emojis. The comment was made in response to a number of label updates by the bots, which is why the comment is out of context here on the mailing list.

I want to highlight that this _not_ a normal situation, label updates on pull requests do not in general convey enough useful information to merit relaying them to a mailing list (nor comment on them). We primarily use labels to aid people who want to sort pull requests in various ways. We could send label updates to the mailing list as well, but I think it would just annoy people (it would annoy me at least).

> I still think that the old good mailing list are the way to go ;)

We also like mailing lists! I use skara-dev all the time to keep track of patches, comments and discussion. I want to be very clear that the goal is *not* to replace the mailing lists, we continue to work very hard to ensure that a contributor who wishes to use the mailing lists and the CLI should have a great experience.

The above doesn't mean we don't have a few bugs, Robin is currently working on making the mailing list experience better. If you have any additional feedback after following skara-dev then we'd be happy to hear it! And as usual, if you see something you think is a bug, then please file one [0].

Thanks,
Erik

[0]: https://bugs.openjdk.java.net/projects/SKARA/issues


From duke at openjdk.java.net  Wed Jul  3 14:03:20 2019
From: duke at openjdk.java.net (Robin Westberg via github.com)
Date: Wed, 3 Jul 2019 14:03:20 GMT
Subject: RFR: 40: Fix failing tests after remote locking
Message-ID: <IwHZXYm-zsmfHzruLmDUVV8s_ZrlYu6wk8pVoKKzYf8=.b2a8d216-648b-4d9e-9af1-ce0c8ac70e68@github.com>

Hi all,

Please remove this test-only fix that removes a few failures introduced by the recent credentials lock method update.

Best regards,
Robin

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

Commits:
 - 928eb722:	Retain credentials lock when using pushAll

Pull request:
http://git.openjdk.java.net/skara/pull/26

Webrev:
https://openjdk.github.io/cr/skara/26/webrev.00

Patch:
http://git.openjdk.java.net/skara/pull/26.diff

Fetch command:
git fetch https://github.com/openjdk/skara.git pull/26/head:pull/26

From robin.westberg at oracle.com  Wed Jul  3 14:04:45 2019
From: robin.westberg at oracle.com (Robin Westberg)
Date: Wed, 3 Jul 2019 16:04:45 +0200
Subject: RFR: 40: Fix failing tests after remote locking
In-Reply-To: <IwHZXYm-zsmfHzruLmDUVV8s_ZrlYu6wk8pVoKKzYf8=.b2a8d216-648b-4d9e-9af1-ce0c8ac70e68@github.com>
References: <IwHZXYm-zsmfHzruLmDUVV8s_ZrlYu6wk8pVoKKzYf8=.b2a8d216-648b-4d9e-9af1-ce0c8ac70e68@github.com>
Message-ID: <5DA50045-DECC-4433-8365-8CF877B67381@oracle.com>

Hi again,

First ?remove" was intended to be ?review?!

Best regards,
Robin

> On 3 Jul 2019, at 16:03, Robin Westberg via github.com <duke at openjdk.java.net> wrote:
> 
> Hi all,
> 
> Please remove this test-only fix that removes a few failures introduced by the recent credentials lock method update.
> 
> Best regards,
> Robin
> 
> ----------------
> 
> Commits:
> - 928eb722:	Retain credentials lock when using pushAll
> 
> Pull request:
> http://git.openjdk.java.net/skara/pull/26
> 
> Webrev:
> https://openjdk.github.io/cr/skara/26/webrev.00
> 
> Patch:
> http://git.openjdk.java.net/skara/pull/26.diff
> 
> Fetch command:
> git fetch https://github.com/openjdk/skara.git pull/26/head:pull/26


From duke at openjdk.java.net  Wed Jul  3 14:15:15 2019
From: duke at openjdk.java.net (Erik Duveblad via github.com)
Date: Wed, 3 Jul 2019 14:15:15 GMT
Subject: RFR: 40: Fix failing tests after remote locking
In-Reply-To: <IwHZXYm-zsmfHzruLmDUVV8s_ZrlYu6wk8pVoKKzYf8=.b2a8d216-648b-4d9e-9af1-ce0c8ac70e68@github.com>
References: <IwHZXYm-zsmfHzruLmDUVV8s_ZrlYu6wk8pVoKKzYf8=.b2a8d216-648b-4d9e-9af1-ce0c8ac70e68@github.com>
Message-ID: <ZzoGpsyCj6J0WxeXG0AEcXz13Pf_osw0q77OrZRVF3M=.fda04416-b298-4e35-aa68-99ec1c5ab059@github.com>

On Wed, 3 Jul 2019 14:03:20 GMT, Robin Westberg via github.com <duke at openjdk.java.net> wrote:

> Hi all,
> 
> Please remove this test-only fix that removes a few failures introduced by the recent credentials lock method update.
> 
> Best regards,
> Robin
> 
> ----------------
> 
> Commits:
>  - 928eb722:	Retain credentials lock when using pushAll
> 
> Pull request:
> http://git.openjdk.java.net/skara/pull/26
> 
> Webrev:
> https://openjdk.github.io/cr/skara/26/webrev.00
> 
> Patch:
> http://git.openjdk.java.net/skara/pull/26.diff
> 
> Fetch command:
> git fetch https://github.com/openjdk/skara.git pull/26/head:pull/26

This PR has been reviewed by Erik Duveblad via github.com - changes are approved. Review comment:

Looks good!

PR: http://git.openjdk.java.net/skara/pull/26

From erik.helin at oracle.com  Wed Jul  3 15:12:14 2019
From: erik.helin at oracle.com (Erik Helin)
Date: Wed, 3 Jul 2019 17:12:14 +0200
Subject: Tool for importing webrev patches?
In-Reply-To: <a331e4f44fed479265942af3d3c4a972@xs4all.nl>
References: <a331e4f44fed479265942af3d3c4a972@xs4all.nl>
Message-ID: <7ceca5c0-c014-a3a0-4197-2c643b70e3e8@oracle.com>

On 7/3/19 2:19 PM, Jorn Vernee wrote:
> The git workflow I've figured out so far is to:
>  ? 1. download the attached .patch file
>  ? 2. create a new local branch based on the one the patch is targeting
>  ? 3. switch to newly created branch
>  ? 4. use `git apply the_patch.patch` to apply the changes
>  ? 5. make a commit for the applied changes
>  ? 6. run the tests and/or play with the code before submitting a review.
>  ? 7. delete the local branch.
> 
> I think steps 2-5 could be merged into 1 using some tool (maybe even 
> step 1. as well). Then, after reviewing, I just have to delete the newly 
> created local branch.
> 
> Does such a tool exist in Skara already? (couldn't find it on the wiki 
> [1]) Or, is there another recommended way for doing this? Is there 
> interest in adding such a tool to Skara?

We would be happy to accept such a contribution :)

I think it is possible to automate quite a bit of what you are 
describing here, this is probably how I would approach it:

1. Name the tool, perhaps: git-webrev-apply? A little verbose maybe, but
    it gets the job done and won't conflict with other git commands.
2. Take the URL for a webrev as input. Since webrev does not use a
    standardized name for the patch file, we must parse the path to the
    .patch file from the index.html file. Fortunately this is fairly
    easy, see [0]. The pattern works with webrevs generated by both
    git-webrev and webrev.ksh.
3. For applying the patch you can see the code in GitPr.java [1].

The three steps above would result in something like:

$ git webrev-apply \
   http://cr.openjdk.java.net/~stefank/8227085/webrev.01/

which just applies the patch on top of HEAD.

I'm not sure about creating a branch unless you also intend to commit 
the applied patch? Otherwise the working tree will be dirty and if the 
user switch back to master it will remain dirty. It is fairly easy to 
use the above tool as part of an alias:

[alias]
webrev-fetch = !git checkout -b review && git webrev-apply $1 && git 
commit -m 'Webrev'

But I have an hard time coming with a clean way of doing the above from 
a tool. For example, what would the commit message be? A webrev is much 
more like a patch than a commit...

One drawback of the tool will be when the webrev has become stale (i.e. 
master has moved on and the patch in the webrev no longer applies 
cleanly). Since webrev does not include the base commit hash there is 
not much we can do here, besides fail :/

What do you think?

Thanks,
Erik

[0]: curl -s https://openjdk.github.io/cr/skara/26/webrev.00/ |\
      grep -P '[ ]*(<td>)?<a href\=\".*\">.*\.patch</a></td>(</tr>)?$'
[1]: 
http://git.openjdk.java.net/skara/blob/master/cli/src/main/java/org/openjdk/skara/cli/GitPr.java#L150

From jbvernee at xs4all.nl  Wed Jul  3 18:13:52 2019
From: jbvernee at xs4all.nl (Jorn Vernee)
Date: Wed, 03 Jul 2019 20:13:52 +0200
Subject: Tool for importing webrev patches?
In-Reply-To: <7ceca5c0-c014-a3a0-4197-2c643b70e3e8@oracle.com>
References: <a331e4f44fed479265942af3d3c4a972@xs4all.nl>
 <7ceca5c0-c014-a3a0-4197-2c643b70e3e8@oracle.com>
Message-ID: <92ff44a4583cbe0b440a707aa05562e0@xs4all.nl>

Comments inline...

On 2019-07-03 17:12, Erik Helin wrote:
> On 7/3/19 2:19 PM, Jorn Vernee wrote:
>> The git workflow I've figured out so far is to:
>>  ? 1. download the attached .patch file
>>  ? 2. create a new local branch based on the one the patch is 
>> targeting
>>  ? 3. switch to newly created branch
>>  ? 4. use `git apply the_patch.patch` to apply the changes
>>  ? 5. make a commit for the applied changes
>>  ? 6. run the tests and/or play with the code before submitting a 
>> review.
>>  ? 7. delete the local branch.
>> 
>> I think steps 2-5 could be merged into 1 using some tool (maybe even 
>> step 1. as well). Then, after reviewing, I just have to delete the 
>> newly created local branch.
>> 
>> Does such a tool exist in Skara already? (couldn't find it on the wiki 
>> [1]) Or, is there another recommended way for doing this? Is there 
>> interest in adding such a tool to Skara?
> 
> We would be happy to accept such a contribution :)

Great! I'll keep working on it.

> I think it is possible to automate quite a bit of what you are
> describing here, this is probably how I would approach it:
> 
> 1. Name the tool, perhaps: git-webrev-apply? A little verbose maybe, 
> but
>    it gets the job done and won't conflict with other git commands.
> 2. Take the URL for a webrev as input. Since webrev does not use a
>    standardized name for the patch file, we must parse the path to the
>    .patch file from the index.html file. Fortunately this is fairly
>    easy, see [0]. The pattern works with webrevs generated by both
>    git-webrev and webrev.ksh.
> 3. For applying the patch you can see the code in GitPr.java [1].

Thanks for the pointers!

I had made a quick prototype with the name 'wimport'. I was thinking 
about adding a command line switch to switch between webrev url and 
local file path, to be able to support both.

> The three steps above would result in something like:
> 
> $ git webrev-apply \
>   http://cr.openjdk.java.net/~stefank/8227085/webrev.01/
> 
> which just applies the patch on top of HEAD.
> 
> I'm not sure about creating a branch unless you also intend to commit
> the applied patch?

That is the plan.

I think making a commit for the patch makes it easier to see which code 
belongs to the patch when making my own changes on top of it, as well as 
making it easier to revert them later. Similarly, when applying multiple 
patches, this makes it easier to see which code belongs to which patch, 
rather than having everything mixed together in the working tree.

> Otherwise the working tree will be dirty and if the
> user switch back to master it will remain dirty. It is fairly easy to
> use the above tool as part of an alias:
> 
> [alias]
> webrev-fetch = !git checkout -b review && git webrev-apply $1 && git
> commit -m 'Webrev'
> 
> But I have an hard time coming with a clean way of doing the above
> from a tool. For example, what would the commit message be? A webrev
> is much more like a patch than a commit...

I was thinking of mimicking what mq does, which creates a change set for 
the patch with a message like "imported patch the_patch.patch". The 
branch could also be named "the_patch.patch".

> One drawback of the tool will be when the webrev has become stale
> (i.e. master has moved on and the patch in the webrev no longer
> applies cleanly). Since webrev does not include the base commit hash
> there is not much we can do here, besides fail :/
> 
> What do you think?

That seems fine to me. HG will create a bunch of .rej files in that case 
for files that conflicted. But, since the problem is usually not being 
on the tip of the branch, it seems better to just fail outright. Then 
it's easier to do a pull and then re-apply the patch.

Jorn

> Thanks,
> Erik
> 
> [0]: curl -s https://openjdk.github.io/cr/skara/26/webrev.00/ |\
>      grep -P '[ ]*(<td>)?<a href\=\".*\">.*\.patch</a></td>(</tr>)?$'
> [1]:
> http://git.openjdk.java.net/skara/blob/master/cli/src/main/java/org/openjdk/skara/cli/GitPr.java#L150

From duke at openjdk.java.net  Thu Jul  4 08:14:37 2019
From: duke at openjdk.java.net (duke)
Date: Thu, 4 Jul 2019 08:14:37 GMT
Subject: git: openjdk/skara: 40: Fix failing tests after remote locking
Message-ID: <b56f7864-26f2-4780-b61e-a5c04b8b066e@openjdk.java.net>

Changeset: 7c68b3b4
Author:    Robin Westberg <rwestberg at openjdk.org>
Date:      2019-07-04 08:14:25 +0000
URL:       http://git.openjdk.java.net/skara/commit/7c68b3b4

40: Fix failing tests after remote locking

Reviewed-by: ehelin

! bots/hgbridge/src/test/java/org/openjdk/skara/bots/hgbridge/BridgeBotTests.java
! bots/notify/src/test/java/org/openjdk/skara/bots/notify/UpdaterTests.java
! test/src/main/java/org/openjdk/skara/test/HostCredentials.java



From duke at openjdk.java.net  Thu Jul  4 08:31:00 2019
From: duke at openjdk.java.net (Erik Duveblad via github.com)
Date: Thu, 4 Jul 2019 08:31:00 GMT
Subject: RFR: 41: Bot launcher should detect ev. http proxy in environment
Message-ID: <TZ4CL6TpbZZAGXchmYDK0JNMtkWH25_Ee5xDg4ECIvk=.a9076f7a-528e-4628-8242-4fff6cabce40@github.com>

Hi all,

this patch ensures that `BotLauncher.java` correctly sets up corresponding system properties for `http_proxy`, `https_proxy` and `no_proxy`. The patch became a little larger than I intended since I had to break out `HttpProxy` into a new module and package to share it between `cli` and `bots/cli`. I also updated the Gradle `ProxyPlugin` to align with the new `proxy` module (there is unfortunately now way to use `HttpProxy` from the Gradle `ProxyPlugin`).

## Testing

- [x] Executed `sh gradlew test` successfully on Linux

Thanks,
Erik

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

Commits:
 - 9584f27f:	41: Bot launcher should detect ev. http proxy in environment

Pull request:
http://git.openjdk.java.net/skara/pull/27

Webrev:
https://openjdk.github.io/cr/skara/27/webrev.00

Patch:
http://git.openjdk.java.net/skara/pull/27.diff

Fetch command:
git fetch https://github.com/openjdk/skara.git pull/27/head:pull/27

From duke at openjdk.java.net  Thu Jul  4 08:35:33 2019
From: duke at openjdk.java.net (Robin Westberg via github.com)
Date: Thu, 4 Jul 2019 08:35:33 GMT
Subject: RFR: 41: Bot launcher should detect ev. http proxy in environment
In-Reply-To: <TZ4CL6TpbZZAGXchmYDK0JNMtkWH25_Ee5xDg4ECIvk=.a9076f7a-528e-4628-8242-4fff6cabce40@github.com>
References: <TZ4CL6TpbZZAGXchmYDK0JNMtkWH25_Ee5xDg4ECIvk=.a9076f7a-528e-4628-8242-4fff6cabce40@github.com>
Message-ID: <L4Y9_GBr4lmw_H0OluttUYG1sQ0N9Ar9j5gwgR4pEEA=.eab802b4-c59b-46df-a741-de7a35334d9d@github.com>

On Thu, 4 Jul 2019 08:31:00 GMT, Erik Duveblad via github.com <duke at openjdk.java.net> wrote:

> Hi all,
> 
> this patch ensures that `BotLauncher.java` correctly sets up corresponding system properties for `http_proxy`, `https_proxy` and `no_proxy`. The patch became a little larger than I intended since I had to break out `HttpProxy` into a new module and package to share it between `cli` and `bots/cli`. I also updated the Gradle `ProxyPlugin` to align with the new `proxy` module (there is unfortunately now way to use `HttpProxy` from the Gradle `ProxyPlugin`).
> 
> ## Testing
> 
> - [x] Executed `sh gradlew test` successfully on Linux
> 
> Thanks,
> Erik
> 
> ----------------
> 
> Commits:
>  - 9584f27f:	41: Bot launcher should detect ev. http proxy in environment
> 
> Pull request:
> http://git.openjdk.java.net/skara/pull/27
> 
> Webrev:
> https://openjdk.github.io/cr/skara/27/webrev.00
> 
> Patch:
> http://git.openjdk.java.net/skara/pull/27.diff
> 
> Fetch command:
> git fetch https://github.com/openjdk/skara.git pull/27/head:pull/27

This PR has been reviewed by Robin Westberg via github.com - changes are approved. Review comment:

Looks good!

PR: http://git.openjdk.java.net/skara/pull/27

proxy/build.gradle line 2:

> 1: /*
> 2:  * Copyright (c) 2018, 2019, Oracle and/or its affiliates. All rights reserved.
> 3:  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.

```suggestion
 * Copyright (c) 2019, Oracle and/or its affiliates. All rights reserved.
```
:)

PR: http://git.openjdk.java.net/skara/pull/27

From duke at openjdk.java.net  Thu Jul  4 08:42:52 2019
From: duke at openjdk.java.net (Erik Duveblad via github.com)
Date: Thu, 4 Jul 2019 08:42:52 GMT
Subject: RFR: 41: Bot launcher should detect ev. http proxy in environment
In-Reply-To: <TZ4CL6TpbZZAGXchmYDK0JNMtkWH25_Ee5xDg4ECIvk=.a9076f7a-528e-4628-8242-4fff6cabce40@github.com>
References: <TZ4CL6TpbZZAGXchmYDK0JNMtkWH25_Ee5xDg4ECIvk=.a9076f7a-528e-4628-8242-4fff6cabce40@github.com>
Message-ID: <w7gPWqH0-xQ-sStvFQpLlHTxdPOhbZ0Ezbsl1leg0kk=.64511161-f41a-4287-8d5d-6433f9201f7d@github.com>

The pull request has been updated with additional changes.

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

Added commits:
 - 46e3c901:	Fix copyright year in proxy/build.gradle
			Co-Authored-By: Robin Westberg <robin at westberg.se>

Pull request:
http://git.openjdk.java.net/skara/pull/27

Webrevs:
 - full: https://openjdk.github.io/cr/skara/27/webrev.01
 - inc: https://openjdk.github.io/cr/skara/27/webrev.00-01

Updated full patch:
http://git.openjdk.java.net/skara/pull/27.diff

Fetch command:
git fetch https://github.com/openjdk/skara.git pull/27/head:pull/27

From duke at openjdk.java.net  Thu Jul  4 08:43:23 2019
From: duke at openjdk.java.net (Erik Duveblad via github.com)
Date: Thu, 4 Jul 2019 08:43:23 GMT
Subject: RFR: 41: Bot launcher should detect ev. http proxy in environment
In-Reply-To: <TZ4CL6TpbZZAGXchmYDK0JNMtkWH25_Ee5xDg4ECIvk=.a9076f7a-528e-4628-8242-4fff6cabce40@github.com>
References: <TZ4CL6TpbZZAGXchmYDK0JNMtkWH25_Ee5xDg4ECIvk=.a9076f7a-528e-4628-8242-4fff6cabce40@github.com>
Message-ID: <U8-cMFgnBB8_j7DHoT4GLGMGB8fcmoa53Zg1T7vWwIc=.ca9b13b0-2d58-452c-8582-0e60e3a8b2a3@github.com>

On Thu, 4 Jul 2019 08:31:00 GMT, Erik Duveblad via github.com <duke at openjdk.java.net> wrote:

> Hi all,
> 
> this patch ensures that `BotLauncher.java` correctly sets up corresponding system properties for `http_proxy`, `https_proxy` and `no_proxy`. The patch became a little larger than I intended since I had to break out `HttpProxy` into a new module and package to share it between `cli` and `bots/cli`. I also updated the Gradle `ProxyPlugin` to align with the new `proxy` module (there is unfortunately now way to use `HttpProxy` from the Gradle `ProxyPlugin`).
> 
> ## Testing
> 
> - [x] Executed `sh gradlew test` successfully on Linux
> 
> Thanks,
> Erik
> 
> ----------------
> 
> Commits:
>  - 9584f27f:	41: Bot launcher should detect ev. http proxy in environment
> 
> Pull request:
> http://git.openjdk.java.net/skara/pull/27
> 
> Webrev:
> https://openjdk.github.io/cr/skara/27/webrev.00
> 
> Patch:
> http://git.openjdk.java.net/skara/pull/27.diff
> 
> Fetch command:
> git fetch https://github.com/openjdk/skara.git pull/27/head:pull/27

Thanks for reviewing @rwestberg!

PR: http://git.openjdk.java.net/skara/pull/27

From duke at openjdk.java.net  Thu Jul  4 08:43:36 2019
From: duke at openjdk.java.net (duke)
Date: Thu, 4 Jul 2019 08:43:36 GMT
Subject: git: openjdk/skara: 41: Bot launcher should detect ev. http proxy in
 environment
Message-ID: <b7eb078a-7095-4ca5-bdb4-1804babad029@openjdk.java.net>

Changeset: 965be9c6
Author:    Erik Helin <ehelin at openjdk.org>
Date:      2019-07-04 08:43:25 +0000
URL:       http://git.openjdk.java.net/skara/commit/965be9c6

41: Bot launcher should detect ev. http proxy in environment

Reviewed-by: rwestberg

! bots/cli/build.gradle
! bots/cli/src/main/java/module-info.java
! bots/cli/src/main/java/org/openjdk/skara/bots/cli/BotLauncher.java
! buildSrc/proxy/src/main/java/org/openjdk/skara/gradle/proxy/ProxyPlugin.java
! cli/build.gradle
! cli/src/main/java/module-info.java
! cli/src/main/java/org/openjdk/skara/cli/GitFork.java
! cli/src/main/java/org/openjdk/skara/cli/GitPr.java
- cli/src/main/java/org/openjdk/skara/cli/HttpProxy.java
+ proxy/build.gradle
+ proxy/src/main/java/module-info.java
+ proxy/src/main/java/org/openjdk/skara/proxy/HttpProxy.java
! settings.gradle



From duke at openjdk.java.net  Thu Jul  4 13:15:30 2019
From: duke at openjdk.java.net (Robin Westberg via github.com)
Date: Thu, 4 Jul 2019 13:15:30 GMT
Subject: RFR: 42: Notifier tests can fail depending on execution order
Message-ID: <Bx64FcU4XYTLePitY9h62uJ1RaKPK74sJLRVVlBjEiQ=.a1b0b007-479a-4941-b7ae-8d88fdb999f3@github.com>

Hi all,

Please review this small test fix that solves an issue that can happen when running the notifier tests against a real host.

Best regards,
Robin

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

Commits:
 - 8b3e41e5:	Remove remote branches when starting test

Pull request:
http://git.openjdk.java.net/skara/pull/28

Webrev:
https://openjdk.github.io/cr/skara/28/webrev.00

Patch:
http://git.openjdk.java.net/skara/pull/28.diff

Fetch command:
git fetch https://github.com/openjdk/skara.git pull/28/head:pull/28

From duke at openjdk.java.net  Thu Jul  4 14:35:50 2019
From: duke at openjdk.java.net (Erik Duveblad via github.com)
Date: Thu, 4 Jul 2019 14:35:50 GMT
Subject: RFR: 43: Repository.get should return Optional.empty on non-existing
 directory
Message-ID: <XedzjVBRzdTaaFXYr3Vzsr7oSS5l5q5pVmQIWZyf1yc=.87e5d88d-6b7e-4180-9fd7-dc099a8bf0d8@github.com>

Hi all,

this small patch ensures that Repository.get returns Optional.empty() for non-existing paths.

Thanks,
Erik

## Testing
- [x] `sh gradlew test` on Linux x86-64

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

Commits:
 - 6f1cc929:	43: Repository.get should return Optional.empty on non-existing directory

Pull request:
http://git.openjdk.java.net/skara/pull/29

Webrev:
https://openjdk.github.io/cr/skara/29/webrev.00

Patch:
http://git.openjdk.java.net/skara/pull/29.diff

Fetch command:
git fetch https://github.com/openjdk/skara.git pull/29/head:pull/29

From duke at openjdk.java.net  Thu Jul  4 14:36:25 2019
From: duke at openjdk.java.net (Erik Duveblad via github.com)
Date: Thu, 4 Jul 2019 14:36:25 GMT
Subject: RFR: 42: Notifier tests can fail depending on execution order
In-Reply-To: <Bx64FcU4XYTLePitY9h62uJ1RaKPK74sJLRVVlBjEiQ=.a1b0b007-479a-4941-b7ae-8d88fdb999f3@github.com>
References: <Bx64FcU4XYTLePitY9h62uJ1RaKPK74sJLRVVlBjEiQ=.a1b0b007-479a-4941-b7ae-8d88fdb999f3@github.com>
Message-ID: <0HYOVFbU6dfu4GXkG5zmIGNXuWS7JDlEj11gYjUR0RM=.42e4b575-bced-4ba3-8e63-0f7ace0792cd@github.com>

On Thu, 4 Jul 2019 13:15:30 GMT, Robin Westberg via github.com <duke at openjdk.java.net> wrote:

> Hi all,
> 
> Please review this small test fix that solves an issue that can happen when running the notifier tests against a real host.
> 
> Best regards,
> Robin
> 
> ----------------
> 
> Commits:
>  - 8b3e41e5:	Remove remote branches when starting test
> 
> Pull request:
> http://git.openjdk.java.net/skara/pull/28
> 
> Webrev:
> https://openjdk.github.io/cr/skara/28/webrev.00
> 
> Patch:
> http://git.openjdk.java.net/skara/pull/28.diff
> 
> Fetch command:
> git fetch https://github.com/openjdk/skara.git pull/28/head:pull/28

This PR has been reviewed by Erik Duveblad via github.com - changes are approved. Review comment:

Looks good!

PR: http://git.openjdk.java.net/skara/pull/28

From duke at openjdk.java.net  Thu Jul  4 14:46:06 2019
From: duke at openjdk.java.net (Robin Westberg via github.com)
Date: Thu, 4 Jul 2019 14:46:06 GMT
Subject: RFR: 43: Repository.get should return Optional.empty on
 non-existing directory
In-Reply-To: <XedzjVBRzdTaaFXYr3Vzsr7oSS5l5q5pVmQIWZyf1yc=.87e5d88d-6b7e-4180-9fd7-dc099a8bf0d8@github.com>
References: <XedzjVBRzdTaaFXYr3Vzsr7oSS5l5q5pVmQIWZyf1yc=.87e5d88d-6b7e-4180-9fd7-dc099a8bf0d8@github.com>
Message-ID: <UsI8qVqanEvkO6Mb4LOiyms5pPk7LKtsybgPYpYVuGg=.8fe3a6d7-2945-41ff-af05-2140e6ffd111@github.com>

On Thu, 4 Jul 2019 14:35:50 GMT, Erik Duveblad via github.com <duke at openjdk.java.net> wrote:

> Hi all,
> 
> this small patch ensures that Repository.get returns Optional.empty() for non-existing paths.
> 
> Thanks,
> Erik
> 
> ## Testing
> - [x] `sh gradlew test` on Linux x86-64
> 
> ----------------
> 
> Commits:
>  - 6f1cc929:	43: Repository.get should return Optional.empty on non-existing directory
> 
> Pull request:
> http://git.openjdk.java.net/skara/pull/29
> 
> Webrev:
> https://openjdk.github.io/cr/skara/29/webrev.00
> 
> Patch:
> http://git.openjdk.java.net/skara/pull/29.diff
> 
> Fetch command:
> git fetch https://github.com/openjdk/skara.git pull/29/head:pull/29

This PR has been reviewed by Robin Westberg via github.com - changes are approved. Review comment:

Looks good!

PR: http://git.openjdk.java.net/skara/pull/29

From duke at openjdk.java.net  Thu Jul  4 14:47:06 2019
From: duke at openjdk.java.net (duke)
Date: Thu, 4 Jul 2019 14:47:06 GMT
Subject: git: openjdk/skara: 42: Notifier tests can fail depending on
 execution order
Message-ID: <4ce98f2e-61fe-4efc-97d1-e96369bedb5d@openjdk.java.net>

Changeset: e83e4733
Author:    Robin Westberg <rwestberg at openjdk.org>
Date:      2019-07-04 14:46:55 +0000
URL:       http://git.openjdk.java.net/skara/commit/e83e4733

42: Notifier tests can fail depending on execution order

Reviewed-by: ehelin

! bots/notify/src/test/java/org/openjdk/skara/bots/notify/UpdaterTests.java



From duke at openjdk.java.net  Thu Jul  4 15:01:36 2019
From: duke at openjdk.java.net (duke)
Date: Thu, 4 Jul 2019 15:01:36 GMT
Subject: git: openjdk/skara: 43: Repository.get should return Optional.empty
 on non-existing directory
Message-ID: <12013446-47b7-4099-b278-67c924583bd4@openjdk.java.net>

Changeset: 90edbabb
Author:    Erik Helin <ehelin at openjdk.org>
Date:      2019-07-04 15:01:19 +0000
URL:       http://git.openjdk.java.net/skara/commit/90edbabb

43: Repository.get should return Optional.empty on non-existing directory

Reviewed-by: rwestberg

! vcs/src/main/java/org/openjdk/skara/vcs/git/GitRepository.java
! vcs/src/main/java/org/openjdk/skara/vcs/hg/HgRepository.java
! vcs/src/test/java/org/openjdk/skara/vcs/RepositoryTests.java



From duke at openjdk.java.net  Fri Jul  5 08:18:21 2019
From: duke at openjdk.java.net (Erik Duveblad via github.com)
Date: Fri, 5 Jul 2019 08:18:21 GMT
Subject: RFR: 44: GitHubApplication should not use a JSONParser instance
Message-ID: <UXP9YyHxTDxAUTkmCD18TgMsm_a5E0qfeRSuy_PLOCI=.ef326ca8-7625-4385-9d14-f0d82445f782@github.com>

Hi all,

a `JSONParser` instance is not thread-safe and it is therefore a little dangerous to create instances of it _if_ that instance might end up being accessible by multiple threads. We have such a case in `GitHubApplication`. Since a `JSONParser` is very cheap to allocate (it only has an `int` and a pointer) I decided to make `JSONParser` package private thereby forcing all callers to use `JSON.parse`.

Thanks,
Erik

## Testing
- [x] `sh gradlew test` on Linux x86-64

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

Commits:
 - 19e23934:	44: GitHubApplication should not use a JSONParser instance

Pull request:
http://git.openjdk.java.net/skara/pull/30

Webrev:
https://openjdk.github.io/cr/skara/30/webrev.00

Patch:
http://git.openjdk.java.net/skara/pull/30.diff

Fetch command:
git fetch https://github.com/openjdk/skara.git pull/30/head:pull/30

From duke at openjdk.java.net  Fri Jul  5 08:23:24 2019
From: duke at openjdk.java.net (Robin Westberg via github.com)
Date: Fri, 5 Jul 2019 08:23:24 GMT
Subject: RFR: 44: GitHubApplication should not use a JSONParser instance
In-Reply-To: <UXP9YyHxTDxAUTkmCD18TgMsm_a5E0qfeRSuy_PLOCI=.ef326ca8-7625-4385-9d14-f0d82445f782@github.com>
References: <UXP9YyHxTDxAUTkmCD18TgMsm_a5E0qfeRSuy_PLOCI=.ef326ca8-7625-4385-9d14-f0d82445f782@github.com>
Message-ID: <EbVXRbyLPjVYu1GRnbfifxkEvDNdqGkMVrTgRibMfvc=.32fd764a-4070-4149-be73-dc88aebb432c@github.com>

On Fri, 5 Jul 2019 08:18:21 GMT, Erik Duveblad via github.com <duke at openjdk.java.net> wrote:

> Hi all,
> 
> a `JSONParser` instance is not thread-safe and it is therefore a little dangerous to create instances of it _if_ that instance might end up being accessible by multiple threads. We have such a case in `GitHubApplication`. Since a `JSONParser` is very cheap to allocate (it only has an `int` and a pointer) I decided to make `JSONParser` package private thereby forcing all callers to use `JSON.parse`.
> 
> Thanks,
> Erik
> 
> ## Testing
> - [x] `sh gradlew test` on Linux x86-64
> 
> ----------------
> 
> Commits:
>  - 19e23934:	44: GitHubApplication should not use a JSONParser instance
> 
> Pull request:
> http://git.openjdk.java.net/skara/pull/30
> 
> Webrev:
> https://openjdk.github.io/cr/skara/30/webrev.00
> 
> Patch:
> http://git.openjdk.java.net/skara/pull/30.diff
> 
> Fetch command:
> git fetch https://github.com/openjdk/skara.git pull/30/head:pull/30

This PR has been reviewed by Robin Westberg via github.com - changes are approved. Review comment:

Looks good, thanks for fixing!

PR: http://git.openjdk.java.net/skara/pull/30

From duke at openjdk.java.net  Fri Jul  5 08:23:55 2019
From: duke at openjdk.java.net (duke)
Date: Fri, 5 Jul 2019 08:23:55 GMT
Subject: git: openjdk/skara: 44: GitHubApplication should not use a JSONParser
 instance
Message-ID: <89030375-e70f-4182-99c9-fa4a23ca282c@openjdk.java.net>

Changeset: 6746b039
Author:    Erik Helin <ehelin at openjdk.org>
Date:      2019-07-05 08:23:46 +0000
URL:       http://git.openjdk.java.net/skara/commit/6746b039

44: GitHubApplication should not use a JSONParser instance

Reviewed-by: rwestberg

! host/src/main/java/org/openjdk/skara/host/github/GitHubApplication.java
! json/src/main/java/org/openjdk/skara/json/JSONParser.java



From duke at openjdk.java.net  Fri Jul  5 08:33:39 2019
From: duke at openjdk.java.net (Robin Westberg via github.com)
Date: Fri, 5 Jul 2019 08:33:39 GMT
Subject: RFR: 45: Fix remaining integration test issues
Message-ID: <4Ksfd85dYlq19CHK99haHVRvx6OrJeVGKFpiK8nzCNI=.e1980769-e249-4de2-84c7-8a6b12638a0b@github.com>

Hi all,

Please review this fix that improves the error message when an incorrect repository is encountered in a merge PR, as well as adjusting the tests.

Best regards,
Robin

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

Commits:
 - 67616fa4:	Improve merge error handling, make the test host consistent with real ones

Pull request:
http://git.openjdk.java.net/skara/pull/31

Webrev:
https://openjdk.github.io/cr/skara/31/webrev.00

Patch:
http://git.openjdk.java.net/skara/pull/31.diff

Fetch command:
git fetch https://github.com/openjdk/skara.git pull/31/head:pull/31

From duke at openjdk.java.net  Fri Jul  5 09:20:03 2019
From: duke at openjdk.java.net (Erik Duveblad via github.com)
Date: Fri, 5 Jul 2019 09:20:03 GMT
Subject: RFR: 45: Fix remaining integration test issues
In-Reply-To: <4Ksfd85dYlq19CHK99haHVRvx6OrJeVGKFpiK8nzCNI=.e1980769-e249-4de2-84c7-8a6b12638a0b@github.com>
References: <4Ksfd85dYlq19CHK99haHVRvx6OrJeVGKFpiK8nzCNI=.e1980769-e249-4de2-84c7-8a6b12638a0b@github.com>
Message-ID: <gwi1BaRn42CNDPnrKQ4ywbZmFckb8SWsUFW7nDSX9cI=.63809dcf-6df9-42bc-bc01-16ec6fea7447@github.com>

On Fri, 5 Jul 2019 08:33:39 GMT, Robin Westberg via github.com <duke at openjdk.java.net> wrote:

> Hi all,
> 
> Please review this fix that improves the error message when an incorrect repository is encountered in a merge PR, as well as adjusting the tests.
> 
> Best regards,
> Robin
> 
> ----------------
> 
> Commits:
>  - 67616fa4:	Improve merge error handling, make the test host consistent with real ones
> 
> Pull request:
> http://git.openjdk.java.net/skara/pull/31
> 
> Webrev:
> https://openjdk.github.io/cr/skara/31/webrev.00
> 
> Patch:
> http://git.openjdk.java.net/skara/pull/31.diff
> 
> Fetch command:
> git fetch https://github.com/openjdk/skara.git pull/31/head:pull/31

This PR has been reviewed by Erik Duveblad via github.com - changes are approved. Review comment:

Looks good, thanks for fixing!

PR: http://git.openjdk.java.net/skara/pull/31

From duke at openjdk.java.net  Fri Jul  5 10:01:57 2019
From: duke at openjdk.java.net (JornVernee via github.com)
Date: Fri, 5 Jul 2019 10:01:57 GMT
Subject: RFR: Add tool for importing webrev patches
Message-ID: <9_jEaW011lAaAzSAWpXvPnqXcL9y_7QmPQYoF2x_muk=.e85bd45a-725d-4ec5-b0df-dc72eb53ee43@github.com>

As discussed on the mailing list: https://mail.openjdk.java.net/pipermail/skara-dev/2019-July/000176.html

This PR adds a tool for importing webrev `.patch` files, either from a webrev url or local file path into a repository.

I've named the tool `wimport` as short for `webrev-import` (I thought the full name sounded a bit too much like a sub-command of `webrev`). This will first checkout a new branch, then apply the patch, and then create a commit for the patch with the message `Imported patch 'NAME'`, similar to what is done by mq. Afterwards a user can just delete the new branch when they're done with e.g. reviewing the webrev. Although, there is also an option to directly apply the webrev without creating a branch or commit.

Currently  the following options are supported:

    usage: git wimport [options] <webrev url|file path>
        -n, --name NAME  Use NAME as a name for the patch (default is patch file name)
        -f, --file       Input is a file path
        -k, --keep       Keep downloaded patch file in current directory
        -d, --direct     Directly apply patch, without creating a branch or commit

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

Commits:
 - 7b20ce75:	Wimport prototype

Pull request:
http://git.openjdk.java.net/skara/pull/32

Webrev:
https://openjdk.github.io/cr/skara/32/webrev.00

Patch:
http://git.openjdk.java.net/skara/pull/32.diff

Fetch command:
git fetch https://github.com/openjdk/skara.git pull/32/head:pull/32

From duke at openjdk.java.net  Fri Jul  5 10:06:08 2019
From: duke at openjdk.java.net (JornVernee via github.com)
Date: Fri, 5 Jul 2019 10:06:08 GMT
Subject: RFR: Add tool for importing webrev patches
In-Reply-To: <9_jEaW011lAaAzSAWpXvPnqXcL9y_7QmPQYoF2x_muk=.e85bd45a-725d-4ec5-b0df-dc72eb53ee43@github.com>
References: <9_jEaW011lAaAzSAWpXvPnqXcL9y_7QmPQYoF2x_muk=.e85bd45a-725d-4ec5-b0df-dc72eb53ee43@github.com>
Message-ID: <2YsDTiCfPaj_lWYt7CPEG-T0eyhGUIYmfoPtW5K4140=.46b49c5f-9e39-4cca-95fd-c3bb12737d9f@github.com>

The pull request has been updated with additional changes.

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

Added commits:
 - 3e4f6684:	Wimport prototype

Pull request:
http://git.openjdk.java.net/skara/pull/32

Webrevs:
 - full: https://openjdk.github.io/cr/skara/32/webrev.01
 - inc: https://openjdk.github.io/cr/skara/32/webrev.00-01

Updated full patch:
http://git.openjdk.java.net/skara/pull/32.diff

Fetch command:
git fetch https://github.com/openjdk/skara.git pull/32/head:pull/32

From duke at openjdk.java.net  Fri Jul  5 10:17:31 2019
From: duke at openjdk.java.net (JornVernee via github.com)
Date: Fri, 5 Jul 2019 10:17:31 GMT
Subject: RFR: Add tool for importing webrev patches
In-Reply-To: <9_jEaW011lAaAzSAWpXvPnqXcL9y_7QmPQYoF2x_muk=.e85bd45a-725d-4ec5-b0df-dc72eb53ee43@github.com>
References: <9_jEaW011lAaAzSAWpXvPnqXcL9y_7QmPQYoF2x_muk=.e85bd45a-725d-4ec5-b0df-dc72eb53ee43@github.com>
Message-ID: <FMXW82MIbdI2bPdLY7kGyke0C4VR_rLLqyBlsIiJjTI=.2b64b4ec-45d3-4d74-b1de-c8266257ca6d@github.com>

The pull request has been updated with additional changes.

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

Added commits:
 - 740ea789:	- Specify -f option takes a path to a .patch file
			- Add missing space between }else
			- Move initializing of path variable inside of if block

Pull request:
http://git.openjdk.java.net/skara/pull/32

Webrevs:
 - full: https://openjdk.github.io/cr/skara/32/webrev.02
 - inc: https://openjdk.github.io/cr/skara/32/webrev.01-02

Updated full patch:
http://git.openjdk.java.net/skara/pull/32.diff

Fetch command:
git fetch https://github.com/openjdk/skara.git pull/32/head:pull/32

From duke at openjdk.java.net  Fri Jul  5 12:46:20 2019
From: duke at openjdk.java.net (Robin Westberg via github.com)
Date: Fri, 5 Jul 2019 12:46:20 GMT
Subject: RFR: 45: Fix remaining integration test issues
In-Reply-To: <4Ksfd85dYlq19CHK99haHVRvx6OrJeVGKFpiK8nzCNI=.e1980769-e249-4de2-84c7-8a6b12638a0b@github.com>
References: <4Ksfd85dYlq19CHK99haHVRvx6OrJeVGKFpiK8nzCNI=.e1980769-e249-4de2-84c7-8a6b12638a0b@github.com>
Message-ID: <N-s3vS0wr72nDM_C2bvLDitDc-CIMEQXG7XYEMUzusc=.89ad2513-76f9-4cdb-add1-fd1922b7cb4f@github.com>

The pull request has been updated with additional changes.

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

Added commits:
 - 6947965f:	Additional GitLab specific fix

Pull request:
http://git.openjdk.java.net/skara/pull/31

Webrevs:
 - full: https://openjdk.github.io/cr/skara/31/webrev.01
 - inc: https://openjdk.github.io/cr/skara/31/webrev.00-01

Updated full patch:
http://git.openjdk.java.net/skara/pull/31.diff

Fetch command:
git fetch https://github.com/openjdk/skara.git pull/31/head:pull/31

From duke at openjdk.java.net  Fri Jul  5 13:20:51 2019
From: duke at openjdk.java.net (Erik Duveblad via github.com)
Date: Fri, 5 Jul 2019 13:20:51 GMT
Subject: RFR: Add tool for importing webrev patches
In-Reply-To: <9_jEaW011lAaAzSAWpXvPnqXcL9y_7QmPQYoF2x_muk=.e85bd45a-725d-4ec5-b0df-dc72eb53ee43@github.com>
References: <9_jEaW011lAaAzSAWpXvPnqXcL9y_7QmPQYoF2x_muk=.e85bd45a-725d-4ec5-b0df-dc72eb53ee43@github.com>
Message-ID: <iFvoVMR3uRLTzl04Kq1QK8hmWjD-ZPjEeYHrFSVQBYg=.475ce7f6-2ff1-4392-9afa-bfd655023f29@github.com>

On Fri, 5 Jul 2019 10:01:57 GMT, JornVernee via github.com <duke at openjdk.java.net> wrote:

> As discussed on the mailing list: https://mail.openjdk.java.net/pipermail/skara-dev/2019-July/000176.html
> 
> This PR adds a tool for importing webrev `.patch` files, either from a webrev url or local file path into a repository.
> 
> I've named the tool `wimport` as short for `webrev-import` (I thought the full name sounded a bit too much like a sub-command of `webrev`). This will first checkout a new branch, then apply the patch, and then create a commit for the patch with the message `Imported patch 'NAME'`, similar to what is done by mq. Afterwards a user can just delete the new branch when they're done with e.g. reviewing the webrev. Although, there is also an option to directly apply the webrev without creating a branch or commit.
> 
> Currently  the following options are supported:
> 
>     usage: git wimport [options] <webrev url|file path>
>         -n, --name NAME  Use NAME as a name for the patch (default is patch file name)
>         -f, --file       Input is a file path
>         -k, --keep       Keep downloaded patch file in current directory
>         -d, --direct     Directly apply patch, without creating a branch or commit
> 
> ----------------
> 
> Commits:
>  - 7b20ce75:	Wimport prototype
> 
> Pull request:
> http://git.openjdk.java.net/skara/pull/32
> 
> Webrev:
> https://openjdk.github.io/cr/skara/32/webrev.00
> 
> Patch:
> http://git.openjdk.java.net/skara/pull/32.diff
> 
> Fetch command:
> git fetch https://github.com/openjdk/skara.git pull/32/head:pull/32

Thanks Jorn for you contribution!

I just had time to take quick look at the code, but wanted to share some high-level thoughts before diving in deeper. I would suggest splitting this tool into two:
1. git-webrev-apply
2. git-webrev-fetch

The motivation would be to two piggyback on already known git commands apply and fetch and try
to match the semantics as good as possible. The first tool, git-webrev-apply is very similar to what you have done in this PR _except_ that it would not do a commit. The second tool, git-webrev-fetch, would be more similar to what you have done here, but here I have few more considerations to make the tool as safe as possible:
- we want git-webrev-fetch to apply directly to index (with `git apply --cached`) so we avoid potentially changing files in the user's working tree.
- if the user already has a dirty index (`git diff --cached` is not empty) then I would consider two options:
  - abort and notify the user that the index is dirty (this differs from how `git fetch` behaves)
  - temporarily store the user's dirty index with `git write-tree`, apply the patch with `git apply --cached`, commit (more on how to commit later), restore the user's index with `git read-tree`
- I think we can find out a bit more about the webrev. For author and committer we can definitely use the username, `https://cr.openjdk.java.net/~(.*)/`. You could potentially use the `census` module if you want to get the real name for the user (to be able to use "Real Name <username at openjdk.org>" form).
- For the commit message I would either go with just the URL of the webrev or try to apply some heuristic to find out if the webrev has corresponding [JBS](https://bugs.openjdk.java.net/) issue.
- For committing the dirty index I'm not fully sure yet of the best way. Ideally we want `origin/master` to be the parent since `master` might have advanced due to a user's local commits. One way to achieve this could be to first commit and then rebase the resulting commit onto `origin/master`. Another, perhaps more correct, but also slower, would be to use `git worktree` to create a new temporary worktree from `origin/master` in /tmp, apply the patch, and then commit.
- I think we can automatically deduce the name of the ref, for a webrev from a URL <https://cr.openjdk.java.net/~ehelin/JDK-01234567/00> I think the ref `webrevs/ehelin/JDK-01234567/00` is fairly natural. This is somewhat similar to how `pulls/` is used for refs related to pull requests.

Regarding the verbose naming of the tools, I actually intended for them to look like webrev subcommands :smiley: The reason for this is if these two tools turn out well then I think we can repurpose `git-webrev` into having subcommands (similar to `git-pr`):
- git webrev generate
- git webrev apply <URL>
- git webrev fetch <URL>

`generate` would be the default command so that `git webrev` stays backwards compatible (just typing `git webrev` would mean `git webrev generate`). But before embarking on this refactoring I wanted us to start with implementing `git webrev-apply` and `git webrev-fetch`.

I would suggest slightly re-purposing this PR into becoming the PR for `git-webrev-apply` and then tackle `git-webrev-fetch` in another PR.

What do you think?

PR: http://git.openjdk.java.net/skara/pull/32

From duke at openjdk.java.net  Fri Jul  5 14:31:33 2019
From: duke at openjdk.java.net (duke)
Date: Fri, 5 Jul 2019 14:31:33 GMT
Subject: git: openjdk/skara: 45: Fix remaining integration test issues
Message-ID: <7bcd14d6-e742-43fe-8a25-e27c11cc13dc@openjdk.java.net>

Changeset: 53a6c51e
Author:    Robin Westberg <rwestberg at openjdk.org>
Date:      2019-07-05 14:31:16 +0000
URL:       http://git.openjdk.java.net/skara/commit/53a6c51e

45: Fix remaining integration test issues

Reviewed-by: ehelin

! bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckRun.java
! bots/pr/src/test/java/org/openjdk/skara/bots/pr/MergeTests.java
! build.gradle
! host/src/main/java/org/openjdk/skara/host/gitlab/GitLabMergeRequest.java
! test/build.gradle
! test/src/main/java/module-info.java
! test/src/main/java/org/openjdk/skara/test/HostCredentials.java
! test/src/main/java/org/openjdk/skara/test/TestHost.java



From duke at openjdk.java.net  Fri Jul  5 15:38:41 2019
From: duke at openjdk.java.net (JornVernee via github.com)
Date: Fri, 5 Jul 2019 15:38:41 GMT
Subject: RFR: Add tool for importing webrev patches
In-Reply-To: <iFvoVMR3uRLTzl04Kq1QK8hmWjD-ZPjEeYHrFSVQBYg=.475ce7f6-2ff1-4392-9afa-bfd655023f29@github.com>
References: <9_jEaW011lAaAzSAWpXvPnqXcL9y_7QmPQYoF2x_muk=.e85bd45a-725d-4ec5-b0df-dc72eb53ee43@github.com>
 <iFvoVMR3uRLTzl04Kq1QK8hmWjD-ZPjEeYHrFSVQBYg=.475ce7f6-2ff1-4392-9afa-bfd655023f29@github.com>
Message-ID: <yjttfOBzkSzvZUGPAUE42gxsTWYx4hWaA8pqhxos86c=.b3bb0d5c-3bf6-42f6-969f-d9b4b0994165@github.com>

On Fri, 5 Jul 2019 13:20:51 GMT, Erik Duveblad via github.com <duke at openjdk.java.net> wrote:

> On Fri, 5 Jul 2019 10:01:57 GMT, JornVernee via github.com <duke at openjdk.java.net> wrote:
> 
>> As discussed on the mailing list: https://mail.openjdk.java.net/pipermail/skara-dev/2019-July/000176.html
>> 
>> This PR adds a tool for importing webrev `.patch` files, either from a webrev url or local file path into a repository.
>> 
>> I've named the tool `wimport` as short for `webrev-import` (I thought the full name sounded a bit too much like a sub-command of `webrev`). This will first checkout a new branch, then apply the patch, and then create a commit for the patch with the message `Imported patch 'NAME'`, similar to what is done by mq. Afterwards a user can just delete the new branch when they're done with e.g. reviewing the webrev. Although, there is also an option to directly apply the webrev without creating a branch or commit.
>> 
>> Currently  the following options are supported:
>> 
>>     usage: git wimport [options] <webrev url|file path>
>>         -n, --name NAME  Use NAME as a name for the patch (default is patch file name)
>>         -f, --file       Input is a file path
>>         -k, --keep       Keep downloaded patch file in current directory
>>         -d, --direct     Directly apply patch, without creating a branch or commit
>> 
>> ----------------
>> 
>> Commits:
>>  - 7b20ce75:	Wimport prototype
>> 
>> Pull request:
>> http://git.openjdk.java.net/skara/pull/32
>> 
>> Webrev:
>> https://openjdk.github.io/cr/skara/32/webrev.00
>> 
>> Patch:
>> http://git.openjdk.java.net/skara/pull/32.diff
>> 
>> Fetch command:
>> git fetch https://github.com/openjdk/skara.git pull/32/head:pull/32
> 
> Thanks Jorn for you contribution!
> 
> I just had time to take quick look at the code, but wanted to share some high-level thoughts before diving in deeper. I would suggest splitting this tool into two:
> 1. git-webrev-apply
> 2. git-webrev-fetch
> 
> The motivation would be to two piggyback on already known git commands apply and fetch and try
> to match the semantics as good as possible. The first tool, git-webrev-apply is very similar to what you have done in this PR _except_ that it would not do a commit. The second tool, git-webrev-fetch, would be more similar to what you have done here, but here I have few more considerations to make the tool as safe as possible:
> - we want git-webrev-fetch to apply directly to index (with `git apply --cached`) so we avoid potentially changing files in the user's working tree.
> - if the user already has a dirty index (`git diff --cached` is not empty) then I would consider two options:
>   - abort and notify the user that the index is dirty (this differs from how `git fetch` behaves)
>   - temporarily store the user's dirty index with `git write-tree`, apply the patch with `git apply --cached`, commit (more on how to commit later), restore the user's index with `git read-tree`
> - I think we can find out a bit more about the webrev. For author and committer we can definitely use the username, `https://cr.openjdk.java.net/~(.*)/`. You could potentially use the `census` module if you want to get the real name for the user (to be able to use "Real Name <username at openjdk.org>" form).
> - For the commit message I would either go with just the URL of the webrev or try to apply some heuristic to find out if the webrev has corresponding [JBS](https://bugs.openjdk.java.net/) issue.
> - For committing the dirty index I'm not fully sure yet of the best way. Ideally we want `origin/master` to be the parent since `master` might have advanced due to a user's local commits. One way to achieve this could be to first commit and then rebase the resulting commit onto `origin/master`. Another, perhaps more correct, but also slower, would be to use `git worktree` to create a new temporary worktree from `origin/master` in /tmp, apply the patch, and then commit.
> - I think we can automatically deduce the name of the ref, for a webrev from a URL <https://cr.openjdk.java.net/~ehelin/JDK-01234567/00> I think the ref `webrevs/ehelin/JDK-01234567/00` is fairly natural. This is somewhat similar to how `pulls/` is used for refs related to pull requests.
> 
> Regarding the verbose naming of the tools, I actually intended for them to look like webrev subcommands :smiley: The reason for this is if these two tools turn out well then I think we can repurpose `git-webrev` into having subcommands (similar to `git-pr`):
> - git webrev generate
> - git webrev apply <URL>
> - git webrev fetch <URL>
> 
> `generate` would be the default command so that `git webrev` stays backwards compatible (just typing `git webrev` would mean `git webrev generate`). But before embarking on this refactoring I wanted us to start with implementing `git webrev-apply` and `git webrev-fetch`.
> 
> I would suggest slightly re-purposing this PR into becoming the PR for `git-webrev-apply` and then tackle `git-webrev-fetch` in another PR.
> 
> What do you think?
> 
> PR: http://git.openjdk.java.net/skara/pull/32

Response inline...

> I just had time to take quick look at the code, but wanted to share some high-level thoughts before diving in deeper. I would suggest splitting this tool into two:
> 
>     1. git-webrev-apply
> 
>     2. git-webrev-fetch
> 
> 
> The motivation would be to two piggyback on already known git commands apply and fetch and try
> to match the semantics as good as possible. The first tool, git-webrev-apply is very similar to what you have done in this PR _except_ that it would not do a commit.

Okay, so it would just be like `git apply`, but with a webrev url as an argument? I suppose it's reasonable to drop support for local `.patch` files in that case, since that behaviour can be achieved by just using `git apply`.

> The second tool, git-webrev-fetch, would be more similar to what you have done here, but here I have few more considerations to make the tool as safe as possible:
> 
>     * we want git-webrev-fetch to apply directly to index (with `git apply --cached`) so we avoid potentially changing files in the user's working tree.

Oh yeah, good point!

>     * if the user already has a dirty index (`git diff --cached` is not empty) then I would consider two options:
>       
>       * abort and notify the user that the index is dirty (this differs from how `git fetch` behaves)
>       * temporarily store the user's dirty index with `git write-tree`, apply the patch with `git apply --cached`, commit (more on how to commit later), restore the user's index with `git read-tree`

Can't the `git read-tree` step create conflicts? I'm a little more in favour of the former option of aborting, then the user can decided either to reset the tree or do a `write-tree` (or something else).

>     * I think we can find out a bit more about the webrev. For author and committer we can definitely use the username, `https://cr.openjdk.java.net/~(.*)/`. You could potentially use the `census` module if you want to get the real name for the user (to be able to use "Real Name [username at openjdk.org](mailto:username at openjdk.org)" form).

If were going with deriving more information from the webrev, I'd rather try to find it in the webrev body, we can possibly get:

 * the author
 * the revision the webrev was generated on
 * the branch the webrev is targeting
 * the associated JBS bug link
 * the patch file link (already doing this for this PR)

>     * For the commit message I would either go with just the URL of the webrev or try to apply some heuristic to find out if the webrev has corresponding [JBS](https://bugs.openjdk.java.net/) issue.

I think some heuristic is good, but we should have a good fallback as well, since we're not guaranteed to find the wanted information. Using the webrev URL as a commit message seems like a good one!

>     * For committing the dirty index I'm not fully sure yet of the best way. Ideally we want `origin/master` to be the parent since `master` might have advanced due to a user's local commits. One way to achieve this could be to first commit and then rebase the resulting commit onto `origin/master`. Another, perhaps more correct, but also slower, would be to use `git worktree` to create a new temporary worktree from `origin/master` in /tmp, apply the patch, and then commit.

Well, not all webrevs target the master branch, but I get your point. An easy way to sidestep this problem is to use the current HEAD as the parent (and whichever branch this might be).

>     * I think we can automatically deduce the name of the ref, for a webrev from a URL https://cr.openjdk.java.net/~ehelin/JDK-01234567/00 I think the ref `webrevs/ehelin/JDK-01234567/00` is fairly natural. This is somewhat similar to how `pulls/` is used for refs related to pull requests.

Sounds good! Overall I think we can use several heuristics to create a `WebrevMetaData` object that we can then generate this kind of information from that.

> Regarding the verbose naming of the tools, I actually intended for them to look like webrev subcommands ???? The reason for this is if these two tools turn out well then I think we can repurpose `git-webrev` into having subcommands (similar to `git-pr`):
> 
>     * git webrev generate
> 
>     * git webrev apply
> 
>     * git webrev fetch
> 
> 
> `generate` would be the default command so that `git webrev` stays backwards compatible (just typing `git webrev` would mean `git webrev generate`). But before embarking on this refactoring I wanted us to start with implementing `git webrev-apply` and `git webrev-fetch`.

Okay, sounds great to me! (just having the usual case of new-contributor-syndrome, not trying to step on anyone's toes ????)

> I would suggest slightly re-purposing this PR into becoming the PR for `git-webrev-apply` and then tackle `git-webrev-fetch` in another PR.
> 
> What do you think?

Sounds good.

Also, I wanted to ask what you want to do for tests? I noticed there are no other test in the `cli` module yet, so I've tested this PR manually, but maybe now is a good time to start adding them?

FWIW, not all the tests pass on Windows currently, particularly some tests that rely on unix tools/path-separators, and quite a bit of the `vcs` tests file (I haven't looked into it yet). In the meantime it might be nice to set up some CI on GitHub, e.g. Travis?

PR: http://git.openjdk.java.net/skara/pull/32

From duke at openjdk.java.net  Mon Jul  8 07:22:22 2019
From: duke at openjdk.java.net (Erik Duveblad via github.com)
Date: Mon, 8 Jul 2019 07:22:22 GMT
Subject: RFR: Add tool for importing webrev patches
In-Reply-To: <yjttfOBzkSzvZUGPAUE42gxsTWYx4hWaA8pqhxos86c=.b3bb0d5c-3bf6-42f6-969f-d9b4b0994165@github.com>
References: <9_jEaW011lAaAzSAWpXvPnqXcL9y_7QmPQYoF2x_muk=.e85bd45a-725d-4ec5-b0df-dc72eb53ee43@github.com>
 <iFvoVMR3uRLTzl04Kq1QK8hmWjD-ZPjEeYHrFSVQBYg=.475ce7f6-2ff1-4392-9afa-bfd655023f29@github.com>
 <yjttfOBzkSzvZUGPAUE42gxsTWYx4hWaA8pqhxos86c=.b3bb0d5c-3bf6-42f6-969f-d9b4b0994165@github.com>
Message-ID: <Unz_PCOdgHU4xsFt__H_euXwH9vLaEXXlqS9tICCmk8=.dc44891e-fa1d-4148-8fe8-679e74cfd2a0@github.com>

On Fri, 5 Jul 2019 15:38:41 GMT, JornVernee via github.com <duke at openjdk.java.net> wrote:

> On Fri, 5 Jul 2019 13:20:51 GMT, Erik Duveblad via github.com <duke at openjdk.java.net> wrote:
> 
>> On Fri, 5 Jul 2019 10:01:57 GMT, JornVernee via github.com <duke at openjdk.java.net> wrote:
>> 
>>> As discussed on the mailing list: https://mail.openjdk.java.net/pipermail/skara-dev/2019-July/000176.html
>>> 
>>> This PR adds a tool for importing webrev `.patch` files, either from a webrev url or local file path into a repository.
>>> 
>>> I've named the tool `wimport` as short for `webrev-import` (I thought the full name sounded a bit too much like a sub-command of `webrev`). This will first checkout a new branch, then apply the patch, and then create a commit for the patch with the message `Imported patch 'NAME'`, similar to what is done by mq. Afterwards a user can just delete the new branch when they're done with e.g. reviewing the webrev. Although, there is also an option to directly apply the webrev without creating a branch or commit.
>>> 
>>> Currently  the following options are supported:
>>> 
>>>     usage: git wimport [options] <webrev url|file path>
>>>         -n, --name NAME  Use NAME as a name for the patch (default is patch file name)
>>>         -f, --file       Input is a file path
>>>         -k, --keep       Keep downloaded patch file in current directory
>>>         -d, --direct     Directly apply patch, without creating a branch or commit
>>> 
>>> ----------------
>>> 
>>> Commits:
>>>  - 7b20ce75:	Wimport prototype
>>> 
>>> Pull request:
>>> http://git.openjdk.java.net/skara/pull/32
>>> 
>>> Webrev:
>>> https://openjdk.github.io/cr/skara/32/webrev.00
>>> 
>>> Patch:
>>> http://git.openjdk.java.net/skara/pull/32.diff
>>> 
>>> Fetch command:
>>> git fetch https://github.com/openjdk/skara.git pull/32/head:pull/32
>> 
>> Thanks Jorn for you contribution!
>> 
>> I just had time to take quick look at the code, but wanted to share some high-level thoughts before diving in deeper. I would suggest splitting this tool into two:
>> 1. git-webrev-apply
>> 2. git-webrev-fetch
>> 
>> The motivation would be to two piggyback on already known git commands apply and fetch and try
>> to match the semantics as good as possible. The first tool, git-webrev-apply is very similar to what you have done in this PR _except_ that it would not do a commit. The second tool, git-webrev-fetch, would be more similar to what you have done here, but here I have few more considerations to make the tool as safe as possible:
>> - we want git-webrev-fetch to apply directly to index (with `git apply --cached`) so we avoid potentially changing files in the user's working tree.
>> - if the user already has a dirty index (`git diff --cached` is not empty) then I would consider two options:
>>   - abort and notify the user that the index is dirty (this differs from how `git fetch` behaves)
>>   - temporarily store the user's dirty index with `git write-tree`, apply the patch with `git apply --cached`, commit (more on how to commit later), restore the user's index with `git read-tree`
>> - I think we can find out a bit more about the webrev. For author and committer we can definitely use the username, `https://cr.openjdk.java.net/~(.*)/`. You could potentially use the `census` module if you want to get the real name for the user (to be able to use "Real Name <username at openjdk.org>" form).
>> - For the commit message I would either go with just the URL of the webrev or try to apply some heuristic to find out if the webrev has corresponding [JBS](https://bugs.openjdk.java.net/) issue.
>> - For committing the dirty index I'm not fully sure yet of the best way. Ideally we want `origin/master` to be the parent since `master` might have advanced due to a user's local commits. One way to achieve this could be to first commit and then rebase the resulting commit onto `origin/master`. Another, perhaps more correct, but also slower, would be to use `git worktree` to create a new temporary worktree from `origin/master` in /tmp, apply the patch, and then commit.
>> - I think we can automatically deduce the name of the ref, for a webrev from a URL <https://cr.openjdk.java.net/~ehelin/JDK-01234567/00> I think the ref `webrevs/ehelin/JDK-01234567/00` is fairly natural. This is somewhat similar to how `pulls/` is used for refs related to pull requests.
>> 
>> Regarding the verbose naming of the tools, I actually intended for them to look like webrev subcommands :smiley: The reason for this is if these two tools turn out well then I think we can repurpose `git-webrev` into having subcommands (similar to `git-pr`):
>> - git webrev generate
>> - git webrev apply <URL>
>> - git webrev fetch <URL>
>> 
>> `generate` would be the default command so that `git webrev` stays backwards compatible (just typing `git webrev` would mean `git webrev generate`). But before embarking on this refactoring I wanted us to start with implementing `git webrev-apply` and `git webrev-fetch`.
>> 
>> I would suggest slightly re-purposing this PR into becoming the PR for `git-webrev-apply` and then tackle `git-webrev-fetch` in another PR.
>> 
>> What do you think?
>> 
>> PR: http://git.openjdk.java.net/skara/pull/32
> 
> Response inline...
> 
>> I just had time to take quick look at the code, but wanted to share some high-level thoughts before diving in deeper. I would suggest splitting this tool into two:
>> 
>>     1. git-webrev-apply
>> 
>>     2. git-webrev-fetch
>> 
>> 
>> The motivation would be to two piggyback on already known git commands apply and fetch and try
>> to match the semantics as good as possible. The first tool, git-webrev-apply is very similar to what you have done in this PR _except_ that it would not do a commit.
> 
> Okay, so it would just be like `git apply`, but with a webrev url as an argument? I suppose it's reasonable to drop support for local `.patch` files in that case, since that behaviour can be achieved by just using `git apply`.
> 
>> The second tool, git-webrev-fetch, would be more similar to what you have done here, but here I have few more considerations to make the tool as safe as possible:
>> 
>>     * we want git-webrev-fetch to apply directly to index (with `git apply --cached`) so we avoid potentially changing files in the user's working tree.
> 
> Oh yeah, good point!
> 
>>     * if the user already has a dirty index (`git diff --cached` is not empty) then I would consider two options:
>>       
>>       * abort and notify the user that the index is dirty (this differs from how `git fetch` behaves)
>>       * temporarily store the user's dirty index with `git write-tree`, apply the patch with `git apply --cached`, commit (more on how to commit later), restore the user's index with `git read-tree`
> 
> Can't the `git read-tree` step create conflicts? I'm a little more in favour of the former option of aborting, then the user can decided either to reset the tree or do a `write-tree` (or something else).
> 
>>     * I think we can find out a bit more about the webrev. For author and committer we can definitely use the username, `https://cr.openjdk.java.net/~(.*)/`. You could potentially use the `census` module if you want to get the real name for the user (to be able to use "Real Name [username at openjdk.org](mailto:username at openjdk.org)" form).
> 
> If were going with deriving more information from the webrev, I'd rather try to find it in the webrev body, we can possibly get:
> 
>  * the author
>  * the revision the webrev was generated on
>  * the branch the webrev is targeting
>  * the associated JBS bug link
>  * the patch file link (already doing this for this PR)
> 
>>     * For the commit message I would either go with just the URL of the webrev or try to apply some heuristic to find out if the webrev has corresponding [JBS](https://bugs.openjdk.java.net/) issue.
> 
> I think some heuristic is good, but we should have a good fallback as well, since we're not guaranteed to find the wanted information. Using the webrev URL as a commit message seems like a good one!
> 
>>     * For committing the dirty index I'm not fully sure yet of the best way. Ideally we want `origin/master` to be the parent since `master` might have advanced due to a user's local commits. One way to achieve this could be to first commit and then rebase the resulting commit onto `origin/master`. Another, perhaps more correct, but also slower, would be to use `git worktree` to create a new temporary worktree from `origin/master` in /tmp, apply the patch, and then commit.
> 
> Well, not all webrevs target the master branch, but I get your point. An easy way to sidestep this problem is to use the current HEAD as the parent (and whichever branch this might be).
> 
>>     * I think we can automatically deduce the name of the ref, for a webrev from a URL https://cr.openjdk.java.net/~ehelin/JDK-01234567/00 I think the ref `webrevs/ehelin/JDK-01234567/00` is fairly natural. This is somewhat similar to how `pulls/` is used for refs related to pull requests.
> 
> Sounds good! Overall I think we can use several heuristics to create a `WebrevMetaData` object that we can then generate this kind of information from that.
> 
>> Regarding the verbose naming of the tools, I actually intended for them to look like webrev subcommands ???? The reason for this is if these two tools turn out well then I think we can repurpose `git-webrev` into having subcommands (similar to `git-pr`):
>> 
>>     * git webrev generate
>> 
>>     * git webrev apply
>> 
>>     * git webrev fetch
>> 
>> 
>> `generate` would be the default command so that `git webrev` stays backwards compatible (just typing `git webrev` would mean `git webrev generate`). But before embarking on this refactoring I wanted us to start with implementing `git webrev-apply` and `git webrev-fetch`.
> 
> Okay, sounds great to me! (just having the usual case of new-contributor-syndrome, not trying to step on anyone's toes ????)
> 
>> I would suggest slightly re-purposing this PR into becoming the PR for `git-webrev-apply` and then tackle `git-webrev-fetch` in another PR.
>> 
>> What do you think?
> 
> Sounds good.
> 
> Also, I wanted to ask what you want to do for tests? I noticed there are no other test in the `cli` module yet, so I've tested this PR manually, but maybe now is a good time to start adding them?
> 
> FWIW, not all the tests pass on Windows currently, particularly some tests that rely on unix tools/path-separators, and quite a bit of the `vcs` tests file (I haven't looked into it yet). In the meantime it might be nice to set up some CI on GitHub, e.g. Travis?
> 
> PR: http://git.openjdk.java.net/skara/pull/32

> > The first tool, git-webrev-apply is very similar to what you have done in this PR _except_ that it would
> > not do a commit.
> 
> Okay, so it would just be like `git apply`, but with a webrev url as an argument? I suppose it's reasonable to drop support for local `.patch` files in that case, since that behaviour can be achieved by just using `git apply`.

Yes, `git-webrev-apply` would behave exactly like `git apply` but with a webrev URL as argument. Yes, I would drop support for local `.patch` files for the exact reason you mention. 

> > ```
> > * if the user already has a dirty index (`git diff --cached` is not empty) then I would consider two options:
> >   
> >   * abort and notify the user that the index is dirty (this differs from how `git fetch` behaves)
> >   * temporarily store the user's dirty index with `git write-tree`, apply the patch with `git apply --cached`, commit (more on how to commit later), restore the user's index with `git read-tree`
> > ```
> 
> Can't the `git read-tree` step create conflicts? I'm a little more in favour of the former option of aborting, then the user can decided either to reset the tree or do a `write-tree` (or something else).

I don't think so? But I haven't tried this idea :smile: The first `git read-tree` will empty the index, we are essentially temporarily storing the index as a tree. The `git apply` followed by `git commit` should also result in an empty index. One could experiment with using `git write-tree` and `git commit-tree` instead of `git commit`, but the result should be very similar. So when we do the final `git read-tree` the index should be clean, `HEAD` should be intact,  the worktree should be intact, so I don't think we should get any conflicts?

However, the above will be a little fiddly, so it is probably best to just start with a warning if the index is dirty.

> > ```
> > * I think we can find out a bit more about the webrev. For author and committer we can definitely use the username, `https://cr.openjdk.java.net/~(.*)/`. You could potentially use the `census` module if you want to get the real name for the user (to be able to use "Real Name [username at openjdk.org](mailto:username at openjdk.org)" form).
> > ```
> 
> If were going with deriving more information from the webrev, I'd rather try to find it in the webrev body, we can possibly get:
> 
> * the author
> * the revision the webrev was generated on
> * the branch the webrev is targeting
> * the associated JBS bug link
> * the patch file link (already doing this for this PR)

Good point! I would probably recommend a mix, since not everyone creates webrevs with `-c`, but many contributors use the pattern `~username/ISSUE/` in the URLs.

> > ```
> > * For the commit message I would either go with just the URL of the webrev or try to apply some heuristic to find out if the webrev has corresponding [JBS](https://bugs.openjdk.java.net/) issue.
> > ```
> 
> I think some heuristic is good, but we should have a good fallback as well, since we're not guaranteed to find the wanted information. Using the webrev URL as a commit message seems like a good one!

:+1: 

> > ```
> > * For committing the dirty index I'm not fully sure yet of the best way. Ideally we want `origin/master` to be the parent since `master` might have advanced due to a user's local commits. One way to achieve this could be to first commit and then rebase the resulting commit onto `origin/master`. Another, perhaps more correct, but also slower, would be to use `git worktree` to create a new temporary worktree from `origin/master` in /tmp, apply the patch, and then commit.
> > ```
> 
> Well, not all webrevs target the master branch, but I get your point. An easy way to sidestep this problem is to use the current HEAD as the parent (and whichever branch this might be).
> 
> > ```
> > * I think we can automatically deduce the name of the ref, for a webrev from a URL https://cr.openjdk.java.net/~ehelin/JDK-01234567/00 I think the ref `webrevs/ehelin/JDK-01234567/00` is fairly natural. This is somewhat similar to how `pulls/` is used for refs related to pull requests.
> > ```
> 
> Sounds good! Overall I think we can use several heuristics to create a `WebrevMetaData` object that we can then generate this kind of information from that.

That sounds like a good start, please consider adding it to the `webrev` module.

> > Regarding the verbose naming of the tools, I actually intended for them to look like webrev subcommands smiley The reason for this is if these two tools turn out well then I think we can repurpose `git-webrev` into having subcommands (similar to `git-pr`):
> > ```
> > * git webrev generate
> > 
> > * git webrev apply
> > 
> > * git webrev fetch
> > ```
> > 
> > 
> > `generate` would be the default command so that `git webrev` stays backwards compatible (just typing `git webrev` would mean `git webrev generate`). But before embarking on this refactoring I wanted us to start with implementing `git webrev-apply` and `git webrev-fetch`.
> 
> Okay, sounds great to me! (just having the usual case of new-contributor-syndrome, not trying to step on anyone's toes )

Haha, the only toes you can step on are mine and Robin's, and we step on each other's toes all the time, so they are fairly hardened by now :laughing: Feel free to suggest as dramatic changes as you like!

> > I would suggest slightly re-purposing this PR into becoming the PR for `git-webrev-apply` and then tackle `git-webrev-fetch` in another PR.
> > What do you think?
> 
> Sounds good.
> 
> Also, I wanted to ask what you want to do for tests? I noticed there are no other test in the `cli` module yet, so I've tested this PR manually, but maybe now is a good time to start adding them?

I general we try to put as much logic as possible into the various libraries and then test the libraries (since they are easier to unit test than the CLI tools). The CLI tools are primarily meant to be small programs "gluing" together a few libraries and therefore I have resorted to manual testing. Some of the CLI tools (the ones not requiring a network connection) should be fairly easy to test though, so feel free to add tests to the `cli` module.

> FWIW, not all the tests pass on Windows currently, particularly some tests that rely on unix tools/path-separators, and quite a bit of the `vcs` tests file (I haven't looked into it yet). In the meantime it might be nice to set up some CI on GitHub, e.g. Travis?

Sorry to hear that the tests aren't passing on Windows, they _should_ pass (we are running them on Windows from time to time). We have something in the works regarding CI, but we need a little more time to work on it, so please stay tuned for that.

PR: http://git.openjdk.java.net/skara/pull/32

From joe.darcy at oracle.com  Mon Jul 15 18:04:06 2019
From: joe.darcy at oracle.com (Joe Darcy)
Date: Mon, 15 Jul 2019 11:04:06 -0700
Subject: FYI, new as candidate JEP 357: Migrate from Mercurial to Git
Message-ID: <94583960-efac-3b88-e197-99822e90ab68@oracle.com>

FYI,

New as candidate: JEP 357: Migrate from Mercurial to Git 
(https://openjdk.java.net/jeps/357).

Cheers,

-Joe


From duke at openjdk.java.net  Wed Jul 31 05:48:01 2019
From: duke at openjdk.java.net (Joe Darcy via github.com)
Date: Wed, 31 Jul 2019 05:48:01 GMT
Subject: RFR: Update README.md
Message-ID: <JVOTDJxnzghQcaoDlpR3NlwPX5d9wUis5zu1wKya4mQ=.4ae9596d-a1c9-4dc9-88e6-edf3963cde6f@github.com>

Fix typo in description of hgbridge.

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

Commits:
 - ebd737b8:	Update README.md
			Fix typo in description of hgbridge.

Pull request:
http://git.openjdk.java.net/skara/pull/33

Webrev:
https://openjdk.github.io/cr/skara/33/webrev.00

Patch:
http://git.openjdk.java.net/skara/pull/33.diff

Fetch command:
git fetch https://github.com/openjdk/skara.git pull/33/head:pull/33

From joe.darcy at oracle.com  Wed Jul 31 17:25:10 2019
From: joe.darcy at oracle.com (Joe Darcy)
Date: Wed, 31 Jul 2019 10:25:10 -0700
Subject: RFR: Update README.md
In-Reply-To: <JVOTDJxnzghQcaoDlpR3NlwPX5d9wUis5zu1wKya4mQ=.4ae9596d-a1c9-4dc9-88e6-edf3963cde6f@github.com>
References: <JVOTDJxnzghQcaoDlpR3NlwPX5d9wUis5zu1wKya4mQ=.4ae9596d-a1c9-4dc9-88e6-edf3963cde6f@github.com>
Message-ID: <80ee34d8-da8a-110d-d1ec-2096581343d8@oracle.com>

PS No additional typos were found in the README.

-Joe

On 7/30/2019 10:48 PM, Joe Darcy via github.com wrote:
> Fix typo in description of hgbridge.
>
> ----------------
>
> Commits:
>   - ebd737b8:	Update README.md
> 			Fix typo in description of hgbridge.
>
> Pull request:
> http://git.openjdk.java.net/skara/pull/33
>
> Webrev:
> https://openjdk.github.io/cr/skara/33/webrev.00
>
> Patch:
> http://git.openjdk.java.net/skara/pull/33.diff
>
> Fetch command:
> git fetch https://github.com/openjdk/skara.git pull/33/head:pull/33

From jonathan.gibbons at oracle.com  Wed Jul 31 17:23:12 2019
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Wed, 31 Jul 2019 10:23:12 -0700
Subject: RFR: Update README.md
In-Reply-To: <80ee34d8-da8a-110d-d1ec-2096581343d8@oracle.com>
References: <JVOTDJxnzghQcaoDlpR3NlwPX5d9wUis5zu1wKya4mQ=.4ae9596d-a1c9-4dc9-88e6-edf3963cde6f@github.com>
 <80ee34d8-da8a-110d-d1ec-2096581343d8@oracle.com>
Message-ID: <d3422475-84bb-a9ed-ca14-f658a99d7e76@oracle.com>

Joe,

I don't know if I count as a Reviewer, but the change looks good to me.

-- Jon


On 07/31/2019 10:25 AM, Joe Darcy wrote:
> PS No additional typos were found in the README.
>
> -Joe
>
> On 7/30/2019 10:48 PM, Joe Darcy via github.com wrote:
>> Fix typo in description of hgbridge.
>>
>> ----------------
>>
>> Commits:
>> ? - ebd737b8:??? Update README.md
>> ??????????? Fix typo in description of hgbridge.
>>
>> Pull request:
>> http://git.openjdk.java.net/skara/pull/33
>>
>> Webrev:
>> https://openjdk.github.io/cr/skara/33/webrev.00
>>
>> Patch:
>> http://git.openjdk.java.net/skara/pull/33.diff
>>
>> Fetch command:
>> git fetch https://github.com/openjdk/skara.git pull/33/head:pull/33