[11u]: 8u222 & 11.0.4 release schedule

[Andrew John Hughes]

On 29/04/2019 21:55, Langer, Christoph wrote:
> Hi Andrew,
> 
> at the end of last week I was thinking the same as you with regards on how we should do the pulling, merging and tagging. However, today Goetz came back from vacation and we discussed this a bit in more and came up with the approach he suggested in his mail. I actually think the approach as outlined by Goetz will help to have higher quality in the tags and we also don't ever need to flip repositories. The only change in week-to-week process would be to stop the integration from jdk11u-dev to jdk11u on the Wednesday when we reach ramp down. During the development stage, we'll pull each Wednesday from jdk11u-dev and will then have 6 days until the following Wednesday to fix high priority issues such as build failures or whatever exceptional thing we can think of (which will hopefully all be rather seldom though).
> 
> Find below some comments on  your remarks:
> 
>> On 29/04/2019 15:50, Lindenmaier, Goetz wrote:
>>> Hi,
>>>
>>> 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.
> 
> Obviously, before we do a first tag in jdk11u we have to pull something from jdk11u-dev. Otherwise we would tag nothing. So, for this week I think we should pull jdk11u-dev on Wednesday and tag 11.0.3+1 next Tuesday.
> 
> As of now, we must not pull anything over to jdk11u anyway, since there's no indication that hgupdater has been updated on jdk11u to account for 11.0.4. Probably, after we have word by ops that hgupdater is up to date, we should pull one test patch first to see if everything really works correctly. The good thing if we were to tag the first build only next week is that we have a few more days to have ops complete their work.
> 
>>> 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.
> 
> See my comment above. ��
> 
>>> 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
>>>
> 
> <snip>
> 
> 
>> What testing do you do? And what would be regarded as a showstopper?
> 
> As for our testing: Goetz had enumerated it here a while ago: https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-February/000648.html 
> Showstoppers for tags would merely be build errors, I guess. Probably also very severe regressions compared to the last tag...
> 
> Best regards
> Christoph
> 
> [0] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-February/000648.html
> 

I find this very confusing.

You may not have to change things over in the different stages, but you
instead have this odd situation where you essentially run a week behind,
and tag a bunch of changes that are, by then, a week old.

I think what I suggested is a lot clearer. I spent a good five minutes
reading over this and still not sure I have it right.  I'm not sure how
this leads to "higher quality" as you're still tagging the same thing.

The issue with hgupdater is easily resolved in my scenario by just not
touching jdk11u until it's ready. The tags will be still added in
jdk11u-dev. The pull in jdk11u is simply delayed. It's not clear to me
what happens in your case. Do you push the changes to jdk11u but not tag
them? Or is it all just kept locally for a week?

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