From rob.mckenna at oracle.com  Fri Jan 12 15:19:35 2018
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Fri, 12 Jan 2018 15:19:35 +0000
Subject: Future jdk9u updates & 9-critical-request
Message-ID: <20180112151935.GC4779@vimes>

Hi Martin,

I see you've added the 9-critical-request label to several bugs lately.
This is just a heads up to let you know that as Oracle has no plans to
release further updates to JDK9 [1] then these labels will be have no
effect until a new project maintainer steps forward.

    -Rob

[1] http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2017-November/000024.html


From martinrb at google.com  Fri Jan 12 19:37:42 2018
From: martinrb at google.com (Martin Buchholz)
Date: Fri, 12 Jan 2018 11:37:42 -0800
Subject: Future jdk9u updates & 9-critical-request
In-Reply-To: <20180112151935.GC4779@vimes>
References: <20180112151935.GC4779@vimes>
Message-ID: <CA+kOe0_3GbH3kVm7v76txZ-2M1b8C++3_hB7VMaDQ9kDjrinZw@mail.gmail.com>

Hi Rob,

On Fri, Jan 12, 2018 at 7:19 AM, Rob McKenna <rob.mckenna at oracle.com> wrote:

> Hi Martin,
>
> I see you've added the 9-critical-request label to several bugs lately.
> This is just a heads up to let you know that as Oracle has no plans to
> release further updates to JDK9 [1] then these labels will be have no
> effect until a new project maintainer steps forward.
>

I think I was confused by the End Of Updates being March 2018; I expected a
last update just before End Of Updates.

I'm not sure whether we will have a new jdk9 updates maintainer step
forward.  I'll ask around.  Some combination of folks from Google, Red Hat,
Azul, etc might make it work.

Can I get my own personal jdk9u hosted at
http://hg.openjdk.java.net/jdk-updates/9jdku-SOME-GOOD-NAME
to park my backport patches even if don't commit to owning jdk9 updates?

Can we get help from Oracle to run cross-platform tests on arbitrary trees
like jdk9u in the future (e.g. via jprt) even if Oracle itself no longer
supports that particular tree?


>     -Rob
>
> [1] http://mail.openjdk.java.net/pipermail/jdk-updates-dev/
> 2017-November/000024.html
>
>

From martijnverburg at gmail.com  Sat Jan 13 09:03:29 2018
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Sat, 13 Jan 2018 09:03:29 +0000
Subject: Future jdk9u updates & 9-critical-request
In-Reply-To: <CA+kOe0_3GbH3kVm7v76txZ-2M1b8C++3_hB7VMaDQ9kDjrinZw@mail.gmail.com>
References: <20180112151935.GC4779@vimes>
 <CA+kOe0_3GbH3kVm7v76txZ-2M1b8C++3_hB7VMaDQ9kDjrinZw@mail.gmail.com>
Message-ID: <CAP7YuATLYgEgcgUu-QHTVD0QSYjL8h3_pKcvurvX6KY_zU4zWw@mail.gmail.com>

Hi Martin,

The Community build farm at AdoptOpenJDK.net may be able to help here.  Let
me know if you?d like further info.

Cheers,
Martijn

On Fri, 12 Jan 2018 at 19:38, Martin Buchholz <martinrb at google.com> wrote:

> Hi Rob,
>
> On Fri, Jan 12, 2018 at 7:19 AM, Rob McKenna <rob.mckenna at oracle.com>
> wrote:
>
> > Hi Martin,
> >
> > I see you've added the 9-critical-request label to several bugs lately.
> > This is just a heads up to let you know that as Oracle has no plans to
> > release further updates to JDK9 [1] then these labels will be have no
> > effect until a new project maintainer steps forward.
> >
>
> I think I was confused by the End Of Updates being March 2018; I expected a
> last update just before End Of Updates.
>
> I'm not sure whether we will have a new jdk9 updates maintainer step
> forward.  I'll ask around.  Some combination of folks from Google, Red Hat,
> Azul, etc might make it work.
>
> Can I get my own personal jdk9u hosted at
> http://hg.openjdk.java.net/jdk-updates/9jdku-SOME-GOOD-NAME
> to park my backport patches even if don't commit to owning jdk9 updates?
>
> Can we get help from Oracle to run cross-platform tests on arbitrary trees
> like jdk9u in the future (e.g. via jprt) even if Oracle itself no longer
> supports that particular tree?
>
>
> >     -Rob
> >
> > [1] http://mail.openjdk.java.net/pipermail/jdk-updates-dev/
> > 2017-November/000024.html
> >
> >
>
-- 
Cheers, Martijn (Sent from Gmail Mobile)

From rob.mckenna at oracle.com  Wed Jan 17 15:01:18 2018
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Wed, 17 Jan 2018 15:01:18 +0000
Subject: Future jdk9u updates & 9-critical-request
In-Reply-To: <CAP7YuATLYgEgcgUu-QHTVD0QSYjL8h3_pKcvurvX6KY_zU4zWw@mail.gmail.com>
References: <20180112151935.GC4779@vimes>
 <CA+kOe0_3GbH3kVm7v76txZ-2M1b8C++3_hB7VMaDQ9kDjrinZw@mail.gmail.com>
 <CAP7YuATLYgEgcgUu-QHTVD0QSYjL8h3_pKcvurvX6KY_zU4zWw@mail.gmail.com>
Message-ID: <20180117150118.GA3420@vimes>

Inline:

On 13/01/18 09:03, Martijn Verburg wrote:
> Hi Martin,
> 
> The Community build farm at AdoptOpenJDK.net may be able to help here.  Let
> me know if you?d like further info.
> 
> Cheers,
> Martijn
> 
> On Fri, 12 Jan 2018 at 19:38, Martin Buchholz <martinrb at google.com> wrote:
> 
> > Hi Rob,
> >
> > On Fri, Jan 12, 2018 at 7:19 AM, Rob McKenna <rob.mckenna at oracle.com>
> > wrote:
> >
> > > Hi Martin,
> > >
> > > I see you've added the 9-critical-request label to several bugs lately.
> > > This is just a heads up to let you know that as Oracle has no plans to
> > > release further updates to JDK9 [1] then these labels will be have no
> > > effect until a new project maintainer steps forward.
> > >
> >
> > I think I was confused by the End Of Updates being March 2018; I expected a
> > last update just before End Of Updates.
> >
> > I'm not sure whether we will have a new jdk9 updates maintainer step
> > forward.  I'll ask around.  Some combination of folks from Google, Red Hat,
> > Azul, etc might make it work.
> >
> > Can I get my own personal jdk9u hosted at
> > http://hg.openjdk.java.net/jdk-updates/9jdku-SOME-GOOD-NAME
> > to park my backport patches even if don't commit to owning jdk9 updates?

At this time, we don't host personal forests/repos on hg.openjdk.java.net.
You would need to look for an alternative solution.

> >
> > Can we get help from Oracle to run cross-platform tests on arbitrary trees
> > like jdk9u in the future (e.g. via jprt) even if Oracle itself no longer
> > supports that particular tree?

Work is happening on getting open build and test infrastructure together.
(for example, the AdoptOpenJDK project mentioned by Martijn) I'm hoping to
see progress on that front in 2018.

    -Rob

> >
> >
> > >     -Rob
> > >
> > > [1] http://mail.openjdk.java.net/pipermail/jdk-updates-dev/
> > > 2017-November/000024.html
> > >
> > >
> >
> -- 
> Cheers, Martijn (Sent from Gmail Mobile)

From aph at redhat.com  Thu Jan 25 16:46:58 2018
From: aph at redhat.com (Andrew Haley)
Date: Thu, 25 Jan 2018 16:46:58 +0000
Subject: Future jdk9u updates & 9-critical-request
In-Reply-To: <20180117150118.GA3420@vimes>
References: <20180112151935.GC4779@vimes>
 <CA+kOe0_3GbH3kVm7v76txZ-2M1b8C++3_hB7VMaDQ9kDjrinZw@mail.gmail.com>
 <CAP7YuATLYgEgcgUu-QHTVD0QSYjL8h3_pKcvurvX6KY_zU4zWw@mail.gmail.com>
 <20180117150118.GA3420@vimes>
