Future jdk9u updates & 9-critical-request

[Volker Simonis]

There's also another important point that needs to be considered here.
Until now, every release had it's own update project with own project
lead and infrastructure. Whenever Oracle lost its interest in updating
a Java version, it generously transferred the project responsibility
to the community (and thankfully RedHat and Azul have taken over this
responsibility for OpenJDK 6 & 7).

With Java 9, things have changed. There's only one generic update
project for all future updates and I doubt Oracle will transfer
ownership of that project to the community. So even if Andrew doesn't
mind to "be jdk9u lead for 10 minutes" it won't even be possible to
realize that, simply because there is neither a jdk9u project nor a
jdk9u project lead. This is unfortunate, because now, even if Oracle
looses interest in a release, like for example OpenJDK 9, there's no
easy way for the community to step in and run these updates according
to their rules.

So maybe we really need to rethink the jdk updates project and how it works.

Needless to say that a working "Vulnerability Group" is key for any
kind of setup with community involvement!

Regards,
Volker


On Mon, Jan 29, 2018 at 7:26 PM, Andrew Hughes <gnu.andrew at redhat.com> wrote:
> 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