Future jdk9u updates & 9-critical-request

[dalibor topic]

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