[11u] Should we make patch 11.0.14.1 with JDK-8218546 and JDK-8280786?

[Lindenmaier, Goetz]

Hi Andrew, 

> I think it is severe enough to qualify.
Thank you, I take this for a yes.

So I will take the following steps:

I will tag the current state of jdk11u as jdk-11.0.14.1+0.

I will open an issue "Bump update version for OpenJDK: jdk-11.0.14.1" 
similar to JDK-8272902 and add the date 2/8/2022.

I will backport JDK-8218546 and JDK-8280786 from jdk11u-dev to jdk11u.

I will tag all three changes with jdk11.0.14.1+1 and jdk11.0.14.1-ga.

Best regards,
  Goetz.

https://bugs.openjdk.java.net/browse/JDK-8272902: 
Bump update version for OpenJDK: jdk-11.0.14
https://bugs.openjdk.java.net/browse/JDK-8218546:
Unable to connect to https://google.com using java.net.HttpClient
https://bugs.openjdk.java.net/browse/JDK-8280786:
Build failure on Solaris after 8262392


> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-retn at openjdk.java.net> On
> Behalf Of Andrew Haley
> Sent: Friday, February 4, 2022 11:19 AM
> To: jdk-updates-dev at openjdk.java.net
> Subject: Re: [11u] Should we make patch 11.0.14.1 with JDK-8218546 and
> JDK-8280786?
> 
> On 2/1/22 11:17, Lindenmaier, Goetz wrote:
> > we (SAP) checked with our internal stakeholders and decided to
> > release a patch for SapMachine 11.0.14 with JDK-8218546.
> >
> > We would prefer to have an "official" patch 11.0.14.1 in
> > OpenJDK jdk11u including this change. Alternatively, we could
> > also release a patch 11.0.14.0.1 only for SapMachine.
> >
> > I think JDK-8218546 is a clear regression in 11.0.14 and
> > thus jdk11u should tag a release that fixes this.
> 
> This reasoning does not necessarily follow: a regression in a point
> release does not always justify a respin. It must be a serious
> regression to qualify.
> 
> In other words, a respin has to be justified on its own merits, not
> simply because it fixes a regression. That it was a regression
> doesn't matter; what matters is the result of the bug.
> 
> > Nobody is
> > forced to release a build with this, but anyone who runs
> > into this problem has a clear path to solve it.
> >
> > I would propose to include the Solaris build fix JDK-8280786
> > in this patch, too.
> >
> > After all, tagging such a release in jdk11u is not much
> > effort. Both issues are fixed in 11.0.15/jdk11u-dev and can
> > easily be cherry-picked to jdk11u.
> >
> > I would hold back consolidating 11.0.15/jdk11u-dev to jdk11u
> > until this is done. Tag 11.0.15+1 is scheduled for tonight.
> 
> OK. I'm in two minds about this one. One the one hand this is not a
> failure in core Java, but on the other I have heard about failures in
> production that it has caused, so I think it is severe enough to
> qualify.
> 
> We might use this as an opportunity to review our processes. We
> backported a patch, but we didn't backport a subsequent patch
> which fixed it. We've seen this pattern several times: a desirable
> backport candidate appears, but it's not always obvious to the
> engineer doing the work that the patch is itself buggy, and needs
> its own backport.
> 
> --
> Andrew Haley  (he/him)
> Java Platform Lead Engineer
> Red Hat UK Ltd.
> <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww
> w.redhat.com%2F&data=04%7C01%7Cgoetz.lindenmaier%40sap.com%
> 7Cc5ce70b90dda49592c5d08d9e7c7d784%7C42f7676cf455423c82f6dc2d99791
> af7%7C0%7C0%7C637795667803062024%7CUnknown%7CTWFpbGZsb3d8eyJ
> WIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%
> 7C3000&sdata=IVM8C3gdGKxvCJSBo7uwpdFdA%2FhkVfs%2FUVgrwaP
> oHAQ%3D&reserved=0>
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fkeyb
> ase.io%2Fandrewhaley&data=04%7C01%7Cgoetz.lindenmaier%40sap.c
> om%7Cc5ce70b90dda49592c5d08d9e7c7d784%7C42f7676cf455423c82f6dc2d9
> 9791af7%7C0%7C0%7C637795667803062024%7CUnknown%7CTWFpbGZsb3d
> 8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%
> 3D%7C3000&sdata=lv1yCc4GOTmz0D5pZMxT%2FxthQpofl%2FW8C3twq
> U%2BVqRs%3D&reserved=0
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671