jdk11u-dev is now switched to 11.0.5

[Andrew John Hughes]

On 31/05/2019 18:25, Andrew Haley wrote:
> On 5/31/19 5:44 PM, Andrew John Hughes wrote:
>> On 30/05/2019 22:56, Langer, Christoph wrote:
>>> Hi,
>>>
>>>>> The level of bureaucratic overhead in these projects is getting absurd.
>>>> We're
>>>>> going to have to do something about it before we all drown.
>>>>
>>>> Yes, there is some overhead, it does not make things more
>>>> simple.  You could delegate some tasks.
> 
> But that won't reduce the overhead: all it will do is spread it out.
> 
>>>> E.g.,
>>>>   * I would volunteer to trigger the update of the JBS version
>>>>      For 11 whenever needed.
>>
>> Do you mean the hgupdater changes via ops? I think usually both 8u & 11u
>> should be handled at the same time to minimise such updates.
> 
> But how? It's not as if the projects are perfectly synchronized. Sure,
> if they happen to need changing at the same time, then we can do so.
> 

Well, rampdown and release are the two points at which changes need to
be made, and these are close, if not the same (barring the delay for 8u
in this cycle) [0] [1]

snip...

> 
> That imposes a strict ordering: review first, then approval. I think
> that approval and review can run in parallel: we don't want to fully
> review every backport patch twice.
> 

The Oracle process I'm familiar with is sequential:

"Additionally the comment should note whether the patch from the JDK
Project applies cleanly. If not, the fix MUST be codereviewed in public
and a public url to that review MUST be provided in the comment." [2]

Under 8u, the approval e-mail used to refer to the review thread.

I'm not suggesting reviewing every backport twice, but I also don't see
how you can approve something if you don't know what you're approving.

Keeping them sequential simplifies the process, because any fix that is
approved has then also been reviewed, and so is only waiting on push.

If the review begins or continues after approval, you end up with
approved bugs that are not yet ready for push. This has been causing
confusion for me with our "Approved requests without push" filter [3],
with bugs listed in there that weren't even posted for review at one point.

I do suspect my perspective may be clouded by the fact I end up doing
both review & approval for most 8u patches. The experience may be
different if you're looking it with fresh eyes purely from the view of
approval.

[0] https://wiki.openjdk.java.net/display/jdk8u/Main
[1] https://wiki.openjdk.java.net/display/JDKUpdates/JDK11u
[2] https://openjdk.java.net/projects/jdk-updates/approval.html
[3] https://bugs.openjdk.java.net/browse/JDK-8225065?filter=36427
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
https://keybase.io/gnu_andrew