Future jdk9u updates & 9-critical-request
dalibor topic
dalibor.topic at oracle.com
Fri Jan 26 19:19:21 UTC 2018
On 25.01.2018 18:31, Andrew Haley wrote:
> On 25/01/18 17:28, Alan Bateman wrote:
>> I don't think anyone deliberately broke anything. I think it's just that
>> 9.0.4 was a security release so the changes couldn't bake in
>> jdk-updates/jdk9u.
>
> Sure, I understand that it wasn't deliberate. However, the
> immediate tagging and tying-off of the branch was.
The tagging serves to mark the corresponding source code for an OpenJDK
release, so that was definitely deliberate, and as it should be. ;)
The forest isn't actually tied off yet, as you can see when you look at
http://hg.openjdk.java.net/jdk-updates/ - it'd be marked as 'READ ONLY'
in that case.
That's also as it should be, as we discussed earlier on this list with
keeping 9u open for a qualified Committer to step up and maintain once
we stop doing it.
What I believe we've done for OpenJDK 6 and JDK 7 Updates was to let any
such maintainer take over from a clean slate, i.e. with no unreleased
patches stuck in the repository. I think it would have been simplest if
we could have done the same for 9u, having a single point in time after
the end of public updates when someone else steps up and maintains it
going forward for however long or short they need to.
That being said, that's not a hard requirement. So we probably could
have a set of unreleased patches in the forest waiting for someone else
to step to maintain the forest and release them.
But what complicates things in the interim time between the last Oracle
planned Oracle-led update (9.0.4) and the official end of public life
for an OpenJDK update release series led by Oracle (March 2018 for JDK 9
Updates) is that we have simultaneous Oracle and OpenJDK releases that
are supposed to converge, rather than diverge over time as long as they
are led by Oracle.
So ideally, we'd have no actual [0] JDK 9 Update releases in that
interim phase before someone else steps up once Oracle steps down, as
the only reason to have one would be a hypothetical future Security Alert.
In that hypothetical scenario with unreleased patches lurking around in
the forest things could become very complicated very quickly, for
example if such patches have unforeseen side-effects on platforms that
weren't tested at the time of their inclusion into then OpenJDK 9u forest.
To make a long story short, I think that we just needed (and I think may
still need) a bit of time to think through the implications of an
unforeseen situation (last planned Oracle unexpectedly build breaking
downstream builds).
Please don't assume that's a deliberately hostile act - we just have to
navigate a more complicated problem space than might be apparent
immediately. I'm sure that it's similarly unappealing to everyone
involved to have to deal with this kind of problems after a release as
it is to you to have to wait on the patches fixing these regressions to
finally make it in. I wish we had foreseen this situation earlier and
avoided the resulting inconvenience.
cheers,
dalibor topic
[0] Tagging additional 'source code only' 'builds' of 9.0.4 rather then
new releases might work, since I assume that these kind of post CPU
regression fixes would typically address build failures on platforms not
already provided on jdk.java.net.
--
<http://www.oracle.com> Dalibor Topic | Principal Product Manager
Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961
<tel:+491737185961>
ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | 22761 Hamburg
ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603
Komplementärin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
<http://www.oracle.com/commitment> Oracle is committed to developing
practices and products that help protect the environment
More information about the jdk-updates-dev
mailing list