RFD: Draft guidelines for working on jdk8u

Andrew Haley aph at redhat.com
Thu Feb 21 09:23:27 UTC 2019

On 2/21/19 12:58 AM, Langer, Christoph wrote:

>>> I'd rather prefer if the repository in the dark will regularly be
>>> refreshed from jdk8u and at the end of the CPU release be merged
>>> back to the open.

>> I don't think that's practical. Those working on the CPU have
>> enough work to do with backporting and testing without having to
>> continually do integration work from jdk8u. It should be frozen at
>> the time the snapshot is taken and only explicit exceptions pushed
>> after that point.

> The stabilization repository will always be virtually frozen. Only
> explicit exceptions of the types I have named above will ever be
> allowed in the release repository. So I would not expect too much of
> integration issues.

If the repo is virtually frozen, then there's nothing to be gained by
regularly refereshing from it. It's risking occasional breakage for no
signitificant gain.

> You can also start considerably later with the CPU compared to the
> time of the fork from dev to stabilization.

I don't think it does much good to specualte about possible future
needs. If we have problems that we need to solve with automation we'll
do that.


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

More information about the jdk8u-dev mailing list