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

[Magnus Ihse Bursie]

On 2022-05-12 19:29, Maurizio Cimadamore wrote:
>
> Hi Magnus.
>
> The /jep command seemed to indeed have blocked integration. I waited 
> around 45 mins since the JEP was targeted, and no change occurred in 
> the PR, which was still showing up with the JEP tag.
>
Didn't we have an issue with CSR labels not being updated in the PR when 
the CSR changed status in JBS, but no other changes were made in the PR? 
Could this be something similar? Maybe as Maurizio says, the polling 
frequency of JBS is not good enough?

/Magnus

> In the end, I dropped the tag using "/jep unneded", and that got me 
> unstuck.
>
> Perhaps it's just matter of polling frequency in JBS not being high 
> enough - in this case I wanted to integrate sooner rather than later, 
> given the delicate nature of the thing being integrated (the less 
> additional merges the better) and the timezone (better to fix 
> something broken now than at 2am :-) ).
>
> Maurizio
>
> On 12/05/2022 18:20, Magnus Ihse Bursie wrote:
>> 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