RFD: Draft guidelines for working on jdk8u

[Langer, Christoph]

Hi,

> snip...
> 
> > We have two active trees, hg.openjdk.java.net/jdk8u/jdk8u/ and
> > hg.openjdk.java.net/jdk8u/jdk8u-dev/. jdk8u-dev is always open to all
> > contributors, and that's where everyone should push their patches
> > after maintainer approval. When the time comes for an update release,
> > jdk8u-dev will be copied to jdk8u for testing and stabilization. From
> > that point onwards only critical bug fixes may be applied to jdk8u, at
> > the discretion of the maintainers.
> 
> I think jdk8u-dev -> jdk8u syncs need to be done at more regular intervals
> with jdk8ux-by style tags.

As per my last mail in jdk-updates-dev [1], I think there should be exactly one sync jdk8u-dev->jdk8u per quarterly release (e.g. RDP2)

But the other way round (jdk8u->jdk8u-dev), we should have regular syncs.

> Also, in the spirit of 11u, are we intending to adopt its process of using
> bug labels to request backports rather than e-mails i.e. jdk8u-fix-request? [0]
> 
> [0] https://openjdk.java.net/projects/jdk-updates/approval.html

I think that would be good. Then it's the same process for developers in any update release.

> Once a quarter, we will snapshot the jdk8u tree and prepare a Critical
> Patch Update (CPU) release. Once the snapshot has been taken the
> engineers working on the CPU will work in the dark, sharing the
> patches with only the OpenJDK Vulnerability Group. Any patches not
> committed to jdk8u at the time of the snapshot will probably have to
> wait for a later release. [ I don't propose to make any non-CPU
> releases: one release a quarter should be quite enough for
> jdk8u. However, if an urgent problem arises we might need to make an
> intermediate release. ]

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.

Best regards
Christoph


[1] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-February/000542.html