JDK Updates Project Page

[Andrew Hughes]

On 9 November 2017 at 20:53, Phil Race <philip.race at oracle.com> wrote:
>

snip...

>
>
> Mario, I think the issue here is that the only planned update releases for
> JDK 9 and JDK 10
> are CPU releases. That's the model going forward. And CPU releases only get
> absolutely critical fixes .. of which the security fixes are the main
> category.
>
> So there won't be a long tail of 9.0.XXX releases like we had JDK 8 updates
> / PSUs
> which need these backports. Backports will become increasingly rare.
>
> Consider that 8u152 had maybe a year of backlogged fixes.
> Some fixes we pushed in May (?) to 8u-dev are only just showing up in 8u162
> b01
> for release next year ..
> But JDK 10 will be out just 6 months after JDK 9 .. and 9 will then become
> obsolete
> and unsupported .. so why does it need non-critical backports anyway ?
> People should be on 10 by then.
>
> Backports are going to become rare if I have my facts right.
>

Well, 8u152 was effectively 8u122 delayed by a year. Prior to that, we
were having PSUs in lock-step with CPUs. We've felt this delay a lot
in having to backport a pile of fixes from 8u152 locally. I hope the intention
with 8u162 is to go back to releasing with the CPU. If so, 8u152 seems more
like an anomaly than an example of how we were working before.

My expectation would be that the short-lived releases would only really see
CPUs but that an LTS would also receive wider updates. Put it this way, it's
going to happen somewhere downstream otherwise - I deal with customers
wanting backports for issues all the time - and I'd prefer it happened
in the OpenJDK repositories so everyone can benefit.

>
>
>
>>
>> The criticality of the bug may be perceived differently then,
>> depending on who is reviewing the fix. I would personally reserve the
>> "critical" term for actual really critical issues (a security
>> emergency fix for example, or, indeed, a P1 bug), but have another
>> flag to signal the backport request, unless the point of this exercise
>> is really to not have upstream backport requests any more other than,
>> well, critical ones [1].
>>

This is something that needs a lot more transparency than the current process.
With respect to the 8u122/152 fiasco, I ended up requesting a bunch of bugs we
were shipping locally for the CPU, as there was no sign of another PSU any time
soon. Some were silently approved and others silently rejected with no
explanation.
I don't even know who reviewed them and so who was judging whether they were
"critical" or not. A fix for AArch64 or PPC may not be critical at all
for Oracle, because
they don't ship it, but it could be causing regular crashes of the VM
and would certainly
count as critical for those of us who do ship it.

My worry with moving away from the mailing list approach is it
decreases the transparency
even more. Now only those monitoring the bug will see what's going on.
It's also worth noting
that not everyone who posts to the update mailing lists has access to
the OpenJDK bug database.
I've filed bugs and pushed fixes on behalf of others before.
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Web Site: http://fuseyism.com
Twitter: https://twitter.com/gnu_andrew_java
PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222