RFD: Draft guidelines for working on jdk8u

Andrew Haley aph at redhat.com
Wed Feb 13 16:59:08 UTC 2019

On 2/13/19 9:05 AM, Volker Simonis wrote:

> I've wrote up a detailed proposal for the jdk11u update process and
> posted it on jdk-updates-dev yesterday [1]. In that mail I propose to
> have two repositories, jdk11u-dev as "always-open" development
> repository and jdk11u as consolidation repository for the upcoming
> update release. The main reason for having such a setup is that
> everybody can see (and test) all the non-security changes which will
> be in the next update release and members of the Vulenrability Group
> will even have the possibility to easily create (and test) a version
> of the upcoming update release which is very close to if not equal to
> the version Red Hat will be working on "in the dark".

We can share that information with VG members.

> I think this is important not only to get a broader test coverage
> for upcoming update releases, but also to simplify the process of
> producing update releases for other down-stream distributors.
> The OpenJDK 8u project already has these two repositories (i.e.
> jdk8u/jdk8u and jdk8u/jdk8u-dev) so it would be trivial to implement
> my proposal for the 8u updates project. What do you think?

What you say above doesn't sound hugely different from what I have
proposed for jdk8u. Can you explain in what ways you believe it to be
different? Your jdk11 does seem to be rather over-prescriptive, but
not in any sense completely wrong.

I'll ask Andrew Hughes to comment on the precide details of what the
trees and branches are named.

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