JDK11/8 Updates: process, schedules and tagging

Tue May 28 15:04:58 UTC 2019

Hi Andrew,

I just took over your changes from the OpenJDK 8 Updates Wiki to the OpenJDK11 pages. Thanks for the nice update. Now the pages reflect the current process and their readability has significantly increased ��

As for the tagging then I think we have agreed to start with tagging in the dev branches the week after GA of the previous release. And when no changes occurred then we'd skip a tag and announce that on the mailing lists. This is what's written down in the Wiki. I fully share your arguments below.

Best regards
Christoph

> -----Original Message-----
> From: Andrew John Hughes <gnu.andrew at redhat.com>
> Sent: Donnerstag, 16. Mai 2019 21:44
> To: Langer, Christoph <christoph.langer at sap.com>; jdk-updates-
> dev at openjdk.java.net; jdk8u-dev at openjdk.java.net; Lindenmaier, Goetz
> <goetz.lindenmaier at sap.com>; Andrew Haley <aph at redhat.com>
> Subject: Re: JDK11/8 Updates: process, schedules and tagging
> 
> On 16/05/2019 10:57, Langer, Christoph wrote:
> > Hi,
> >
> >
> >
> > after we had the discussion about the OpenJDK 8/11 release process and
> > schedule [0], I’d like to explicitly spell out the current status and
> > update the Wiki pages.
> >
> >
> >
> > It seems like we have agreed to a 3 phase model
> >
> >
> >
> > 1. Development
> >
> > 2. Rampdown (RDP2)
> >
> > 3. Freeze
> >
> >
> >
> > I’ve updated the timelines on the Wiki pages [1], [2] now accordingly.
> > Please check/review.
> >
> 
> Thanks. I'll review the 8u page and check it matches the process I'm
> following.
> 
> I do think "RDP2" should be avoided as there is no "RDP1".
> 
> >
> >
> > I would short-summarize our process like this:
> >
> > During development phase, changes go into the development repositories
> > (jdk8u-dev/jdk11u-dev) and weekly tagging will be done in there. When
> > the release repositories (jdk8u/jdk11u) aren’t blocked by
> > rampdown/freeze of the previous release, the tags will be synced on a
> > weekly basis to the release repositories. When rampdown of a release
> > starts, merges from dev to release repositories are suspended and RDP2
> > approved changes have to be pushed to the release repositories. From
> > that time merges happen from release->dev. After the freeze tag, no
> > changes must go into the release repository while the CPU is assembled
> > non publicly. After release, the CPU is merged back to the open
> > repositories.
> 
> Yes:
> 
> Dev phase: dev tagged, dev->master
> Rampdown phase: master tagged, master->dev
> Freeze phase: no changes to master
> Release: CPU changes pushed to master, master->dev
> 
> >
> >
> >
> > Is that our common understanding? If I get no objections, I’ll update
> > the process description pages [3] and [4] accordingly.
> >
> >
> >
> > I furthermore have 2 questions / things to clarify.
> >
> >
> >
> > a) Will we tag in the dev-repositories right from the start? E.g. will
> > we start tagging 11.0.5 right after the 11.0.4 RDP2 integration from
> > 11u-dev to 11u in the week after May 28?
> >
> >     - I would suggest to do so.
> 
> We do tag that point as -b00, I believe.
> 
> If you mean do we start weekly tags of release x+1 in dev once release x
> is in rampdown, then no, I don't plan to for 8u. If you have the cycles
> to do so for 11, you can, but I need that time - particularly the freeze
> period - to prepare, build and test the imminent releases.
> 
> Also, I don't really see the point when there is nowhere to promote the
> build to, as master is still on release x.
> 
> That does mean that b01 will run over a longer period than other tags,
> but I don't see that as a particular problem.
> 
> >
> > b) Will we also do a weekly tag when no changes happened after the
> > previous tag? This should probably be a rare case given the current
> > activities but we should have a guideline for that.
> >
> >     - My feeling would be to skip the tag then. I can’t see any value in
> > this.
> >
> 
> I agree with skipping such empty tags, with an appropriate list
> announcement.
> 
> I think the predictability argument is already lost in the final stages
> where we may have to add multiple tags in secret during the addition of
> the security patches. On the other hand, tagging periods with no changes
> introduces the possibility of a lot of needless work testing unchanged
> sources.
> 
> I think it's easier to convey the message that a tag is being skipped -
> which someone who notices the lack of a new tag may look for - than it
> is to tag and have unknown users downstream building and testing
> something with no changes.
> 
> The problem with comparing with Oracle processes is that their process
> is largely internal and so there are not the same potential
> communication issues.
> 
> I think this is unlikely during the development stage, but more likely
> during the rampdown if nothing is critical enough to be included in the
> imminent release.
> 
> My answer to both questions is concerned more with the reality of the
> workload involved than pointlessly sticking to an agreed protocol, when
> our limited resources could be better utilised.
> 
> >
> >
> > May I please have your feedback on that (especially from the Andrews ��)
> >
> >
> >
> > Thanks
> >
> > Christoph
> >
> >
> >
> > [0]
> > https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-
> April/000996.html
> >
> > [1] https://wiki.openjdk.java.net/display/JDKUpdates/JDK11u
> >
> > [2] https://wiki.openjdk.java.net/display/jdk8u/Main
> >
> > [3]
> >
> https://wiki.openjdk.java.net/display/JDKUpdates/Detailed+Process+Descri
> ption
> >
> >
> > [4]
> https://wiki.openjdk.java.net/display/jdk8u/Detailed+Process+Description
> >
> >
> >
> 
> Thanks,
> --
> 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