Future jdk9u updates & 9-critical-request

[Rob McKenna]

Hi Martin,

On 25/01/18 10:19, Martin Buchholz wrote:
> There is enough interest in jdk9 that at least minimal community
> maintenance should be possible.
> 
> Neither Google nor I personally are currently willing to step up to being
> the official maintainer of jdk9u, but I have some fixes to contribute if a
> maintainer is willing to accept them.
> 
> The obvious candidates for jdk9u official maintainer are Andrew Haley (Red
> Hat) and Dmitry Cherepanov (Azul).  jdk8 and jdk10 are also likely to need
> new maintainers starting in 2018-09.  Start planning now.
> 
> jdk9 went through a long period where bug fixes were discouraged or
> deferred.  jdk9 rampdown started in 2017-01.  Some engineers (including
> myself) tagged some bugs with the label "9-bp".  I created a simple JIRA
> filter for all such bugs - https://bugs.openjdk.java.
> net/issues/?filter=33680 .  There was never any vehicle for those jdk9
> fixes to be delivered because there was never an actual non-security update
> jdk9 release.  It's the first time such a thing has happened for a major
> jdk release.

As per: http://openjdk.java.net/projects/jdk-updates/approval.html you
can add a <release>-critical-request label to the bugs in order to get
them included into an update. (so 9-critical-request in this instance)

Unfortunately this process was only announced at the beginning of last
November which left slightly less than 2 months for the requests
to get into 9.0.4 but I'm hoping the process will solve this problem
for future releases.

    -Rob

> 
> jdk8 was released 4 years ago.  The next release suitable for risk-averse
> adopters would seem to be one of the early bug fix releases of jdk11
> expected in 2019.  It's a long time.
> 
> On Thu, Jan 25, 2018 at 9:36 AM, Andrew Dinn <adinn at redhat.com> wrote:
> 
> > On 25/01/18 17:28, Alan Bateman wrote:
> > > On 25/01/2018 16:46, Andrew Haley wrote
> > >> :
> > >> This is ridiculously hostile behaviour: to break a bunch of things
> > >> in OpenJDK, do a release, and then immediately drop the project
> > >> on the floor before giving anyone a chance to fix what is broken.
> > >> Really, I would have expected better than this.
> > >>
> > >> I guess I'll have to be the project maintainer for long enough to
> > >> commit the necessary fixes so that jdk9u works for all ports, not
> > >> just the ones that Oracle ships.
> > >>
> > > 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.
> >
> > No, of course it was not deliberate breakage. The deliberate action we
> > are concerned about would be simply walking away from the mess afterwards.
> >
> > > This may be something that the establishment of the vulnerabilities
> > > group will help with. Alternatively maybe the JDK Update maintainers
> > > could just approve the changes needed to get the ports aligned and leave
> > > it at that. If someone steps up to maintain the JDK 9 updates going
> > > forward then they could tag a new release that includes the changes.
> > Well, of course, this is a poster-child level argument for getting the
> > vulnerabilities group sorted out asap. But that's a secondary question
> > right now. The important question still remains what to do about a tree
> > that has been left in a half-baked state. I think it would make a great
> > deal of sense for the existing patches which are known to resolve the
> > problem to be pushed to the current tree.
> >
> > regards,
> >
> >
> > Andrew Dinn
> > -----------
> > Senior Principal Software Engineer
> > Red Hat UK Ltd
> > Registered in England and Wales under Company Registration No. 03798903
> > Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
> >