RFD: Draft guidelines for working on jdk8u
gnu.andrew at redhat.com
Wed Feb 13 16:50:05 UTC 2019
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 . 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,
>  https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-February/000411.html
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
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 . The lead should obviously be one of those. I'll
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.
Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)
Web Site: http://fuseyism.com
PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222
More information about the jdk8u-dev