From ihse at openjdk.java.net Fri Oct 1 08:06:40 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Fri, 1 Oct 2021 08:06:40 GMT Subject: Integrated: Improve "git sync" and "git fork" resilience In-Reply-To: References: Message-ID: On Thu, 30 Sep 2021 13:57:52 GMT, Magnus Ihse Bursie wrote: > The Skara CLI tools `git sync` and `git fork` are very much appreciated, but they are not fully designed to make sure you get the intended result. Part of this problem is that they are too general, and part is that they are too dumb. :-) > > These changes make sure that `git sync` always syncs between your personal fork, and the upstream repository (determined by the Git Forge provider as the "parent" repo you created your fork from), and `git fork` always sets up your repository for such `git sync` usage. > > If you really know what you are doing, you *can* still use `git sync` to sync between fully unrelated repos using the `--to` and `--from` arguments, but this is highly discouraged (and will require the `--force` flag as well, to be accepted). > > Before syncing, `git sync` will check that you have a proper `origin` and `upstream` remote configured, and that the upstream is consistent with what the Git Forge provider says. If the `upstream` remote is missing, it will be configured for you (unless `--no-remote` is given). > > `git fork` will now always set the `upstream` remote (unless given `--no-remote`). > > If these sounds like obvious behavior, it is worth noting what happened before. If `upstream` was missing, `git sync` had no idea what to do. `git fork` had a second, undocumented *) mode, in which you could run `git fork` without any arguments in a directory that already contained a checked out repo. That would create a personal fork of that repo on the Git Forge provider, but it would still keep `origin` as the upstream repo URI, and instead add a `fork` remote for the newly created personal fork. This mode of operation was barely supported (and broken) on `git sync`. The backwards way of naming the remotes could lead to no end of troubles. > > *) I say "undocumented" since there is no explicit documentation about this feature that I could found. However, the "upstream URI" argument to `git fork` is documented as "optional" (but all other documentation assumes that it is present, so the behavior when omitted is not specified). > > When implementing these fixes, it was clear that the code was in desperate need of a massive cleanup. There were dead code, code duplication, unclear logic, misleading names, etc... So in the end the code is so different from what I started from that a side-by-side comparison might be impossible. You can see individual changes in the separate commits, or you can review the new version of the files as were they new additions. These refactorings also uncovered a bug in `git fork`, where adding `--no-remote` would disable `--sync` and `--setup-pre-push-hooks`. I fixed that also. > > Unfortunately, we still don't have a testing story for our CLI tools. :-( I have however done extensive ad-hoc testing, with all possible combinations of flags, etc. This pull request has now been integrated. Changeset: e6ce7a6b Author: Magnus Ihse Bursie URL: https://git.openjdk.java.net/skara/commit/e6ce7a6b68177e26b6f91b85eb60f61ec360cc4b Stats: 850 lines in 2 files changed: 386 ins; 222 del; 242 mod Improve "git sync" and "git fork" resilience Reviewed-by: erikj, kcr ------------- PR: https://git.openjdk.java.net/skara/pull/1226 From erik.joelsson at oracle.com Fri Oct 1 13:22:45 2021 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Fri, 1 Oct 2021 06:22:45 -0700 Subject: [External] : Re: Switch jdk8u development to Git/Skara In-Reply-To: References: Message-ID: Hello Andrew, Thank you for your detailed reply! On 2021-09-30 19:25, Andrew Hughes wrote: > Hi. Sorry for the delayed reply, but we needed some time to think > this over in detail. No worries. > I'd still consider the 11u move in progress, as it's not yet > completed a release from the new repository. That's the stage > that particularly concerns me and I'll be keeping an eye on. Understood. > The possibility of a two-phase approach to this has allayed a lot of my > fears about the possibility of such a transition. Following the well-trodden > path used by the main JDK repositories, and the greater time period to > adapt to the transition, would ease things a lot. > > Having discussed this at length with Severin, I propose the following timetable: > > 1. End of November 2021 (Rampdown of 8u322 / Start of 8u332 Development) > > * Convert 8u & 8u-dev to Mercurial mono repositories. > Given they should be identical at this point, it should be possible to > do one conversion of 8u, provide copies at both 8u and 8u-dev, and > then let each copy diverge. > > * Create live read-only mirrors of 8u & 8u-dev in git > > 2. End of February 2022 (Rampdown of 8u332 / Start of 8u342 Development) > > * 8u-dev development switches to Git & Skara, with the previous read-only > git mirror being used directly. > * 8u remains on Mercurial for the release of 8u332. 8u can be synced > to 8u-dev from the 8u git mirror. > > 3. April 2022 (Release of 8u332) > > * 8u git is used directly for promotions of 8u342. > > I think this provides the best balance of risk, while also allowing 8u > to be consumed from git within the next few months. I think this plan looks reasonable, but I will need to check internally before I can give a final go ahead. Could you narrow down the potential cut over windows to date ranges? > The most demand I'm seeing for 8u to be in git is from downstream > users, who expect it to be on github with the rest, while the most > change is required from developers, who have to adapt to the markedly > different process used by Skara. The above allows an additional cycle > for developers to adapt to this change, see the live git mirrors in > operation and perhaps experiment with development in later JDK trees. > Meanwhile, downstream users should be able to start working with > 8u in git from December. > > Please let us know if the above seems feasible. My understanding > is that the majority of work will be at the end of November, > and the second and third changes should just be a matter of making > it possible to commit to the git repositories. Yes, the consolidation is the trickiest part with the most amount of unknowns that could potentially delay things. I do believe I have it under control however. You can look at the current prototype here: https://hg.openjdk.java.net/jdk8u/consol-proto/ > A couple of additional questions: > > 1. Would the consolidation to a monorepo take place on top of > the existing root repository or be an entirely new Mercurial > repository? I've been trying to recall from the jdk10 transition, > but can't remember. Either way, the change for developers should > just be a one-time switch to the repository and the process > of submitting patches remains exactly the same as it is now, > except everything is from the one repository. No, it's a new repository. In the case of the OpenJDK 8u consolidation, it will be based on the existing JDK 10 consolidated repository and share history up until jdk8-b120, where the history started to diverge in the original repositories. The change for developers should be minimal as you say. The guarantee we give is that each promotion tag is equivalent between the monorepo and the forest. > 2. Is the consolidated repository expected to be identical > to a fully-checked out copy of the forest (i.e. the root > repository with each subrepo as a top-level subdirectory). > I know some files moved with jdk10, but I think we'd want > everything to stay the same with 8u. Yes, the file layout is identical. We have no plans to rearrange things for 8u. You may want to do some cleanup afterwards, like removing the hgforest.sh/get_source.sh scripts that are no longer useful and remove the no longer used .hgtags files from old nested repo directories. > 3. As mentioned in another reply, could Skara's backport > command be adapted to "shuffle" the paths to fit the > 8u layout? This may be quite tricky as currently it > requires both the 10u->9u conversion and the 9u->8u > conversion, but without this, the backport command > is effectively unusable and they all would have to > be performed manually. I can see this being a very useful feature, but also a non trivial effort to implement. I can't say at this time if I would personally be able to allocate time for this. > 4. Could Skara be adapted to enforce the jdk8u-fix-yes / > jdk8u-critical-yes JIRA labels so the change can't be pushed until it > has been approved? This sounds like a rather simple feature in comparison. Please file an enhancement request for SKARA. /Erik From christoph.langer at sap.com Fri Oct 1 15:21:05 2021 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 1 Oct 2021 15:21:05 +0000 Subject: [External] : Re: Switch jdk8u development to Git/Skara In-Reply-To: References: Message-ID: Hi, > > 4. Could Skara be adapted to enforce the jdk8u-fix-yes / > > jdk8u-critical-yes JIRA labels so the change can't be pushed until it > > has been approved? > > This sounds like a rather simple feature in comparison. Please file an > enhancement request for SKARA. I filed https://bugs.openjdk.java.net/browse/SKARA-1199 because this would be a very nice feature for the other update projects (e.g. jdk11u) as well. Thanks & Best regards Christoph From erikj at openjdk.java.net Fri Oct 1 18:49:53 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 1 Oct 2021 18:49:53 GMT Subject: Integrated: 1198: Stop using fake non existing from email addresses In-Reply-To: References: Message-ID: On Thu, 30 Sep 2021 22:47:28 GMT, Erik Joelsson wrote: > With this patch, Skara mlbridge will no longer construct fake email addresses for users not in the census. Instead mails will be sent with the configured do-not-reply address (which is currently duke at openjdk.java.net). The full name of the user will still be added, just like before, so it's still possible for a human to see who made the comment that triggered the email. > > Most of the changes are just adapting test cases that relied on this functionality. Those tests should still be valid as they are still verifying the full names correctly. This pull request has now been integrated. Changeset: 75e03472 Author: Erik Joelsson URL: https://git.openjdk.java.net/skara/commit/75e03472cdb5533f24fe874e99604071c9e15452 Stats: 22 lines in 2 files changed: 0 ins; 9 del; 13 mod 1198: Stop using fake non existing from email addresses Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/skara/pull/1228 From erikj at openjdk.java.net Fri Oct 1 18:50:58 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 1 Oct 2021 18:50:58 GMT Subject: Integrated: 1196: Add extension points on RestRequest to support more REST authorization methods In-Reply-To: References: Message-ID: On Thu, 30 Sep 2021 21:34:30 GMT, Erik Joelsson wrote: > This patch adds and extends some extension points in the RestRequest API. The immediate use of these extensions are being implemented in a custom extension to Skara. There are 3 main changes: > > 1. The optional lambda that handles authorization headers for a request now has access to the HttpRequest.Builder, so that it may inspect existing headers. This is causing a lot of small changes throughout the code base, just adding the new parameter to any lambda implementing the FunctionalInterface. > 2. Adding a new optional field to the QueryBuilder, naming a header where a sha256 hash of the request body will be stored. Requiring such a hash seems common enough to have built in support for it in Skara, but the name of the header seems to differ between API providers. > 3. Adding another optional lambda which can override how pagination is handled. This gets access to the HttpResponse to extract any necessary data to generate an HttpRequest.Builder for accessing the next page. This pull request has now been integrated. Changeset: 834e5768 Author: Erik Joelsson URL: https://git.openjdk.java.net/skara/commit/834e576815578ab75801ae9220be3cb10a689ff2 Stats: 91 lines in 11 files changed: 57 ins; 7 del; 27 mod 1196: Add extension points on RestRequest to support more REST authorization methods Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/skara/pull/1227 From ihse at openjdk.java.net Tue Oct 5 11:22:03 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Tue, 5 Oct 2021 11:22:03 GMT Subject: RFR: 1186: Backport command stopped working on Gitlab Message-ID: <5x-TAEO-zqI6nzox_PPJ2oxJCTnauFXdBz0IHhIoLFI=.0e23f664-6e1e-4fb4-930a-fe7825ca252a@github.com> Our POST request to `/members` to add collaborators fails with status code 415 (Unsupported Media Type) on recent versions of Gitlab. This is the only place in our Gitlab code where we do not send REST parameters as json, but as `&`-concatted raw data. I can't find any indication in the Gitlab API documentation that this is no longer supported, but otoh there is no reason to continue handling this method different from all other REST calls. So I am fairly certain that this patch solves the problem (which makes sure we use json parameters here as everywhere else). However, I have not been able to test this. We have no tests that run on live instances of Gitlab, and the adhoc testing setup that I have used to not have a repo where backports are enabled (and I'm also a bit uncertain on how to properly configure that). I believe the patch is likely to be low risk to accept it nevertheless, but I'd like input from Kevin or Erik on this assessment. ------------- Commit messages: - 1186: Backport command stopped working on Gitlab Changes: https://git.openjdk.java.net/skara/pull/1229/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1229&range=00 Issue: https://bugs.openjdk.java.net/browse/SKARA-1186 Stats: 3 lines in 1 file changed: 1 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/skara/pull/1229.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1229/head:pull/1229 PR: https://git.openjdk.java.net/skara/pull/1229 From ihse at openjdk.java.net Tue Oct 5 11:33:18 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Tue, 5 Oct 2021 11:33:18 GMT Subject: RFR: 1189: Update mapping so the Hotspot Style Guide is reviewed on hotspot-dev Message-ID: This will add review target list hotspot-dev for doc/hotspot-style and doc/hotspot-unit-tests. Since there is no exclude mechanism in the mailing list selection, it is not easy to exclude these from the build-dev target. In this case, I think it's okay to cross-post to build-dev (I like to keep track of documentation changes :)) but in the long term I think the mailing list rules should benefit from having an exclusion system to exclude certain subparts of a directory tree (not just in this case). ------------- Commit messages: - 1189: Update mapping so the Hotspot Style Guide is reviewed on hotspot-dev Changes: https://git.openjdk.java.net/skara/pull/1230/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1230&range=00 Issue: https://bugs.openjdk.java.net/browse/SKARA-1189 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/skara/pull/1230.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1230/head:pull/1230 PR: https://git.openjdk.java.net/skara/pull/1230 From kcr at openjdk.java.net Tue Oct 5 11:47:26 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 5 Oct 2021 11:47:26 GMT Subject: RFR: 1189: Update mapping so the Hotspot Style Guide is reviewed on hotspot-dev In-Reply-To: References: Message-ID: On Tue, 5 Oct 2021 11:30:01 GMT, Magnus Ihse Bursie wrote: > This will add review target list hotspot-dev for doc/hotspot-style and doc/hotspot-unit-tests. > > Since there is no exclude mechanism in the mailing list selection, it is not easy to exclude these from the build-dev target. In this case, I think it's okay to cross-post to build-dev (I like to keep track of documentation changes :)) but in the long term I think the mailing list rules should benefit from having an exclusion system to exclude certain subparts of a directory tree (not just in this case). Marked as reviewed by kcr (Reviewer). ------------- PR: https://git.openjdk.java.net/skara/pull/1230 From ihse at openjdk.java.net Tue Oct 5 12:50:16 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Tue, 5 Oct 2021 12:50:16 GMT Subject: RFR: 1201: Multiple command reply messages include 'HostUserDetails' Message-ID: <_S4eqlXpd7d181bPhpGylcvR-B9x-evzYE4lfpQwndk=.d40fd70e-51f7-4d3f-a308-5db20e1b8713@github.com> Fixing this as the bug reporter suggested, by removing all explicit (broken or not) and duplicated constructions of "@" + username in the command replies, and adding a general @-mention in CommitCommands as well as PR Commands. ------------- Commit messages: - 1201: Multiple command reply messages include 'HostUserDetails' Changes: https://git.openjdk.java.net/skara/pull/1231/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1231&range=00 Issue: https://bugs.openjdk.java.net/browse/SKARA-1201 Stats: 26 lines in 5 files changed: 3 ins; 4 del; 19 mod Patch: https://git.openjdk.java.net/skara/pull/1231.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1231/head:pull/1231 PR: https://git.openjdk.java.net/skara/pull/1231 From ihse at openjdk.java.net Tue Oct 5 12:51:46 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Tue, 5 Oct 2021 12:51:46 GMT Subject: Integrated: 1189: Update mapping so the Hotspot Style Guide is reviewed on hotspot-dev In-Reply-To: References: Message-ID: On Tue, 5 Oct 2021 11:30:01 GMT, Magnus Ihse Bursie wrote: > This will add review target list hotspot-dev for doc/hotspot-style and doc/hotspot-unit-tests. > > Since there is no exclude mechanism in the mailing list selection, it is not easy to exclude these from the build-dev target. In this case, I think it's okay to cross-post to build-dev (I like to keep track of documentation changes :)) but in the long term I think the mailing list rules should benefit from having an exclusion system to exclude certain subparts of a directory tree (not just in this case). This pull request has now been integrated. Changeset: 98e2fb01 Author: Magnus Ihse Bursie URL: https://git.openjdk.java.net/skara/commit/98e2fb0179f19eccce0be4e11cde6676eca18ebd Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 1189: Update mapping so the Hotspot Style Guide is reviewed on hotspot-dev Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/skara/pull/1230 From kcr at openjdk.java.net Tue Oct 5 17:56:46 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 5 Oct 2021 17:56:46 GMT Subject: RFR: 1186: Backport command stopped working on Gitlab In-Reply-To: <5x-TAEO-zqI6nzox_PPJ2oxJCTnauFXdBz0IHhIoLFI=.0e23f664-6e1e-4fb4-930a-fe7825ca252a@github.com> References: <5x-TAEO-zqI6nzox_PPJ2oxJCTnauFXdBz0IHhIoLFI=.0e23f664-6e1e-4fb4-930a-fe7825ca252a@github.com> Message-ID: On Tue, 5 Oct 2021 11:19:05 GMT, Magnus Ihse Bursie wrote: > Our POST request to `/members` to add collaborators fails with status code 415 (Unsupported Media Type) on recent versions of Gitlab. > > This is the only place in our Gitlab code where we do not send REST parameters as json, but as `&`-concatted raw data. I can't find any indication in the Gitlab API documentation that this is no longer supported, but otoh there is no reason to continue handling this method different from all other REST calls. > > So I am fairly certain that this patch solves the problem (which makes sure we use json parameters here as everywhere else). However, I have not been able to test this. We have no tests that run on live instances of Gitlab, and the adhoc testing setup that I have used to not have a repo where backports are enabled (and I'm also a bit uncertain on how to properly configure that). > > I believe the patch is likely to be low risk to accept it nevertheless, but I'd like input from Kevin or Erik on this assessment. This looks fine to me. forge/src/main/java/org/openjdk/skara/forge/gitlab/GitLabRepository.java line 584: > 582: request.post("members") > 583: .body("user_id", user.id()) > 584: .body("access_level", accessLevel) Minor: indentation looks off by 1. ------------- Marked as reviewed by kcr (Reviewer). PR: https://git.openjdk.java.net/skara/pull/1229 From kcr at openjdk.java.net Tue Oct 5 18:01:04 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 5 Oct 2021 18:01:04 GMT Subject: RFR: 1201: Multiple command reply messages include 'HostUserDetails' In-Reply-To: <_S4eqlXpd7d181bPhpGylcvR-B9x-evzYE4lfpQwndk=.d40fd70e-51f7-4d3f-a308-5db20e1b8713@github.com> References: <_S4eqlXpd7d181bPhpGylcvR-B9x-evzYE4lfpQwndk=.d40fd70e-51f7-4d3f-a308-5db20e1b8713@github.com> Message-ID: On Tue, 5 Oct 2021 12:47:23 GMT, Magnus Ihse Bursie wrote: > Fixing this as the bug reporter suggested, by removing all explicit (broken or not) and duplicated constructions of "@" + username in the command replies, and adding a general @-mention in CommitCommands as well as PR Commands. Looks fine. ------------- Marked as reviewed by kcr (Reviewer). PR: https://git.openjdk.java.net/skara/pull/1231 From kcr at openjdk.java.net Tue Oct 5 18:18:38 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 5 Oct 2021 18:18:38 GMT Subject: RFR: 1201: Multiple command reply messages include 'HostUserDetails' In-Reply-To: <_S4eqlXpd7d181bPhpGylcvR-B9x-evzYE4lfpQwndk=.d40fd70e-51f7-4d3f-a308-5db20e1b8713@github.com> References: <_S4eqlXpd7d181bPhpGylcvR-B9x-evzYE4lfpQwndk=.d40fd70e-51f7-4d3f-a308-5db20e1b8713@github.com> Message-ID: On Tue, 5 Oct 2021 12:47:23 GMT, Magnus Ihse Bursie wrote: > Fixing this as the bug reporter suggested, by removing all explicit (broken or not) and duplicated constructions of "@" + username in the command replies, and adding a general @-mention in CommitCommands as well as PR Commands. I see a lot of unit test failures, which I hadn't noticed when I approved it. Have you run the tests locally to see what the results are? ------------- PR: https://git.openjdk.java.net/skara/pull/1231 From magnus.ihse.bursie at oracle.com Wed Oct 6 10:41:31 2021 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 6 Oct 2021 12:41:31 +0200 Subject: RFR: 1201: Multiple command reply messages include 'HostUserDetails' In-Reply-To: References: <_S4eqlXpd7d181bPhpGylcvR-B9x-evzYE4lfpQwndk=.d40fd70e-51f7-4d3f-a308-5db20e1b8713@github.com> Message-ID: <33f88a15-e911-58f2-46a0-49be3fba4dd0@oracle.com> No, I have not. :-( Still not fully up to speed on best-practice Skara development. I'll check into those test errors and fix them. /Magnus On 2021-10-05 20:18, Kevin Rushforth wrote: > On Tue, 5 Oct 2021 12:47:23 GMT, Magnus Ihse Bursie wrote: > >> Fixing this as the bug reporter suggested, by removing all explicit (broken or not) and duplicated constructions of "@" + username in the command replies, and adding a general @-mention in CommitCommands as well as PR Commands. > I see a lot of unit test failures, which I hadn't noticed when I approved it. Have you run the tests locally to see what the results are? > > ------------- > > PR: https://git.openjdk.java.net/skara/pull/1231 From ihse at openjdk.java.net Wed Oct 6 10:54:00 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Wed, 6 Oct 2021 10:54:00 GMT Subject: RFR: 1186: Backport command stopped working on Gitlab [v2] In-Reply-To: <5x-TAEO-zqI6nzox_PPJ2oxJCTnauFXdBz0IHhIoLFI=.0e23f664-6e1e-4fb4-930a-fe7825ca252a@github.com> References: <5x-TAEO-zqI6nzox_PPJ2oxJCTnauFXdBz0IHhIoLFI=.0e23f664-6e1e-4fb4-930a-fe7825ca252a@github.com> Message-ID: > Our POST request to `/members` to add collaborators fails with status code 415 (Unsupported Media Type) on recent versions of Gitlab. > > This is the only place in our Gitlab code where we do not send REST parameters as json, but as `&`-concatted raw data. I can't find any indication in the Gitlab API documentation that this is no longer supported, but otoh there is no reason to continue handling this method different from all other REST calls. > > So I am fairly certain that this patch solves the problem (which makes sure we use json parameters here as everywhere else). However, I have not been able to test this. We have no tests that run on live instances of Gitlab, and the adhoc testing setup that I have used to not have a repo where backports are enabled (and I'm also a bit uncertain on how to properly configure that). > > I believe the patch is likely to be low risk to accept it nevertheless, but I'd like input from Kevin or Erik on this assessment. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Fix indentation ------------- Changes: - all: https://git.openjdk.java.net/skara/pull/1229/files - new: https://git.openjdk.java.net/skara/pull/1229/files/853f533f..dd1ac00d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=skara&pr=1229&range=01 - incr: https://webrevs.openjdk.java.net/?repo=skara&pr=1229&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/skara/pull/1229.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1229/head:pull/1229 PR: https://git.openjdk.java.net/skara/pull/1229 From ihse at openjdk.java.net Wed Oct 6 10:57:04 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Wed, 6 Oct 2021 10:57:04 GMT Subject: RFR: 1186: Backport command stopped working on Gitlab [v2] In-Reply-To: References: <5x-TAEO-zqI6nzox_PPJ2oxJCTnauFXdBz0IHhIoLFI=.0e23f664-6e1e-4fb4-930a-fe7825ca252a@github.com> Message-ID: On Tue, 5 Oct 2021 17:54:00 GMT, Kevin Rushforth wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix indentation > > forge/src/main/java/org/openjdk/skara/forge/gitlab/GitLabRepository.java line 584: > >> 582: request.post("members") >> 583: .body("user_id", user.id()) >> 584: .body("access_level", accessLevel) > > Minor: indentation looks off by 1. I fixed it. There is no consistent formatting standard in Skara. :-( In just this file, I found examples of having indentation in multiples of four spaces, e.g. lines 638-640, or (like here) trying to align with the dot, e.g. lines 608-612. I'd *really* prefer that we introduce a well-defined formatting standard, and stick to it. (Possibly doing a one-shot formatting of all code after establishing the standard.) ------------- PR: https://git.openjdk.java.net/skara/pull/1229 From ihse at openjdk.java.net Wed Oct 6 10:57:04 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Wed, 6 Oct 2021 10:57:04 GMT Subject: Integrated: 1186: Backport command stopped working on Gitlab In-Reply-To: <5x-TAEO-zqI6nzox_PPJ2oxJCTnauFXdBz0IHhIoLFI=.0e23f664-6e1e-4fb4-930a-fe7825ca252a@github.com> References: <5x-TAEO-zqI6nzox_PPJ2oxJCTnauFXdBz0IHhIoLFI=.0e23f664-6e1e-4fb4-930a-fe7825ca252a@github.com> Message-ID: <-Dj7rvxtSjiBMh0Jh70z5qxjQe92xPr5vYPt5PuukEQ=.50ee6659-1554-4943-a545-99579232459d@github.com> On Tue, 5 Oct 2021 11:19:05 GMT, Magnus Ihse Bursie wrote: > Our POST request to `/members` to add collaborators fails with status code 415 (Unsupported Media Type) on recent versions of Gitlab. > > This is the only place in our Gitlab code where we do not send REST parameters as json, but as `&`-concatted raw data. I can't find any indication in the Gitlab API documentation that this is no longer supported, but otoh there is no reason to continue handling this method different from all other REST calls. > > So I am fairly certain that this patch solves the problem (which makes sure we use json parameters here as everywhere else). However, I have not been able to test this. We have no tests that run on live instances of Gitlab, and the adhoc testing setup that I have used to not have a repo where backports are enabled (and I'm also a bit uncertain on how to properly configure that). > > I believe the patch is likely to be low risk to accept it nevertheless, but I'd like input from Kevin or Erik on this assessment. This pull request has now been integrated. Changeset: dc477842 Author: Magnus Ihse Bursie URL: https://git.openjdk.java.net/skara/commit/dc47784296aa6daee79745fbe1897db6e3aa45be Stats: 3 lines in 1 file changed: 1 ins; 1 del; 1 mod 1186: Backport command stopped working on Gitlab Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/skara/pull/1229 From ihse at openjdk.java.net Wed Oct 6 12:40:23 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Wed, 6 Oct 2021 12:40:23 GMT Subject: RFR: 1201: Multiple command reply messages include 'HostUserDetails' [v2] In-Reply-To: <_S4eqlXpd7d181bPhpGylcvR-B9x-evzYE4lfpQwndk=.d40fd70e-51f7-4d3f-a308-5db20e1b8713@github.com> References: <_S4eqlXpd7d181bPhpGylcvR-B9x-evzYE4lfpQwndk=.d40fd70e-51f7-4d3f-a308-5db20e1b8713@github.com> Message-ID: > Fixing this as the bug reporter suggested, by removing all explicit (broken or not) and duplicated constructions of "@" + username in the command replies, and adding a general @-mention in CommitCommands as well as PR Commands. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Fix tests that broke ------------- Changes: - all: https://git.openjdk.java.net/skara/pull/1231/files - new: https://git.openjdk.java.net/skara/pull/1231/files/2a897832..2bc294b5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=skara&pr=1231&range=01 - incr: https://webrevs.openjdk.java.net/?repo=skara&pr=1231&range=00-01 Stats: 12 lines in 4 files changed: 0 ins; 0 del; 12 mod Patch: https://git.openjdk.java.net/skara/pull/1231.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1231/head:pull/1231 PR: https://git.openjdk.java.net/skara/pull/1231 From ihse at openjdk.java.net Wed Oct 6 22:20:35 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Wed, 6 Oct 2021 22:20:35 GMT Subject: RFR: 1201: Multiple command reply messages include 'HostUserDetails' [v3] In-Reply-To: <_S4eqlXpd7d181bPhpGylcvR-B9x-evzYE4lfpQwndk=.d40fd70e-51f7-4d3f-a308-5db20e1b8713@github.com> References: <_S4eqlXpd7d181bPhpGylcvR-B9x-evzYE4lfpQwndk=.d40fd70e-51f7-4d3f-a308-5db20e1b8713@github.com> Message-ID: <7_eIuopwsuz03m2TmR2m36vZ9ZGlg5y9Wz__XkO_DnI=.3b2264ca-57f7-492c-a668-8ca9c46df9da@github.com> > Fixing this as the bug reporter suggested, by removing all explicit (broken or not) and duplicated constructions of "@" + username in the command replies, and adding a general @-mention in CommitCommands as well as PR Commands. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Fix makeNonCleanBackportClean ------------- Changes: - all: https://git.openjdk.java.net/skara/pull/1231/files - new: https://git.openjdk.java.net/skara/pull/1231/files/2bc294b5..7e842062 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=skara&pr=1231&range=02 - incr: https://webrevs.openjdk.java.net/?repo=skara&pr=1231&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/skara/pull/1231.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1231/head:pull/1231 PR: https://git.openjdk.java.net/skara/pull/1231 From ihse at openjdk.java.net Wed Oct 6 22:23:05 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Wed, 6 Oct 2021 22:23:05 GMT Subject: RFR: 1201: Multiple command reply messages include 'HostUserDetails' [v3] In-Reply-To: <7_eIuopwsuz03m2TmR2m36vZ9ZGlg5y9Wz__XkO_DnI=.3b2264ca-57f7-492c-a668-8ca9c46df9da@github.com> References: <_S4eqlXpd7d181bPhpGylcvR-B9x-evzYE4lfpQwndk=.d40fd70e-51f7-4d3f-a308-5db20e1b8713@github.com> <7_eIuopwsuz03m2TmR2m36vZ9ZGlg5y9Wz__XkO_DnI=.3b2264ca-57f7-492c-a668-8ca9c46df9da@github.com> Message-ID: On Wed, 6 Oct 2021 22:20:35 GMT, Magnus Ihse Bursie wrote: >> Fixing this as the bug reporter suggested, by removing all explicit (broken or not) and duplicated constructions of "@" + username in the command replies, and adding a general @-mention in CommitCommands as well as PR Commands. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Fix makeNonCleanBackportClean The last failing test was weird. We tried adding the `/clean` command to a backport, and yet somehow it did not get the `clean` label. Although debugging showed that we did set the label, but when we checked for it, it was gone. It turned out that there were an additional task that was run that removed the `clean` label, unless the exact wording as written by the response comment of the `/clean` command were present. (Which now had changed slightly) This feels extremely brittle. If we should look for special comments made by the bots, we should tag them using `` or something like that. I wonder how many more surprises like this lies dormant in the code... ------------- PR: https://git.openjdk.java.net/skara/pull/1231 From ihse at openjdk.java.net Thu Oct 7 06:25:07 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Thu, 7 Oct 2021 06:25:07 GMT Subject: Integrated: 1201: Multiple command reply messages include 'HostUserDetails' In-Reply-To: <_S4eqlXpd7d181bPhpGylcvR-B9x-evzYE4lfpQwndk=.d40fd70e-51f7-4d3f-a308-5db20e1b8713@github.com> References: <_S4eqlXpd7d181bPhpGylcvR-B9x-evzYE4lfpQwndk=.d40fd70e-51f7-4d3f-a308-5db20e1b8713@github.com> Message-ID: On Tue, 5 Oct 2021 12:47:23 GMT, Magnus Ihse Bursie wrote: > Fixing this as the bug reporter suggested, by removing all explicit (broken or not) and duplicated constructions of "@" + username in the command replies, and adding a general @-mention in CommitCommands as well as PR Commands. This pull request has now been integrated. Changeset: c731445c Author: Magnus Ihse Bursie URL: https://git.openjdk.java.net/skara/commit/c731445ce5dc110ad1967c8f6b1e7065a49c4f9e Stats: 39 lines in 10 files changed: 3 ins; 4 del; 32 mod 1201: Multiple command reply messages include 'HostUserDetails' Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/skara/pull/1231 From ihse at openjdk.java.net Thu Oct 7 12:52:02 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Thu, 7 Oct 2021 12:52:02 GMT Subject: RFR: Do not print "Optional[repo name]" for backport PR command Message-ID: The sneaky `var` notation has caused a type problem. :-( `var repoName` was in fact `Optional`, not `String`, so when printing this to the user, it was presented like this: "Could not automatically backport 481a0456 to Optional[openjdk/jdk11u-dev] due to conflicts in the following files:" The naming here is perhaps not my proudest moment, but I did not want to mess with the usage by `potentialTargetRepo` and so I wanted to keep the original value. I think the else-string will never actually show up, due to the isEmpty() check on potentialTargetRepo. ------------- Commit messages: - Do not print "Optional[repo name]" for backport PR command Changes: https://git.openjdk.java.net/skara/pull/1232/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1232&range=00 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/skara/pull/1232.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1232/head:pull/1232 PR: https://git.openjdk.java.net/skara/pull/1232 From erikj at openjdk.java.net Mon Oct 11 13:19:36 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 11 Oct 2021 13:19:36 GMT Subject: RFR: Do not print "Optional[repo name]" for backport PR command In-Reply-To: References: Message-ID: On Thu, 7 Oct 2021 12:48:43 GMT, Magnus Ihse Bursie wrote: > The sneaky `var` notation has caused a type problem. :-( `var repoName` was in fact `Optional`, not `String`, so when printing this to the user, it was presented like this: > > "Could not automatically backport 481a0456 to Optional[openjdk/jdk11u-dev] due to conflicts in the following files:" > > The naming here is perhaps not my proudest moment, but I did not want to mess with the usage by `potentialTargetRepo` and so I wanted to keep the original value. I think the else-string will never actually show up, due to the isEmpty() check on potentialTargetRepo. Marked as reviewed by erikj (Lead). ------------- PR: https://git.openjdk.java.net/skara/pull/1232 From ihse at openjdk.java.net Mon Oct 11 17:51:30 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Mon, 11 Oct 2021 17:51:30 GMT Subject: Integrated: Do not print "Optional[repo name]" for backport PR command In-Reply-To: References: Message-ID: On Thu, 7 Oct 2021 12:48:43 GMT, Magnus Ihse Bursie wrote: > The sneaky `var` notation has caused a type problem. :-( `var repoName` was in fact `Optional`, not `String`, so when printing this to the user, it was presented like this: > > "Could not automatically backport 481a0456 to Optional[openjdk/jdk11u-dev] due to conflicts in the following files:" > > The naming here is perhaps not my proudest moment, but I did not want to mess with the usage by `potentialTargetRepo` and so I wanted to keep the original value. I think the else-string will never actually show up, due to the isEmpty() check on potentialTargetRepo. This pull request has now been integrated. Changeset: 42e04b17 Author: Magnus Ihse Bursie URL: https://git.openjdk.java.net/skara/commit/42e04b179457d4201ad640a55b7fea3c275a7b46 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Do not print "Optional[repo name]" for backport PR command Reviewed-by: erikj ------------- PR: https://git.openjdk.java.net/skara/pull/1232 From erikj at openjdk.java.net Mon Oct 11 21:50:42 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 11 Oct 2021 21:50:42 GMT Subject: RFR: 885: jbsupdater -pool record consumption modifications Message-ID: <6bImrRAmF5NqLabya0LJ-PNPtUYCk5HSu4RUVWo_3ss=.501b7889-cf88-450d-89df-299c06189c66@github.com> This patch changes how -pool records are consumed, to help differentiate between OpenJDK and OracleJDK update releases. OracleJDK update releases have moved to using fixVersions with an -oracle suffix. With this change, pool record consumption for such releases will also use an -oracle suffix. I opted for a very simple implementation, where any "-suffix" on a fixVersion is now required as suffix on a -pool version to be a match. I think this makes the most sense and keeps things simple going forward. While in the area, I also removed logic for treating N-open fixVersions the same way as N-pool versions. I have no memory of seeing that behavior in action and I believe that implementation was based on a misunderstanding. I could be wrong however, so if anyone can think of a reason to keep that logic, please let me know. ------------- Commit messages: - SKARA-885 Changes: https://git.openjdk.java.net/skara/pull/1233/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1233&range=00 Issue: https://bugs.openjdk.java.net/browse/SKARA-885 Stats: 21 lines in 4 files changed: 13 ins; 0 del; 8 mod Patch: https://git.openjdk.java.net/skara/pull/1233.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1233/head:pull/1233 PR: https://git.openjdk.java.net/skara/pull/1233 From ihse at openjdk.java.net Tue Oct 12 08:59:07 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Tue, 12 Oct 2021 08:59:07 GMT Subject: RFR: 885: jbsupdater -pool record consumption modifications In-Reply-To: <6bImrRAmF5NqLabya0LJ-PNPtUYCk5HSu4RUVWo_3ss=.501b7889-cf88-450d-89df-299c06189c66@github.com> References: <6bImrRAmF5NqLabya0LJ-PNPtUYCk5HSu4RUVWo_3ss=.501b7889-cf88-450d-89df-299c06189c66@github.com> Message-ID: On Mon, 11 Oct 2021 21:47:05 GMT, Erik Joelsson wrote: > This patch changes how -pool records are consumed, to help differentiate between OpenJDK and OracleJDK update releases. OracleJDK update releases have moved to using fixVersions with an -oracle suffix. With this change, pool record consumption for such releases will also use an -oracle suffix. I opted for a very simple implementation, where any "-suffix" on a fixVersion is now required as suffix on a -pool version to be a match. I think this makes the most sense and keeps things simple going forward. > > While in the area, I also removed logic for treating N-open fixVersions the same way as N-pool versions. I have no memory of seeing that behavior in action and I believe that implementation was based on a misunderstanding. I could be wrong however, so if anyone can think of a reason to keep that logic, please let me know. It looks like the patch does what you claim it to do. :-) I can't say I fully understand the -pool (or backporting in general) relationship, though, so I can't really if this is the correct action. ------------- Marked as reviewed by ihse (Reviewer). PR: https://git.openjdk.java.net/skara/pull/1233 From kcr at openjdk.java.net Tue Oct 12 11:55:57 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 12 Oct 2021 11:55:57 GMT Subject: RFR: 885: jbsupdater -pool record consumption modifications In-Reply-To: <6bImrRAmF5NqLabya0LJ-PNPtUYCk5HSu4RUVWo_3ss=.501b7889-cf88-450d-89df-299c06189c66@github.com> References: <6bImrRAmF5NqLabya0LJ-PNPtUYCk5HSu4RUVWo_3ss=.501b7889-cf88-450d-89df-299c06189c66@github.com> Message-ID: On Mon, 11 Oct 2021 21:47:05 GMT, Erik Joelsson wrote: > This patch changes how -pool records are consumed, to help differentiate between OpenJDK and OracleJDK update releases. OracleJDK update releases have moved to using fixVersions with an -oracle suffix. With this change, pool record consumption for such releases will also use an -oracle suffix. I opted for a very simple implementation, where any "-suffix" on a fixVersion is now required as suffix on a -pool version to be a match. I think this makes the most sense and keeps things simple going forward. > > While in the area, I also removed logic for treating N-open fixVersions the same way as N-pool versions. I have no memory of seeing that behavior in action and I believe that implementation was based on a misunderstanding. I could be wrong however, so if anyone can think of a reason to keep that logic, please let me know. This looks correct to me, too. ------------- Marked as reviewed by kcr (Reviewer). PR: https://git.openjdk.java.net/skara/pull/1233 From erik.joelsson at oracle.com Tue Oct 12 21:51:45 2021 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Tue, 12 Oct 2021 14:51:45 -0700 Subject: Switch jdk7u development to Git/Skara Message-ID: <24feab95-a6fb-6959-c7bc-7c6de51d28a1@oracle.com> Hello jdk7u maintainers, I would like to raise the subject of potentially moving jdk7u development over to Github/Skara at some point in the future. Currently the only 2 projects still on hg.openjdk.java.net are jdk7u and jdk8u, and we are currently in the process of figuring out the migration path for jdk8u [1]. If the current plan holds, then in April 2022, jdk7u will be the only project left. I don't know how long jdk7u will stay active, but even if it's for a limited time, the move would be greatly appreciated from an infrastructure support point of view. The move for 7u is similar to 8u and a bit trickier than the previous move of 11u. We first need to consolidate the Mercurial repositories into one, like we did for 10. I have already produced a prototype conversion, both of a consolidated HG repo [2] and then also to Github [3]. In the jdk8u plan, we are aiming for a separate forest consolidation step in November, followed by a two step move to Git in February and April respectively. We can do the same thing for 7u, or we can do it all in one step. Note that the consolidation is the step that has the most potential for down time. I would recommend planning for a full week just in case something goes wrong, though expected time is more likely around 1-2 days. I would like to hear from the maintainers of jdk7u what your preferred strategy would be and what timelines would potentially work for you. /Erik [1] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2021-October/014316.html [2] http://hg.openjdk.java.net/jdk7u/consol-proto/ [3] https://github.com/openjdk/jdk7u From erik.joelsson at oracle.com Tue Oct 12 22:13:47 2021 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Tue, 12 Oct 2021 15:13:47 -0700 Subject: [External] : Re: Switch jdk8u development to Git/Skara In-Reply-To: References: Message-ID: On 2021-10-01 06:22, erik.joelsson at oracle.com wrote: >> Having discussed this at length with Severin, I propose the following >> timetable: >> >> 1. End of November 2021 (Rampdown of 8u322 / Start of 8u332 Development) >> >> * Convert 8u & 8u-dev to Mercurial mono repositories. >> Given they should be identical at this point, it should be possible to >> do one conversion of 8u, provide copies at both 8u and 8u-dev, and >> then let each copy diverge. >> >> * Create live read-only mirrors of 8u & 8u-dev in git >> >> 2. End of February 2022 (Rampdown of 8u332 / Start of 8u342 Development) >> >> * 8u-dev development switches to Git & Skara, with the previous >> read-only >> git mirror being used directly. >> * 8u remains on Mercurial for the release of 8u332.? 8u can be synced >> to 8u-dev from the 8u git mirror. >> >> 3. April 2022 (Release of 8u332) >> >> * 8u git is used directly for promotions of 8u342. >> >> I think this provides the best balance of risk, while also allowing 8u >> to be consumed from git within the next few months. > I think this plan looks reasonable, but I will need to check > internally before I can give a final go ahead. Could you narrow down > the potential cut over windows to date ranges? > We think this timetable is good. I have filed [1] for the first step. We need to decide on: 1. Cutoff date 2. New URL/name for https://hg.openjdk.java.net/jdk8u/jdk8u 3. New URL/name for https://hg.openjdk.java.net/jdk8u/jdk8u-dev /Erik [1] https://bugs.openjdk.java.net/browse/SKARA-1214 From erik.joelsson at oracle.com Wed Oct 13 12:52:56 2021 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Wed, 13 Oct 2021 05:52:56 -0700 Subject: [External] : Re: Switch jdk8u development to Git/Skara In-Reply-To: References: Message-ID: On 2021-10-12 16:13, Andrew Hughes wrote: > On 06:22 Fri 01 Oct , erik.joelsson at oracle.com wrote: >> I think this plan looks reasonable, but I will need to check internally >> before I can give a final go ahead. Could you narrow down the potential >> cut over windows to date ranges? > Certainly. > > 1. The monorepo transition and creation of live read-only git mirrors > would be after the rampdown of 8u322, which is scheduled for Friday, > November the 26th, 2021. So I would expect the transition to begin on > the week beginning Monday, November the 29th, 2021. One of the > reasons we chose this particular period for what is expected to be the > most involved work is that the December period is usually quiet, as > many people ramp down themselves for the holiday period. So a delay > should be less problematic than at other times. > > 2. The 8u-dev git repo should go live the week beginning Monday, > February 28th, 2022, following rampdown on Friday the 25th. > Technically, this should hopefully just mean making the repository > writable. The main issue is in adjusting our processes to using > git and Skara. > > 3. The 8u git repo should go live after the 8u332 release is pushed, > on Tuesday, April the 19th 2022. As 8u is only used at this point > for the build promotions I'm making, a delay here doesn't > directly affect developers; it would just mean a later build promotion. > > I've updated the 8u wiki with the 8u322 & 8u332 schedules as well: > > https://wiki.openjdk.java.net/display/jdk8u/Main Thanks, updating my calendar. >> Yes, the consolidation is the trickiest part with the most amount of >> unknowns that could potentially delay things. I do believe I have it >> under control however. You can look at the current prototype here: >> >> https://hg.openjdk.java.net/jdk8u/consol-proto/ >> > Thanks. Are the commits from duke usual? The one for 8u312-b05 > particularly catches my attention, as I'd expect several tags > from myself, as with b04, instead. Yes, this is (unfortunately) normal. The original tag commits are transplanted over to the mono repo, but they are no longer actual tag commits as they refer to .hgtags files that are no longer actual .hgtags files. The actual new tags are created at consolidation time and I use the user "duke" to create them (just as "duke" is also performing all the merges that need to be done). For every tag except the very last one, the original tag commits are included in the mono repo, as they are part of the changes for the next tag. For the very last tag however, the current logic does not include them. At least for the prototype, doing so would invalidate (or at least complicate) the ability to incrementally continue the consolidation with new changes. In theory, I could convert them at the very end as a special case, but I don't think it's really worth it. The same thing happened in the JDK 10 consolidation. > That makes sense. In the worst case, I assume the original forest will > still be available for reference. > > One of the reasons I suggest the rampdown for the consolidation is we > should be able to just do the process once for 8u, and then 8u-dev can > just be a duplicate that diverges afterwards. > > I presume once the hg monorepos are there, we can have read-only git > mirrors which will eventually become the live repos? Yes, all correct. The old forests will be around as read-only references for a very long time. There are a lot of deep links in JBS for example pointing into repositories. Doing the consolidation at a point where 8u and 8u-dev are equivalent definitely helps. Git mirrors will be up very soon after the consolidation. >> Yes, the file layout is identical. We have no plans to rearrange things >> for 8u. You may want to do some cleanup afterwards, like removing the >> hgforest.sh/get_source.sh scripts that are no longer useful and remove >> the no longer used .hgtags files from old nested repo directories. > That's good to hear. Yes, having just been looking through the 11.0.13 > changes, I see quite a few alterations to adapt to using git in > build instructions, testing, etc. I expect we'll want to do similar > over the 8u322 & 8u332 lifecycles. There is also a bit of build logic in there to record the state of the HG forest into the release file that needed to be adapted to git. >>> 4. Could Skara be adapted to enforce the jdk8u-fix-yes / >>> jdk8u-critical-yes JIRA labels so the change can't be pushed until it >>> has been approved? >> This sounds like a rather simple feature in comparison. Please file an >> enhancement request for SKARA. >> > Oh, excellent, will do. > I believe Christoph beat you to it. See SKARA-1199. /Erik From erikj at openjdk.java.net Wed Oct 13 14:20:51 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 13 Oct 2021 14:20:51 GMT Subject: RFR: 1213: Generic jdk-cpu fixVersion Message-ID: This patch does two things. 1. Makes "jdk-cpu" a valid JdkVersion in Skara terms. This will allow us to use this generic version as fixversion for our jdk-cpu repos. 2. Makes it possible to configure "altfixversions" for a repository in the notifier. If an altfixversion is configured for a branch, then the notifier will not attempt to update any bugs or add any new backports if one of the altfixversions is already found to be fixed. The second change is needed to prevent changes being merged from jdk to jdk-cpu from creating new backport records for every change in the jdk repo. I removed the test "testIssuePoolOpenVersion" as it was an exact copy of the test preceding it "testIssuePoolVersion". ------------- Commit messages: - Allow generic jdk-cpu fixVersion - Make jdk-cpu a valid JdkVersion Changes: https://git.openjdk.java.net/skara/pull/1234/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1234&range=00 Issue: https://bugs.openjdk.java.net/browse/SKARA-1213 Stats: 204 lines in 8 files changed: 149 ins; 11 del; 44 mod Patch: https://git.openjdk.java.net/skara/pull/1234.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1234/head:pull/1234 PR: https://git.openjdk.java.net/skara/pull/1234 From erikj at openjdk.java.net Wed Oct 13 18:17:02 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 13 Oct 2021 18:17:02 GMT Subject: RFR: 1216: Update to JDK 17 and Gradle 7.2 Message-ID: This patch bumps the required JDK version to build and run Skara to JDK 17 and the version of Gradle to 7.2. I'm also eliminating some redundant declarations of where to download the JDK binaries so that it's all defined in deps.env. ------------- Commit messages: - SKARA-1216 Changes: https://git.openjdk.java.net/skara/pull/1235/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1235&range=00 Issue: https://bugs.openjdk.java.net/browse/SKARA-1216 Stats: 34 lines in 5 files changed: 10 ins; 0 del; 24 mod Patch: https://git.openjdk.java.net/skara/pull/1235.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1235/head:pull/1235 PR: https://git.openjdk.java.net/skara/pull/1235 From kcr at openjdk.java.net Wed Oct 13 18:20:15 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 13 Oct 2021 18:20:15 GMT Subject: RFR: 1216: Update to JDK 17 and Gradle 7.2 In-Reply-To: References: Message-ID: <6tWEC4LiP7BIDQCWfof6owuaTQ6e9nr0IdkF-FzOvTc=.74d933b8-37e1-4a1b-a4bf-2cf7c8b33ab2@github.com> On Wed, 13 Oct 2021 18:13:41 GMT, Erik Joelsson wrote: > This patch bumps the required JDK version to build and run Skara to JDK 17 and the version of Gradle to 7.2. I'm also eliminating some redundant declarations of where to download the JDK binaries so that it's all defined in deps.env. Many projects "happen to work" when using JDK 17 with gradle 7.2, but it isn't supported until gradle 7.3, which is not yet released. See gradle/gradle#16857 ------------- PR: https://git.openjdk.java.net/skara/pull/1235 From erikj at openjdk.java.net Wed Oct 13 19:25:40 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 13 Oct 2021 19:25:40 GMT Subject: RFR: 1216: Update to JDK 17 and Gradle 7.2 In-Reply-To: References: Message-ID: On Wed, 13 Oct 2021 18:13:41 GMT, Erik Joelsson wrote: > This patch bumps the required JDK version to build and run Skara to JDK 17 and the version of Gradle to 7.2. I'm also eliminating some redundant declarations of where to download the JDK binaries so that it's all defined in deps.env. > Many projects "happen to work" when using JDK 17 with gradle 7.2, but it isn't supported until gradle 7.3, which is not yet released. See [gradle/gradle#16857](https://github.com/gradle/gradle/issues/16857) Yes, I did see that bug so I decided to test the Skara project myself. From what I understand, we aren't doing too crazy stuff in the Skara build and so far, things seem to be working. But you also have a point that there is no official support yet. ------------- PR: https://git.openjdk.java.net/skara/pull/1235 From ihse at openjdk.java.net Wed Oct 13 20:53:24 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Wed, 13 Oct 2021 20:53:24 GMT Subject: RFR: 1216: Update to JDK 17 and Gradle 7.2 In-Reply-To: References: Message-ID: On Wed, 13 Oct 2021 18:13:41 GMT, Erik Joelsson wrote: > This patch bumps the required JDK version to build and run Skara to JDK 17 and the version of Gradle to 7.2. I'm also eliminating some redundant declarations of where to download the JDK binaries so that it's all defined in deps.env. Marked as reviewed by ihse (Reviewer). ------------- PR: https://git.openjdk.java.net/skara/pull/1235 From kcr at openjdk.java.net Wed Oct 13 21:22:26 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 13 Oct 2021 21:22:26 GMT Subject: RFR: 1216: Update to JDK 17 and Gradle 7.2 In-Reply-To: References: Message-ID: On Wed, 13 Oct 2021 18:13:41 GMT, Erik Joelsson wrote: > This patch bumps the required JDK version to build and run Skara to JDK 17 and the version of Gradle to 7.2. I'm also eliminating some redundant declarations of where to download the JDK binaries so that it's all defined in deps.env. I have no objection if you want to update to gradle 7.2 and JDK 17 as long as you've done enough testing. It looks like you missed updating [gradle/wrapper/gradle-wrapper.properties](https://github.com/openjdk/skara/blob/master/gradle/wrapper/gradle-wrapper.properties#L22). ------------- PR: https://git.openjdk.java.net/skara/pull/1235 From erikj at openjdk.java.net Wed Oct 13 21:41:47 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 13 Oct 2021 21:41:47 GMT Subject: RFR: 1216: Update to JDK 17 and Gradle 7.2 [v2] In-Reply-To: References: Message-ID: > This patch bumps the required JDK version to build and run Skara to JDK 17 and the version of Gradle to 7.2. I'm also eliminating some redundant declarations of where to download the JDK binaries so that it's all defined in deps.env. Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision: Update gradle wrapper ------------- Changes: - all: https://git.openjdk.java.net/skara/pull/1235/files - new: https://git.openjdk.java.net/skara/pull/1235/files/6b4eda61..9a9279d4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=skara&pr=1235&range=01 - incr: https://webrevs.openjdk.java.net/?repo=skara&pr=1235&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/skara/pull/1235.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1235/head:pull/1235 PR: https://git.openjdk.java.net/skara/pull/1235 From erikj at openjdk.java.net Wed Oct 13 21:41:47 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 13 Oct 2021 21:41:47 GMT Subject: RFR: 1216: Update to JDK 17 and Gradle 7.2 In-Reply-To: References: Message-ID: On Wed, 13 Oct 2021 21:20:00 GMT, Kevin Rushforth wrote: > I have no objection if you want to update to gradle 7.2 and JDK 17 as long as you've done enough testing. > > It looks like you missed updating [gradle/wrapper/gradle-wrapper.properties](https://github.com/openjdk/skara/blob/master/gradle/wrapper/gradle-wrapper.properties#L22). Ah good catch. The gradle-wrapper.properties isn't used by the main gradlew script, but I suppose it's there to be picked up by IDEs. ------------- PR: https://git.openjdk.java.net/skara/pull/1235 From serb at openjdk.java.net Wed Oct 13 23:08:39 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Wed, 13 Oct 2021 23:08:39 GMT Subject: RFR: 1216: Update to JDK 17 and Gradle 7.2 [v2] In-Reply-To: References: Message-ID: On Wed, 13 Oct 2021 21:41:47 GMT, Erik Joelsson wrote: >> This patch bumps the required JDK version to build and run Skara to JDK 17 and the version of Gradle to 7.2. I'm also eliminating some redundant declarations of where to download the JDK binaries so that it's all defined in deps.env. > > Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision: > > Update gradle wrapper It works! Thank you for fixing that! And now it is possible to use it on m1 w/o rosetta ------------- Marked as reviewed by serb (no project role). PR: https://git.openjdk.java.net/skara/pull/1235 From kcr at openjdk.java.net Wed Oct 13 23:22:06 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 13 Oct 2021 23:22:06 GMT Subject: RFR: 1216: Update to JDK 17 and Gradle 7.2 [v2] In-Reply-To: References: Message-ID: <3Qg9RbTSn2wDL-fxMa98yI8H6m5Zu13SdL1WOhosNBY=.ea837585-5b23-44e6-b960-0f17b3ac33ba@github.com> On Wed, 13 Oct 2021 21:41:47 GMT, Erik Joelsson wrote: >> This patch bumps the required JDK version to build and run Skara to JDK 17 and the version of Gradle to 7.2. I'm also eliminating some redundant declarations of where to download the JDK binaries so that it's all defined in deps.env. > > Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision: > > Update gradle wrapper Looks good. ------------- Marked as reviewed by kcr (Reviewer). PR: https://git.openjdk.java.net/skara/pull/1235 From erikj at openjdk.java.net Thu Oct 14 18:48:11 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 14 Oct 2021 18:48:11 GMT Subject: Integrated: 1216: Update to JDK 17 and Gradle 7.2 In-Reply-To: References: Message-ID: On Wed, 13 Oct 2021 18:13:41 GMT, Erik Joelsson wrote: > This patch bumps the required JDK version to build and run Skara to JDK 17 and the version of Gradle to 7.2. I'm also eliminating some redundant declarations of where to download the JDK binaries so that it's all defined in deps.env. This pull request has now been integrated. Changeset: a0fbcadd Author: Erik Joelsson URL: https://git.openjdk.java.net/skara/commit/a0fbcadd92ab29b7f41fe39c335ea2ecbf02a2e2 Stats: 36 lines in 6 files changed: 10 ins; 0 del; 26 mod 1216: Update to JDK 17 and Gradle 7.2 Reviewed-by: ihse, serb, kcr ------------- PR: https://git.openjdk.java.net/skara/pull/1235 From erikj at openjdk.java.net Thu Oct 14 19:19:48 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 14 Oct 2021 19:19:48 GMT Subject: RFR: 885: jbsupdater -pool record consumption modifications [v2] In-Reply-To: <6bImrRAmF5NqLabya0LJ-PNPtUYCk5HSu4RUVWo_3ss=.501b7889-cf88-450d-89df-299c06189c66@github.com> References: <6bImrRAmF5NqLabya0LJ-PNPtUYCk5HSu4RUVWo_3ss=.501b7889-cf88-450d-89df-299c06189c66@github.com> Message-ID: > This patch changes how -pool records are consumed, to help differentiate between OpenJDK and OracleJDK update releases. OracleJDK update releases have moved to using fixVersions with an -oracle suffix. With this change, pool record consumption for such releases will also use an -oracle suffix. I opted for a very simple implementation, where any "-suffix" on a fixVersion is now required as suffix on a -pool version to be a match. I think this makes the most sense and keeps things simple going forward. > > While in the area, I also removed logic for treating N-open fixVersions the same way as N-pool versions. I have no memory of seeing that behavior in action and I believe that implementation was based on a misunderstanding. I could be wrong however, so if anyone can think of a reason to keep that logic, please let me know. Erik Joelsson has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Fall back to normal N-pool records if no matching N-pool- record is found - Merge branch 'master' into SKARA-885-pool-records - SKARA-885 ------------- Changes: - all: https://git.openjdk.java.net/skara/pull/1233/files - new: https://git.openjdk.java.net/skara/pull/1233/files/b59a7468..a1cf9edd Webrevs: - full: https://webrevs.openjdk.java.net/?repo=skara&pr=1233&range=01 - incr: https://webrevs.openjdk.java.net/?repo=skara&pr=1233&range=00-01 Stats: 81 lines in 8 files changed: 41 ins; 4 del; 36 mod Patch: https://git.openjdk.java.net/skara/pull/1233.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1233/head:pull/1233 PR: https://git.openjdk.java.net/skara/pull/1233 From erikj at openjdk.java.net Thu Oct 14 19:19:49 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 14 Oct 2021 19:19:49 GMT Subject: RFR: 885: jbsupdater -pool record consumption modifications In-Reply-To: <6bImrRAmF5NqLabya0LJ-PNPtUYCk5HSu4RUVWo_3ss=.501b7889-cf88-450d-89df-299c06189c66@github.com> References: <6bImrRAmF5NqLabya0LJ-PNPtUYCk5HSu4RUVWo_3ss=.501b7889-cf88-450d-89df-299c06189c66@github.com> Message-ID: <0txT8gcFIyqwGPFNLb0cuMN2GacI8BCC41Bq0KumACE=.32ca650e-c2b2-447c-870b-def24d655153@github.com> On Mon, 11 Oct 2021 21:47:05 GMT, Erik Joelsson wrote: > This patch changes how -pool records are consumed, to help differentiate between OpenJDK and OracleJDK update releases. OracleJDK update releases have moved to using fixVersions with an -oracle suffix. With this change, pool record consumption for such releases will also use an -oracle suffix. I opted for a very simple implementation, where any "-suffix" on a fixVersion is now required as suffix on a -pool version to be a match. I think this makes the most sense and keeps things simple going forward. > > While in the area, I also removed logic for treating N-open fixVersions the same way as N-pool versions. I have no memory of seeing that behavior in action and I believe that implementation was based on a misunderstanding. I could be wrong however, so if anyone can think of a reason to keep that logic, please let me know. To ease the deployment of this change and the transition that will follow, I decided to change the behavior and continue to fall back to regular N-pool records if no N-pool- record is found. With this change, we can deploy this PR as it is without affecting anything currently in use. Later we may decide to require N-pool- records to avoid stealing N-pool records. ------------- PR: https://git.openjdk.java.net/skara/pull/1233 From erikj at openjdk.java.net Mon Oct 18 18:42:18 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 18 Oct 2021 18:42:18 GMT Subject: RFR: 1184: Failure to retrieve the JBS bug should be an integration blocker Message-ID: This patch makes it an integration blocker if the Skara bot is unable to read an Issue in the issue tracker system that the PR is claiming to fix. The PR bot for github repos uses credentials that can only see publicly viewable bugs, so this will make it impossible for Oracle employees to accidentally use a "confidential" bug for change in OpenJDK. ------------- Commit messages: - Restore Issues list for missing issues - SKARA-1184 Changes: https://git.openjdk.java.net/skara/pull/1236/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1236&range=00 Issue: https://bugs.openjdk.java.net/browse/SKARA-1184 Stats: 77 lines in 2 files changed: 56 ins; 6 del; 15 mod Patch: https://git.openjdk.java.net/skara/pull/1236.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1236/head:pull/1236 PR: https://git.openjdk.java.net/skara/pull/1236 From erikj at openjdk.java.net Mon Oct 18 18:42:19 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 18 Oct 2021 18:42:19 GMT Subject: RFR: 1184: Failure to retrieve the JBS bug should be an integration blocker In-Reply-To: References: Message-ID: On Mon, 18 Oct 2021 18:37:39 GMT, Erik Joelsson wrote: > This patch makes it an integration blocker if the Skara bot is unable to read an Issue in the issue tracker system that the PR is claiming to fix. The PR bot for github repos uses credentials that can only see publicly viewable bugs, so this will make it impossible for Oracle employees to accidentally use a "confidential" bug for change in OpenJDK. bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckRun.java line 505: > 503: } > 504: } > 505: progressBody.append("\n"); One of the logical paths here was missing adding the newline, while I definitely think it should do so, so I figured it should be moved to the end instead. bots/pr/src/test/java/org/openjdk/skara/bots/pr/IssueTests.java line 189: > 187: var editHash = CheckableRepository.appendAndCommit(localRepo); > 188: localRepo.push(editHash, author.url(), "edit", true); > 189: var issue1 = credentials.createIssue(issues, "Main"); This test needed a bit of a rewrite so that all issues referenced were actually present in the mock issue tracker. ------------- PR: https://git.openjdk.java.net/skara/pull/1236 From erikj at openjdk.java.net Mon Oct 18 18:52:38 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 18 Oct 2021 18:52:38 GMT Subject: RFR: 1184: Failure to retrieve the JBS bug should be an integration blocker In-Reply-To: References: Message-ID: On Mon, 18 Oct 2021 18:37:39 GMT, Erik Joelsson wrote: > This patch makes it an integration blocker if the Skara bot is unable to read an Issue in the issue tracker system that the PR is claiming to fix. The PR bot for github repos uses credentials that can only see publicly viewable bugs, so this will make it impossible for Oracle employees to accidentally use a "confidential" bug for change in OpenJDK. Here is a PR in the playground where the new functionality can be observed: https://github.com/openjdk/playground/pull/91 It's unfortunate that the error message appears twice in the PR body, but I can't really see a good way out of that. The check itself fits best in the integration blocker group of checks, which are calculated in the bot itself, separate from Jcheck. The "Issue(s)" section is meant to be informative and is generated separately. When generating the Issue(s) section, it will also try to contact the issue tracker to get issue data, and if that fails (which it could do on its own, independent of the integration blocker check) I think it would be wrong it just silently ignore that. The goal is to make this obvious to the user, so I don't think it's a big problem. ------------- PR: https://git.openjdk.java.net/skara/pull/1236 From ihse at openjdk.java.net Tue Oct 19 11:46:36 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Tue, 19 Oct 2021 11:46:36 GMT Subject: RFR: 1184: Failure to retrieve the JBS bug should be an integration blocker In-Reply-To: References: Message-ID: <6I2d5FedLJgO262H6hqPtRmuSgk-yd4vlRlKdtNdykk=.f2191c00-811f-4360-87ec-e707597f53af@github.com> On Mon, 18 Oct 2021 18:37:39 GMT, Erik Joelsson wrote: > This patch makes it an integration blocker if the Skara bot is unable to read an Issue in the issue tracker system that the PR is claiming to fix. The PR bot for github repos uses credentials that can only see publicly viewable bugs, so this will make it impossible for Oracle employees to accidentally use a "confidential" bug for change in OpenJDK. Marked as reviewed by ihse (Reviewer). It looks a bit redundant, but I accept that trying to fix it requires more effort than it's worth. ------------- PR: https://git.openjdk.java.net/skara/pull/1236 From ihse at openjdk.java.net Tue Oct 19 11:48:26 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Tue, 19 Oct 2021 11:48:26 GMT Subject: RFR: 885: jbsupdater -pool record consumption modifications [v2] In-Reply-To: References: <6bImrRAmF5NqLabya0LJ-PNPtUYCk5HSu4RUVWo_3ss=.501b7889-cf88-450d-89df-299c06189c66@github.com> Message-ID: On Thu, 14 Oct 2021 19:19:48 GMT, Erik Joelsson wrote: >> This patch changes how -pool records are consumed, to help differentiate between OpenJDK and OracleJDK update releases. OracleJDK update releases have moved to using fixVersions with an -oracle suffix. With this change, pool record consumption for such releases will also use an -oracle suffix. I opted for a very simple implementation, where any "-suffix" on a fixVersion is now required as suffix on a -pool version to be a match. I think this makes the most sense and keeps things simple going forward. >> >> While in the area, I also removed logic for treating N-open fixVersions the same way as N-pool versions. I have no memory of seeing that behavior in action and I believe that implementation was based on a misunderstanding. I could be wrong however, so if anyone can think of a reason to keep that logic, please let me know. > > Erik Joelsson has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Fall back to normal N-pool records if no matching N-pool- record is found > - Merge branch 'master' into SKARA-885-pool-records > - SKARA-885 Marked as reviewed by ihse (Reviewer). ------------- PR: https://git.openjdk.java.net/skara/pull/1233 From magnus.ihse.bursie at oracle.com Thu Oct 21 23:19:44 2021 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 22 Oct 2021 01:19:44 +0200 Subject: Contributions on GitHub getting stuck Message-ID: <37c238eb-7348-a754-932c-6513a6c9b966@oracle.com> I just noticed that there are many PRs on openjdk/jdk that has gotten stuck in a Catch 22, due to how our rules and Skara tools work together. This list, which currently has 24 PRs on it, lists open PRs that neither have a "oca" nor a "rfr" label: https://github.com/pulls?q=is%3Aopen+is%3Apr+draft%3Afalse+repo%3Aopenjdk%2Fjdk+-label%3Arfr+-label%3Aoca+ It seems that this happens when someone creates a PR, gets told to sign the OCA, does so, but then still not is a OpenJDK author (of course!) and so cannot create a JBS issue. And without a JBS issue number, Skara does not move the PR to the RFR state. And without that, no mail is sent out. And at least for the PRs in the build category, I was completely oblivious to their existence. Even though we write stuff like "Please talk on the relevant mailing lists first" in the User Guide, people assume (rightfully so, I believe) that submitting PRs is an acceptable way to contribute. And when told by the bots to go sign the OCA and then being told "Nice, you're good to go now!", and still nothing happens, this creates bad optics. At the very least I think Skara should add some message in these cases saying explicitly "You need a JBS issue too get this PR reviewed. Please ask on the relevant mailing list for sponsorship". And maybe we should rethink if we perhaps should not send a mail in any case, at least notifying folks that there is an incoming PR that might need guidance. /Magnus From kevin.rushforth at oracle.com Thu Oct 21 23:41:16 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 21 Oct 2021 16:41:16 -0700 Subject: Contributions on GitHub getting stuck In-Reply-To: <37c238eb-7348-a754-932c-6513a6c9b966@oracle.com> References: <37c238eb-7348-a754-932c-6513a6c9b966@oracle.com> Message-ID: I agree there is room for improvement in guiding contributors, perhaps with a comment that includes a helpful message as you suggest, along with a pointer to the contributing guidelines. However, I like the current policy where email doesn't get sent until a PR has met some reasonable threshold of readiness, so I would not be in favor of sending email to the development lists until it is rfr. For those component areas where someone wants to see it, and jump in and be helpful, they can. -- Kevin On 10/21/2021 4:19 PM, Magnus Ihse Bursie wrote: > I just noticed that there are many PRs on openjdk/jdk that has gotten > stuck in a Catch 22, due to how our rules and Skara tools work together. > > This list, which currently has 24 PRs on it, lists open PRs that > neither have a "oca" nor a "rfr" label: > > https://github.com/pulls?q=is%3Aopen+is%3Apr+draft%3Afalse+repo%3Aopenjdk%2Fjdk+-label%3Arfr+-label%3Aoca+ > > > It seems that this happens when someone creates a PR, gets told to > sign the OCA, does so, but then still not is a OpenJDK author (of > course!) and so cannot create a JBS issue. And without a JBS issue > number, Skara does not move the PR to the RFR state. And without that, > no mail is sent out. And at least for the PRs in the build category, I > was completely oblivious to their existence. > > Even though we write stuff like "Please talk on the relevant mailing > lists first" in the User Guide, people assume (rightfully so, I > believe) that submitting PRs is an acceptable way to contribute. And > when told by the bots to go sign the OCA and then being told "Nice, > you're good to go now!", and still nothing happens, this creates bad > optics. > > At the very least I think Skara should add some message in these cases > saying explicitly "You need a JBS issue too get this PR reviewed. > Please ask on the relevant mailing list for sponsorship". And maybe we > should rethink if we perhaps should not send a mail in any case, at > least notifying folks that there is an incoming PR that might need > guidance. > > /Magnus From Alan.Bateman at oracle.com Fri Oct 22 06:39:27 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 22 Oct 2021 07:39:27 +0100 Subject: Contributions on GitHub getting stuck In-Reply-To: <37c238eb-7348-a754-932c-6513a6c9b966@oracle.com> References: <37c238eb-7348-a754-932c-6513a6c9b966@oracle.com> Message-ID: <3561992f-d1b0-ec2c-7999-45853d627eb3@oracle.com> On 22/10/2021 00:19, Magnus Ihse Bursie wrote: > I just noticed that there are many PRs on openjdk/jdk that has gotten > stuck in a Catch 22, due to how our rules and Skara tools work together. > > This list, which currently has 24 PRs on it, lists open PRs that > neither have a "oca" nor a "rfr" label: > > https://github.com/pulls?q=is%3Aopen+is%3Apr+draft%3Afalse+repo%3Aopenjdk%2Fjdk+-label%3Arfr+-label%3Aoca+ > > > It seems that this happens when someone creates a PR, gets told to > sign the OCA, does so, but then still not is a OpenJDK author (of > course!) and so cannot create a JBS issue. And without a JBS issue > number, Skara does not move the PR to the RFR state. And without that, > no mail is sent out. And at least for the PRs in the build category, I > was completely oblivious to their existence. > > Even though we write stuff like "Please talk on the relevant mailing > lists first" in the User Guide, people assume (rightfully so, I > believe) that submitting PRs is an acceptable way to contribute. And > when told by the bots to go sign the OCA and then being told "Nice, > you're good to go now!", and still nothing happens, this creates bad > optics. > > At the very least I think Skara should add some message in these cases > saying explicitly "You need a JBS issue too get this PR reviewed. > Please ask on the relevant mailing list for sponsorship". And maybe we > should rethink if we perhaps should not send a mail in any case, at > least notifying folks that there is an incoming PR that might need > guidance. I don't disagree that it would be helpful if a bot added a comment to say that a JBS issue needs to be created. BTW: Of the 24, it looks like 12 (the PRs with the "[PATCH]" prefix in the description) are from a prolific contributor that is doing code cleanup right across the JDK. He has a JBS login so it might be that these are really draft changes. -Alan From dalibor.topic at oracle.com Fri Oct 22 13:13:32 2021 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Fri, 22 Oct 2021 15:13:32 +0200 Subject: Contributions on GitHub getting stuck In-Reply-To: <37c238eb-7348-a754-932c-6513a6c9b966@oracle.com> References: <37c238eb-7348-a754-932c-6513a6c9b966@oracle.com> Message-ID: <1eb2f603-c1d8-c17b-3380-8f95a7c995aa@oracle.com> On 22.10.2021 01:19, Magnus Ihse Bursie wrote: > At the very least I think Skara should add some message in these cases > saying explicitly "You need a JBS issue too get this PR reviewed. Please > ask on the relevant mailing list for sponsorship". And maybe we should > rethink if we perhaps should not send a mail in any case, at least > notifying folks that there is an incoming PR that might need guidance. The status of an issue implies that you need a JBS issue implicitly: See e.g. https://github.com/openjdk/jdk/pull/6076 Progress * Change must not contain extraneous whitespace (check) * Commit message must refer to an issue (no check) <----- here ;) * Change must be properly reviewed (no check) I took a brief look at https://github.com/openjdk/jdk/pulls?q=is%3Apr+is%3Aopen+-is%3Adraft+-label%3Arfr+-label%3Aoca+ Most of them are from people in the OpenJDK census who have contributed to the jdk repo before, so filing an issue should not be a problem in their case, if they so desire, in order to move their PR forward. The others have not contributed to the jdk repo yet, so in their case, a more explicit nudge towards asking on the list may be useful, but if a bot were to do the nudging, then it should really take the census into account - I'm not sure regular contributors would appreciate being regularly e-mailed by a bot that they didn't file an issue for their PR yet. In those cases, we should assume that the contributor know best what they are doing, and will file for an issue when they are ready. cheers, dalibor topic -- Dalibor Topic Consulting Product Manager Phone: +494089091214 , Mobile: +491737185961 , Video: dalibor.topic at oracle.com Oracle Global Services Germany GmbH Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRB 246209 Gesch?ftsf?hrer: Ralf Herrmann From erikj at openjdk.java.net Mon Oct 25 13:39:42 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 25 Oct 2021 13:39:42 GMT Subject: Integrated: 885: jbsupdater -pool record consumption modifications In-Reply-To: <6bImrRAmF5NqLabya0LJ-PNPtUYCk5HSu4RUVWo_3ss=.501b7889-cf88-450d-89df-299c06189c66@github.com> References: <6bImrRAmF5NqLabya0LJ-PNPtUYCk5HSu4RUVWo_3ss=.501b7889-cf88-450d-89df-299c06189c66@github.com> Message-ID: On Mon, 11 Oct 2021 21:47:05 GMT, Erik Joelsson wrote: > This patch changes how -pool records are consumed, to help differentiate between OpenJDK and OracleJDK update releases. OracleJDK update releases have moved to using fixVersions with an -oracle suffix. With this change, pool record consumption for such releases will also use an -oracle suffix. I opted for a very simple implementation, where any "-suffix" on a fixVersion is now required as suffix on a -pool version to be a match. I think this makes the most sense and keeps things simple going forward. > > While in the area, I also removed logic for treating N-open fixVersions the same way as N-pool versions. I have no memory of seeing that behavior in action and I believe that implementation was based on a misunderstanding. I could be wrong however, so if anyone can think of a reason to keep that logic, please let me know. This pull request has now been integrated. Changeset: f8bffa99 Author: Erik Joelsson URL: https://git.openjdk.java.net/skara/commit/f8bffa9912d61532c86b9adc5aa185f83b62bb2d Stats: 53 lines in 4 files changed: 40 ins; 0 del; 13 mod 885: jbsupdater -pool record consumption modifications Reviewed-by: ihse, kcr ------------- PR: https://git.openjdk.java.net/skara/pull/1233 From erikj at openjdk.java.net Mon Oct 25 13:40:28 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 25 Oct 2021 13:40:28 GMT Subject: Integrated: 1184: Failure to retrieve the JBS bug should be an integration blocker In-Reply-To: References: Message-ID: On Mon, 18 Oct 2021 18:37:39 GMT, Erik Joelsson wrote: > This patch makes it an integration blocker if the Skara bot is unable to read an Issue in the issue tracker system that the PR is claiming to fix. The PR bot for github repos uses credentials that can only see publicly viewable bugs, so this will make it impossible for Oracle employees to accidentally use a "confidential" bug for change in OpenJDK. This pull request has now been integrated. Changeset: e2db496a Author: Erik Joelsson URL: https://git.openjdk.java.net/skara/commit/e2db496a0d28318125c263fe167f345698d65572 Stats: 77 lines in 2 files changed: 56 ins; 6 del; 15 mod 1184: Failure to retrieve the JBS bug should be an integration blocker Reviewed-by: ihse ------------- PR: https://git.openjdk.java.net/skara/pull/1236 From erikj at openjdk.java.net Mon Oct 25 13:40:29 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 25 Oct 2021 13:40:29 GMT Subject: RFR: 1213: Generic jdk-cpu fixVersion In-Reply-To: References: Message-ID: On Wed, 13 Oct 2021 14:17:19 GMT, Erik Joelsson wrote: > This patch does two things. > > 1. Makes "jdk-cpu" a valid JdkVersion in Skara terms. This will allow us to use this generic version as fixversion for our jdk-cpu repos. > 2. Makes it possible to configure "altfixversions" for a repository in the notifier. If an altfixversion is configured for a branch, then the notifier will not attempt to update any bugs or add any new backports if one of the altfixversions is already found to be fixed. > > The second change is needed to prevent changes being merged from jdk to jdk-cpu from creating new backport records for every change in the jdk repo. > > I removed the test "testIssuePoolOpenVersion" as it was an exact copy of the test preceding it "testIssuePoolVersion". Ping. ------------- PR: https://git.openjdk.java.net/skara/pull/1234 From kcr at openjdk.java.net Mon Oct 25 14:27:44 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 25 Oct 2021 14:27:44 GMT Subject: RFR: 1213: Generic jdk-cpu fixVersion In-Reply-To: References: Message-ID: On Wed, 13 Oct 2021 14:17:19 GMT, Erik Joelsson wrote: > This patch does two things. > > 1. Makes "jdk-cpu" a valid JdkVersion in Skara terms. This will allow us to use this generic version as fixversion for our jdk-cpu repos. > 2. Makes it possible to configure "altfixversions" for a repository in the notifier. If an altfixversion is configured for a branch, then the notifier will not attempt to update any bugs or add any new backports if one of the altfixversions is already found to be fixed. > > The second change is needed to prevent changes being merged from jdk to jdk-cpu from creating new backport records for every change in the jdk repo. > > I removed the test "testIssuePoolOpenVersion" as it was an exact copy of the test preceding it "testIssuePoolVersion". Looks good. ------------- Marked as reviewed by kcr (Reviewer). PR: https://git.openjdk.java.net/skara/pull/1234 From erikj at openjdk.java.net Mon Oct 25 20:43:29 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 25 Oct 2021 20:43:29 GMT Subject: RFR: 1213: Generic jdk-cpu fixVersion [v2] In-Reply-To: References: Message-ID: <_sagQ01atVsn4Xu-dDBOTiQmN2x7lqY3c2oJv-tz2VA=.6873d58a-4800-4930-9d88-46ce03ef10c7@github.com> > This patch does two things. > > 1. Makes "jdk-cpu" a valid JdkVersion in Skara terms. This will allow us to use this generic version as fixversion for our jdk-cpu repos. > 2. Makes it possible to configure "altfixversions" for a repository in the notifier. If an altfixversion is configured for a branch, then the notifier will not attempt to update any bugs or add any new backports if one of the altfixversions is already found to be fixed. > > The second change is needed to prevent changes being merged from jdk to jdk-cpu from creating new backport records for every change in the jdk repo. > > I removed the test "testIssuePoolOpenVersion" as it was an exact copy of the test preceding it "testIssuePoolVersion". Erik Joelsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: - Merge branch 'master' into SKARA-1213-jdk-cpu - Merge branch 'master' into SKARA-1213-jdk-cpu - Allow generic jdk-cpu fixVersion - Make jdk-cpu a valid JdkVersion ------------- Changes: https://git.openjdk.java.net/skara/pull/1234/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1234&range=01 Stats: 202 lines in 8 files changed: 148 ins; 11 del; 43 mod Patch: https://git.openjdk.java.net/skara/pull/1234.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1234/head:pull/1234 PR: https://git.openjdk.java.net/skara/pull/1234 From erikj at openjdk.java.net Mon Oct 25 20:43:30 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 25 Oct 2021 20:43:30 GMT Subject: Integrated: 1213: Generic jdk-cpu fixVersion In-Reply-To: References: Message-ID: On Wed, 13 Oct 2021 14:17:19 GMT, Erik Joelsson wrote: > This patch does two things. > > 1. Makes "jdk-cpu" a valid JdkVersion in Skara terms. This will allow us to use this generic version as fixversion for our jdk-cpu repos. > 2. Makes it possible to configure "altfixversions" for a repository in the notifier. If an altfixversion is configured for a branch, then the notifier will not attempt to update any bugs or add any new backports if one of the altfixversions is already found to be fixed. > > The second change is needed to prevent changes being merged from jdk to jdk-cpu from creating new backport records for every change in the jdk repo. > > I removed the test "testIssuePoolOpenVersion" as it was an exact copy of the test preceding it "testIssuePoolVersion". This pull request has now been integrated. Changeset: 2793865d Author: Erik Joelsson URL: https://git.openjdk.java.net/skara/commit/2793865df9f4b4ece30427f143aec0c9498b4e0d Stats: 202 lines in 8 files changed: 148 ins; 11 del; 43 mod 1213: Generic jdk-cpu fixVersion Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/skara/pull/1234 From magnus.ihse.bursie at oracle.com Tue Oct 26 08:24:15 2021 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 26 Oct 2021 10:24:15 +0200 Subject: Contributions on GitHub getting stuck In-Reply-To: <1eb2f603-c1d8-c17b-3380-8f95a7c995aa@oracle.com> References: <37c238eb-7348-a754-932c-6513a6c9b966@oracle.com> <1eb2f603-c1d8-c17b-3380-8f95a7c995aa@oracle.com> Message-ID: On 2021-10-22 15:13, Dalibor Topic wrote: > On 22.10.2021 01:19, Magnus Ihse Bursie wrote: >> At the very least I think Skara should add some message in these >> cases saying explicitly "You need a JBS issue too get this PR >> reviewed. Please ask on the relevant mailing list for sponsorship". >> And maybe we should rethink if we perhaps should not send a mail in >> any case, at least notifying folks that there is an incoming PR that >> might need guidance. > > The status of an issue implies that you need a JBS issue implicitly: > > See e.g. https://github.com/openjdk/jdk/pull/6076 > > Progress > * Change must not contain extraneous whitespace (check) > * Commit message must refer to an issue (no check) <----- here ;) > * Change must be properly reviewed (no check) > > I took a brief look at > https://github.com/openjdk/jdk/pulls?q=is%3Apr+is%3Aopen+-is%3Adraft+-label%3Arfr+-label%3Aoca+ > > Most of them are from people in the OpenJDK census who have > contributed to the jdk repo before, so filing an issue should not be a > problem in their case, if they so desire, in order to move their PR > forward. > > The others have not contributed to the jdk repo yet, so in their case, > a more explicit nudge towards asking on the list may be useful, but if > a bot were to do the nudging, then it should really take the census > into account - I'm not sure regular contributors would appreciate > being regularly e-mailed by a bot that they didn't file an issue for > their PR yet. > > In those cases, we should assume that the contributor know best what > they are doing, and will file for an issue when they are ready. I agree. People who already have an OpenJDK id and can file bugs presumably know what needs to be done. So this boils down to that I think a bot should notify new contributors that posts a PR which does not have a bug ID, giving them a pointer on how to proceed. /Magnus > > cheers, > dalibor topic From erikj at openjdk.java.net Wed Oct 27 14:09:14 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 27 Oct 2021 14:09:14 GMT Subject: RFR: 1229: Skara Backports handling needs to handle non backport type as backport Message-ID: This patch changes the Backports::findBackports method to no longer filter out issues that aren't of type "Backport" and just honor the "backported by" links as they are. ------------- Commit messages: - SKARA-1229 Changes: https://git.openjdk.java.net/skara/pull/1237/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1237&range=00 Issue: https://bugs.openjdk.java.net/browse/SKARA-1229 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/skara/pull/1237.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1237/head:pull/1237 PR: https://git.openjdk.java.net/skara/pull/1237 From ihse at openjdk.java.net Thu Oct 28 13:30:19 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Thu, 28 Oct 2021 13:30:19 GMT Subject: RFR: 1229: Skara Backports handling needs to handle non backport type as backport In-Reply-To: References: Message-ID: On Wed, 27 Oct 2021 14:05:38 GMT, Erik Joelsson wrote: > This patch changes the Backports::findBackports method to no longer filter out issues that aren't of type "Backport" and just honor the "backported by" links as they are. I could have sworn I reviewed this. Github must have lost my review. :-( Anyway, looks good but having comments in the middle of an expression looks a bit odd. Maybe move them to after collect()? ------------- Marked as reviewed by ihse (Reviewer). PR: https://git.openjdk.java.net/skara/pull/1237 From erikj at openjdk.java.net Thu Oct 28 19:16:01 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 28 Oct 2021 19:16:01 GMT Subject: Integrated: 1229: Skara Backports handling needs to handle non backport type as backport In-Reply-To: References: Message-ID: On Wed, 27 Oct 2021 14:05:38 GMT, Erik Joelsson wrote: > This patch changes the Backports::findBackports method to no longer filter out issues that aren't of type "Backport" and just honor the "backported by" links as they are. This pull request has now been integrated. Changeset: 626937d3 Author: Erik Joelsson URL: https://git.openjdk.java.net/skara/commit/626937d35d2bc6c7a426ca25717b571fc9a4af0f Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod 1229: Skara Backports handling needs to handle non backport type as backport Reviewed-by: ihse ------------- PR: https://git.openjdk.java.net/skara/pull/1237