Fwd: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v34]

Thu May 12 17:20:41 UTC 2022

Seems there was some issue with the new `/jep` command. I understand why 
Maurizio did not want to hold up the integration to have it resolved, 
but we should check what happened, and fix any bugs. I think this was 
the very first proper test of the JEP command in a real-life scenario, 
and it's a bit disappointing if it blocked the integration even if 
everything was correct.

/Magnus

-------- Forwarded Message --------
Subject: 	Re: RFR: 8282191: Implementation of Foreign Function & Memory 
API (Preview) [v34]
Date: 	Thu, 12 May 2022 15:51:00 GMT
From: 	Maurizio Cimadamore <mcimadamore at openjdk.java.net>
To: 	build-dev at openjdk.java.net, core-libs-dev at openjdk.java.net, 
hotspot-dev at openjdk.java.net, nio-dev at openjdk.java.net, 
shenandoah-dev at openjdk.java.net

On Fri, 29 Apr 2022 08:29:52 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>>> Remind: please use the command `/jep JEP-424` [1] to mark this PR.
>>>
>>> [1] 
>>> https://wiki.openjdk.java.net/display/SKARA/Pull+Request+Commands#PullRequestCommands-/jep
>>
>> Question: I'm willing to try it out. If something goes wrong - would 
>> a `jep unneeded` be enough to "unstuck" this PR?
>
>> would a jep unneeded be enough to "unstuck" this PR?
>
> Yes if no bug. Conceptually, the `/jep unneeded` will behave as no jep 
> command.

@lgxbslgx - JEP has been targeted, but the JEP action seems to be 
blocking this - what should we do?

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

PR: https://git.openjdk.java.net/jdk/pull/7888