[11u]: 8u222 & 11.0.4 release schedule

Tue Apr 30 12:40:55 UTC 2019

Hi Andrew,

> > To put this into concrete steps, is it ok if I do the following?:
> >
> > In jdk11u:
> > Tuesday between 12:00 and 18:00 CE(S)T
> > hg pull
> > hg tag;
> > run tests and build
> > Wednesday between 12:00 and 18:00 (after tests completed):
> > hg pull/hg merge if necessary.
> > hg push --> publishes the tag to 11u
> As it stands, this is going to mean testing and tagging nothing, because
> jdk11u is at 11.0.3-ga.

Well, obviously this is only the initial case.  I could have pulled from jdk11u-dev
last week if I had known.  Exceptionally, I could pull right now.
I tried to run this discussion 4 weeks ago, but did not get much
feedback.  The hg-updater issue is blocking us, anyways.
If we now pull to jdk11u, it will all be tagged as going to 11.0.3.

> > hg pull jdk11u-dev  --> this is skipped after 2019-05-28
> > hg merge
> > hg push --> brings the latest changes from 11u-dev to 11u
> >                      They can be tested 6 days in 11u.
> >
> Whereas the jdk11u-dev changes are not being tested.
They would be tested from there on in jdk11u.
Who keeps us from doing fixes in jdk11u in those 6 days?

> > In jdk11u-dev:
> > Wednesday before 18:00 CE(S)T
> > hg pull
> > hg pull jdk11u
> > hg merge
> > run tests and build
> > Thursday after tests completed:
> > hg pull/hg merge if necessary.
> > hg push --> brings the latest changes and the tag from 11u to 11u-dev
> >
> 
> This was my thinking (and thus my plan for 8u):
> 
> Development stage (2019-05-01 to 2019-05-29):
> 
> jdk11u-dev:
> 
> $ hg pull
> <build & run tests>
> If all good:
> 
> $ hg tag jdk-11.0.4+x
> $ hg push
> 
> jdk11u:
> 
> $ hg pull
> $ hg pull jdk11u-dev
> $ hg merge (if necessary)
> 
> I don't think a merge should be necessary as jdk11u-dev is a superset of
> jdk11u and that merge has already been performed in pulling
> jdk-11.0.3-ga into jdk11u-dev.
> 
> At rampdown: jdk11u-dev is tagged jdk-11.0.5+0
> 
> Rampdown stage (2019-06-05 to 2019-06-26):
> 
> jdk11u:
> 
> $ hg pull
> <build & run tests>
> If all good:
> 
> $ hg tag jdk-11.0.4+y
> $ hg push
> 
> jdk11u-dev:
> 
> $ hg pull
> $ hg pull jdk11u
> $ hg merge
> 
> Merging will be necessary as jdk11u will contain 11.0.5 changes by this
> point.
>
> In other words, the same process takes place in both stages, but the
> repositories switch roles; in the development stage, jdk11u-dev is the
> master receiving changes and is merged into jdk11u, while in the
> rampdown stage, jdk11u is now receiving changes for that release and is
> merged into jdk11u-dev.

I think we should not concentrate on reducing the hg commands on
our side.  
We should try to build a process that is easy to communicate and 
understand for those that are not as involved as we are.
If we always tag in jdk11u, we can say:
"jdk11u is the consolidation repository for the next release"
Now the message is:  up to this day we do work in jdk11u-dev, 
from that on in jdk11u. 
And it raises the question: why is it merged to jdk11u? It's the 
same anyways!
Thus, following your approach, I would propose to skip merging
to jdk11u until start of the rampdown.

> What testing do you do?

We build and test jdk11u-dev and jdk11u as Christoph pointed out announced here
https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-February/000648.html
on a daily basis.  This is all automated and backed by a database where we 
can see test failures about half a year back.
We still add new tests, recently we 
added jtreg tests nashorn, jaxp and langtools.
(Adding test always means to fix a lot of test bugs and setup issues.)
The builds of jdk11u-dev include a mercurial patch queue with the 
changes we are working on. Therefore the test results are not 
that reliable ... well, it is a dev code line :)
Further tests are done in our SapMachine infrastructure. 
The SapMachine build is only triggered if a tag arrives in the
jdk11u code line.
Finally we distribute prerelease builds to departments in 
our company that use it for testing.  As there only is a window
of four weeks from RDP2 to the code freeze, feedback from
these will probably go directly to SapMachine and then to the
next OpenJDK 11u release. But we will share issues and try to get
fixes into the current OpenJDK release. 
These tests with real applications often show incompatibilities
in the jdk changes ... 

> And what would be regarded as a showstopper?
If we have 6 days in jdk11u before the tag, we could push an
urgent fix directly to jdk11u before adding the tag.
I.e., we could hopefully avoid showstoppers.
I think we should only skip or delay a tag in very rare cases,
as downstream work depends on the tags. Instead, we should
open bugs and refer to the tag that shows the bug.

> One of my aims this time around is to do more frequent downstream merges
> so I can test each tag on a wider range of architectures, and not be
> caught out by arch-specific build failures late in the cycle.
That would be great :)

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