How speedy are patches to be downported to 11?
Aleksey Shipilev
shade at redhat.com
Wed Feb 17 08:19:59 UTC 2021
On 2/17/21 8:43 AM, Thomas Stüfe wrote:
> Related to that, how are possible compatibility issues to be handled? Eg. a
> patch fixing the output of a command may be correct but may still throw off
> parsers.
Judgement call. We generally try to avoid introducing non-bug differences in update releases. But
that is not a firm rule, AFAIU.
> I suspect the answer will be "its up to you", and depends
> on patch complexity and bug severity. But I still am curious how you handle
> this in practice.
My personal guideline is like this:
- obvious build fixes are proposed right away (because they unbreak stuff);
- testbug fixes are proposed right away (because they do not affect product quality);
- simple fixes are proposed after a few nightly cycles (the follow-up bugs are usually filed
within days from the initial integration into master);
- complex fixes are proposed after at least 10 days (same reason, but give more time to catch bugs)
- very complex fixes are proposed after about a month of stewing, and then only in the initial
months of the update release (and they generally try to match the Oracle's version)
jdk-backports-monitor, for example, has the automatic cooldown set for 10 days:
https://builds.shipilev.net/backports-monitor/label-actionable-redhat-interest.txt
------------------------------------
JDK-8260934: java/lang/StringBuilder/HugeCapacity.java fails without Compact Strings
Original Bug:
URL: https://bugs.openjdk.java.net/browse/JDK-8260934
Reporter: Aleksey Shipilev
Assignee: Aleksey Shipilev
Priority: P4
Components: core-libs/java.lang
Original Fix:
17: JDK-8260934, https://git.openjdk.java.net/jdk/commit/ad54d8dd, shade, 7 day(s) ago
Backports and Forwardports:
16: WAITING for patch to bake a little: 3 days more
11: WAITING for patch to bake a little: 3 days more
8: Not affected
------------------------------------
--
Thanks,
-Aleksey
More information about the jdk-updates-dev
mailing list