Future jdk9u updates & 9-critical-request

[Andrew Haley]

On 26/01/18 19:19, dalibor topic wrote:
> 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's really beside the point.  What went wrong, IMO, was that
breaking changes were committed but the release was still made even
though it was broken.  That is very unusual in open source projects.
I don't think I've ever seen it happen before.

If Oracle had needed an immediate security release they could have
tagged and released with their own tag, but waited for an ack response
from everyone else using the tree for the final GA release.  IMO,
that is the job of the release manager.

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

To be clear, I understand the breaking the release was not
deliberately hostile.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671