JDK 11.0.3 Update process

[Rob McKenna]

Ah, you're both absolutely right. I had forgotten the difference in
process in the JDK Project.

There are a number of duplicate changesets in 12, but these could
be a case of realising after the fact that the fix should be in the
earlier release.

So I can't speak for that project, but with JDK Updates (and JDK 8u
before it) the decision was made to have engineers push to a single
always-open repository in the interests of simplicity. It is a little
extra work for an integrator(*), but it drastically simplifies things from
the perspective of the committer.

(*) That is to say, there is usually only a small number of patches to
bring into a stabilization forest on a weekly basis, and they generally
apply cleanly.

    -Rob


On 20/02/19 08:31, Langer, Christoph wrote:
> Hi Rob, Goetz,
> 
> > > I'm not sure I follow. Post RDP2 of jdk12, all approved changes are first
> > > pushed to jdk/jdk and then to the jdk/jdk12 stabilization repo. In this
> > > case two records will be created, one for 13 and one for 12.
> > 
> > If you push changes first to jdk/jdk and then to jdk/jdk12 by hg
> > export/import,
> > and in the end pull jdk/jdk12 back to jdk/jdk, the changes should be there
> > twice, shouldn't they? But it's not the case.  E.g., I had a look at
> > 8218662: Allow 204 responses with Content-Length:0
> > 
> > ... Obviously, I'm looking at the publicly visible repos. Internally,
> > you might be doing something else.
> 
> Goetz is right here. For jdk12/jdk the process is different to the works on the Oracle update releases. If a fix is considered important enough to go into jdk12 (e.g. P1) it is pushed to jdk12. It eventually bubbles back to jdk during a weekly merge of jdk12->jdk. You'll see jdk13 backports in JBS then for an issue that was fixed in jdk12 originally. That's the kind of process that we, the SAP team, think should be established for jdk11 and jdk8 updates.
> 
> Best regards
> Christoph
>