[11u]: 8u222 & 11.0.4 release schedule

[Andrew John Hughes]

On 30/04/2019 13:40, Lindenmaier, Goetz wrote:
> 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.

Many of us were very busy with the last release.

>  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.

Indeed. This seems like a reason to do it in jdk11u-dev.

>  
>>> 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?

What do you mean by "doing fixes"? Work should go on in jdk11u-dev, not
jdk11.

>  
>>> 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.

That's not my aim.

> We should try to build a process that is easy to communicate

We should. I'm sorry, but I don't find yours to be so.

 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. 

No, it isn't. I'm not sure who the 'we' is here, but maybe this is the
confusion here.

The message is work is always done in the development tree, jdk11u-dev.

Work in the jdk11u-dev tree is always work on the development stage of a
release.

Explicitly moving the focus for release x from the development tree to
the master tree at rampdown is designed to shift development focus to
the next release, x+1.

If an issue is found in working on x+1, or in testing x, that is a
showstopper for release x, then that may be flagged as
jdk8u-critical-request to get it into the upcoming release.

But otherwise, the intent here is for people to start aiming their work
at the next release at rampdown. Patches being pushed to jdk11u should
be rare.

> 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.

Because jdk11u and jdk11u-dev are aimed at different audiences.

The master tree (jdk11u) is snapshots for people to test and integrate
downstream, leading up to the final release.

The development tree (jdk11u-dev) is for developers to work on the release.

I don't see how that's any different to your scenario which, I believe,
also updates both.

I don't expect developers working on jdk8u development to have to care
much about the master tree, unless they is a critical issue with the
upcoming release. I don't expect consumers to care about the development
tree at all; they should consume solely from jdk11.

As I said before, merging to jdk11u earlier is intended to provide for
earlier testing of a smaller number of changes. It's an attempt to meet
your call for earlier testing without locking everything down before
many people have even had time to work on the release.

> 
>> 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.

Which is why I suggest starting such builds over the next week or so.

My plan for 8u is to integrate the build downstream and do our usual
builds and testing as much as possible for each tag.

> 

-- 
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