RFD: Draft guidelines for working on jdk8u

[Andrew Haley]

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