JDK-8227662 approval

[Langer, Christoph]

Hi,

> -----Original Message-----
> From: Andrew John Hughes <gnu.andrew at redhat.com>
> Sent: Freitag, 17. Januar 2020 18:34
> To: Langer, Christoph <christoph.langer at sap.com>; Mario Torre
> <neugens at redhat.com>; jdk-updates-dev <jdk-updates-
> dev at openjdk.java.net>
> Subject: Re: JDK-8227662 approval
> 
> 
> 
> On 17/01/2020 10:51, Langer, Christoph wrote:
> > Hi Mario,
> >
> > I've approved it. As it's an Oracle 11.0.7 item, there's no discussion about it.
> ��
> >
> 
> I don't see 11.0.7-oracle on the bug.
> 
> Compare with e.g. https://bugs.openjdk.java.net/browse/JDK-8227646
> 

Oh, you're right. I confused 11.0.7 with 11.0.7-oracle there. But still, the fix seems appropriate - it's a local, self-contained fix of an issue with a test case attached. So my approval holds valid, still.

> > At the committers workshop we shall discuss some process alleviations for
> Oracle parity backports...
> >
> 
> I don't think we should be giving a free pass to issues, simply because
> Oracle has blessed them for unknown reasons.
> 
> We have discussed this before.

I understand your concern. I think in general our goal is to pull in the backports that Oracle selected, even without knowing all the reasons behind their decisions. This is about both, keeping compatibility and have some parity regarding fixed problems. Sure, there might be technical concerns or risk assessments that might inhibit some backport or cause it to be shifted in a later release cycle.

But looking at 11u, there's some people who do the big bulk of Oracle parity backports, e.g. Goetz, Aleksey or myself. And we all have quite a good regression test infrastructure at hand to assess whether a backport would break something. So, to ease the processing for these folks, I was thinking to propose disburdening their process a bit by
a) considering Oracle backports as auto-approved
b) require review of backport changesets on some sense of proportion, e.g. not if there was only some contextual resolving necessary
c) restrict this "fast-path" backporting to a named set of people

I would also think that the need for a public review when pushing the CPU changes should be dropped. Those changes have been discussed and reviewed via the vulnerability group and you probably have done the integration builds and tests for the GA tag. So these changes can then just be pushed after the embargo is over.

But all that would be my proposal for a discussion at the committers workshop. Would be great if you could be there, too. ��

Best regards
Christoph