Message-ID: <e485c44d-8c27-7dba-baaa-15b92bca981b@redhat.com>

On 17/01/18 15:01, Rob McKenna wrote:
> I see you've added the 9-critical-request label to several bugs lately.
> This is just a heads up to let you know that as Oracle has no plans to
> release further updates to JDK9 [1] then these labels will be have no
> effect until a new project maintainer steps forward.

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.

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

From Alan.Bateman at oracle.com  Thu Jan 25 17:28:34 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 25 Jan 2018 17:28:34 +0000
Subject: Future jdk9u updates & 9-critical-request
In-Reply-To: <e485c44d-8c27-7dba-baaa-15b92bca981b@redhat.com>
References: <20180112151935.GC4779@vimes>
 <CA+kOe0_3GbH3kVm7v76txZ-2M1b8C++3_hB7VMaDQ9kDjrinZw@mail.gmail.com>
 <CAP7YuATLYgEgcgUu-QHTVD0QSYjL8h3_pKcvurvX6KY_zU4zWw@mail.gmail.com>
 <20180117150118.GA3420@vimes>
 <e485c44d-8c27-7dba-baaa-15b92bca981b@redhat.com>
Message-ID: <09ea7d53-19e9-f23c-e0a6-b2155ba4d38a@oracle.com>

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.

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.

-Alan



From aph at redhat.com  Thu Jan 25 17:31:53 2018
From: aph at redhat.com (Andrew Haley)
Date: Thu, 25 Jan 2018 17:31:53 +0000
Subject: Future jdk9u updates & 9-critical-request
In-Reply-To: <09ea7d53-19e9-f23c-e0a6-b2155ba4d38a@oracle.com>
References: <20180112151935.GC4779@vimes>
 <CA+kOe0_3GbH3kVm7v76txZ-2M1b8C++3_hB7VMaDQ9kDjrinZw@mail.gmail.com>
 <CAP7YuATLYgEgcgUu-QHTVD0QSYjL8h3_pKcvurvX6KY_zU4zWw@mail.gmail.com>
 <20180117150118.GA3420@vimes>
 <e485c44d-8c27-7dba-baaa-15b92bca981b@redhat.com>
 <09ea7d53-19e9-f23c-e0a6-b2155ba4d38a@oracle.com>
Message-ID: <ea1f583b-9fce-4f87-5896-8843f5b2b101@redhat.com>

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.

Sure, I understand that it wasn't deliberate.  However, the
immediate tagging and tying-off of the branch was.

> This may be something that the establishment of the vulnerabilities 
> group will help with.

That is surely true.

> Alternatively maybe the JDK Update maintainers could just approve
> the changes needed to get the ports aligned and leave it at that.

That would be nice.

> If someone steps up to maintain the JDK 9 updates going forward then
> they could tag a new release that includes the changes.

Well, I could formally take over the project, but it seems a bit
excessive.  I'll do that if it's the only way to get it done.

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

From adinn at redhat.com  Thu Jan 25 17:36:07 2018
From: adinn at redhat.com (Andrew Dinn)
Date: Thu, 25 Jan 2018 17:36:07 +0000
Subject: Future jdk9u updates & 9-critical-request
In-Reply-To: <09ea7d53-19e9-f23c-e0a6-b2155ba4d38a@oracle.com>
References: <20180112151935.GC4779@vimes>
 <CA+kOe0_3GbH3kVm7v76txZ-2M1b8C++3_hB7VMaDQ9kDjrinZw@mail.gmail.com>
 <CAP7YuATLYgEgcgUu-QHTVD0QSYjL8h3_pKcvurvX6KY_zU4zWw@mail.gmail.com>
 <20180117150118.GA3420@vimes>
 <e485c44d-8c27-7dba-baaa-15b92bca981b@redhat.com>
 <09ea7d53-19e9-f23c-e0a6-b2155ba4d38a@oracle.com>
Message-ID: <509c9ac2-4663-1002-e229-ccf0743d000f@redhat.com>

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

From rob.mckenna at oracle.com  Thu Jan 25 18:17:00 2018
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Thu, 25 Jan 2018 18:17:00 +0000
Subject: Future jdk9u updates & 9-critical-request
In-Reply-To: <ea1f583b-9fce-4f87-5896-8843f5b2b101@redhat.com>
References: <20180112151935.GC4779@vimes>
 <CA+kOe0_3GbH3kVm7v76txZ-2M1b8C++3_hB7VMaDQ9kDjrinZw@mail.gmail.com>
 <CAP7YuATLYgEgcgUu-QHTVD0QSYjL8h3_pKcvurvX6KY_zU4zWw@mail.gmail.com>
 <20180117150118.GA3420@vimes>
 <e485c44d-8c27-7dba-baaa-15b92bca981b@redhat.com>
 <09ea7d53-19e9-f23c-e0a6-b2155ba4d38a@oracle.com>
 <ea1f583b-9fce-4f87-5896-8843f5b2b101@redhat.com>
Message-ID: <20180125181700.GA11674@vimes>

Hi Andrew

This is the first time we've encountered this situation so my apologies
for any alarm caused. On reflection I should have been more proactive
about explicitly seeking out a new maintainer for JDK 9 Updates.

As Dalibor notes [1] we would welcome a suitable party who wished to
step forward to maintain future 9 Updates. My reluctance to approve these
particular requests was to avoid pre-empting decisions made by that new
maintainer.

I'll send out a proposal shortly on how we can handle the maintenance of
such releases in the future.

    -Rob

[1] http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2017-November/000024.html

On 25/01/18 17:31, Andrew Haley 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.
> 
> Sure, I understand that it wasn't deliberate.  However, the
> immediate tagging and tying-off of the branch was.
> 
> > This may be something that the establishment of the vulnerabilities 
> > group will help with.
> 
> That is surely true.
> 
> > Alternatively maybe the JDK Update maintainers could just approve
> > the changes needed to get the ports aligned and leave it at that.
> 
> That would be nice.
> 
> > If someone steps up to maintain the JDK 9 updates going forward then
> > they could tag a new release that includes the changes.
> 
> Well, I could formally take over the project, but it seems a bit
> excessive.  I'll do that if it's the only way to get it done.
> 
> -- 
> Andrew Haley
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From martinrb at google.com  Thu Jan 25 18:19:53 2018
From: martinrb at google.com (Martin Buchholz)
Date: Thu, 25 Jan 2018 10:19:53 -0800
Subject: Future jdk9u updates & 9-critical-request
In-Reply-To: <509c9ac2-4663-1002-e229-ccf0743d000f@redhat.com>
References: <20180112151935.GC4779@vimes>
 <CA+kOe0_3GbH3kVm7v76txZ-2M1b8C++3_hB7VMaDQ9kDjrinZw@mail.gmail.com>
 <CAP7YuATLYgEgcgUu-QHTVD0QSYjL8h3_pKcvurvX6KY_zU4zWw@mail.gmail.com>
 <20180117150118.GA3420@vimes>
 <e485c44d-8c27-7dba-baaa-15b92bca981b@redhat.com>
 <09ea7d53-19e9-f23c-e0a6-b2155ba4d38a@oracle.com>
 <509c9ac2-4663-1002-e229-ccf0743d000f@redhat.com>
Message-ID: <CA+kOe08bex+suM2KqzZkvmxH31KP7UW+=36yytJTuk33zu=6eQ@mail.gmail.com>

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.

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
>

