JDK 11.0.3 Update process

[Langer, Christoph]

Hi,

I think the picture gets clearer now. Let me try to wrap it up a bit.

Repositories:
jdk11u-dev: The always open repository, where developers can push downports of their fixes after receiving approval via JBS "jdk11u-fix-request" tag
jdk11u: The stabilization branch for working towards the next CPU, should be run under RDP2 rules [0] or something alike
The private security repository: Run at RedHat in the dark

Release process:
For each CPU we define and communicate an RDP2 date or timeframe (like Oracle does [1])
At RDP2, we:
1. increment the hgupdater fix version of jdk11u
2. merge jdk11u-dev into jdk11u
3. increment the hgupdater fix version of jdk11u-dev
4. send a notification to the mailing list that RDP2 branching for 11.0.x has been done

Selection criteria for changes, approval process:
jdk11u-dev: All sorts of fixes/changes that we deem eligible for jdk11u. Developer requests approval via JBS "jdk11u-fix-request" tag, if patch doesn't apply runs an RFR and then pushes
jdk11u: I can see 2 types of changes:
a) changes that meet the RDP2 criteria (E.g. P1 and P2 bugs, test fixes)
b) integration of changes that Oracle brings to their CPU post RDP2 (which will probably be hg export/imports of changes that we then already have in jdk11u-dev)
In case a patch for jdk11u is requested, the JBS "jdk11u-fix-request" tag shall be set and the Fix Request comment needs to state that the request is targeted for jdk11u. The approver needs to check criteria a) and b)

Tagging:
We should tag jdk11u-dev on a weekly basis
We should tag jdk11u regularly... maybe not exactly weekly but when we think it's time for a build. E.g. if there have been significant changes and at the discretion of the CPU release engineers
We should have additional tags as Goetz proposed: 11.0.x-rdp2, 11.0.x-ga

Merging/Integration:
jdk11u-dev shall be merged into jdk11u once at RDP2.
jdk11u shall be merged back into jdk11u-dev regularly, every time we set a build tag.

Security Repo:
Ideally, I believe the security repository at RedHat should be a clone of jdk11u which is regularly refreshed by merges. Then, at the release day, the security repository shall be merged back into jdk11u and from jdk11u we shall immediately merge down to jdk11u-dev.
If it's more suitable for the process at RedHat, you could as well hold a patch queue that is always in a condition to apply to the current jdk11u. The most important thing is, that all is set up to allow an immediate push of security changes to the open on the release day.

Does that describe the process we want to run?

Best regards
Christoph

[0] https://openjdk.java.net/jeps/3
[1] https://wiki.openjdk.java.net/display/JDKUpdates/JDK12u


> -----Original Message-----
> From: Lindenmaier, Goetz
> Sent: Mittwoch, 20. Februar 2019 08:54
> To: Andrew Hughes <gnu.andrew at redhat.com>
> Cc: Langer, Christoph <christoph.langer at sap.com>; jdk-updates-
> dev at openjdk.java.net
> Subject: RE: JDK 11.0.3 Update process
> 
> Hi,
> 
> well, should have condensed this into one mail ... but nevertheless ...
> > I didn't say there was anything the matter with it, more that I was
> > surprised it was happening so quickly. I'm still wrapping up things from
> > the last CPU.
> Guess my other mail explains why we want to engage now.  We want to
> release SapMachine as close to 4/15 as possible, and with the same set
> of changes as you.
> 
> > From experience, the earlier you split off a release branch, the more
> > work has to be done in backporting from the current development branch
> > to the release branch, or, as you suggest, pulling from the release branch
> > back into the development branch.
> I don't think the pulling is that much work, but letting the fixes soak makes
> sense.
> 
> > On that latter approach, there's an obvious risk there that you push
> something
> > to 11.0.3 first which causes issues. I think there are good reasons for only
> > determining fixes as worthy for the release branch after they've soaked for
> > some time in the development branch. It's also not clear to me what the
> > "RDP2 rules" are.
> https://openjdk.java.net/jeps/3
> This explains what changes may be pushed in which phase.
> We could reuse that.
> 
> > I would like to see regular tags for both 8u & 11u. This would help testing
> > of our downstream trees, which currently don't get merged until Oracle
> push
> > all their internal work after release.
> Yes.  Tags would be great.  I would appreciate weekly builds tags in jdk11u
> after rdp2,
> 11.0.3-rdp2 when last jdk11u-dev is pulled to jdk11u,
> 11.0.3-rdp1 when you (and us)  snapshot the tree,
> 11.0.3-ga in the end.
> 
> Cheers,
>   Goetz.
> 
> > --
> > 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