RFD: Draft guidelines for working on jdk8u
gnu.andrew at redhat.com
Wed Feb 20 17:39:18 UTC 2019
On Wed, 20 Feb 2019 at 10:08, Langer, Christoph
<christoph.langer at sap.com> wrote:
> > 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 , 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.
But what is being synced from jdk8u->jdk8u-dev?
This seems to be suggesting that they are developed separately for a long
period of time. It also seems to be pretty risky to put changes directly
into jdk8u first before they have soaked in jdk8u-dev.
> > 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? 
> >  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.
I don't think that's practical. Those working on the CPU have enough work
to do with backporting and testing without having to continually do integration
work from jdk8u. It should be frozen at the time the snapshot is taken and only
explicit exceptions pushed after that point.
> Best regards
>  https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-February/000542.html
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