From rob.mckenna at oracle.com  Thu Jan 25 18:40:22 2018
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Thu, 25 Jan 2018 18:40:22 +0000
Subject: Future jdk9u updates & 9-critical-request
In-Reply-To: <CA+kOe08bex+suM2KqzZkvmxH31KP7UW+=36yytJTuk33zu=6eQ@mail.gmail.com>
References: <20180112151935.GC4779@vimes>
 <CA+kOe0_3GbH3kVm7v76txZ-2M1b8C++3_hB7VMaDQ9kDjrinZw@mail.gmail.com>
 <CAP7YuATLYgEgcgUu-QHTVD0QSYjL8h3_pKcvurvX6KY_zU4zWw@mail.gmail.com>
 <20180117150118.GA3420@vimes>
 <e485c44d-8c27-7dba-baaa-15b92bca981b@redhat.com>
 <09ea7d53-19e9-f23c-e0a6-b2155ba4d38a@oracle.com>
 <509c9ac2-4663-1002-e229-ccf0743d000f@redhat.com>
 <CA+kOe08bex+suM2KqzZkvmxH31KP7UW+=36yytJTuk33zu=6eQ@mail.gmail.com>
Message-ID: <20180125184022.GA12117@vimes>

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

From martijnverburg at gmail.com  Thu Jan 25 23:22:33 2018
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Thu, 25 Jan 2018 23:22:33 +0000
Subject: Future jdk9u updates & 9-critical-request
In-Reply-To: <20180125184022.GA12117@vimes>
References: <20180112151935.GC4779@vimes>
 <CA+kOe0_3GbH3kVm7v76txZ-2M1b8C++3_hB7VMaDQ9kDjrinZw@mail.gmail.com>
 <CAP7YuATLYgEgcgUu-QHTVD0QSYjL8h3_pKcvurvX6KY_zU4zWw@mail.gmail.com>
 <20180117150118.GA3420@vimes>
 <e485c44d-8c27-7dba-baaa-15b92bca981b@redhat.com>
 <09ea7d53-19e9-f23c-e0a6-b2155ba4d38a@oracle.com>
 <509c9ac2-4663-1002-e229-ccf0743d000f@redhat.com>
 <CA+kOe08bex+suM2KqzZkvmxH31KP7UW+=36yytJTuk33zu=6eQ@mail.gmail.com>
 <20180125184022.GA12117@vimes>
Message-ID: <CAP7YuAT3S2uHkAgZ2JXyRb7n+5LzNpSwGNZmpu+e3YU5y9LTeg@mail.gmail.com>

Hi all,

FYI - If maintainers do step up to take over 8u, 9u etc we will officially
support those ports WRT to CI infrastructure for the various ports
(including JCK testing) at AdoptOpenJDK.net.

Let me know if you?d like any further info (or drop adoption-discuss a
note).

Cheers,
Martijn



On Fri, 26 Jan 2018 at 07:41, Rob McKenna <rob.mckenna at oracle.com> wrote:

> 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
> > >
>
-- 
Cheers, Martijn (Sent from Gmail Mobile)

From aph at redhat.com  Fri Jan 26 10:03:12 2018
From: aph at redhat.com (Andrew Haley)
Date: Fri, 26 Jan 2018 10:03:12 +0000
Subject: Future jdk9u updates & 9-critical-request
In-Reply-To: <CA+kOe08bex+suM2KqzZkvmxH31KP7UW+=36yytJTuk33zu=6eQ@mail.gmail.com>
References: <20180112151935.GC4779@vimes>
 <CA+kOe0_3GbH3kVm7v76txZ-2M1b8C++3_hB7VMaDQ9kDjrinZw@mail.gmail.com>
 <CAP7YuATLYgEgcgUu-QHTVD0QSYjL8h3_pKcvurvX6KY_zU4zWw@mail.gmail.com>
 <20180117150118.GA3420@vimes>
 <e485c44d-8c27-7dba-baaa-15b92bca981b@redhat.com>
 <09ea7d53-19e9-f23c-e0a6-b2155ba4d38a@oracle.com>
 <509c9ac2-4663-1002-e229-ccf0743d000f@redhat.com>
 <CA+kOe08bex+suM2KqzZkvmxH31KP7UW+=36yytJTuk33zu=6eQ@mail.gmail.com>
Message-ID: <ff382718-4e87-c3f9-3025-77b009bcb73e@redhat.com>

On 25/01/18 18:19, Martin Buchholz wrote:
> There is enough interest in jdk9 that at least minimal community
> maintenance should be possible.

Maybe.  I have no interest in doing it because I believe that the
LTS/STS model is a good one, so the STS releases really should be short
term.  I don't mind being jdk9u lead for the ten minutes it takes to
fix the breakage and tag the tree for a release.

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

From dalibor.topic at oracle.com  Fri Jan 26 16:53:32 2018
From: dalibor.topic at oracle.com (dalibor topic)
Date: Fri, 26 Jan 2018 17:53:32 +0100
Subject: Future jdk9u updates & 9-critical-request
In-Reply-To: <20180117150118.GA3420@vimes>
References: <20180112151935.GC4779@vimes>
 <CA+kOe0_3GbH3kVm7v76txZ-2M1b8C++3_hB7VMaDQ9kDjrinZw@mail.gmail.com>
 <CAP7YuATLYgEgcgUu-QHTVD0QSYjL8h3_pKcvurvX6KY_zU4zWw@mail.gmail.com>
 <20180117150118.GA3420@vimes>
Message-ID: <5c70c96b-b8d2-f7c8-a362-a5ffd35f4709@oracle.com>

On 17.01.2018 16:01, Rob McKenna wrote:
> Work is happening on getting open build and test infrastructure together.
> (for example, the AdoptOpenJDK project mentioned by Martijn) I'm hoping to
> see progress on that front in 2018.

Indeed, the recently announced 
http://mail.openjdk.java.net/pipermail/jdk-dev/2018-January/000566.html 
is a big and very welcome step forward.

cheers,
dalibor topic

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

From dalibor.topic at oracle.com  Fri Jan 26 19:19:21 2018
From: dalibor.topic at oracle.com (dalibor topic)
Date: Fri, 26 Jan 2018 20:19:21 +0100
Subject: Future jdk9u updates & 9-critical-request
In-Reply-To: <ea1f583b-9fce-4f87-5896-8843f5b2b101@redhat.com>
References: <20180112151935.GC4779@vimes>
 <CA+kOe0_3GbH3kVm7v76txZ-2M1b8C++3_hB7VMaDQ9kDjrinZw@mail.gmail.com>
 <CAP7YuATLYgEgcgUu-QHTVD0QSYjL8h3_pKcvurvX6KY_zU4zWw@mail.gmail.com>
 <20180117150118.GA3420@vimes>
 <e485c44d-8c27-7dba-baaa-15b92bca981b@redhat.com>
 <09ea7d53-19e9-f23c-e0a6-b2155ba4d38a@oracle.com>
 <ea1f583b-9fce-4f87-5896-8843f5b2b101@redhat.com>
Message-ID: <5d7078c0-643e-8be1-9b2e-e148681e2dc3@oracle.com>

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 being said, that's not a hard requirement. So we probably could 
have a set of unreleased patches in the forest waiting for someone else 
to step to maintain the forest and release them.

But what complicates things in the interim time between the last Oracle 
planned Oracle-led update (9.0.4) and the official end of public life 
for an OpenJDK update release series led by Oracle (March 2018 for JDK 9 
Updates) is that we have simultaneous Oracle and OpenJDK releases that 
are supposed to converge, rather than diverge over time as long as they 
are led by Oracle.

So ideally, we'd have no actual [0] JDK 9 Update releases in that 
interim phase before someone else steps up once Oracle steps down, as 
the only reason to have one would be a hypothetical future Security Alert.

