RFD: Draft guidelines for working on jdk8u

[Andrew Haley]

OpenJDK 8 is a long-term stable release of OpenJDK. Our primary goal
is to maintain it, fixing significant bugs and especially security
problems as we go along. The "first, do no harm" principle applies: we
must not break things.

We do not yet have much experience with our test systems, so for the
first couple of quarters we should be very cautious. Later on we can
be more adventurous, but for now it's "bug fixes only".

All fixes for significant bugs that do not change behavioural
compatibility [1] may be applied to jdk8u. To use the language of the
JDK 6 project, by default such fixes are assumed to be applicable to
jdk8u, especially if having "soaked" in later JDK releases for a time
without incident.

By "significant" I mean any bug that affects runtime behaviour in a
way that either produces incorrect results or crashes the VM,
especially TCK failures. Failures that are due solely to bizarre or
unreasonable combinations of -XX: command-line parameters probably
don't reach the bar of significance, and fixing them will carry a
non-zero risk of breaking something, so we should err on the size of
caution.

Build failures on all platforms, including 32-bit ones, are assumed to
be applicable. Also, there is a good deal of C++ code with Undefined
Behaviour in HotSpot, and such bugs tend to cause failures with more
recent C++ compilers. While all UB fixes may be applied to jdk8u, they
should be submitted to the current development tree first.

Occasionally we might have to make changes which raise compatibility
issues. We will liase with the Compatibility & Specification Review
(CSR) Group.

Once a quarter, we will snapshot the jdk8u development tree and
prepare a Critical Patch Update (CPU) release. Once the snapshot has
been taken the engineers working on the CPU will work in the dark,
sharing the patches with only the OpenJDK Vulnerability Group. Any
patches not committed to jdk8u at the time of the snapshot will
probably have to wait for a later release. I don't propose to make any
non-CPU releases: one release a quarter should be quite enough for
jdk8u. However, if an urgent problem arises we might need to do make
an intermediate release.

Having said all of that, there is considerable customer demand for
backports of features from later OpenJDK releases. I don't intend to
forbid such backports, but strict rules will apply. Features which
apply to ports in jdk8u must have the property that they can be
disabled altogether by the use of a command-line switch. This switch
should turn the feature into a NOP, so that it does not affect the
rest of the system in any way. Reviewers should ensure that every hunk
in such a changeset is guarded by an if (Feature_enabled) statement or
something similar. This will also allow Feature_enabled to be made a
compile-time constant, and if set to false this will allow images to
be created without the feature.

With regard to the likely feature backports, there are several
possibilities, in particular the Java Flight Recorder (JFR).  It'll
take a while to produce the JFR backport, so we should perhaps create
a tree for it now by cloning the jdk8u-dev tree. Patches should be
reviewed, but it's obviously a work in progress.

[1] https://blogs.oracle.com/darcy/kinds-of-compatibility:-source,-binary,-and-behavioral

Comments welcome.

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