Changes to 8u and 11u process

Andrew Haley aph at
Tue Aug 6 13:46:56 UTC 2019

We've been running 8u and 11u for two quarters now, and it's time to
adjust our processes.

First, the easy one: Christoph Langer is now a maintainer of JDK 11u.

Backports which have already been approved by Oracle for their
proprietary fork will no longer need approval for 8u- and 11u-open.
There are two reasons for this. Firstly, it's safe to assume that
Oracle have done their due diligence with regard to suitability.
Secondly, it's a waste of effort on the part of the maintainer.

Backports of fixes to tests no longer need to be approved, but they
should still be reviewed if there are any changes.

We will use the CSR process, with the help of the CSR team, for any
backports of patches which required CSRs in mainline. Hopefully this
will be rare, and the CSR team will process review requests promptly.

Finally, more of a recommendation.

Rule #0: Do no harm.

I know of no very strong reason why 8u- and 11u-open should in general
have much more churn than the corresponding closed projects. If they
have, there is a serious risk that they will be less stable. We must
avoid, above all else, the open updates being (or being perceived as)
less reliable than the closed. [That being said, we've already made
the decision to backport some major items; it's a delicate balance.]

Where it makes sense, please minimize the size of the patches. If you
can adapt a backport patch to fit rather than also backporting a bunch
of its dependencies, please consider doing so. Bear in mind that
stability is the most important feature that these updates projects
have. Simple history in backports is important: it's more important to
reduce the volume of changes to 8u and 11u than it is to reduce the
differences between the backports and head.

Feature backports should be treated with a degree of skepticism. 8u
and 11u are stable maintenance versions not development branches, so
features shouldn't be backported without a compelling reason and a
careful analysis of risk. Please discuss such backports on the list.

Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

More information about the jdk8u-dev mailing list