RFD: Draft guidelines for working on jdk8u

[Andrew Hughes]

On Wed, 13 Feb 2019 at 09:06, Volker Simonis <volker.simonis at gmail.com> wrote:
>
> Hi Andrew,
>
> 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". 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?
>
> Thank you and best regards,
> Volker
>
> [1] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-February/000411.html

+1.

I'd like to see 11u & 8u working in a similar way to minimise confusion. That
means 8u adopting the tagging process from 11u, and 11 having two trees
so we can separate release-ready sources from development sources.

I've been thinking over a few things, but being too caught up with the
last lingering
parts of the CPU to post. My current idea is:

1. Changes are pushed to jdkxxu-dev after review and approval.

2. At regular periods (fortnightly?), changes are promoted to jdkxxu and tagged.

3. At a point before the CPU (basically when we have the patches, which is
usually at most a month before), jdkxxu is declared frozen so we have a base
for the update.

4. When the CPU is unembargoed, the changes are pushed to both trees and
a release made. jdkxxu is unfrozen and #2 resumes.

We will need something more involved if there are changes in jdkxxu-dev which
may need longer to soak. I would suggest they use a project tree or a new tree
within jdkxxu, then they are promoted to jdkxxu-dev when ready. This is much
like the way the AArch64 & PPC ports were added and is essentially a third
level below jdkxxu-dev.

I think we need to stick to a restricted set of maintainers for jdkxx, as I said
before [0]. The lead should obviously be one of those. I'll
additionally nominate
myself as someone who has a lot of experience of doing such merges and
releases, e.g with OpenJDK 6 & 7. But we should aim for more people so we
have some redundancy.

I think that's broadly along similar lines to what you posted to the
updates list earlier.

[0] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-February/008509.html
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Web Site: http://fuseyism.com
Twitter: https://twitter.com/gnu_andrew_java
PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222