In that hypothetical scenario with unreleased patches lurking around in 
the forest things could become very complicated very quickly, for 
example if such patches have unforeseen side-effects on platforms that 
weren't tested at the time of their inclusion into then OpenJDK 9u forest.

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. I'm sure that it's similarly unappealing to everyone 
involved to have to deal with this kind of problems after a release as 
it is to you to have to wait on the patches fixing these regressions to 
finally make it in. I wish we had foreseen this situation earlier and 
avoided the resulting inconvenience.

cheers,
dalibor topic

[0] Tagging additional 'source code only' 'builds' of 9.0.4 rather then 
new releases might work, since I assume that these kind of post CPU 
regression fixes would typically address build failures on platforms not 
already provided on jdk.java.net.


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

From aph at redhat.com  Sat Jan 27 10:23:58 2018
From: aph at redhat.com (Andrew Haley)
Date: Sat, 27 Jan 2018 10:23:58 +0000
Subject: Future jdk9u updates & 9-critical-request
In-Reply-To: <5d7078c0-643e-8be1-9b2e-e148681e2dc3@oracle.com>
References: <20180112151935.GC4779@vimes>
 <CA+kOe0_3GbH3kVm7v76txZ-2M1b8C++3_hB7VMaDQ9kDjrinZw@mail.gmail.com>
 <CAP7YuATLYgEgcgUu-QHTVD0QSYjL8h3_pKcvurvX6KY_zU4zWw@mail.gmail.com>
 <20180117150118.GA3420@vimes>
 <e485c44d-8c27-7dba-baaa-15b92bca981b@redhat.com>
 <09ea7d53-19e9-f23c-e0a6-b2155ba4d38a@oracle.com>
 <ea1f583b-9fce-4f87-5896-8843f5b2b101@redhat.com>
 <5d7078c0-643e-8be1-9b2e-e148681e2dc3@oracle.com>
Message-ID: <a71747f8-276f-947e-93c6-fe0a71b94422@redhat.com>

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

From stuart.monteith at linaro.org  Mon Jan 29 11:25:45 2018
From: stuart.monteith at linaro.org (Stuart Monteith)
Date: Mon, 29 Jan 2018 11:25:45 +0000
Subject: Future jdk9u updates & 9-critical-request
In-Reply-To: <5c70c96b-b8d2-f7c8-a362-a5ffd35f4709@oracle.com>
References: <20180112151935.GC4779@vimes>
 <CA+kOe0_3GbH3kVm7v76txZ-2M1b8C++3_hB7VMaDQ9kDjrinZw@mail.gmail.com>
 <CAP7YuATLYgEgcgUu-QHTVD0QSYjL8h3_pKcvurvX6KY_zU4zWw@mail.gmail.com>
 <20180117150118.GA3420@vimes>
 <5c70c96b-b8d2-f7c8-a362-a5ffd35f4709@oracle.com>
Message-ID: <CAEGA6kbLVe4bTm+zOBwuoQfdKo2yEStDQCs-67BrWqC_zrZ08w@mail.gmail.com>

Hello Dalibor,
   Is it the case then that, like AdoptOpenJDK, the Submit Repo will
be building and testing on all of the OpenJDK backends? It doesn't
replace a sensible multi-platform development process, but it would
help at least flag basic omissions.

BR,
   Stuart

On 26 January 2018 at 16:53, dalibor topic <dalibor.topic at oracle.com> wrote:
> On 17.01.2018 16:01, Rob McKenna wrote:
>>
>> Work is happening on getting open build and test infrastructure together.
>> (for example, the AdoptOpenJDK project mentioned by Martijn) I'm hoping to
>> see progress on that front in 2018.
>
>
> Indeed, the recently announced
> http://mail.openjdk.java.net/pipermail/jdk-dev/2018-January/000566.html is a
> big and very welcome step forward.
>
> cheers,
> dalibor topic
>
> --
> <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

From neugens at redhat.com  Mon Jan 29 11:54:25 2018
From: neugens at redhat.com (Mario Torre)
Date: Mon, 29 Jan 2018 12:54:25 +0100
Subject: Future jdk9u updates & 9-critical-request
In-Reply-To: <5d7078c0-643e-8be1-9b2e-e148681e2dc3@oracle.com>
References: <20180112151935.GC4779@vimes>
 <CA+kOe0_3GbH3kVm7v76txZ-2M1b8C++3_hB7VMaDQ9kDjrinZw@mail.gmail.com>
 <CAP7YuATLYgEgcgUu-QHTVD0QSYjL8h3_pKcvurvX6KY_zU4zWw@mail.gmail.com>
 <20180117150118.GA3420@vimes>
 <e485c44d-8c27-7dba-baaa-15b92bca981b@redhat.com>
 <09ea7d53-19e9-f23c-e0a6-b2155ba4d38a@oracle.com>
 <ea1f583b-9fce-4f87-5896-8843f5b2b101@redhat.com>
 <5d7078c0-643e-8be1-9b2e-e148681e2dc3@oracle.com>
Message-ID: <CAJwKKmYm-hTRvgcd4+f6qsSh_MWDawQnOaUH_NhAVcX8oEi52A@mail.gmail.com>

On Fri, Jan 26, 2018 at 8:19 PM, dalibor topic <dalibor.topic at oracle.com> wrote:

> 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. I'm sure that it's similarly unappealing to everyone involved
> to have to deal with this kind of problems after a release as it is to you
> to have to wait on the patches fixing these regressions to finally make it
> in. I wish we had foreseen this situation earlier and avoided the resulting
> inconvenience.

Indeed, as others have said, no one believes that was *deliberately*
hostile, even Andrew's first email wasn't suggesting that if you read
it carefully.

This is an important topic to sort out correctly, we've been telling
people that the short term releases are high quality releases, we need
to keep them so ever after the last of their security patches is
shipped, if we live the repositories in a messed state just because we
have a new main line for development, we're sending the wrong signal.

