jdk11u-dev is now switched to 11.0.5

[Andrew Haley]

On 6/3/19 3:49 PM, Andrew John Hughes wrote:
> 
> 
> 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]

Well, yeah. If the two coincide we can do them together.

> 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.

Maybe, but the patch itself has already been reviewed: all you're approving
is an already-reviewed patch. So maybe the patch itself is interesting, but
maybe not. The question for the approver is whether this patch is worth doing,
not whether it's a good patch: we already know it is.

> 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.

That's a tooling problem IMO.

> I do suspect my perspective may be clouded by the fact I end up doing
> both review & approval for most 8u patches.

I think so. These are different tasks,and having one person doing both
at once, essential as a single job, makes a nonsense of the
separation.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671