Future jdk9u updates & 9-critical-request

[Andrew Hughes]

On 31 January 2018 at 14:44, dalibor topic <dalibor.topic at oracle.com> wrote:
> On 29.01.2018 19:26, Andrew Hughes wrote:
>>
>> 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.
>
>
> The role that feature releases used to play in the update release series now
> falls squarely onto the shoulders of the major releases. Update releases are
> strictly limited to fixes of security issues, regressions, and bugs in newer
> features.
>

I'm aware of this. It remains to be seen how this will work out in practice
once we have long term support releases as well.

> I don't think that the clean slate is as important in this Project as it was
> for 7, when several dozens of patches could accumulate for many months in
> the open forest before a final release.
>

I don't follow you here, because the timing between update releases hasn't
changed; they still occur on a quarterly cycle. Major releases are more
frequent than before, but they occur under the jdk project, not
jdk-updates. I do think that the shorter shelf life of updates like 9 means
there will less desire for it to be maintained further, given its consequential
lower adoption rate. But that all remains to be seen.

What's not clear to me at present how any patches would even make their
way into a release. How do changes from the jdk-updates forests make their
way into whatever is marked as a release, as this seems to be developed
externally and then merged post-release?

The problem here occurred because this release was performed behind
the scenes and then the code for it dumped in the repository afterwards.
There was no opportunity for anyone in the OpenJDK community to test
it before release. The argument about patches in the repository already
is interesting, but has no relevance to the issue of breakage caused by
a change in something which has already been released, but not published.

At least this time it was timely, unlike with 9.0.1, which was delayed due
to administrative concerns.

> In the case of the updates in this Project, I think one can expect at most a
> handful or two of additional changes to be requested and approved in the two
> months between the last release and the next major release.

As I said above, this time period is no different to how it was for
OpenJDK 7 & 8.
The only exception was when 8u122 was abruptly abandoned with little
explanation, and so patches for 8u122, 8u132 and 8u142 all ended up being
part of 8u152. Given we seem to have gone back to regular three monthly
updates with 8u162, I regard this more as an anomaly than standard practice.

>
> Given that the requests and approvals and commits [0] can all be easily
> tracked, they shouldn't come as a huge surprise to a potential future
> maintainer.

Well, that link shows us commits. My concern is that the process from request
to approval is not transparent. I used the tagging process to get
issues included
in 8u, as you may remember. Some were approved and some were rejected, but
there was no explanation as to why for either.

With 8u, I've been able to search for the mails on a backport and discovered why
it was approved and why changes were made in the backport. How is the same
achieved for 9u and on?

>
> cheers,
> dalibor topic
>
> [0]
> http://mail.openjdk.java.net/pipermail/jdk-updates-changes/2018-January/thread.html
>
> --
> <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



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