[11u]: 8u222 & 11.0.4 release schedule

Tue Apr 30 12:43:08 UTC 2019

Hi Andrew,

... sorry for all these long mails :)  ... but I think it's important
to get to a common understanding of all the motivations
behind these things. 

So here I go:

> That's a good point and a case of bad terminology on my side :(
> I used "RDP1" because we were already talking about RDP2, without really
> thinking of the implication. Because I've been focused on the last
> release until the last week or so, I'm still very much of the frame of
> mind that we are still relatively early in the next releases and it
> wasn't my intention to suggest we'd be locking things down so soon.
Ok.

> The update projects differ from the main JDK project in a number of
> ways: they have half the life span (three months rather than six), all
> changes require explicit approval as well as review, and the very nature
> of an update release means that it isn't the place for major new
> features. Hence, I'm not sure the priority matrix in JEP3 really makes
> much sense in our context, as a maintainer can choose to block a
> particular fix anyway, and, in many cases, 

> the original priority will
> have been determined by someone other than the backporter.
It's not a priority that expresses how urgent to work on it.
It is a rating at how severe the bug is. It is not well documented:
https://wiki.openjdk.java.net/display/OpenJFX/Submitting+a+Bug+Report
but this at least helps a bit. In the end, it is the assessment of the persons
that worked on the bug, who are experts on the issue.
Thus I think it well applies to an updates project.

And yes, the changes brought to the updates project are more stable/smaller
than in a new release. But on the other side introducing a regression 
is much more severe. The security updates go to productive systems
with much less testing than for new releases.

Finally I think all the people in the OpenJDK community are 
familiar with the OpenJDK development process. To make the 
jdk11u process easy to understand, we should use as much 
of the terminology etc. that is also used in the development
of new releases, documented on all the wiki pages, and known
to the developers.
Again, this is not about me, you, Christoph, Aleksey or Andrew Haley,
it's all about the other contributors. It must be simple to understand
for them.

What I would like is:

jdk11u-dev: push anything, no tags, jdk11u-fix-request.
jdk11u: rampdown of next release. push according to rules. tagged. jdk11u-critical-request.
  4 weeks RDP2
  4 weeks RDP1
  3 weeks RC / frozen 
  (Always open to all changes downported by Oracle).
  Or maybe 3+3+2 weeks ...

This gives three months 'free' development for a release in 11u-dev
plus 11 weeks of rampdown in 11u.
(The 4 additional merges 11u-dev->11u shorten this by 4 weeks rampdown
  and pushes the start of n+1 development back 4 weeks.)

But I already gave up on this simple thing with longer rampdown :).
Which is fine... and also the reason we have our own build (SapMachine)
where we can do quick fixes and releases on our own.

> Hence, I would prefer a simpler three stage structure - development,
> rampdown and freeze - which is what was in my mind when I wrote the
> previous schedule (if not the terminology).
> 
> So, for clarity:
> 
> March 2019: jdk11u-dev repo open (tag: jdk-11.0.4+0)
> =============== 11.0.3 Released ============================
> =     jdk11u tree gets changes by merge from jdk11u-dev    =
> ============================================================
> Wednesday, May 01 2019: First build (tag: jdk-11.0.4+1)
> Wednesday, May 08 2019: Second build (tag: jdk-11.0.4+2)
> Wednesday, May 15 2019: Third build (tag: jdk-11.0.4+3)
> Wednesday, May 21 2019: Fourth build (tag: jdk-11.0.4+4)
> Wednesday, May 29 2019: Fifth and final dev build (tag: jdk-11.0.4+5)
> ================= Rampdown =================================
> = jdk11u tree gets changes only by jdk11u-critical-request =

Could you give a specification of what changes qualify to be 
pushed in this phase?  I think we need to document this
for the 11u project if we don't reuse the established terms.
E.g., a contributor needs to know whether to hurry to 
catch the deadline of the start of the rampdown phase.
Also, If I want to downport a bug, I want to have some way
to determine which repo to target with it.

> ============================================================
> Wednesday, June 5, 2019: First rampdown build (tag: jdk-11.0.4+6)
> Wednesday, June 12, 2019: Second rampdown build (tag: jdk-11.0.4+7)
> Wednesday, June 19, 2019: Third rampdown build (tag: jdk-11.0.4+8)
> Wednesday June 26 2019: Last tag before code freeze (tag: jdk-11.0.4+9)
> ================= FREEZE ===================================
> =            jdk11u sees no public changes                 =
> ============================================================
> Tuesday, July 16 2019: GA (tag: jdk-11.0.4-ga, likely to be jdk-11.0.4+10)
> 
> So, we could probably start the post-release stage a week earlier in
> future i.e. the Wednesday of the week after the CPU, if we're happy with
> the same stable process.

Maybe we should even start regular tagging in jdk11u-dev right after 
we bumped the version to 11.0.5 ... there seems to be a need of 
tagged development versions, as the downstream builds are triggered by 
tags.

Best regards,
  Goetz.

> 
> Best regards,
> --
> Andrew :)
> 
> Senior Free Java Software Engineer
> Red Hat, Inc. (http://www.redhat.com)
> 
> PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
> Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
> https://keybase.io/gnu_andrew