I'm not sure either what's the right answer here, but perhaps we need
coordination to step over the project before the security is made, or
after a grace period of up to one release after the last, in other
words patches that affect the code of the repositories after the last
release drop need to be coordinated with the new maintainer to allow
for a new release if that is necessary, even if a maintainer is not
appointed. In that respect Rob original email was considered "hostile"
(sorry Rob, writing that doesn't sound right!) and not acceptable.

The security group will clearly allow all that, but as long as we
don't have it we need to find a best effort solution that works.

Cheers,
Mario

From rob.mckenna at oracle.com  Mon Jan 29 17:58:02 2018
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Mon, 29 Jan 2018 17:58:02 +0000
Subject: Future jdk9u updates & 9-critical-request
In-Reply-To: <CA+kOe0_3GbH3kVm7v76txZ-2M1b8C++3_hB7VMaDQ9kDjrinZw@mail.gmail.com>
References: <20180112151935.GC4779@vimes>
 <CA+kOe0_3GbH3kVm7v76txZ-2M1b8C++3_hB7VMaDQ9kDjrinZw@mail.gmail.com>
Message-ID: <20180129175802.GA4886@vimes>

Hi Martin,

Just a heads up to let you know these have been approved.

I'm planning to propose a new process around approvals soon which will
(hopefully) prevent a similar situation from occuring again.

    -Rob

On 12/01/18 11:37, Martin Buchholz wrote:
> Hi Rob,
> 
> On Fri, Jan 12, 2018 at 7:19 AM, Rob McKenna <rob.mckenna at oracle.com> wrote:
> 
> > Hi Martin,
> >
> > I see you've added the 9-critical-request label to several bugs lately.
> > This is just a heads up to let you know that as Oracle has no plans to
> > release further updates to JDK9 [1] then these labels will be have no
> > effect until a new project maintainer steps forward.
> >
> 
> I think I was confused by the End Of Updates being March 2018; I expected a
> last update just before End Of Updates.
> 
> I'm not sure whether we will have a new jdk9 updates maintainer step
> forward.  I'll ask around.  Some combination of folks from Google, Red Hat,
> Azul, etc might make it work.
> 
> Can I get my own personal jdk9u hosted at
> http://hg.openjdk.java.net/jdk-updates/9jdku-SOME-GOOD-NAME
> to park my backport patches even if don't commit to owning jdk9 updates?
> 
> Can we get help from Oracle to run cross-platform tests on arbitrary trees
> like jdk9u in the future (e.g. via jprt) even if Oracle itself no longer
> supports that particular tree?
> 
> 
> >     -Rob
> >
> > [1] http://mail.openjdk.java.net/pipermail/jdk-updates-dev/
> > 2017-November/000024.html
> >
> >

From gnu.andrew at redhat.com  Mon Jan 29 18:26:00 2018
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Mon, 29 Jan 2018 18:26:00 +0000
Subject: Future jdk9u updates & 9-critical-request
In-Reply-To: <5d7078c0-643e-8be1-9b2e-e148681e2dc3@oracle.com>
References: <20180112151935.GC4779@vimes>
 <CA+kOe0_3GbH3kVm7v76txZ-2M1b8C++3_hB7VMaDQ9kDjrinZw@mail.gmail.com>
 <CAP7YuATLYgEgcgUu-QHTVD0QSYjL8h3_pKcvurvX6KY_zU4zWw@mail.gmail.com>
 <20180117150118.GA3420@vimes>
 <e485c44d-8c27-7dba-baaa-15b92bca981b@redhat.com>
 <09ea7d53-19e9-f23c-e0a6-b2155ba4d38a@oracle.com>
 <ea1f583b-9fce-4f87-5896-8843f5b2b101@redhat.com>
 <5d7078c0-643e-8be1-9b2e-e148681e2dc3@oracle.com>
Message-ID: <CABi63P7eRpu36da3iuY9Bv8xch-Fsd9_yPuBFJ+0dOyOPEu1zA@mail.gmail.com>

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

From volker.simonis at gmail.com  Mon Jan 29 23:28:06 2018
From: volker.simonis at gmail.com (Volker Simonis)
Date: Tue, 30 Jan 2018 00:28:06 +0100
Subject: Future jdk9u updates & 9-critical-request
In-Reply-To: <CABi63P7eRpu36da3iuY9Bv8xch-Fsd9_yPuBFJ+0dOyOPEu1zA@mail.gmail.com>
References: <20180112151935.GC4779@vimes>
 <CA+kOe0_3GbH3kVm7v76txZ-2M1b8C++3_hB7VMaDQ9kDjrinZw@mail.gmail.com>
 <CAP7YuATLYgEgcgUu-QHTVD0QSYjL8h3_pKcvurvX6KY_zU4zWw@mail.gmail.com>
 <20180117150118.GA3420@vimes>
 <e485c44d-8c27-7dba-baaa-15b92bca981b@redhat.com>
 <09ea7d53-19e9-f23c-e0a6-b2155ba4d38a@oracle.com>
 <ea1f583b-9fce-4f87-5896-8843f5b2b101@redhat.com>
 <5d7078c0-643e-8be1-9b2e-e148681e2dc3@oracle.com>
 <CABi63P7eRpu36da3iuY9Bv8xch-Fsd9_yPuBFJ+0dOyOPEu1zA@mail.gmail.com>
Message-ID: <CA+3eh139wybdog0E=ME1U+ZNUKayDZhqUJL2RbeY+5qP4wEubw@mail.gmail.com>

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

From gnu.andrew at redhat.com  Tue Jan 30 17:41:19 2018
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Tue, 30 Jan 2018 17:41:19 +0000
Subject: Future jdk9u updates & 9-critical-request
In-Reply-To: <CA+3eh139wybdog0E=ME1U+ZNUKayDZhqUJL2RbeY+5qP4wEubw@mail.gmail.com>
References: <20180112151935.GC4779@vimes>
 <CA+kOe0_3GbH3kVm7v76txZ-2M1b8C++3_hB7VMaDQ9kDjrinZw@mail.gmail.com>
 <CAP7YuATLYgEgcgUu-QHTVD0QSYjL8h3_pKcvurvX6KY_zU4zWw@mail.gmail.com>
 <20180117150118.GA3420@vimes>
 <e485c44d-8c27-7dba-baaa-15b92bca981b@redhat.com>
 <09ea7d53-19e9-f23c-e0a6-b2155ba4d38a@oracle.com>
 <ea1f583b-9fce-4f87-5896-8843f5b2b101@redhat.com>
 <5d7078c0-643e-8be1-9b2e-e148681e2dc3@oracle.com>
 <CABi63P7eRpu36da3iuY9Bv8xch-Fsd9_yPuBFJ+0dOyOPEu1zA@mail.gmail.com>
 <CA+3eh139wybdog0E=ME1U+ZNUKayDZhqUJL2RbeY+5qP4wEubw@mail.gmail.com>
Message-ID: <CABi63P7Nng=ceR3UFruW_4oGnhTLEL+bY8kRGn38vRdW4YG-fQ@mail.gmail.com>

On 29 January 2018 at 23:28, Volker Simonis <volker.simonis at gmail.com> wrote:
> 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
>
>

Very good point, and one which is going to become a bigger issue once
we reach the first LTS release, OpenJDK 11, as that will need to be
worked on in parallel with 12 through to 16, and it's more likely that someone
else will want to maintain that version past OpenJDK 17 (i.e. > 3 years)
-- 
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

From martinrb at google.com  Tue Jan 30 23:02:43 2018
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 30 Jan 2018 15:02:43 -0800
Subject: Future jdk9u updates & 9-critical-request
In-Reply-To: <20180129175802.GA4886@vimes>
References: <20180112151935.GC4779@vimes>
 <CA+kOe0_3GbH3kVm7v76txZ-2M1b8C++3_hB7VMaDQ9kDjrinZw@mail.gmail.com>
 <20180129175802.GA4886@vimes>
Message-ID: <CA+kOe0_ye8f3p-tTsyYBSO3ojf4ZC7efTuSHJ9E6_V6NgwNntg@mail.gmail.com>

On Mon, Jan 29, 2018 at 9:58 AM, Rob McKenna <rob.mckenna at oracle.com> wrote:

> Hi Martin,
>
> Just a heads up to let you know these have been approved.
>

Thanks, Rob.

I now have a batch of changesets ready to go, but I'm unsure about
mechanics.  Do I need to Create Backport in JIRA ?  Is there a canonical
description of the backport process anywhere?

From dalibor.topic at oracle.com  Wed Jan 31 10:34:27 2018
From: dalibor.topic at oracle.com (dalibor topic)
Date: Wed, 31 Jan 2018 11:34:27 +0100
Subject: Future jdk9u updates & 9-critical-request
In-Reply-To: <CAEGA6kbLVe4bTm+zOBwuoQfdKo2yEStDQCs-67BrWqC_zrZ08w@mail.gmail.com>
References: <20180112151935.GC4779@vimes>
 <CA+kOe0_3GbH3kVm7v76txZ-2M1b8C++3_hB7VMaDQ9kDjrinZw@mail.gmail.com>
 <CAP7YuATLYgEgcgUu-QHTVD0QSYjL8h3_pKcvurvX6KY_zU4zWw@mail.gmail.com>
 <20180117150118.GA3420@vimes>
 <5c70c96b-b8d2-f7c8-a362-a5ffd35f4709@oracle.com>
 <CAEGA6kbLVe4bTm+zOBwuoQfdKo2yEStDQCs-67BrWqC_zrZ08w@mail.gmail.com>
Message-ID: <deb7f2aa-264b-f107-5d17-0d6312ca42b9@oracle.com>

On 29.01.2018 12:25, Stuart Monteith wrote:
> Hello Dalibor,
>     Is it the case then that, like AdoptOpenJDK, the Submit Repo will
> be building and testing on all of the OpenJDK backends? 

I don't think that the wiki has documentation yet on the tested backends.

I would assume that initially it'd be focused on building/testing on one 
or more of the platforms that we currently publish OpenJDK JDK 10 early 
access binaries for, i.e. 64-bit x86 Linux, etc.

cheers,
dalibor topic

> It doesn't
> replace a sensible multi-platform development process, but it would
> help at least flag basic omissions.
> 
> BR,
>     Stuart
> 
> On 26 January 2018 at 16:53, dalibor topic <dalibor.topic at oracle.com> wrote:
>> On 17.01.2018 16:01, Rob McKenna wrote:
>>>
>>> Work is happening on getting open build and test infrastructure together.
>>> (for example, the AdoptOpenJDK project mentioned by Martijn) I'm hoping to
>>> see progress on that front in 2018.
>>
>>
>> Indeed, the recently announced
>> http://mail.openjdk.java.net/pipermail/jdk-dev/2018-January/000566.html is a
>> big and very welcome step forward.
>>
>> cheers,
>> dalibor topic
>>
>> --
>> <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

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

From david.holmes at oracle.com  Wed Jan 31 10:43:26 2018
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 31 Jan 2018 20:43:26 +1000
Subject: Future jdk9u updates & 9-critical-request
In-Reply-To: <deb7f2aa-264b-f107-5d17-0d6312ca42b9@oracle.com>
References: <20180112151935.GC4779@vimes>
 <CA+kOe0_3GbH3kVm7v76txZ-2M1b8C++3_hB7VMaDQ9kDjrinZw@mail.gmail.com>
 <CAP7YuATLYgEgcgUu-QHTVD0QSYjL8h3_pKcvurvX6KY_zU4zWw@mail.gmail.com>
 <20180117150118.GA3420@vimes>
 <5c70c96b-b8d2-f7c8-a362-a5ffd35f4709@oracle.com>
 <CAEGA6kbLVe4bTm+zOBwuoQfdKo2yEStDQCs-67BrWqC_zrZ08w@mail.gmail.com>
 <deb7f2aa-264b-f107-5d17-0d6312ca42b9@oracle.com>
Message-ID: <40791ceb-e7cb-0100-b38d-5292cf4ae72e@oracle.com>

On 31/01/2018 8:34 PM, dalibor topic wrote:
> On 29.01.2018 12:25, Stuart Monteith wrote:
>> Hello Dalibor,
>> ??? Is it the case then that, like AdoptOpenJDK, the Submit Repo will
>> be building and testing on all of the OpenJDK backends? 
> 
> I don't think that the wiki has documentation yet on the tested backends.
> 
> I would assume that initially it'd be focused on building/testing on one 
> or more of the platforms that we currently publish OpenJDK JDK 10 early 
> access binaries for, i.e. 64-bit x86 Linux, etc.

 From the wiki:

"This allows non-Oracle committers to build and test on the platforms 
supported by Oracle."

So most definitely not all of the OpenJDK backends.

Cheers,
David
-----

> cheers,
> dalibor topic
> 
>> It doesn't
>> replace a sensible multi-platform development process, but it would
>> help at least flag basic omissions.
>>
>> BR,
>> ??? Stuart
>>
>> On 26 January 2018 at 16:53, dalibor topic <dalibor.topic at oracle.com> 
>> wrote:
>>> On 17.01.2018 16:01, Rob McKenna wrote:
>>>>
>>>> Work is happening on getting open build and test infrastructure 
>>>> together.
>>>> (for example, the AdoptOpenJDK project mentioned by Martijn) I'm 
>>>> hoping to
>>>> see progress on that front in 2018.
>>>
>>>
>>> Indeed, the recently announced
>>> http://mail.openjdk.java.net/pipermail/jdk-dev/2018-January/000566.html 
>>> is a
>>> big and very welcome step forward.
>>>
>>> cheers,
>>> dalibor topic
>>>
>>> -- 
>>> <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
> 

From rob.mckenna at oracle.com  Wed Jan 31 12:01:48 2018
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Wed, 31 Jan 2018 12:01:48 +0000
Subject: Future jdk9u updates & 9-critical-request
In-Reply-To: <CABi63P7eRpu36da3iuY9Bv8xch-Fsd9_yPuBFJ+0dOyOPEu1zA@mail.gmail.com>
References: <20180112151935.GC4779@vimes>
 <CA+kOe0_3GbH3kVm7v76txZ-2M1b8C++3_hB7VMaDQ9kDjrinZw@mail.gmail.com>
 <CAP7YuATLYgEgcgUu-QHTVD0QSYjL8h3_pKcvurvX6KY_zU4zWw@mail.gmail.com>
 <20180117150118.GA3420@vimes>
 <e485c44d-8c27-7dba-baaa-15b92bca981b@redhat.com>
 <09ea7d53-19e9-f23c-e0a6-b2155ba4d38a@oracle.com>
 <ea1f583b-9fce-4f87-5896-8843f5b2b101@redhat.com>
 <5d7078c0-643e-8be1-9b2e-e148681e2dc3@oracle.com>
 <CABi63P7eRpu36da3iuY9Bv8xch-Fsd9_yPuBFJ+0dOyOPEu1zA@mail.gmail.com>
Message-ID: <20180131120148.GA3738@tecra>

On 29/01/18 18:26, Andrew Hughes wrote:
> 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.

The intention here was to streamline the process. You can tell what
backports have been requested by searching for the X-critical-request label
(and its corresponding X-critical-approved) - understanding what has been
committed (as opposed to merely approved) will require checking the
repo for a changeset. (we've added a couple of links to the project page [2]
to make this more obvious)

We're certainly not averse to resurrecting the mailing-list centric approach
if the general consensus supports it however!

    -Rob

[1] https://bugs.openjdk.java.net/issues/?jql=Project%20%3D%20JDK%20and%20labels%20in%20(9-critical-request)

From rob.mckenna at oracle.com  Wed Jan 31 12:39:31 2018
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Wed, 31 Jan 2018 12:39:31 +0000
Subject: Future jdk9u updates & 9-critical-request
In-Reply-To: <CABi63P7Nng=ceR3UFruW_4oGnhTLEL+bY8kRGn38vRdW4YG-fQ@mail.gmail.com>
References: <CA+kOe0_3GbH3kVm7v76txZ-2M1b8C++3_hB7VMaDQ9kDjrinZw@mail.gmail.com>
 <CAP7YuATLYgEgcgUu-QHTVD0QSYjL8h3_pKcvurvX6KY_zU4zWw@mail.gmail.com>
 <20180117150118.GA3420@vimes>
 <e485c44d-8c27-7dba-baaa-15b92bca981b@redhat.com>
 <09ea7d53-19e9-f23c-e0a6-b2155ba4d38a@oracle.com>
 <ea1f583b-9fce-4f87-5896-8843f5b2b101@redhat.com>
 <5d7078c0-643e-8be1-9b2e-e148681e2dc3@oracle.com>
 <CABi63P7eRpu36da3iuY9Bv8xch-Fsd9_yPuBFJ+0dOyOPEu1zA@mail.gmail.com>
 <CA+3eh139wybdog0E=ME1U+ZNUKayDZhqUJL2RbeY+5qP4wEubw@mail.gmail.com>
 <CABi63P7Nng=ceR3UFruW_4oGnhTLEL+bY8kRGn38vRdW4YG-fQ@mail.gmail.com>
Message-ID: <20180131123550.GB3738@tecra>

Yep, this is something we've been thinking about. The proposal hasn't
quite been finalized but the idea is to provide a way to avoid the
heavyweight process of creating new projects for each train, instead
we would adapt the JDK8u maintainer delegation process [1] to fit the bill.
(we would have the option of forest specific co-maintainers and sub-rules)

    -Rob

[1] http://openjdk.java.net/projects/jdk8u/maintainer-template.html

On 30/01/18 17:41, Andrew Hughes wrote:
> On 29 January 2018 at 23:28, Volker Simonis <volker.simonis at gmail.com> wrote:
> > 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
> >
> >
> 
> Very good point, and one which is going to become a bigger issue once
> we reach the first LTS release, OpenJDK 11, as that will need to be
> worked on in parallel with 12 through to 16, and it's more likely that someone
> else will want to maintain that version past OpenJDK 17 (i.e. > 3 years)
> -- 
> 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

From dalibor.topic at oracle.com  Wed Jan 31 12:47:58 2018
From: dalibor.topic at oracle.com (dalibor topic)
Date: Wed, 31 Jan 2018 13:47:58 +0100
Subject: Future jdk9u updates & 9-critical-request
In-Reply-To: <a71747f8-276f-947e-93c6-fe0a71b94422@redhat.com>
References: <20180112151935.GC4779@vimes>
 <CA+kOe0_3GbH3kVm7v76txZ-2M1b8C++3_hB7VMaDQ9kDjrinZw@mail.gmail.com>
 <CAP7YuATLYgEgcgUu-QHTVD0QSYjL8h3_pKcvurvX6KY_zU4zWw@mail.gmail.com>
 <20180117150118.GA3420@vimes>
 <e485c44d-8c27-7dba-baaa-15b92bca981b@redhat.com>
 <09ea7d53-19e9-f23c-e0a6-b2155ba4d38a@oracle.com>
 <ea1f583b-9fce-4f87-5896-8843f5b2b101@redhat.com>
 <5d7078c0-643e-8be1-9b2e-e148681e2dc3@oracle.com>
 <a71747f8-276f-947e-93c6-fe0a71b94422@redhat.com>
Message-ID: <5719928e-370b-9f86-a5c6-790cad142fd5@oracle.com>

On 27.01.2018 11:23, Andrew Haley wrote:> 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.

I think part of the challenge here are that the OpenJDK 9.0.4 release 
isn't broken on the platforms it was tested with and released on:

64 bit Windows, Linux and macOS on x86 architecture.

That's two platforms more than 9.0.1 was released on, fwiw, but still a 
long shot from all the platforms that are potentially included in the 
jdk9u forest's source code.

It's worth keeping in mind that the next jdk9u maintainer, assuming 
someone qualified steps up, might decide to focus their attention on an 
entirely different set of platforms.

So I think this is an interesting conversation to have, as it would also 
put constraints on how the next set jdk9u forest maintainers would need 
to act.

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

Rather than waiting for explicit responses from everyone else, which 
tends to be cumbersome in practice, one might consider

* using the critical approval process for P1 issues as before, 
specifically for changes resolving build issues on platforms that 
weren't tested as part of the release, and then

* tagging the next build of the last released version one or two weeks 
after GA

... in the current case that would be 9.0.4+12

cheers,
dalibor topic
-- 
<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

From dalibor.topic at oracle.com  Wed Jan 31 13:04:52 2018
From: dalibor.topic at oracle.com (dalibor topic)
Date: Wed, 31 Jan 2018 14:04:52 +0100
Subject: Future jdk9u updates & 9-critical-request
In-Reply-To: <20180131120148.GA3738@tecra>
References: <20180112151935.GC4779@vimes>
 <CA+kOe0_3GbH3kVm7v76txZ-2M1b8C++3_hB7VMaDQ9kDjrinZw@mail.gmail.com>
 <CAP7YuATLYgEgcgUu-QHTVD0QSYjL8h3_pKcvurvX6KY_zU4zWw@mail.gmail.com>
 <20180117150118.GA3420@vimes>
 <e485c44d-8c27-7dba-baaa-15b92bca981b@redhat.com>
 <09ea7d53-19e9-f23c-e0a6-b2155ba4d38a@oracle.com>
 <ea1f583b-9fce-4f87-5896-8843f5b2b101@redhat.com>
 <5d7078c0-643e-8be1-9b2e-e148681e2dc3@oracle.com>
 <CABi63P7eRpu36da3iuY9Bv8xch-Fsd9_yPuBFJ+0dOyOPEu1zA@mail.gmail.com>
 <20180131120148.GA3738@tecra>
Message-ID: <8a4bddbd-997a-0a31-f8b9-2859caa529e5@oracle.com>

On 31.01.2018 13:01, Rob McKenna wrote:
> The intention here was to streamline the process. You can tell what
> backports have been requested by searching for the X-critical-request label
> (and its corresponding X-critical-approved) - understanding what has been
> committed (as opposed to merely approved) will require checking the
> repo for a changeset. (we've added a couple of links to the project page [2]
> to make this more obvious)

Yep, it's the new

Push Requests
[Requested] [Approved]

section on http://openjdk.java.net/projects/jdk-updates/ .

Speaking of which, I clicked through, but I didn't see a push approval 
request for https://bugs.openjdk.java.net/browse/JDK-8195685 there yet.

If Andrew Dinn hasn't done so already, I'd suggest starting with that 
step, per http://openjdk.java.net/projects/jdk-updates/approval.html .

I don't think that it hurts to file the request already, even though 
this thread is still ongoing.

cheers,
dalibor topic

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

From dalibor.topic at oracle.com  Wed Jan 31 13:15:53 2018
From: dalibor.topic at oracle.com (dalibor topic)
Date: Wed, 31 Jan 2018 14:15:53 +0100
Subject: Future jdk9u updates & 9-critical-request
In-Reply-To: <CA+kOe0_ye8f3p-tTsyYBSO3ojf4ZC7efTuSHJ9E6_V6NgwNntg@mail.gmail.com>
References: <20180112151935.GC4779@vimes>
 <CA+kOe0_3GbH3kVm7v76txZ-2M1b8C++3_hB7VMaDQ9kDjrinZw@mail.gmail.com>
 <20180129175802.GA4886@vimes>
 <CA+kOe0_ye8f3p-tTsyYBSO3ojf4ZC7efTuSHJ9E6_V6NgwNntg@mail.gmail.com>
Message-ID: <2898d47a-5916-d11e-af24-1e4dca34da8b@oracle.com>

On 31.01.2018 00:02, Martin Buchholz wrote:
> I now have a batch of changesets ready to go, but I'm unsure about
> mechanics.  Do I need to Create Backport in JIRA ?

No.

>  Is there a canonical
> description of the backport process anywhere?

There is http://openjdk.java.net/projects/jdk-updates/approval.html . 
Please feel free to ask specific questions as necessary.

cheers,
dalibor topic
-- 
<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

From sgehwolf at redhat.com  Wed Jan 31 13:38:37 2018
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Wed, 31 Jan 2018 14:38:37 +0100
Subject: Future jdk9u updates & 9-critical-request
In-Reply-To: <8a4bddbd-997a-0a31-f8b9-2859caa529e5@oracle.com>
References: <20180112151935.GC4779@vimes>
 <CA+kOe0_3GbH3kVm7v76txZ-2M1b8C++3_hB7VMaDQ9kDjrinZw@mail.gmail.com>
 <CAP7YuATLYgEgcgUu-QHTVD0QSYjL8h3_pKcvurvX6KY_zU4zWw@mail.gmail.com>
 <20180117150118.GA3420@vimes>
 <e485c44d-8c27-7dba-baaa-15b92bca981b@redhat.com>
 <09ea7d53-19e9-f23c-e0a6-b2155ba4d38a@oracle.com>
 <ea1f583b-9fce-4f87-5896-8843f5b2b101@redhat.com>
 <5d7078c0-643e-8be1-9b2e-e148681e2dc3@oracle.com>
 <CABi63P7eRpu36da3iuY9Bv8xch-Fsd9_yPuBFJ+0dOyOPEu1zA@mail.gmail.com>
 <20180131120148.GA3738@tecra>
 <8a4bddbd-997a-0a31-f8b9-2859caa529e5@oracle.com>
Message-ID: <1517405917.4101.33.camel@redhat.com>

On Wed, 2018-01-31 at 14:04 +0100, dalibor topic wrote:
> On 31.01.2018 13:01, Rob McKenna wrote:
> > The intention here was to streamline the process. You can tell what
> > backports have been requested by searching for the X-critical-
> > request label
> > (and its corresponding X-critical-approved) - understanding what
> > has been
> > committed (as opposed to merely approved) will require checking the
> > repo for a changeset. (we've added a couple of links to the project
> > page [2]
> > to make this more obvious)
> 
> Yep, it's the new
> 
> Push Requests
> [Requested] [Approved]
> 
> section on http://openjdk.java.net/projects/jdk-updates/ .

Note that the link for '[Requested]' uses the label 9-critical-
requested for its query. Should it use 9-critical-request as per the
example in:
http://openjdk.java.net/projects/jdk-updates/approval.html

Thanks,
Severin

From dalibor.topic at oracle.com  Wed Jan 31 14:12:12 2018
From: dalibor.topic at oracle.com (dalibor topic)
Date: Wed, 31 Jan 2018 15:12:12 +0100
Subject: Future jdk9u updates & 9-critical-request
In-Reply-To: <1517405917.4101.33.camel@redhat.com>
References: <20180112151935.GC4779@vimes>
 <CA+kOe0_3GbH3kVm7v76txZ-2M1b8C++3_hB7VMaDQ9kDjrinZw@mail.gmail.com>
 <CAP7YuATLYgEgcgUu-QHTVD0QSYjL8h3_pKcvurvX6KY_zU4zWw@mail.gmail.com>
 <20180117150118.GA3420@vimes>
 <e485c44d-8c27-7dba-baaa-15b92bca981b@redhat.com>
 <09ea7d53-19e9-f23c-e0a6-b2155ba4d38a@oracle.com>
 <ea1f583b-9fce-4f87-5896-8843f5b2b101@redhat.com>
 <5d7078c0-643e-8be1-9b2e-e148681e2dc3@oracle.com>
 <CABi63P7eRpu36da3iuY9Bv8xch-Fsd9_yPuBFJ+0dOyOPEu1zA@mail.gmail.com>
 <20180131120148.GA3738@tecra>
 <8a4bddbd-997a-0a31-f8b9-2859caa529e5@oracle.com>
 <1517405917.4101.33.camel@redhat.com>
Message-ID: <03c6aed2-520e-150e-c5e4-b331eaa9eccb@oracle.com>

On 31.01.2018 14:38, Severin Gehwolf wrote:

> Note that the link for '[Requested]' uses the label 9-critical-
> requested for its query. Should it use 9-critical-request as per the
> example in:
> http://openjdk.java.net/projects/jdk-updates/approval.html

Thanks, good catch!

I pushed the corresponding change, and the fixed URL should be displayed 
with the next refresh.

cheers,
dalibor topic

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

From dalibor.topic at oracle.com  Wed Jan 31 14:44:59 2018
From: dalibor.topic at oracle.com (dalibor topic)
Date: Wed, 31 Jan 2018 15:44:59 +0100
Subject: Future jdk9u updates & 9-critical-request
In-Reply-To: <CABi63P7eRpu36da3iuY9Bv8xch-Fsd9_yPuBFJ+0dOyOPEu1zA@mail.gmail.com>
References: <20180112151935.GC4779@vimes>
 <CA+kOe0_3GbH3kVm7v76txZ-2M1b8C++3_hB7VMaDQ9kDjrinZw@mail.gmail.com>
 <CAP7YuATLYgEgcgUu-QHTVD0QSYjL8h3_pKcvurvX6KY_zU4zWw@mail.gmail.com>
 <20180117150118.GA3420@vimes>
 <e485c44d-8c27-7dba-baaa-15b92bca981b@redhat.com>
 <09ea7d53-19e9-f23c-e0a6-b2155ba4d38a@oracle.com>
 <ea1f583b-9fce-4f87-5896-8843f5b2b101@redhat.com>
 <5d7078c0-643e-8be1-9b2e-e148681e2dc3@oracle.com>
 <CABi63P7eRpu36da3iuY9Bv8xch-Fsd9_yPuBFJ+0dOyOPEu1zA@mail.gmail.com>
Message-ID: <0c921032-d70c-91eb-8cb5-c559d1d51d73@oracle.com>

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

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.

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.

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

From martinrb at google.com  Wed Jan 31 23:30:23 2018
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 31 Jan 2018 15:30:23 -0800
Subject: Future jdk9u updates & 9-critical-request
In-Reply-To: <2898d47a-5916-d11e-af24-1e4dca34da8b@oracle.com>
References: <20180112151935.GC4779@vimes>
 <CA+kOe0_3GbH3kVm7v76txZ-2M1b8C++3_hB7VMaDQ9kDjrinZw@mail.gmail.com>
 <20180129175802.GA4886@vimes>
 <CA+kOe0_ye8f3p-tTsyYBSO3ojf4ZC7efTuSHJ9E6_V6NgwNntg@mail.gmail.com>
 <2898d47a-5916-d11e-af24-1e4dca34da8b@oracle.com>
Message-ID: <CA+kOe0-OyRrVLLsK0xNg5sCGGffDdk3OH=bugXaH2T85pUBQsQ@mail.gmail.com>

My batch of patches has been pushed to jdk-updates/jdk9u/jdk

On Wed, Jan 31, 2018 at 5:15 AM, dalibor topic <dalibor.topic at oracle.com>
wrote:

> On 31.01.2018 00:02, Martin Buchholz wrote:
>
>> I now have a batch of changesets ready to go, but I'm unsure about
>> mechanics.  Do I need to Create Backport in JIRA ?
>>
>
> No.
>
>  Is there a canonical
>> description of the backport process anywhere?
>>
>
> There is http://openjdk.java.net/projects/jdk-updates/approval.html .
> Please feel free to ask specific questions as necessary.
>
>
> cheers,
> dalibor topic
> --
> <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 | 2276
> <https://maps.google.com/?q=Co.+KG+%7C+K%C3%BChneh%C3%B6fe+5+%7C+2276&entry=gmail&source=g>1
> Hamburg
>
> ORACLE Deutschland B.V. & Co. KG
> Hauptverwaltung: Riesstr. 25
> <https://maps.google.com/?q=waltung:+Riesstr.+25&entry=gmail&source=g>,
> 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
>

From martinrb at google.com  Wed Jan 31 23:47:19 2018
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 31 Jan 2018 15:47:19 -0800
Subject: Future jdk9u updates & 9-critical-request
In-Reply-To: <CA+kOe0-OyRrVLLsK0xNg5sCGGffDdk3OH=bugXaH2T85pUBQsQ@mail.gmail.com>
References: <20180112151935.GC4779@vimes>
 <CA+kOe0_3GbH3kVm7v76txZ-2M1b8C++3_hB7VMaDQ9kDjrinZw@mail.gmail.com>
 <20180129175802.GA4886@vimes>
 <CA+kOe0_ye8f3p-tTsyYBSO3ojf4ZC7efTuSHJ9E6_V6NgwNntg@mail.gmail.com>
 <2898d47a-5916-d11e-af24-1e4dca34da8b@oracle.com>
 <CA+kOe0-OyRrVLLsK0xNg5sCGGffDdk3OH=bugXaH2T85pUBQsQ@mail.gmail.com>
Message-ID: <CA+kOe087LTLKtyCLgDw-QuCkFCfqDGvbVBnLNbwC-3c6BEU_uA@mail.gmail.com>

Some automated process marked my backports as "Fixed in 9.0.6" which was
surprising.
Some of us expected the sequence
9   9.0.1   9.0.2   9.0.3
but on seeing 9.0.4 we expected the subsequent one to be 9.0.7.

On Wed, Jan 31, 2018 at 3:30 PM, Martin Buchholz <martinrb at google.com>
wrote:

> My batch of patches has been pushed to jdk-updates/jdk9u/jdk
>