Future jdk9u updates & 9-critical-request

[Andrew Hughes]

On 26 January 2018 at 19:19, dalibor topic <dalibor.topic at oracle.com> 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.
>

The main difference is that Oracle maintainership of OpenJDK 7 ended
with a publicly developed update, u80, while OpenJDK 9 has concluded with a
security update.

OpenJDK 9 has also had a much more contracted lifecycle than
has been expected in the past, and is likely to remain a unique
release in having
a long development cycle - making it quite different from OpenJDK 8 -
but a short
release cycle. Transition from 8 to 9 is much more of an undertaking
than I would expect
9 to 10 is going to be, and what we'll probably see the 9 and 10
releases being skipped
in many cases, as part of transitioning between the two release
cycles. As a result,
there hasn't been anything like the run-up to its end-of-support
deadline as there was
with OpenJDK 6 and 7.

There also hasn't been much chance for any patches to build up. The
repositories for
9.0.1 were late in appearing due to the transition to the jdk-updates
project only happening
after this release, leaving very little time for anything to be
backported to 9 before 9.0.4.
It's also now very hard to tell what backports have been requested and
actually committed
due to the move from an open process on the mailing list to tagging of
bug requests, which
not only takes time for people to adapt to, but also seems like a
backwards step in terms of
community involvement.

One of the problems here is the lack of a more open release process.
At present, it goes:

1. Release binaries
2. Retro-actively request to add the sources for these binaries to OpenJDK

I'm not pointing fingers only at Oracle for this, because we've also
ended up adopting this
process with IcedTea and OpenJDK 6 & 7. It's difficult to deal with
security releases any other way,
because binaries have to be ready to go when the embargo is lifted. If
the release
is left open for discussion, you risk having binaries that don't match
the source.

So I suspect the real problem here is the lack of feature updates in
this new lifecycle,
To compare 6 & 7 with 9 is comparing apples and oranges, because they operated
under a completely different release process. If Oracle want to leave
future maintainers
with a "clean slate", there needs to be a concluding feature release
i.e. something we
can openly contribute to, as we did under 7 and 8. I would suggest
this occurs in parallel
with the first release of the next version, and is used as a point
outside of security updates,
to say "This is the last one of x. You need to be switching to x+1
over the next month to
continue getting security updates.".
-- 
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