Classify JDK-8219890 and JDK-8208656 as critical in JBS

[Andrew John Hughes]

On 09/04/2019 13:43, Langer, Christoph wrote:
> Hi Andrew,
> 
>  
> 
> I can see that the changes for JDK-8219890 [0] and JDK-8208656 [1] have
> been pushed to jdk8u-dev and jdk11u-dev in the meanwhile.
> 
>  
> 
> These are most probably prerequisites of the Japanese era update
> JDK-8205432 [2] that comes with the JDK 8u212 and JDK 11.0.3 CPUs. Can
> you confirm that?

They are.

It would be a little easier to answer such questions if you included the
summaries so I know which bugs you're referring to. All these numbers
are pretty meaningless.

> 
>  
> 
> Since I strongly believe so, I have added “jdk11u-critical-request” and
> “jdk8u-critical-request” to both plus a fix request comment that states
> its relation to JDK-8205432.
> 
>  
> 
> I think we should make sure that public fixes which get integrated into
> the CPU repositories and will hence get merged on the release day are
> flagged as “critical-yes”. This will bring them up in the relevant JBS
> views, e.g. [3] for jdk8u and [4] for jdk11u and downstream providers of
> OpenJDK can easily check which public changes will be included on top of
> the last public tag and get merged in on the release day.

I've assumed jdkx-critical-request to be relevant during the period
between branch and freeze.

Changes after freeze will be posted, reviewed and approved in bulk (as
Oracle did with the full set). It is uncommon for any of these changes
to be public. These Japanese changes are unusual in that they had to
wait until the era name was announced on 2019-04-01. Most of the changes
after freeze are not visible bugs to which I can apply such a label,
and, where we can, it may also be confusing to apply the critical label
and then push to the -dev tree. They can't be pushed to the main tree
because they are preceded by embargoed changes.

For downstream providers who are members of the vulnerability group, I
have provided an exact list of what is included after the freeze. I
think that's clearer than trying to work it out from the bug database,
which will inevitably be incomplete. Those who are not members of the
group can not know the full set of changes in the final release until
the unembargo date.

So, in short, I don't have a strong objection to using the tag for these
later changes, but they are not going to provide a complete picture of
the release. If they did, we would just be pushing the changes directly
to the main tree.

> 
>  
> 
> Thanks & best regards
> 
> Christoph
> 
>  
> 
> [0] https://bugs.openjdk.java.net/browse/JDK-8219890
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8208656
> 
> [2] https://bugs.openjdk.java.net/browse/JDK-8205432
> 
> [3] https://bugs.openjdk.java.net/issues/?filter=36562
> 
> [4] https://bugs.openjdk.java.net/issues/?filter=36558
> 

-- 
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