JDK 11.0.3 Update process

[Volker Simonis]

As it seems we all agree on having a second jdk11u-dev repository,
maybe we can already request it?

I'm not sure about the exact process here, but I think the jdk-updates
project lead has to do this?

@Rob: could you please request the creation of a new
jdk-updates/jdk11u-dev repository or otherwise tell us what we'll have
to do in order to get such a repository?

Thank you and best regards,
Volker

On Wed, Feb 13, 2019 at 7:38 PM Andrew Haley <aph at redhat.com> wrote:
>
> On 2/13/19 6:30 PM, Volker Simonis wrote:
> >> There are potentially some issues here. We may have to integrate
> >> non-security fixes into the hidden CPU tree, and we may have to do
> >> that in a way that people outside the VG cannot see. So yes, that's
> >> highly desirable, but no promises.
> >>
> > Yes, but this should be only for the fairly rare cases, where a
> > security fix has some dependency on a non-security change and pulling
> > that non-security change in via jdk-updates/jdk11u would disclose
> > something about the upcoming security change. Otherwise, I still think
> > it would be advisable to do such changes in jdk-updates/jdk11u and
> > regularly merge them into jdk-updates/jdk11u-sec.
>
> Well, yes, but not if doing so impacts our ability to deliver the CPU in
> a timely way. We'll try.
>
> > Sorry if my insistence in doing as much as possible of the
> > non-security work in in jdk-updates/jdk11u (and pulling it from there
> > into jdk-updates/jdk11u-sec) seems stubborn. I understand that it may
> > produce a little extra-overhead on the side of the
> > jdk-updates/jdk11u-sec maintainers. On the other side, it makes the
> > live for all the other down-stream consumers easier, leads to better
> > test coverage for the update release and keeps the VG mailing list
> > focused on vulnerability issues. Otherwise, it would be necessary to
> > also communicate and discuss the non-security fixes done in the
> > "closed" jdk-updates/jdk11u-sec over the VG mailing list.
>
> Yes, I get that. But I will not tie the hands of the developers in the
> critical path.
>
> --
> Andrew Haley
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671