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

[Langer, Christoph]

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.

OK, right, will try to remember next time. ��

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

I can see your points. That's a bit of a process discussion I guess. ��

So, right, most of the changes after freeze are probably embargoed changes to invisible bugs. However, there will also be some public fixes, e.g. prerequisites to other CPU changes or fixes that we need to pull into a CPU for other reasons, such as the Japanese era. The latter were somewhat special in that they were pushed to jdk8u-dev and jdk11u-dev as well instead of waiting for the merge back from CPU.

It's also good that you provide the full list of changes to the vulnerability group, which for sure would be the only way to get a complete picture.

However, for the public JBS part I'd like to have some tagging to the visible bugs that go into a CPU. I think the "critical" labels would be a good way to do this. This of course will not mean that a change can/will be pushed to the dev codelines in advance such as the Japanese era stuff. But these tags will give the complete picture when comparing the contents of the OpenJDK community release with the Oracle release. And, the information about public bugs being part of a CPU was always visible for Oracle updates via the JBS backport items. Though you could not see the actual fix obviously.

Maybe there's some feedback from other people about this?

Thanks
Christoph