JDK11/8 Updates: process, schedules and tagging

Lindenmaier, Goetz goetz.lindenmaier at sap.com
Fri May 17 08:04:42 UTC 2019


Hi,

> I do think "RDP2" should be avoided as there is no "RDP1".
I understand you don't want the OpenJDK RDP terms.
So let's use the term Rampdown.

Could you please propose some wording to describe which 
changes are acceptable during rampdown?

I will do the weekly tags on 11.

Best regards,
  Goetz.



> > 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+Descripti
> on
> >
> >
> > [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



More information about the jdk-updates-dev mailing list