From rwestrel at redhat.com  Fri Feb  1 13:56:29 2019
From: rwestrel at redhat.com (Roland Westrelin)
Date: Fri, 01 Feb 2019 14:56:29 +0100
Subject: [11u] RFR(M): 8214206: Fix for JDK-8213419 is broken on 32-bit
Message-ID: <87ef8r394i.fsf@redhat.com>


I'd like to backport this fix to 11u but the patch doesn't apply cleanly
some I'm requesting a new review.

http://cr.openjdk.java.net/~roland/8214206.11u/webrev.00/

jdk 12 fix:
https://bugs.openjdk.java.net/browse/JDK-8214206
http://hg.openjdk.java.net/jdk/jdk/rev/7d3cde494494

Roland.

From tobias.hartmann at oracle.com  Wed Feb  6 09:23:57 2019
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Wed, 6 Feb 2019 10:23:57 +0100
Subject: [11u] RFR(M): 8214206: Fix for JDK-8213419 is broken on 32-bit
In-Reply-To: <87ef8r394i.fsf@redhat.com>
References: <87ef8r394i.fsf@redhat.com>
Message-ID: <d6cb3852-43e9-ae8f-4e31-4fe31f8aa9f1@oracle.com>

Hi Roland,

looks good to me.

Best regards,
Tobias

On 01.02.19 14:56, Roland Westrelin wrote:
> 
> I'd like to backport this fix to 11u but the patch doesn't apply cleanly
> some I'm requesting a new review.
> 
> http://cr.openjdk.java.net/~roland/8214206.11u/webrev.00/
> 
> jdk 12 fix:
> https://bugs.openjdk.java.net/browse/JDK-8214206
> http://hg.openjdk.java.net/jdk/jdk/rev/7d3cde494494
> 
> Roland.
> 

From rwestrel at redhat.com  Wed Feb  6 12:43:56 2019
From: rwestrel at redhat.com (Roland Westrelin)
Date: Wed, 06 Feb 2019 13:43:56 +0100
Subject: [11u] RFR(M): 8214206: Fix for JDK-8213419 is broken on 32-bit
In-Reply-To: <d6cb3852-43e9-ae8f-4e31-4fe31f8aa9f1@oracle.com>
References: <87ef8r394i.fsf@redhat.com>
 <d6cb3852-43e9-ae8f-4e31-4fe31f8aa9f1@oracle.com>
Message-ID: <87tvhh13zn.fsf@redhat.com>


Thanks for the review, Tobias.

Roland.

From shade at redhat.com  Thu Feb  7 11:01:52 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 7 Feb 2019 12:01:52 +0100
Subject: jdk11u and -oracle versions
Message-ID: <2b5483e4-e582-521c-6c8e-480f244a31d7@redhat.com>

Look at this issue:
  https://bugs.openjdk.java.net/browse/JDK-8204142

It has jdk11u-fix-request and jdk11u-fix-yes labels. And it has backport that mentions
11.0.3-oracle. And there are *no* relevant changesets in jdk-updates/jdk11u:
  http://hg.openjdk.java.net/jdk-updates/jdk11u/log?rev=8204142

I have a few questions at this point:
 a) What is 11.0.3-oracle, and why indeed it is in openjdk bug tracker?
 b) Where is the pushed changeset? Is it in some Oracle-private tree? I assumed jdk*u-fix* tags are
for openjdk repositories, so issues have to be pushed to openjdk repositories, not some Oracle
internal repo?

Thanks,
-Aleksey

From volker.simonis at gmail.com  Thu Feb  7 17:10:17 2019
From: volker.simonis at gmail.com (Volker Simonis)
Date: Thu, 7 Feb 2019 18:10:17 +0100
Subject: jdk11u and -oracle versions
In-Reply-To: <2b5483e4-e582-521c-6c8e-480f244a31d7@redhat.com>
References: <2b5483e4-e582-521c-6c8e-480f244a31d7@redhat.com>
Message-ID: <CA+3eh12B939fbjLL_1JoH7--=KxshhZHDnYR8aShc95gOvSkbw@mail.gmail.com>

Hi Aleksey,

we've partially covered these topics at the Committers Workshop, but I
agree that we haven't come to a universal solution yet :)

On Thu, Feb 7, 2019 at 12:02 PM Aleksey Shipilev <shade at redhat.com> wrote:
>
> Look at this issue:
>   https://bugs.openjdk.java.net/browse/JDK-8204142
>
> It has jdk11u-fix-request and jdk11u-fix-yes labels. And it has backport that mentions
> 11.0.3-oracle. And there are *no* relevant changesets in jdk-updates/jdk11u:
>   http://hg.openjdk.java.net/jdk-updates/jdk11u/log?rev=8204142
>
> I have a few questions at this point:
>  a) What is 11.0.3-oracle, and why indeed it is in openjdk bug tracker?

"11.0.3-oracle" is an Oracle-internal repository which we won't see. I
think it is OK if Oracle uses JBS for both. OpenJDK and Oracle JDK
releases (after all, it's their bug system :) In the end it can even
help the community to see what Oracle will downport into their
commercial update releases.

I had a short chat with Andrew H. regarding this topic. I proposed to
"automatically" downport all the changes which Oracle downports to
their closed updated releases. "Automatically" is a little misleading
in this context because it would surely require manual interaction of
the corresponding update maintainer (which we don't have for 11u yet).
It is "automatic" in the sense that, until now, we can see what Oracle
is downporting (at least for non-closed bugs).

The thing with the "jdk11u-fix-yes" label is a little confusing
though. I suppose Oracle was (or maybe still is) using it for their
own, closed downports but if I remember right, somebody from Oracle
mentioned at FOSDEM that they already have (or will have) a special,
"jdk11uoracle-fix-yes" label in the future. Maybe somebody from Oracle
can comment on this topic?

In the end, I think it is good, if Oracle will stay transparent in JBS
with regards to update releases. In an ideal world, we could then take
over all their downports in the same way as they could take all the
community downports. This would keep the Oracle and OpenJDK update
releases in sync feature-wise which would be definitely nice for the
Java community.

Regards,
Volker

>  b) Where is the pushed changeset? Is it in some Oracle-private tree? I assumed jdk*u-fix* tags are
> for openjdk repositories, so issues have to be pushed to openjdk repositories, not some Oracle
> internal repo?
>
> Thanks,
> -Aleksey

From iris.clark at oracle.com  Thu Feb  7 17:34:07 2019
From: iris.clark at oracle.com (Iris Clark)
Date: Thu, 7 Feb 2019 17:34:07 +0000 (UTC)
Subject: Maintenance Draft Reviews for Java SE 8 (JSR 337) and Java SE 11 (JSR
 384) posted to jcp.org
Message-ID: <ecd1c556-87ac-4d42-ba23-be1af7048e22@default>

The Maintenance Draft Review [0] contents for the Java SE 8 (JSR 337) and
Java SE 11 (JSR 384) Platforms were posted to jcp.org on 5 February 2019 [1,2].
The contents correspond to the updates outlined in the announcement [3,4] of
our intention to conduct the Review.  The Review ends on 7 March 2019 with the
Ballot running from 12-18 March 2019.

Assuming that the Maintenance Review Ballot succeeds, Oracle will produce
Maintenance Releases [5] of JSR 337 and JSR 384 in late March 2019.

Thanks,
iris

[0] https://jcp.org/en/procedures/jcp2#3.6.2
[1] https://jcp.org/en/jsr/detail?id=337
[2] https://jcp.org/en/jsr/detail?id=384
[3] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2018-December/008324.html
[4] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2018-December/000308.html
[5] https://jcp.org/en/procedures/jcp2#3.6.4

From aph at redhat.com  Thu Feb  7 18:03:06 2019
From: aph at redhat.com (Andrew Haley)
Date: Thu, 7 Feb 2019 18:03:06 +0000
Subject: jdk11u and -oracle versions
In-Reply-To: <CA+3eh12B939fbjLL_1JoH7--=KxshhZHDnYR8aShc95gOvSkbw@mail.gmail.com>
References: <2b5483e4-e582-521c-6c8e-480f244a31d7@redhat.com>
 <CA+3eh12B939fbjLL_1JoH7--=KxshhZHDnYR8aShc95gOvSkbw@mail.gmail.com>
Message-ID: <166d154d-b015-2646-80a7-9e0859d511cf@redhat.com>

On 2/7/19 5:10 PM, Volker Simonis wrote:
> In the end, I think it is good, if Oracle will stay transparent in JBS
> with regards to update releases. In an ideal world, we could then take
> over all their downports in the same way as they could take all the
> community downports. This would keep the Oracle and OpenJDK update
> releases in sync feature-wise which would be definitely nice for the
> Java community.

I agree with all of this. Thanks you.

-- 
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 aph at redhat.com  Thu Feb  7 18:10:24 2019
From: aph at redhat.com (Andrew Haley)
Date: Thu, 7 Feb 2019 18:10:24 +0000
Subject: [11u-communication] Call for new lead maintainer
In-Reply-To: <20190130183324.GH27761@vimes>
References: <20190130183324.GH27761@vimes>
Message-ID: <7907ed59-a9ba-6aa8-35ba-88fe8a03d673@redhat.com>

On 1/30/19 6:33 PM, Rob McKenna wrote:
> To help transition the jdk11u repository[0] to a new set of
> maintainers, I'd like to invite JDK Updates Project Committers
> and Reviewers who are not currently employed by Oracle to nominate
> themselves for the position of lead maintainer by replying to this
> mail.

Thank you. This is essentially the same message that I sent in reply
to the jdk8u maintainership:

I am willing to perform that role. I lead the OpenJDK 7 (and 8!)
projects and have in the past led OpenJDK 6u and the AArch64 port. I
have personally contributed 145 patches to OpenJDK, in many areas but
mostly HotSpot. I wrote a substantial chunk of the AArch64 port. I am
a community representative on the OpenJDK Governing Board, and have
been since its inception.

Perhaps most importantly, I have the Java Platform group at Red Hat --
a team of about twenty engineers -- supporting me. I couldn't do it
without them.

With regard to future plans, my Rule 0 is "first, do no harm": OpenJDK
11 is an increasingly important part of many organization's
infrastructure, and we must not break it. I don't imagine that there
will be many major feature backports, but I won't forbid them
altogether.  I don't intend to be a dictator: we should reach
consensus on such decisions.

Testing backports is going to be tricky. I've been discussing this
with several organizations including AdoptOpenJDK and Amazon Web
Services, all keen to help. We already have extensive test suites, and
we will work together to improve them.

Security is an important issue. We have a healthy OpenJDK
Vulnerability Group, and will work with them to ensure that OpenJDK 11
remains secure. Critical updates will be done quarterly, as they have
been throughout the life of OpenJDK 11.

-- 
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 christoph.langer at sap.com  Fri Feb  8 10:16:55 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 8 Feb 2019 10:16:55 +0000
Subject: jdk11u and -oracle versions
In-Reply-To: <2b5483e4-e582-521c-6c8e-480f244a31d7@redhat.com>
References: <2b5483e4-e582-521c-6c8e-480f244a31d7@redhat.com>
Message-ID: <5555d3e97f714afa802b812fb41ebb42@sap.com>

Hi,

> Look at this issue:
>   https://bugs.openjdk.java.net/browse/JDK-8204142
> 
> It has jdk11u-fix-request and jdk11u-fix-yes labels. And it has backport that
> mentions
> 11.0.3-oracle. And there are *no* relevant changesets in jdk-
> updates/jdk11u:
>   http://hg.openjdk.java.net/jdk-updates/jdk11u/log?rev=8204142
> 
> I have a few questions at this point:
>  a) What is 11.0.3-oracle, and why indeed it is in openjdk bug tracker?
>  b) Where is the pushed changeset? Is it in some Oracle-private tree? I
> assumed jdk*u-fix* tags are
> for openjdk repositories, so issues have to be pushed to openjdk
> repositories, not some Oracle
> internal repo?

FWIW: For that very bug, the jdk11u-fix-request label was set on 11/20/18 when the jdk11u-fix-request procedure still applied for Oracle. The request was approved then on 12/03/18. Afterwards I think the downport was either forgotten or Oracle's process changed. It then eventually got pushed to the 11.0.3 internal Oracle repository on 01/21/19.

As per the current rules, I guess the patch can now be pushed to jdk11u by any committer, in case it applies cleanly.

Best regards
Christoph


From shade at redhat.com  Fri Feb  8 10:54:27 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Fri, 8 Feb 2019 11:54:27 +0100
Subject: jdk11u and -oracle versions
In-Reply-To: <5555d3e97f714afa802b812fb41ebb42@sap.com>
References: <2b5483e4-e582-521c-6c8e-480f244a31d7@redhat.com>
 <5555d3e97f714afa802b812fb41ebb42@sap.com>
Message-ID: <a16e532f-8d15-823c-7559-a7a5f6b8a8b1@redhat.com>

On 2/8/19 11:16 AM, Langer, Christoph wrote:
> As per the current rules, I guess the patch can now be pushed to jdk11u by any committer, in case
> it applies cleanly.

I think I would do that, after talking to Martin (original submitter).

-Aleksey


From rob.mckenna at oracle.com  Mon Feb 11 14:39:27 2019
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Mon, 11 Feb 2019 14:39:27 +0000
Subject: jdk11u and -oracle versions
In-Reply-To: <5555d3e97f714afa802b812fb41ebb42@sap.com>
References: <2b5483e4-e582-521c-6c8e-480f244a31d7@redhat.com>
 <5555d3e97f714afa802b812fb41ebb42@sap.com>
Message-ID: <20190211143927.GA5290@vimes>

Hi folks,

On 08/02/19 10:16, Langer, Christoph wrote:
> Hi,
> 
> > Look at this issue:
> >   https://bugs.openjdk.java.net/browse/JDK-8204142
> > 
> > It has jdk11u-fix-request and jdk11u-fix-yes labels. And it has backport that
> > mentions
> > 11.0.3-oracle. And there are *no* relevant changesets in jdk-
> > updates/jdk11u:
> >   http://hg.openjdk.java.net/jdk-updates/jdk11u/log?rev=8204142
> > 

Thanks for pointing this out. The openjdk fix request was added
erroneously and was not required. I've removed those labels to make it
clear that this is not being actively ported to jdk11u.

> > I have a few questions at this point:
> >  a) What is 11.0.3-oracle, and why indeed it is in openjdk bug tracker?

11.0.3-oracle represents an Oracle JDK release and is entirely separate
from OpenJDK. (other examples include recent releses of JDK6 & 7, such
as 7u201)

The backports in the jdk11u repository use 11.0.3, following the convention
from JEPs 223 and 322.

> >  b) Where is the pushed changeset? Is it in some Oracle-private tree? I
> > assumed jdk*u-fix* tags are
> > for openjdk repositories, so issues have to be pushed to openjdk
> > repositories, not some Oracle
> > internal repo?

Yes, this fix is planned for Oracle JDK 11.0.3. If you also backport it
to OpenJDK 11.0.3, it would additionally have a fixVersion of 11.0.3.

> 
> FWIW: For that very bug, the jdk11u-fix-request label was set on 11/20/18 when the jdk11u-fix-request procedure still applied for Oracle. The request was approved then on 12/03/18. Afterwards I think the downport was either forgotten or Oracle's process changed. It then eventually got pushed to the 11.0.3 internal Oracle repository on 01/21/19.
> 
> As per the current rules, I guess the patch can now be pushed to jdk11u by any committer, in case it applies cleanly.

True! I've removed the labels just to avoid the impression that it is
actively being worked, but as soon as someone wants to tackle it I'll be
ready to approve a new request.

    -Rob

> 
> Best regards
> Christoph
> 

From rob.mckenna at oracle.com  Mon Feb 11 14:45:20 2019
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Mon, 11 Feb 2019 14:45:20 +0000
Subject: jdk11u and -oracle versions
In-Reply-To: <CA+3eh12B939fbjLL_1JoH7--=KxshhZHDnYR8aShc95gOvSkbw@mail.gmail.com>
References: <2b5483e4-e582-521c-6c8e-480f244a31d7@redhat.com>
 <CA+3eh12B939fbjLL_1JoH7--=KxshhZHDnYR8aShc95gOvSkbw@mail.gmail.com>
Message-ID: <20190211144520.GB5290@vimes>

On 07/02/19 18:10, Volker Simonis wrote:
> Hi Aleksey,
> 
> we've partially covered these topics at the Committers Workshop, but I
> agree that we haven't come to a universal solution yet :)
> 
> On Thu, Feb 7, 2019 at 12:02 PM Aleksey Shipilev <shade at redhat.com> wrote:
> >
> > Look at this issue:
> >   https://bugs.openjdk.java.net/browse/JDK-8204142
> >
> > It has jdk11u-fix-request and jdk11u-fix-yes labels. And it has backport that mentions
> > 11.0.3-oracle. And there are *no* relevant changesets in jdk-updates/jdk11u:
> >   http://hg.openjdk.java.net/jdk-updates/jdk11u/log?rev=8204142
> >
> > I have a few questions at this point:
> >  a) What is 11.0.3-oracle, and why indeed it is in openjdk bug tracker?
> 
> "11.0.3-oracle" is an Oracle-internal repository which we won't see. I
> think it is OK if Oracle uses JBS for both. OpenJDK and Oracle JDK
> releases (after all, it's their bug system :) In the end it can even
> help the community to see what Oracle will downport into their
> commercial update releases.
> 
> I had a short chat with Andrew H. regarding this topic. I proposed to
> "automatically" downport all the changes which Oracle downports to
> their closed updated releases. "Automatically" is a little misleading
> in this context because it would surely require manual interaction of
> the corresponding update maintainer (which we don't have for 11u yet).
> It is "automatic" in the sense that, until now, we can see what Oracle
> is downporting (at least for non-closed bugs).
> 
> The thing with the "jdk11u-fix-yes" label is a little confusing
> though. I suppose Oracle was (or maybe still is) using it for their
> own, closed downports but if I remember right, somebody from Oracle
> mentioned at FOSDEM that they already have (or will have) a special,
> "jdk11uoracle-fix-yes" label in the future. Maybe somebody from Oracle
> can comment on this topic?

jdk11u-fix-request/yes is exclusively used by OpenJDK!

    -Rob

> 
> In the end, I think it is good, if Oracle will stay transparent in JBS
> with regards to update releases. In an ideal world, we could then take
> over all their downports in the same way as they could take all the
> community downports. This would keep the Oracle and OpenJDK update
> releases in sync feature-wise which would be definitely nice for the
> Java community.
> 
> Regards,
> Volker
> 
> >  b) Where is the pushed changeset? Is it in some Oracle-private tree? I assumed jdk*u-fix* tags are
> > for openjdk repositories, so issues have to be pushed to openjdk repositories, not some Oracle
> > internal repo?
> >
> > Thanks,
> > -Aleksey

From shade at redhat.com  Mon Feb 11 15:18:32 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 11 Feb 2019 16:18:32 +0100
Subject: jdk11u and -oracle versions
In-Reply-To: <20190211143927.GA5290@vimes>
References: <2b5483e4-e582-521c-6c8e-480f244a31d7@redhat.com>
 <5555d3e97f714afa802b812fb41ebb42@sap.com> <20190211143927.GA5290@vimes>
Message-ID: <4c1ca906-cc01-8a1a-6414-9979a88ade1c@redhat.com>

On 2/11/19 3:39 PM, Rob McKenna wrote:
>> FWIW: For that very bug, the jdk11u-fix-request label was set on 11/20/18 when the
>> jdk11u-fix-request procedure still applied for Oracle. The request was approved then on
>> 12/03/18. Afterwards I think the downport was either forgotten or Oracle's process changed. It
>> then eventually got pushed to the 11.0.3 internal Oracle repository on 01/21/19.
>> 
>> As per the current rules, I guess the patch can now be pushed to jdk11u by any committer, in
>> case it applies cleanly.
> 
> True! I've removed the labels just to avoid the impression that it is actively being worked, but
> as soon as someone wants to tackle it I'll be ready to approve a new request.

I talked to Martin (the original submitter), we have re-tested it for jdk-updates/jdk11u, and I
pushed the fix to 11.0.3 a few hours ago, before tags were removed:
  https://bugs.openjdk.java.net/browse/JDK-8218741

You can reinstate the tags back, I think?

-Aleksey



From martinrb at google.com  Mon Feb 11 16:06:46 2019
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 11 Feb 2019 08:06:46 -0800
Subject: jdk11u and -oracle versions
In-Reply-To: <4c1ca906-cc01-8a1a-6414-9979a88ade1c@redhat.com>
References: <2b5483e4-e582-521c-6c8e-480f244a31d7@redhat.com>
 <5555d3e97f714afa802b812fb41ebb42@sap.com> <20190211143927.GA5290@vimes>
 <4c1ca906-cc01-8a1a-6414-9979a88ade1c@redhat.com>
Message-ID: <CA+kOe0-uDuWi-Jz-jku-k3E097_Zt-vmMmSA9+a=UPn5hnv9AA@mail.gmail.com>

Consider having a jdk-updates policy that if there exists a backport to
Oracle JDK N then the corresponding backport to OpenJDK N is automatically
pre-approved.

On Mon, Feb 11, 2019 at 7:19 AM Aleksey Shipilev <shade at redhat.com> wrote:

> On 2/11/19 3:39 PM, Rob McKenna wrote:
> >> FWIW: For that very bug, the jdk11u-fix-request label was set on
> 11/20/18 when the
> >> jdk11u-fix-request procedure still applied for Oracle. The request was
> approved then on
> >> 12/03/18. Afterwards I think the downport was either forgotten or
> Oracle's process changed. It
> >> then eventually got pushed to the 11.0.3 internal Oracle repository on
> 01/21/19.
> >>
> >> As per the current rules, I guess the patch can now be pushed to jdk11u
> by any committer, in
> >> case it applies cleanly.
> >
> > True! I've removed the labels just to avoid the impression that it is
> actively being worked, but
> > as soon as someone wants to tackle it I'll be ready to approve a new
> request.
>
> I talked to Martin (the original submitter), we have re-tested it for
> jdk-updates/jdk11u, and I
> pushed the fix to 11.0.3 a few hours ago, before tags were removed:
>   https://bugs.openjdk.java.net/browse/JDK-8218741
>
> You can reinstate the tags back, I think?
>
> -Aleksey
>
>
>

From rob.mckenna at oracle.com  Mon Feb 11 16:35:41 2019
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Mon, 11 Feb 2019 16:35:41 +0000
Subject: jdk11u and -oracle versions
In-Reply-To: <4c1ca906-cc01-8a1a-6414-9979a88ade1c@redhat.com>
References: <2b5483e4-e582-521c-6c8e-480f244a31d7@redhat.com>
 <5555d3e97f714afa802b812fb41ebb42@sap.com>
 <20190211143927.GA5290@vimes>
 <4c1ca906-cc01-8a1a-6414-9979a88ade1c@redhat.com>
Message-ID: <20190211163541.GC5290@vimes>

I can! Thanks Aleksey. My mistake.

    -Rob

On 11/02/19 16:18, Aleksey Shipilev wrote:
> On 2/11/19 3:39 PM, Rob McKenna wrote:
> >> FWIW: For that very bug, the jdk11u-fix-request label was set on 11/20/18 when the
> >> jdk11u-fix-request procedure still applied for Oracle. The request was approved then on
> >> 12/03/18. Afterwards I think the downport was either forgotten or Oracle's process changed. It
> >> then eventually got pushed to the 11.0.3 internal Oracle repository on 01/21/19.
> >> 
> >> As per the current rules, I guess the patch can now be pushed to jdk11u by any committer, in
> >> case it applies cleanly.
> > 
> > True! I've removed the labels just to avoid the impression that it is actively being worked, but
> > as soon as someone wants to tackle it I'll be ready to approve a new request.
> 
> I talked to Martin (the original submitter), we have re-tested it for jdk-updates/jdk11u, and I
> pushed the fix to 11.0.3 a few hours ago, before tags were removed:
>   https://bugs.openjdk.java.net/browse/JDK-8218741
> 
> You can reinstate the tags back, I think?
> 
> -Aleksey
> 
> 




From shade at redhat.com  Mon Feb 11 16:41:01 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 11 Feb 2019 17:41:01 +0100
Subject: jdk11u and -oracle versions
In-Reply-To: <20190211163541.GC5290@vimes>
References: <2b5483e4-e582-521c-6c8e-480f244a31d7@redhat.com>
 <5555d3e97f714afa802b812fb41ebb42@sap.com> <20190211143927.GA5290@vimes>
 <4c1ca906-cc01-8a1a-6414-9979a88ade1c@redhat.com>
 <20190211163541.GC5290@vimes>
Message-ID: <d6b55ed6-f4a8-b095-d933-dbc7184bd4bb@redhat.com>

On 2/11/19 5:35 PM, Rob McKenna wrote:
> I can! Thanks Aleksey. My mistake.

No problem!

Thanks for explaining how we ended up here. I agree that 11.0.3-oracle backports are okay to have in
JBS, as long as jdk11u-fix-request process is not used to create them. Otherwise it would trip our
current backport tracking, and would be problematic after 11u maintainership takeover.

-Aleksey


From christoph.langer at sap.com  Mon Feb 11 19:10:58 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 11 Feb 2019 19:10:58 +0000
Subject: JDK 11.0.3 Update process
Message-ID: <c7027fa19a28408e83461360f3ce6974@sap.com>

Hello Andrew, all,

while we know that the jdk11 updates project is in the phase of transitioning to its new maintainers and this will take a little while to settle down, the next quarterly update JDK 11.0.3, scheduled for April, is in the process of ramping up.

When discussing the JDK update process today in our team at SAP, we found a few questions open which we think need to be answered soon.

One question is, whether changes brought into the jdk11u repo as of today will still target for 11.0.3? I assume that's the case as no communication has been made telling otherwise. Can you confirm this? Furthermore, if that's true, when will be the cutoff point? Or will we maybe pick a certain change in the jdk11u repo that is known as of today to be the base for 11.0.3?

Furthermore, can we assume a new open consolidation repository will be created on hg.openjdk.java.net where update release ramp up for OpenJDK 11 updates will take place?

Any comments are welcome.

Thanks
Christoph


From rob.mckenna at oracle.com  Tue Feb 12 00:09:37 2019
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Tue, 12 Feb 2019 00:09:37 +0000
Subject: [11u-communication] CFV: 11u lead maintainer nomination for Andrew
 Haley
Message-ID: <20190212000937.GE5290@vimes>

As the Project Lead, I would like to ask for your vote for the
nomination [0] of Andrew Haley as future lead maintainer.

Votes are due by the 18th of February.

Only current JDK Updates Committers [1] are eligible to vote
on this nomination.  Votes must be cast in the open by replying
"Vote: yes" to this mail.

For Lazy Consensus voting instructions, see [2].

  -Rob

[0] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-February/000379.html
[1] http://openjdk.java.net/census
[2] http://openjdk.java.net/bylaws#lazy-consensus


From ivan.gerasimov at oracle.com  Tue Feb 12 00:12:31 2019
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Mon, 11 Feb 2019 16:12:31 -0800
Subject: [11u-communication] CFV: 11u lead maintainer nomination for
 Andrew Haley
In-Reply-To: <20190212000937.GE5290@vimes>
References: <20190212000937.GE5290@vimes>
Message-ID: <46a5b59f-9f28-2358-f79a-c7cdb8c11265@oracle.com>

Vote: yes

On 2/11/19 4:09 PM, Rob McKenna wrote:
> As the Project Lead, I would like to ask for your vote for the
> nomination [0] of Andrew Haley as future lead maintainer.
>
> Votes are due by the 18th of February.
>
> Only current JDK Updates Committers [1] are eligible to vote
> on this nomination.  Votes must be cast in the open by replying
> "Vote: yes" to this mail.
>
> For Lazy Consensus voting instructions, see [2].
>
>    -Rob
>
> [0] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-February/000379.html
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/bylaws#lazy-consensus
>
>
-- 
With kind regards,
Ivan Gerasimov


From serguei.spitsyn at oracle.com  Tue Feb 12 00:33:02 2019
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Mon, 11 Feb 2019 16:33:02 -0800
Subject: [11u-communication] CFV: 11u lead maintainer nomination for
 Andrew Haley
In-Reply-To: <20190212000937.GE5290@vimes>
References: <20190212000937.GE5290@vimes>
Message-ID: <de84df74-1bb1-ca6f-3931-5799e68317d4@oracle.com>

Vote: yes


From david.holmes at oracle.com  Tue Feb 12 00:47:47 2019
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 12 Feb 2019 10:47:47 +1000
Subject: [11u-communication] CFV: 11u lead maintainer nomination for
 Andrew Haley
In-Reply-To: <20190212000937.GE5290@vimes>
References: <20190212000937.GE5290@vimes>
Message-ID: <4aeb4cea-8c82-c660-2ba3-318523c7cbd5@oracle.com>

Vote: yes

David

On 12/02/2019 10:09 am, Rob McKenna wrote:
> As the Project Lead, I would like to ask for your vote for the
> nomination [0] of Andrew Haley as future lead maintainer.
> 
> Votes are due by the 18th of February.
> 
> Only current JDK Updates Committers [1] are eligible to vote
> on this nomination.  Votes must be cast in the open by replying
> "Vote: yes" to this mail.
> 
> For Lazy Consensus voting instructions, see [2].
> 
>    -Rob
> 
> [0] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-February/000379.html
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/bylaws#lazy-consensus
> 

From zgu at redhat.com  Tue Feb 12 00:50:52 2019
From: zgu at redhat.com (zgu at redhat.com)
Date: Mon, 11 Feb 2019 19:50:52 -0500
Subject: [11u-communication] CFV: 11u lead maintainer nomination for
 Andrew Haley
In-Reply-To: <20190212000937.GE5290@vimes>
References: <20190212000937.GE5290@vimes>
Message-ID: <1549932652.20944.22.camel@redhat.com>

Vote: yes

-Zhengyu

On Tue, 2019-02-12 at 00:09 +0000, Rob McKenna wrote:
> As the Project Lead, I would like to ask for your vote for the
> nomination [0] of Andrew Haley as future lead maintainer.
> 
> Votes are due by the 18th of February.
> 
> Only current JDK Updates Committers [1] are eligible to vote
> on this nomination.  Votes must be cast in the open by replying
> "Vote: yes" to this mail.
> 
> For Lazy Consensus voting instructions, see [2].
> 
>   -Rob
> 
> [0] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-Febr
> uary/000379.html
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/bylaws#lazy-consensus
> 

From martinrb at google.com  Tue Feb 12 02:58:02 2019
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 11 Feb 2019 18:58:02 -0800
Subject: [11u-communication] CFV: 11u lead maintainer nomination for
 Andrew Haley
In-Reply-To: <20190212000937.GE5290@vimes>
References: <20190212000937.GE5290@vimes>
Message-ID: <CA+kOe0_5Z73ro1iqDx2==GFNn_4Yo2b5QaakMAB5jRN=8aDWVw@mail.gmail.com>

Vote: yes

From christoph.langer at sap.com  Tue Feb 12 07:20:30 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 12 Feb 2019 07:20:30 +0000
Subject: [11u-communication] CFV: 11u lead maintainer nomination for
 Andrew Haley
In-Reply-To: <20190212000937.GE5290@vimes>
References: <20190212000937.GE5290@vimes>
Message-ID: <5f254916ff48438aac6128e75916b246@sap.com>

Vote:yes

> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> Behalf Of Rob McKenna
> Sent: Dienstag, 12. Februar 2019 01:10
> To: jdk-updates-dev at openjdk.java.net
> Subject: [11u-communication] CFV: 11u lead maintainer nomination for
> Andrew Haley
> 
> As the Project Lead, I would like to ask for your vote for the
> nomination [0] of Andrew Haley as future lead maintainer.
> 
> Votes are due by the 18th of February.
> 
> Only current JDK Updates Committers [1] are eligible to vote
> on this nomination.  Votes must be cast in the open by replying
> "Vote: yes" to this mail.
> 
> For Lazy Consensus voting instructions, see [2].
> 
>   -Rob
> 
> [0] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-
> February/000379.html
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/bylaws#lazy-consensus


From goetz.lindenmaier at sap.com  Tue Feb 12 07:52:23 2019
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Tue, 12 Feb 2019 07:52:23 +0000
Subject: [11u-communication] CFV: 11u lead maintainer nomination for
 Andrew Haley
In-Reply-To: <20190212000937.GE5290@vimes>
References: <20190212000937.GE5290@vimes>
Message-ID: <114ae5858286436d8004518de0c91cb1@sap.com>

vote: yes

Best regards,
  Goetz

> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> Behalf Of Rob McKenna
> Sent: Dienstag, 12. Februar 2019 01:10
> To: jdk-updates-dev at openjdk.java.net
> Subject: [11u-communication] CFV: 11u lead maintainer nomination for
> Andrew Haley
> 
> As the Project Lead, I would like to ask for your vote for the
> nomination [0] of Andrew Haley as future lead maintainer.
> 
> Votes are due by the 18th of February.
> 
> Only current JDK Updates Committers [1] are eligible to vote
> on this nomination.  Votes must be cast in the open by replying
> "Vote: yes" to this mail.
> 
> For Lazy Consensus voting instructions, see [2].
> 
>   -Rob
> 
> [0] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-
> February/000379.html
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/bylaws#lazy-consensus


From rkennke at redhat.com  Tue Feb 12 08:46:13 2019
From: rkennke at redhat.com (Roman Kennke)
Date: Tue, 12 Feb 2019 09:46:13 +0100
Subject: [11u-communication] CFV: 11u lead maintainer nomination for
 Andrew Haley
In-Reply-To: <20190212000937.GE5290@vimes>
References: <20190212000937.GE5290@vimes>
Message-ID: <95f61909-6495-00f4-6c6d-93c7505611ec@redhat.com>

Vote: yes

Thanks,
Roman


> As the Project Lead, I would like to ask for your vote for the
> nomination [0] of Andrew Haley as future lead maintainer.
> 
> Votes are due by the 18th of February.
> 
> Only current JDK Updates Committers [1] are eligible to vote
> on this nomination.  Votes must be cast in the open by replying
> "Vote: yes" to this mail.
> 
> For Lazy Consensus voting instructions, see [2].
> 
>   -Rob
> 
> [0] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-February/000379.html
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/bylaws#lazy-consensus
> 

From rwestrel at redhat.com  Tue Feb 12 08:49:56 2019
From: rwestrel at redhat.com (Roland Westrelin)
Date: Tue, 12 Feb 2019 09:49:56 +0100
Subject: [11u-communication] CFV: 11u lead maintainer nomination for
 Andrew Haley
In-Reply-To: <20190212000937.GE5290@vimes>
References: <20190212000937.GE5290@vimes>
Message-ID: <87ftsttmq3.fsf@redhat.com>


Vote: yes

Roland.

From volker.simonis at gmail.com  Tue Feb 12 09:17:16 2019
From: volker.simonis at gmail.com (Volker Simonis)
Date: Tue, 12 Feb 2019 10:17:16 +0100
Subject: [11u-communication] CFV: 11u lead maintainer nomination for
 Andrew Haley
In-Reply-To: <20190212000937.GE5290@vimes>
References: <20190212000937.GE5290@vimes>
Message-ID: <CA+3eh12c0n=yjwCqT3a0NkkFOC_uCq=nkFLwk5ffm02CUfo5SA@mail.gmail.com>

Vote: yes

On Tue, Feb 12, 2019 at 1:10 AM Rob McKenna <rob.mckenna at oracle.com> wrote:
>
> As the Project Lead, I would like to ask for your vote for the
> nomination [0] of Andrew Haley as future lead maintainer.
>
> Votes are due by the 18th of February.
>
> Only current JDK Updates Committers [1] are eligible to vote
> on this nomination.  Votes must be cast in the open by replying
> "Vote: yes" to this mail.
>
> For Lazy Consensus voting instructions, see [2].
>
>   -Rob
>
> [0] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-February/000379.html
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/bylaws#lazy-consensus
>

From martin.doerr at sap.com  Tue Feb 12 09:27:27 2019
From: martin.doerr at sap.com (Doerr, Martin)
Date: Tue, 12 Feb 2019 09:27:27 +0000
Subject: [11u-communication] CFV: 11u lead maintainer nomination for
 Andrew Haley
In-Reply-To: <CA+3eh12c0n=yjwCqT3a0NkkFOC_uCq=nkFLwk5ffm02CUfo5SA@mail.gmail.com>
References: <20190212000937.GE5290@vimes>
 <CA+3eh12c0n=yjwCqT3a0NkkFOC_uCq=nkFLwk5ffm02CUfo5SA@mail.gmail.com>
Message-ID: <AM6PR02MB478826254D23CBF250565C669A650@AM6PR02MB4788.eurprd02.prod.outlook.com>

Vote: yes


From sgehwolf at redhat.com  Tue Feb 12 09:38:53 2019
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Tue, 12 Feb 2019 10:38:53 +0100
Subject: [11u-communication] CFV: 11u lead maintainer nomination for
 Andrew Haley
In-Reply-To: <20190212000937.GE5290@vimes>
References: <20190212000937.GE5290@vimes>
Message-ID: <b83b529bfc5fd3ba104d968440f900d476aa4173.camel@redhat.com>

Vote: yes.

On Tue, 2019-02-12 at 00:09 +0000, Rob McKenna wrote:
> As the Project Lead, I would like to ask for your vote for the
> nomination [0] of Andrew Haley as future lead maintainer.
> 
> Votes are due by the 18th of February.
> 
> Only current JDK Updates Committers [1] are eligible to vote
> on this nomination.  Votes must be cast in the open by replying
> "Vote: yes" to this mail.
> 
> For Lazy Consensus voting instructions, see [2].
> 
>   -Rob
> 
> [0] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-February/000379.html
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/bylaws#lazy-consensus
> 


From adinn at redhat.com  Tue Feb 12 09:53:51 2019
From: adinn at redhat.com (Andrew Dinn)
Date: Tue, 12 Feb 2019 09:53:51 +0000
Subject: [11u-communication] CFV: 11u lead maintainer nomination for
 Andrew Haley
In-Reply-To: <20190212000937.GE5290@vimes>
References: <20190212000937.GE5290@vimes>
Message-ID: <c9c6a145-eb8f-27b8-e4e7-7c95deb099f6@redhat.com>

Vote: yes

On 12/02/2019 00:09, Rob McKenna wrote:
> As the Project Lead, I would like to ask for your vote for the
> nomination [0] of Andrew Haley as future lead maintainer.
> 
> Votes are due by the 18th of February.
> 
> Only current JDK Updates Committers [1] are eligible to vote
> on this nomination.  Votes must be cast in the open by replying
> "Vote: yes" to this mail.
> 
> For Lazy Consensus voting instructions, see [2].
> 
>   -Rob
> 
> [0] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-February/000379.html
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/bylaws#lazy-consensus
> 
> 

-- 
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 daniel.fuchs at oracle.com  Tue Feb 12 10:47:32 2019
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 12 Feb 2019 11:47:32 +0100
Subject: [11u-communication] CFV: 11u lead maintainer nomination for
 Andrew Haley
In-Reply-To: <20190212000937.GE5290@vimes>
References: <20190212000937.GE5290@vimes>
Message-ID: <b1e75f2c-7fa2-a6f4-fccd-71629ba58bbf@oracle.com>

Vote: yes

best regards,

-- daniel

On 12/02/2019 01:09, Rob McKenna wrote:
> As the Project Lead, I would like to ask for your vote for the
> nomination [0] of Andrew Haley as future lead maintainer.
> 
> Votes are due by the 18th of February.
> 
> Only current JDK Updates Committers [1] are eligible to vote
> on this nomination.  Votes must be cast in the open by replying
> "Vote: yes" to this mail.
> 
> For Lazy Consensus voting instructions, see [2].
> 
>    -Rob
> 
> [0] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-February/000379.html
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/bylaws#lazy-consensus
> 


From tobias.hartmann at oracle.com  Tue Feb 12 10:56:25 2019
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Tue, 12 Feb 2019 11:56:25 +0100
Subject: [11u-communication] CFV: 11u lead maintainer nomination for
 Andrew Haley
In-Reply-To: <20190212000937.GE5290@vimes>
References: <20190212000937.GE5290@vimes>
Message-ID: <5571347b-9b75-38f9-33aa-2b9146bda383@oracle.com>

Vote: yes

Best regards,
Tobias

On 12.02.19 01:09, Rob McKenna wrote:
> As the Project Lead, I would like to ask for your vote for the
> nomination [0] of Andrew Haley as future lead maintainer.
> 
> Votes are due by the 18th of February.
> 
> Only current JDK Updates Committers [1] are eligible to vote
> on this nomination.  Votes must be cast in the open by replying
> "Vote: yes" to this mail.
> 
> For Lazy Consensus voting instructions, see [2].
> 
>   -Rob
> 
> [0] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-February/000379.html
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/bylaws#lazy-consensus
> 

From Roger.Riggs at oracle.com  Tue Feb 12 14:32:39 2019
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Tue, 12 Feb 2019 09:32:39 -0500
Subject: [11u-communication] CFV: 11u lead maintainer nomination for
 Andrew Haley
In-Reply-To: <20190212000937.GE5290@vimes>
References: <20190212000937.GE5290@vimes>
Message-ID: <d76d69b6-6acf-2e04-42e3-9028c2fec411@oracle.com>

Vote: Yes

On 02/11/2019 07:09 PM, Rob McKenna wrote:
> As the Project Lead, I would like to ask for your vote for the
> nomination [0] of Andrew Haley as future lead maintainer.


From shade at redhat.com  Tue Feb 12 14:36:33 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 12 Feb 2019 15:36:33 +0100
Subject: [11u-communication] CFV: 11u lead maintainer nomination for
 Andrew Haley
In-Reply-To: <20190212000937.GE5290@vimes>
References: <20190212000937.GE5290@vimes>
Message-ID: <3622b842-d15a-c5bc-61cd-fd6bff8b209c@redhat.com>

Vote: yes

-Aleksey

On 2/12/19 1:09 AM, Rob McKenna wrote:
> As the Project Lead, I would like to ask for your vote for the
> nomination [0] of Andrew Haley as future lead maintainer.
> 
> Votes are due by the 18th of February.
> 
> Only current JDK Updates Committers [1] are eligible to vote
> on this nomination.  Votes must be cast in the open by replying
> "Vote: yes" to this mail.
> 
> For Lazy Consensus voting instructions, see [2].
> 
>   -Rob
> 
> [0] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-February/000379.html
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/bylaws#lazy-consensus
> 



From dms at samersoff.net  Tue Feb 12 14:55:41 2019
From: dms at samersoff.net (Dmitry Samersoff)
Date: Tue, 12 Feb 2019 17:55:41 +0300
Subject: [11u-communication] CFV: 11u lead maintainer nomination for
 Andrew Haley
In-Reply-To: <3622b842-d15a-c5bc-61cd-fd6bff8b209c@redhat.com>
References: <20190212000937.GE5290@vimes>
 <3622b842-d15a-c5bc-61cd-fd6bff8b209c@redhat.com>
Message-ID: <0c6b918c-ab79-d660-1467-4e468987730d@samersoff.net>

Vote: yes

On 12.02.2019 17:36, Aleksey Shipilev wrote:
> Vote: yes
> 
> -Aleksey
> 
> On 2/12/19 1:09 AM, Rob McKenna wrote:
>> As the Project Lead, I would like to ask for your vote for the
>> nomination [0] of Andrew Haley as future lead maintainer.
>>
>> Votes are due by the 18th of February.
>>
>> Only current JDK Updates Committers [1] are eligible to vote
>> on this nomination.  Votes must be cast in the open by replying
>> "Vote: yes" to this mail.
>>
>> For Lazy Consensus voting instructions, see [2].
>>
>>   -Rob
>>
>> [0] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-February/000379.html
>> [1] http://openjdk.java.net/census
>> [2] http://openjdk.java.net/bylaws#lazy-consensus
>>
> 
> 

From dmitrij.pochepko at bell-sw.com  Tue Feb 12 15:44:20 2019
From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko)
Date: Tue, 12 Feb 2019 18:44:20 +0300
Subject: [11u-communication] CFV: 11u lead maintainer nomination for
 Andrew Haley
In-Reply-To: <20190212000937.GE5290@vimes>
References: <20190212000937.GE5290@vimes>
Message-ID: <dd57f226-94a2-edc0-c302-820745413e0e@bell-sw.com>

Vote: yes

On 12/02/2019 3:09 AM, Rob McKenna wrote:
> As the Project Lead, I would like to ask for your vote for the
> nomination [0] of Andrew Haley as future lead maintainer.
>
> Votes are due by the 18th of February.
>
> Only current JDK Updates Committers [1] are eligible to vote
> on this nomination.  Votes must be cast in the open by replying
> "Vote: yes" to this mail.
>
> For Lazy Consensus voting instructions, see [2].
>
>    -Rob
>
> [0] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-February/000379.html
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/bylaws#lazy-consensus
>

From vladimir.kozlov at oracle.com  Tue Feb 12 17:12:53 2019
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 12 Feb 2019 09:12:53 -0800
Subject: [11u-communication] CFV: 11u lead maintainer nomination for
 Andrew Haley
In-Reply-To: <20190212000937.GE5290@vimes>
References: <20190212000937.GE5290@vimes>
Message-ID: <0ac29bed-4378-65d3-df29-333738725fb5@oracle.com>

Vote: yes

On 2/11/19 4:09 PM, Rob McKenna wrote:
> As the Project Lead, I would like to ask for your vote for the
> nomination [0] of Andrew Haley as future lead maintainer.
> 
> Votes are due by the 18th of February.
> 
> Only current JDK Updates Committers [1] are eligible to vote
> on this nomination.  Votes must be cast in the open by replying
> "Vote: yes" to this mail.
> 
> For Lazy Consensus voting instructions, see [2].
> 
>    -Rob
> 
> [0] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-February/000379.html
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/bylaws#lazy-consensus
> 

From hohensee at amazon.com  Tue Feb 12 18:33:50 2019
From: hohensee at amazon.com (Hohensee, Paul)
Date: Tue, 12 Feb 2019 18:33:50 +0000
Subject: [11u-communication] CFV: 11u lead maintainer nomination for
 Andrew Haley
In-Reply-To: <20190212000937.GE5290@vimes>
References: <20190212000937.GE5290@vimes>
Message-ID: <28C60C9A-0821-4F82-BE2B-A895C39E10AC@amazon.com>

Vote: yes

?On 2/11/19, 4:11 PM, "jdk-updates-dev on behalf of Rob McKenna" <jdk-updates-dev-bounces at openjdk.java.net on behalf of rob.mckenna at oracle.com> wrote:

    As the Project Lead, I would like to ask for your vote for the
    nomination [0] of Andrew Haley as future lead maintainer.
    
    Votes are due by the 18th of February.
    
    Only current JDK Updates Committers [1] are eligible to vote
    on this nomination.  Votes must be cast in the open by replying
    "Vote: yes" to this mail.
    
    For Lazy Consensus voting instructions, see [2].
    
      -Rob
    
    [0] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-February/000379.html
    [1] http://openjdk.java.net/census
    [2] http://openjdk.java.net/bylaws#lazy-consensus
    
    


From volker.simonis at gmail.com  Tue Feb 12 19:11:43 2019
From: volker.simonis at gmail.com (Volker Simonis)
Date: Tue, 12 Feb 2019 20:11:43 +0100
Subject: JDK 11.0.3 Update process
In-Reply-To: <c7027fa19a28408e83461360f3ce6974@sap.com>
References: <c7027fa19a28408e83461360f3ce6974@sap.com>
Message-ID: <CA+3eh12Rtb1MQt2xr-Tu8svvZ0+NEWs4bsn0oRpnHyGhXF0fqA@mail.gmail.com>

Hi all,

I think this are very valid questions for which we have to find an
answer pretty soon. Please find my further comments inline:

On Mon, Feb 11, 2019 at 8:11 PM Langer, Christoph
<christoph.langer at sap.com> wrote:
>
> Hello Andrew, all,
>
> while we know that the jdk11 updates project is in the phase of transitioning to its new maintainers and this will take a little while to settle down, the next quarterly update JDK 11.0.3, scheduled for April, is in the process of ramping up.
>
> When discussing the JDK update process today in our team at SAP, we found a few questions open which we think need to be answered soon.
>
> One question is, whether changes brought into the jdk11u repo as of today will still target for 11.0.3? I assume that's the case as no communication has been made telling otherwise. Can you confirm this? Furthermore, if that's true, when will be the cutoff point? Or will we maybe pick a certain change in the jdk11u repo that is known as of today to be the base for 11.0.3?

I suppose you wanted to write "known to be the base for
11.0.3-oracle". I don't think we should look for Oracle here. First of
all, we don't know which was the cutoff point at which Oracle has
branched its 11.0.3-oracle consolidation branch. And even if they
would tell us, this would only make sense for our 11.0.3-openjdk
release. For all future releases, Oracle will branch their
consolidation branches from their internal, 11u-oracle repository
which will be different from 11u-openjdk and to which we don't have
access anyway.

>
> Furthermore, can we assume a new open consolidation repository will be created on hg.openjdk.java.net where update release ramp up for OpenJDK 11 updates will take place?

We've discussed this at SAP and we would definitely vote for two
repos: a development AND a consolidation repository (i.e.
"jdk-updates/jdk11u-dev" as "always-open" for approved downports and
"jdk-updates/jdk11u" for consolidating the next update release). I've
used this notation in the following picture which tries to explain our
current proposal (please bear with me, I'm not an artist :)

http://cr.openjdk.java.net/~simonis/webrevs/2019/jdk11u-project/11u-update-project.png

The following explanations try to make the picture (and proposed
process) more understandable:

- repositories are being drawn as a linear sequence of changes to
simplify the picture
- jdk/jdk is the "always-open" jdk development repo with a stream of
new changes ('a' to 'h')
- jdk-updates/jdk11u-dev is the "always-open" development repository
for 11u updates. After approval, changes from jdk/jdk can be
downported to jdk-updates/jdk11u-dev any time (e.g. 'a', 'c' and 'e'
in the picture).
- at a given time (usually within a week or two after the previous 11u
update (jdk-11.0.2 in the picture) has been released) the current head
of  jdk-updates/jdk11u-dev will be tagged with the '-rdp2' tag of the
next update release (jdk11.0.3 in the picture).
- the change with this tag will be pushed to (or pulled from)
jdk-updates/jdk11u. This effectively merges all the changes which have
been accumulated in jdk-updates/jdk11u-dev into jdk-updates/jdk11u
(e.g. 'a' and 'c' in the picture).
- jdk-updates/jdk11u will now be used to prepare the next update
release (11.0.3 in this example). Only P2 (and later P1 bugs,
depending on the rules defined by the Maintainer) will be pushed to
jdk-updates/jdk11u. These changes can either come from jdk/jdk or they
can be specific to jdk-updates/jdk11u like 'y' and 'z' in the picture.
- in any case jdk-updates/jdk11u will be regularly (e.g. weekly,
depending on the Maintainers decision) merged back into
jdk-updates/jdk11u-dev. This saves committers from having to push the
same change into both, jdk-updates/jdk11u and jdk-updates/jdk11u-dev,
and works similar to the automated push from a new feature release
repo back into jdk/jdk. In the picture these are the changes 'y' and
'z' which get pushed to (or pulled from) jdk-updates/jdk11u-dev and
merged into jdk-updates/jdk11u-dev with merge change 'm3'.
- the jdk11u Maintainer needs to keep an additional, "closed"
repository, where he can integrate and test the closed security fixes
for the upcoming update release which he receives through the OpenJDK
Vulnerability Groups mailing list. In the picture this is called
jdk-updates/jdk11u-sec.
- jdk-updates/jdk11u-sec starts by merging in the corresponding
'jdk-...-rdp2' change from jdk-updates/jdk11u (merge changeset 'm2' in
the picture).
- after that, jdk-updates/jdk11u-sec is ready for taking security
fixes (e.g. 'p' in the picture)
- at the same time jdk-updates/jdk11u-sec will be regularly synced
with jdk-updates/jdk11u by pulling from there (ideally this can happen
at the same time at which jdk-updates/jdk11u and
jdk-updates/jdk11u-dev are synced to keep things simple). In the
picture this happens with merge change 'm5' which pulls 'y' and 'z'
from jdk-updates/jdk11u.
- new security fixes can be pushed to jdk-updates/jdk11u-sec at any
time by the Maintainer (e.g. 'q' in the picture).
- right before the patch day, the head revision of
jdk-updates/jdk11u-sec will be tagged with the corresponding '-ga' tag
('jdk-11.0.3-ga' in the picture).
- on the patch day, the Maintainer can release its binary releases
based on the '-ga' tag and at the same time push that tag back to
jdk-updates/jdk11u (merge 'm6' in the picture) and
jdk-updates/jdk11u-dev (merge 'm7' in the picture). This will give all
the other down-stream distributors and packager the possibility to
build their binary packages based on the same '-ga' tagged changeset.
- at this point in time, jdk-updates/jdk11u and jdk-updates/jdk11u-sec
will be the same, while jdk-updates/jdk11u-dev will have all the
changes from jdk-updates/jdk11u-sec (or jdk-updates/jdk11u) PLUS the
additional downports which have been collected in
jdk-updates/jdk11u-dev since the last RDP2 change was tagged (in the
picture these additional changes are 'e' and 'g'.
- shortly after the update has been released, we're ready to tag the
head of jdk-updates/jdk11u-dev with the next '-rdp2' tag and the same
procedure begins again for the next update release.

Why do we think it is important to have two update repositories (i.e.
jdk-updates/jdk11u-dev AND jdk-updates/jdk11u) ?

- having both repos gives other down-stream distributors the
possibility to test (and potentially fix) all of the non-security
changes which will be included in the next update release. This is
important because the 11u Maintainer will probably not have the
possibility to test on all the supported platforms and all the
different configurations on his own
- it will also make it transparent to the community which non-security
changes will be integrated into the next update release.
- having both these repos gives other down-stream distributors, who
are also members of the OpenJDK Vulnerability Group, a chance to test
the non-security PLUS the security fixes together (which should be
pretty close to the version Maintainer is preparing and testing) on
all their platforms and for all their configurations.

Please let me know what you think about this proposal. I'm obviously
mostly interested in the opinion of the new, designated jdk11u
Maintener, but I think this is an important topic for all potential
jdk11u downstream distributors.

I would also be happy to add this write-up and picture (or a
consolidated version thereof) to the JDK11u Wiki at
https://wiki.openjdk.java.net/display/JDKUpdates/JDK11u if somebody
thinks that it my be useful.

Thank you and best regards,
Volker




>
> Any comments are welcome.
>
> Thanks
> Christoph
>

From mark.reinhold at oracle.com  Tue Feb 12 19:40:08 2019
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Tue, 12 Feb 2019 11:40:08 -0800
Subject: [11u-communication] CFV: 11u lead maintainer nomination for
 Andrew Haley
In-Reply-To: <20190212000937.GE5290@vimes>
References: <20190212000937.GE5290@vimes>
Message-ID: <20190212114008.233211942@eggemoggin.niobe.net>

Vote: yes

- Mark

From jesper.wilhelmsson at oracle.com  Tue Feb 12 21:20:10 2019
From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com)
Date: Tue, 12 Feb 2019 22:20:10 +0100
Subject: [11u-communication] CFV: 11u lead maintainer nomination for
 Andrew Haley
In-Reply-To: <20190212000937.GE5290@vimes>
References: <20190212000937.GE5290@vimes>
Message-ID: <4FE8F6F9-737E-4936-B7A8-CFF6671931FE@oracle.com>

Vote: Yes
/Jesper

> On 12 Feb 2019, at 01:09, Rob McKenna <rob.mckenna at oracle.com> wrote:
> 
> As the Project Lead, I would like to ask for your vote for the
> nomination [0] of Andrew Haley as future lead maintainer.
> 
> Votes are due by the 18th of February.
> 
> Only current JDK Updates Committers [1] are eligible to vote
> on this nomination.  Votes must be cast in the open by replying
> "Vote: yes" to this mail.
> 
> For Lazy Consensus voting instructions, see [2].
> 
>  -Rob
> 
> [0] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-February/000379.html
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/bylaws#lazy-consensus
> 


From igor.ignatyev at oracle.com  Tue Feb 12 21:22:31 2019
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Tue, 12 Feb 2019 13:22:31 -0800
Subject: [11u-communication] CFV: 11u lead maintainer nomination for
 Andrew Haley
In-Reply-To: <20190212000937.GE5290@vimes>
References: <20190212000937.GE5290@vimes>
Message-ID: <86968D2A-6595-457A-8470-157C5154FEB6@oracle.com>

Vote: yes

-- Igor

> On Feb 11, 2019, at 4:09 PM, Rob McKenna <rob.mckenna at oracle.com> wrote:
> 
> As the Project Lead, I would like to ask for your vote for the
> nomination [0] of Andrew Haley as future lead maintainer.


From neugens.limasoftware at gmail.com  Wed Feb 13 16:10:26 2019
From: neugens.limasoftware at gmail.com (Mario Torre)
Date: Wed, 13 Feb 2019 17:10:26 +0100
Subject: [11u-communication] CFV: 11u lead maintainer nomination for
 Andrew Haley
In-Reply-To: <20190212000937.GE5290@vimes>
References: <20190212000937.GE5290@vimes>
Message-ID: <CAGUMyaRbrcdyesHFcgy+nQxEcFp-=4WC4wt_04zCoBBcEvN25w@mail.gmail.com>

Vote: Yes

Cheers,
Mario

Il giorno mar 12 feb 2019 alle ore 01:10 Rob McKenna
<rob.mckenna at oracle.com> ha scritto:
>
> As the Project Lead, I would like to ask for your vote for the
> nomination [0] of Andrew Haley as future lead maintainer.
>
> Votes are due by the 18th of February.
>
> Only current JDK Updates Committers [1] are eligible to vote
> on this nomination.  Votes must be cast in the open by replying
> "Vote: yes" to this mail.
>
> For Lazy Consensus voting instructions, see [2].
>
>   -Rob
>
> [0] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-February/000379.html
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/bylaws#lazy-consensus
>


-- 
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF

Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens
Proud GNU Classpath developer: http://www.classpath.org/
OpenJDK: http://openjdk.java.net/projects/caciocavallo/

Please, support open standards:
http://endsoftpatents.org/

From gnu.andrew at redhat.com  Wed Feb 13 16:50:05 2019
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Wed, 13 Feb 2019 16:50:05 +0000
Subject: RFD: Draft guidelines for working on jdk8u
In-Reply-To: <CA+3eh11FXBFBfUyesMroqozUmTrUeJunoGk7ON3cKpt-4-bedA@mail.gmail.com>
References: <119c5824-262e-b0d9-8a33-ceac24b7a8ab@redhat.com>
 <09404bec-476f-8191-1319-60266a4f9631@linux.vnet.ibm.com>
 <963bb29b-7f90-6744-ddb4-132609d1d689@redhat.com>
 <CAP7YuAQAURsncaLZn=fJQ2N=h1EaMSMp2+aNNVkaT9vvsrKESg@mail.gmail.com>
 <29e286ca-013b-023d-1cee-5938f551ceb7@redhat.com>
 <CAP7YuATnZA3ie9mLAj2w7U9Q1TuS1ao+fKx6rQcwYBrd=-vL6g@mail.gmail.com>
 <CA+3eh11FXBFBfUyesMroqozUmTrUeJunoGk7ON3cKpt-4-bedA@mail.gmail.com>
Message-ID: <CABi63P4gNURFa78UOPHobN6LMqw0QRU9t6b7doTyWVUwu_gApA@mail.gmail.com>

On Wed, 13 Feb 2019 at 09:06, Volker Simonis <volker.simonis at gmail.com> wrote:
>
> Hi Andrew,
>
> I've wrote up a detailed proposal for the jdk11u update process and
> posted it on jdk-updates-dev yesterday [1]. In that mail I propose to
> have two repositories, jdk11u-dev as "always-open" development
> repository and jdk11u as consolidation repository for the upcoming
> update release. The main reason for having such a setup is that
> everybody can see (and test) all the non-security changes which will
> be in the next update release and members of the Vulenrability Group
> will even have the possibility to easily create (and test) a version
> of the upcoming update release which is very close to if not equal to
> the version Red Hat will be working on "in the dark". I think this is
> important not only to get a broader test coverage for upcoming update
> releases, but also to simplify the process of producing update
> releases for other down-stream distributors.
>
> The OpenJDK 8u project already has these two repositories (i.e.
> jdk8u/jdk8u and jdk8u/jdk8u-dev) so it would be trivial to implement
> my proposal for the 8u updates project. What do you think?
>
> Thank you and best regards,
> Volker
>
> [1] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-February/000411.html

+1.

I'd like to see 11u & 8u working in a similar way to minimise confusion. That
means 8u adopting the tagging process from 11u, and 11 having two trees
so we can separate release-ready sources from development sources.

I've been thinking over a few things, but being too caught up with the
last lingering
parts of the CPU to post. My current idea is:

1. Changes are pushed to jdkxxu-dev after review and approval.

2. At regular periods (fortnightly?), changes are promoted to jdkxxu and tagged.

3. At a point before the CPU (basically when we have the patches, which is
usually at most a month before), jdkxxu is declared frozen so we have a base
for the update.

4. When the CPU is unembargoed, the changes are pushed to both trees and
a release made. jdkxxu is unfrozen and #2 resumes.

We will need something more involved if there are changes in jdkxxu-dev which
may need longer to soak. I would suggest they use a project tree or a new tree
within jdkxxu, then they are promoted to jdkxxu-dev when ready. This is much
like the way the AArch64 & PPC ports were added and is essentially a third
level below jdkxxu-dev.

I think we need to stick to a restricted set of maintainers for jdkxx, as I said
before [0]. The lead should obviously be one of those. I'll
additionally nominate
myself as someone who has a lot of experience of doing such merges and
releases, e.g with OpenJDK 6 & 7. But we should aim for more people so we
have some redundancy.

I think that's broadly along similar lines to what you posted to the
updates list earlier.

[0] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-February/008509.html
-- 
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 aph at redhat.com  Wed Feb 13 17:19:23 2019
From: aph at redhat.com (Andrew Haley)
Date: Wed, 13 Feb 2019 17:19:23 +0000
Subject: JDK 11.0.3 Update process
In-Reply-To: <CA+3eh12Rtb1MQt2xr-Tu8svvZ0+NEWs4bsn0oRpnHyGhXF0fqA@mail.gmail.com>
References: <c7027fa19a28408e83461360f3ce6974@sap.com>
 <CA+3eh12Rtb1MQt2xr-Tu8svvZ0+NEWs4bsn0oRpnHyGhXF0fqA@mail.gmail.com>
Message-ID: <be92b505-d50b-097c-d26f-f9768c90cbd0@redhat.com>

On 2/12/19 7:11 PM, Volker Simonis wrote:
> Hi all,
> 
> I think this are very valid questions for which we have to find an
> answer pretty soon. Please find my further comments inline:
> 
> On Mon, Feb 11, 2019 at 8:11 PM Langer, Christoph
> <christoph.langer at sap.com> wrote:
>>
>> while we know that the jdk11 updates project is in the phase of
>> transitioning to its new maintainers and this will take a little
>> while to settle down, the next quarterly update JDK 11.0.3,
>> scheduled for April, is in the process of ramping up.
>>
>> When discussing the JDK update process today in our team at SAP, we
>> found a few questions open which we think need to be answered soon.
>>
>> One question is, whether changes brought into the jdk11u repo as of
>> today will still target for 11.0.3? I assume that's the case as no
>> communication has been made telling otherwise. Can you confirm
>> this? Furthermore, if that's true, when will be the cutoff point?
>> Or will we maybe pick a certain change in the jdk11u repo that is
>> known as of today to be the base for 11.0.3?

The cutoff date must be before when we branch for the CPU, and that
will be when the patches drop into the VG. I take your point that it
would be nice to know in advance exactly when the cutoff will be, but
on the other hand I don't think it's necessary or desirable to cut off
early. On the other hand, we will start working on the CPU as soon as
we can.

> I suppose you wanted to write "known to be the base for
> 11.0.3-oracle". I don't think we should look for Oracle here. First
> of all, we don't know which was the cutoff point at which Oracle has
> branched its 11.0.3-oracle consolidation branch. And even if they
> would tell us, this would only make sense for our 11.0.3-openjdk
> release. For all future releases, Oracle will branch their
> consolidation branches from their internal, 11u-oracle repository
> which will be different from 11u-openjdk and to which we don't have
> access anyway.

Yes, indeed so.

>> Furthermore, can we assume a new open consolidation repository will
>> be created on hg.openjdk.java.net where update release ramp up for
>> OpenJDK 11 updates will take place?
> 
> We've discussed this at SAP and we would definitely vote for two
> repos: a development AND a consolidation repository (i.e.
> "jdk-updates/jdk11u-dev" as "always-open" for approved downports and
> "jdk-updates/jdk11u" for consolidating the next update release). I've
> used this notation in the following picture which tries to explain our
> current proposal (please bear with me, I'm not an artist :)

Yes, that sounds right. The development repo continues after the
snapshot.

> http://cr.openjdk.java.net/~simonis/webrevs/2019/jdk11u-project/11u-update-project.png
> 
> The following explanations try to make the picture (and proposed
> process) more understandable:
> 
> - repositories are being drawn as a linear sequence of changes to
> simplify the picture

> - jdk/jdk is the "always-open" jdk development repo with a stream of
> new changes ('a' to 'h')

> - jdk-updates/jdk11u-dev is the "always-open" development repository
> for 11u updates. After approval, changes from jdk/jdk can be
> downported to jdk-updates/jdk11u-dev any time (e.g. 'a', 'c' and 'e'
> in the picture).

jdk/jdk is the head jdk development repo. Some changes, mostly bug
fixes, will be backported to jdk-updates/jdk11u-dev.

> - at a given time (usually within a week or two after the previous 11u
> update (jdk-11.0.2 in the picture) has been released) the current head
> of  jdk-updates/jdk11u-dev will be tagged with the '-rdp2' tag of the
> next update release (jdk11.0.3 in the picture).

> - the change with this tag will be pushed to (or pulled from)
> jdk-updates/jdk11u. This effectively merges all the changes which have
> been accumulated in jdk-updates/jdk11u-dev into jdk-updates/jdk11u
> (e.g. 'a' and 'c' in the picture).

Right.

> - jdk-updates/jdk11u will now be used to prepare the next update
> release (11.0.3 in this example). Only P2 (and later P1 bugs,
> depending on the rules defined by the Maintainer) will be pushed to
> jdk-updates/jdk11u. These changes can either come from jdk/jdk or they
> can be specific to jdk-updates/jdk11u like 'y' and 'z' in the picture.

It depends if the bug exists in later releases. If it does, it must be
fixed there too in order to be accepted by 11u.

> - in any case jdk-updates/jdk11u will be regularly (e.g. weekly,
> depending on the Maintainers decision) merged back into
> jdk-updates/jdk11u-dev. This saves committers from having to push the
> same change into both, jdk-updates/jdk11u and jdk-updates/jdk11u-dev,
> and works similar to the automated push from a new feature release
> repo back into jdk/jdk. In the picture these are the changes 'y' and
> 'z' which get pushed to (or pulled from) jdk-updates/jdk11u-dev and
> merged into jdk-updates/jdk11u-dev with merge change 'm3'.

Again, that seems reasonable.

> - the jdk11u Maintainer needs to keep an additional, "closed"
> repository, where he can integrate and test the closed security fixes
> for the upcoming update release which he receives through the OpenJDK
> Vulnerability Groups mailing list. In the picture this is called
> jdk-updates/jdk11u-sec.

Yes.

> - jdk-updates/jdk11u-sec starts by merging in the corresponding
> 'jdk-...-rdp2' change from jdk-updates/jdk11u (merge changeset 'm2' in
> the picture).

> - after that, jdk-updates/jdk11u-sec is ready for taking security
> fixes (e.g. 'p' in the picture)

> - at the same time jdk-updates/jdk11u-sec will be regularly synced
> with jdk-updates/jdk11u

Maybe. I'm not promising anything about that.

> by pulling from there (ideally this can happen
> at the same time at which jdk-updates/jdk11u and
> jdk-updates/jdk11u-dev are synced to keep things simple). In the
> picture this happens with merge change 'm5' which pulls 'y' and 'z'
> from jdk-updates/jdk11u.

> - new security fixes can be pushed to jdk-updates/jdk11u-sec at any
> time by the Maintainer (e.g. 'q' in the picture).

> - right before the patch day, the head revision of
> jdk-updates/jdk11u-sec will be tagged with the corresponding '-ga' tag
> ('jdk-11.0.3-ga' in the picture).

> - on the patch day, the Maintainer can release its binary releases
> based on the '-ga' tag and at the same time push that tag back to
> jdk-updates/jdk11u (merge 'm6' in the picture) and
> jdk-updates/jdk11u-dev (merge 'm7' in the picture). This will give all
> the other down-stream distributors and packager the possibility to
> build their binary packages based on the same '-ga' tagged changeset.

This sounds reasonable.

> - at this point in time, jdk-updates/jdk11u and jdk-updates/jdk11u-sec
> will be the same, while jdk-updates/jdk11u-dev will have all the
> changes from jdk-updates/jdk11u-sec (or jdk-updates/jdk11u) PLUS the
> additional downports which have been collected in
> jdk-updates/jdk11u-dev since the last RDP2 change was tagged (in the
> picture these additional changes are 'e' and 'g'.

> - shortly after the update has been released, we're ready to tag the
> head of jdk-updates/jdk11u-dev with the next '-rdp2' tag and the same
> procedure begins again for the next update release.
> 
> Why do we think it is important to have two update repositories (i.e.
> jdk-updates/jdk11u-dev AND jdk-updates/jdk11u) ?

> - having both repos gives other down-stream distributors the
> possibility to test (and potentially fix) all of the non-security
> changes which will be included in the next update release. This is
> important because the 11u Maintainer will probably not have the
> possibility to test on all the supported platforms and all the
> different configurations on his own

> - it will also make it transparent to the community which non-security
> changes will be integrated into the next update release.

There are potentially some issues here. We may have to integrate
non-security fixes into the hidden CPU tree, and we may have to do
that in a way that people outside the VG cannot see. So yes, that's
highly desirable, but no promises.

> - having both these repos gives other down-stream distributors, who
> are also members of the OpenJDK Vulnerability Group, a chance to test
> the non-security PLUS the security fixes together (which should be
> pretty close to the version Maintainer is preparing and testing) on
> all their platforms and for all their configurations.
> 
> Please let me know what you think about this proposal. I'm obviously
> mostly interested in the opinion of the new, designated jdk11u
> Maintener, but I think this is an important topic for all potential
> jdk11u downstream distributors.
> 
> I would also be happy to add this write-up and picture (or a
> consolidated version thereof) to the JDK11u Wiki at
> https://wiki.openjdk.java.net/display/JDKUpdates/JDK11u if somebody
> thinks that it my be useful.

This doesn't sound significantly different from what we already do for
jdk7. We must have two repositories, one for development and one
stabilization branch. We must also have an internal repository for
security updates.

We need flexibility to do what we need to do, to begin with, and then
we'll see how things settle out.

I take it that you, or some of your people, will be happy to do some
of the work you've described above, at least the open part?

-- 
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 volker.simonis at gmail.com  Wed Feb 13 18:30:22 2019
From: volker.simonis at gmail.com (Volker Simonis)
Date: Wed, 13 Feb 2019 19:30:22 +0100
Subject: JDK 11.0.3 Update process
In-Reply-To: <be92b505-d50b-097c-d26f-f9768c90cbd0@redhat.com>
References: <c7027fa19a28408e83461360f3ce6974@sap.com>
 <CA+3eh12Rtb1MQt2xr-Tu8svvZ0+NEWs4bsn0oRpnHyGhXF0fqA@mail.gmail.com>
 <be92b505-d50b-097c-d26f-f9768c90cbd0@redhat.com>
Message-ID: <CA+3eh13GiMDF-8_kofUqzZvCWK2_va+DRMJDtYm6COSDLzQV6g@mail.gmail.com>

On Wed, Feb 13, 2019 at 6:19 PM Andrew Haley <aph at redhat.com> wrote:
>
> On 2/12/19 7:11 PM, Volker Simonis wrote:
> > Hi all,
> >
> > I think this are very valid questions for which we have to find an
> > answer pretty soon. Please find my further comments inline:
> >
> > On Mon, Feb 11, 2019 at 8:11 PM Langer, Christoph
> > <christoph.langer at sap.com> wrote:
> >>
> >> while we know that the jdk11 updates project is in the phase of
> >> transitioning to its new maintainers and this will take a little
> >> while to settle down, the next quarterly update JDK 11.0.3,
> >> scheduled for April, is in the process of ramping up.
> >>
> >> When discussing the JDK update process today in our team at SAP, we
> >> found a few questions open which we think need to be answered soon.
> >>
> >> One question is, whether changes brought into the jdk11u repo as of
> >> today will still target for 11.0.3? I assume that's the case as no
> >> communication has been made telling otherwise. Can you confirm
> >> this? Furthermore, if that's true, when will be the cutoff point?
> >> Or will we maybe pick a certain change in the jdk11u repo that is
> >> known as of today to be the base for 11.0.3?
>
> The cutoff date must be before when we branch for the CPU, and that
> will be when the patches drop into the VG. I take your point that it
> would be nice to know in advance exactly when the cutoff will be, but
> on the other hand I don't think it's necessary or desirable to cut off
> early. On the other hand, we will start working on the CPU as soon as
> we can.
>
> > I suppose you wanted to write "known to be the base for
> > 11.0.3-oracle". I don't think we should look for Oracle here. First
> > of all, we don't know which was the cutoff point at which Oracle has
> > branched its 11.0.3-oracle consolidation branch. And even if they
> > would tell us, this would only make sense for our 11.0.3-openjdk
> > release. For all future releases, Oracle will branch their
> > consolidation branches from their internal, 11u-oracle repository
> > which will be different from 11u-openjdk and to which we don't have
> > access anyway.
>
> Yes, indeed so.
>
> >> Furthermore, can we assume a new open consolidation repository will
> >> be created on hg.openjdk.java.net where update release ramp up for
> >> OpenJDK 11 updates will take place?
> >
> > We've discussed this at SAP and we would definitely vote for two
> > repos: a development AND a consolidation repository (i.e.
> > "jdk-updates/jdk11u-dev" as "always-open" for approved downports and
> > "jdk-updates/jdk11u" for consolidating the next update release). I've
> > used this notation in the following picture which tries to explain our
> > current proposal (please bear with me, I'm not an artist :)
>
> Yes, that sounds right. The development repo continues after the
> snapshot.
>
> > http://cr.openjdk.java.net/~simonis/webrevs/2019/jdk11u-project/11u-update-project.png
> >
> > The following explanations try to make the picture (and proposed
> > process) more understandable:
> >
> > - repositories are being drawn as a linear sequence of changes to
> > simplify the picture
>
> > - jdk/jdk is the "always-open" jdk development repo with a stream of
> > new changes ('a' to 'h')
>
> > - jdk-updates/jdk11u-dev is the "always-open" development repository
> > for 11u updates. After approval, changes from jdk/jdk can be
> > downported to jdk-updates/jdk11u-dev any time (e.g. 'a', 'c' and 'e'
> > in the picture).
>
> jdk/jdk is the head jdk development repo. Some changes, mostly bug
> fixes, will be backported to jdk-updates/jdk11u-dev.
>
> > - at a given time (usually within a week or two after the previous 11u
> > update (jdk-11.0.2 in the picture) has been released) the current head
> > of  jdk-updates/jdk11u-dev will be tagged with the '-rdp2' tag of the
> > next update release (jdk11.0.3 in the picture).
>
> > - the change with this tag will be pushed to (or pulled from)
> > jdk-updates/jdk11u. This effectively merges all the changes which have
> > been accumulated in jdk-updates/jdk11u-dev into jdk-updates/jdk11u
> > (e.g. 'a' and 'c' in the picture).
>
> Right.
>
> > - jdk-updates/jdk11u will now be used to prepare the next update
> > release (11.0.3 in this example). Only P2 (and later P1 bugs,
> > depending on the rules defined by the Maintainer) will be pushed to
> > jdk-updates/jdk11u. These changes can either come from jdk/jdk or they
> > can be specific to jdk-updates/jdk11u like 'y' and 'z' in the picture.
>
> It depends if the bug exists in later releases. If it does, it must be
> fixed there too in order to be accepted by 11u.
>
> > - in any case jdk-updates/jdk11u will be regularly (e.g. weekly,
> > depending on the Maintainers decision) merged back into
> > jdk-updates/jdk11u-dev. This saves committers from having to push the
> > same change into both, jdk-updates/jdk11u and jdk-updates/jdk11u-dev,
> > and works similar to the automated push from a new feature release
> > repo back into jdk/jdk. In the picture these are the changes 'y' and
> > 'z' which get pushed to (or pulled from) jdk-updates/jdk11u-dev and
> > merged into jdk-updates/jdk11u-dev with merge change 'm3'.
>
> Again, that seems reasonable.
>
> > - the jdk11u Maintainer needs to keep an additional, "closed"
> > repository, where he can integrate and test the closed security fixes
> > for the upcoming update release which he receives through the OpenJDK
> > Vulnerability Groups mailing list. In the picture this is called
> > jdk-updates/jdk11u-sec.
>
> Yes.
>
> > - jdk-updates/jdk11u-sec starts by merging in the corresponding
> > 'jdk-...-rdp2' change from jdk-updates/jdk11u (merge changeset 'm2' in
> > the picture).
>
> > - after that, jdk-updates/jdk11u-sec is ready for taking security
> > fixes (e.g. 'p' in the picture)
>
> > - at the same time jdk-updates/jdk11u-sec will be regularly synced
> > with jdk-updates/jdk11u
>
> Maybe. I'm not promising anything about that.

I meant (and probably better had written) "jdk-updates/jdk11u-sec
regularly pulls from from jdk-updates/jdk11u". How else would you be
able to test and prepare the upcoming release, if you don't merge the
non-security AND the security fixes into one repository?

>
> > by pulling from there (ideally this can happen
> > at the same time at which jdk-updates/jdk11u and
> > jdk-updates/jdk11u-dev are synced to keep things simple). In the
> > picture this happens with merge change 'm5' which pulls 'y' and 'z'
> > from jdk-updates/jdk11u.
>
> > - new security fixes can be pushed to jdk-updates/jdk11u-sec at any
> > time by the Maintainer (e.g. 'q' in the picture).
>
> > - right before the patch day, the head revision of
> > jdk-updates/jdk11u-sec will be tagged with the corresponding '-ga' tag
> > ('jdk-11.0.3-ga' in the picture).
>
> > - on the patch day, the Maintainer can release its binary releases
> > based on the '-ga' tag and at the same time push that tag back to
> > jdk-updates/jdk11u (merge 'm6' in the picture) and
> > jdk-updates/jdk11u-dev (merge 'm7' in the picture). This will give all
> > the other down-stream distributors and packager the possibility to
> > build their binary packages based on the same '-ga' tagged changeset.
>
> This sounds reasonable.
>
> > - at this point in time, jdk-updates/jdk11u and jdk-updates/jdk11u-sec
> > will be the same, while jdk-updates/jdk11u-dev will have all the
> > changes from jdk-updates/jdk11u-sec (or jdk-updates/jdk11u) PLUS the
> > additional downports which have been collected in
> > jdk-updates/jdk11u-dev since the last RDP2 change was tagged (in the
> > picture these additional changes are 'e' and 'g'.
>
> > - shortly after the update has been released, we're ready to tag the
> > head of jdk-updates/jdk11u-dev with the next '-rdp2' tag and the same
> > procedure begins again for the next update release.
> >
> > Why do we think it is important to have two update repositories (i.e.
> > jdk-updates/jdk11u-dev AND jdk-updates/jdk11u) ?
>
> > - having both repos gives other down-stream distributors the
> > possibility to test (and potentially fix) all of the non-security
> > changes which will be included in the next update release. This is
> > important because the 11u Maintainer will probably not have the
> > possibility to test on all the supported platforms and all the
> > different configurations on his own
>
> > - it will also make it transparent to the community which non-security
> > changes will be integrated into the next update release.
>
> There are potentially some issues here. We may have to integrate
> non-security fixes into the hidden CPU tree, and we may have to do
> that in a way that people outside the VG cannot see. So yes, that's
> highly desirable, but no promises.
>

Yes, but this should be only for the fairly rare cases, where a
security fix has some dependency on a non-security change and pulling
that non-security change in via jdk-updates/jdk11u would disclose
something about the upcoming security change. Otherwise, I still think
it would be advisable to do such changes in jdk-updates/jdk11u and
regularly merge them into jdk-updates/jdk11u-sec.

Sorry if my insistence in doing as much as possible of the
non-security work in in jdk-updates/jdk11u (and pulling it from there
into jdk-updates/jdk11u-sec) seems stubborn. I understand that it may
produce a little extra-overhead on the side of the
jdk-updates/jdk11u-sec maintainers. On the other side, it makes the
live for all the other down-stream consumers easier, leads to better
test coverage for the update release and keeps the VG mailing list
focused on vulnerability issues. Otherwise, it would be necessary to
also communicate and discuss the non-security fixes done in the
"closed" jdk-updates/jdk11u-sec over the VG mailing list.

> > - having both these repos gives other down-stream distributors, who
> > are also members of the OpenJDK Vulnerability Group, a chance to test
> > the non-security PLUS the security fixes together (which should be
> > pretty close to the version Maintainer is preparing and testing) on
> > all their platforms and for all their configurations.
> >
> > Please let me know what you think about this proposal. I'm obviously
> > mostly interested in the opinion of the new, designated jdk11u
> > Maintener, but I think this is an important topic for all potential
> > jdk11u downstream distributors.
> >
> > I would also be happy to add this write-up and picture (or a
> > consolidated version thereof) to the JDK11u Wiki at
> > https://wiki.openjdk.java.net/display/JDKUpdates/JDK11u if somebody
> > thinks that it my be useful.
>
> This doesn't sound significantly different from what we already do for
> jdk7. We must have two repositories, one for development and one
> stabilization branch. We must also have an internal repository for
> security updates.
>
> We need flexibility to do what we need to do, to begin with, and then
> we'll see how things settle out.
>
> I take it that you, or some of your people, will be happy to do some
> of the work you've described above, at least the open part?
>

Yes, sure - why not :)

> --
> 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 aph at redhat.com  Wed Feb 13 18:38:19 2019
From: aph at redhat.com (Andrew Haley)
Date: Wed, 13 Feb 2019 18:38:19 +0000
Subject: JDK 11.0.3 Update process
In-Reply-To: <CA+3eh13GiMDF-8_kofUqzZvCWK2_va+DRMJDtYm6COSDLzQV6g@mail.gmail.com>
References: <c7027fa19a28408e83461360f3ce6974@sap.com>
 <CA+3eh12Rtb1MQt2xr-Tu8svvZ0+NEWs4bsn0oRpnHyGhXF0fqA@mail.gmail.com>
 <be92b505-d50b-097c-d26f-f9768c90cbd0@redhat.com>
 <CA+3eh13GiMDF-8_kofUqzZvCWK2_va+DRMJDtYm6COSDLzQV6g@mail.gmail.com>
Message-ID: <586ca28f-83c9-1703-040c-f9cb1f3b6180@redhat.com>

On 2/13/19 6:30 PM, Volker Simonis wrote:
>> There are potentially some issues here. We may have to integrate
>> non-security fixes into the hidden CPU tree, and we may have to do
>> that in a way that people outside the VG cannot see. So yes, that's
>> highly desirable, but no promises.
>>
> Yes, but this should be only for the fairly rare cases, where a
> security fix has some dependency on a non-security change and pulling
> that non-security change in via jdk-updates/jdk11u would disclose
> something about the upcoming security change. Otherwise, I still think
> it would be advisable to do such changes in jdk-updates/jdk11u and
> regularly merge them into jdk-updates/jdk11u-sec.

Well, yes, but not if doing so impacts our ability to deliver the CPU in
a timely way. We'll try.

> Sorry if my insistence in doing as much as possible of the
> non-security work in in jdk-updates/jdk11u (and pulling it from there
> into jdk-updates/jdk11u-sec) seems stubborn. I understand that it may
> produce a little extra-overhead on the side of the
> jdk-updates/jdk11u-sec maintainers. On the other side, it makes the
> live for all the other down-stream consumers easier, leads to better
> test coverage for the update release and keeps the VG mailing list
> focused on vulnerability issues. Otherwise, it would be necessary to
> also communicate and discuss the non-security fixes done in the
> "closed" jdk-updates/jdk11u-sec over the VG mailing list.

Yes, I get that. But I will not tie the hands of the developers in the
critical path.

-- 
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 christoph.langer at sap.com  Wed Feb 13 22:06:43 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 13 Feb 2019 22:06:43 +0000
Subject: RFD: Draft guidelines for working on jdk8u
In-Reply-To: <CABi63P4gNURFa78UOPHobN6LMqw0QRU9t6b7doTyWVUwu_gApA@mail.gmail.com>
References: <119c5824-262e-b0d9-8a33-ceac24b7a8ab@redhat.com>
 <09404bec-476f-8191-1319-60266a4f9631@linux.vnet.ibm.com>
 <963bb29b-7f90-6744-ddb4-132609d1d689@redhat.com>
 <CAP7YuAQAURsncaLZn=fJQ2N=h1EaMSMp2+aNNVkaT9vvsrKESg@mail.gmail.com>
 <29e286ca-013b-023d-1cee-5938f551ceb7@redhat.com>
 <CAP7YuATnZA3ie9mLAj2w7U9Q1TuS1ao+fKx6rQcwYBrd=-vL6g@mail.gmail.com>
 <CA+3eh11FXBFBfUyesMroqozUmTrUeJunoGk7ON3cKpt-4-bedA@mail.gmail.com>
 <CABi63P4gNURFa78UOPHobN6LMqw0QRU9t6b7doTyWVUwu_gApA@mail.gmail.com>
Message-ID: <9939e07c22e8495c8cacf4e04b9ae6ab@sap.com>

Hi,

> -----Original Message-----
> From: jdk8u-dev <jdk8u-dev-bounces at openjdk.java.net> On Behalf Of
> Andrew Hughes
> Sent: Mittwoch, 13. Februar 2019 17:50
> To: Volker Simonis <volker.simonis at gmail.com>
> Cc: jdk8u-dev at openjdk.java.net; jdk-updates-dev at openjdk.java.net
> Subject: Re: RFD: Draft guidelines for working on jdk8u
> 
> I'd like to see 11u & 8u working in a similar way to minimise confusion. That
> means 8u adopting the tagging process from 11u, and 11 having two trees
> so we can separate release-ready sources from development sources.
> 
> I've been thinking over a few things, but being too caught up with the
> last lingering
> parts of the CPU to post. My current idea is:
> 
> 1. Changes are pushed to jdkxxu-dev after review and approval.
> 
> 2. At regular periods (fortnightly?), changes are promoted to jdkxxu and
> tagged.
> 
> 3. At a point before the CPU (basically when we have the patches, which is
> usually at most a month before), jdkxxu is declared frozen so we have a base
> for the update.
> 
> 4. When the CPU is unembargoed, the changes are pushed to both trees and
> a release made. jdkxxu is unfrozen and #2 resumes.
> 
> We will need something more involved if there are changes in jdkxxu-dev
> which
> may need longer to soak. I would suggest they use a project tree or a new
> tree
> within jdkxxu, then they are promoted to jdkxxu-dev when ready. This is
> much
> like the way the AArch64 & PPC ports were added and is essentially a third
> level below jdkxxu-dev.

+1

> I think we need to stick to a restricted set of maintainers for jdkxx, as I said
> before [0]. The lead should obviously be one of those. I'll
> additionally nominate
> myself as someone who has a lot of experience of doing such merges and
> releases, e.g with OpenJDK 6 & 7. But we should aim for more people so we
> have some redundancy.

Right. The team at SAP volunteers for being involved as co-maintainers of jdk11u. ??

> I think that's broadly along similar lines to what you posted to the
> updates list earlier.

Yes, it looks to me as there is some common understanding here...
 
Best regards
Christoph


From rasbold at google.com  Wed Feb 13 23:06:01 2019
From: rasbold at google.com (Chuck Rasbold)
Date: Wed, 13 Feb 2019 15:06:01 -0800
Subject: [11u-communication] CFV: 11u lead maintainer nomination for
 Andrew Haley
In-Reply-To: <20190212000937.GE5290@vimes>
References: <20190212000937.GE5290@vimes>
Message-ID: <CALFb4KuuCD=L6=i9-zJ8xrBdVKnk5r=Z59Rfw=vTBrbQHBW+oQ@mail.gmail.com>

Vote: yes

On Mon, Feb 11, 2019 at 4:10 PM Rob McKenna <rob.mckenna at oracle.com> wrote:

> As the Project Lead, I would like to ask for your vote for the
> nomination [0] of Andrew Haley as future lead maintainer.
>
> Votes are due by the 18th of February.
>
> Only current JDK Updates Committers [1] are eligible to vote
> on this nomination.  Votes must be cast in the open by replying
> "Vote: yes" to this mail.
>
> For Lazy Consensus voting instructions, see [2].
>
>   -Rob
>
> [0]
> https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-February/000379.html
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/bylaws#lazy-consensus
>
>

From zgu at redhat.com  Thu Feb 14 15:22:48 2019
From: zgu at redhat.com (zgu at redhat.com)
Date: Thu, 14 Feb 2019 10:22:48 -0500
Subject: [11u] RFR 8200109: NMT: diff_malloc_site assert(early->flags() ==
 current->flags(), "Must be the same memory type")
Message-ID: <1550157768.10039.6.camel@redhat.com>

I would like to backport this patch to 11u. The JDK13 patch does not
apply cleanly, but they are minor conflicts.

Bug: https://bugs.openjdk.java.net/browse/JDK-8200109
JDK13 Webrev: http://cr.openjdk.java.net/~zgu/JDK-8200109/webrev.00/
JDK13 code review: https://mail.openjdk.java.net/pipermail/hotspot-runt
ime-dev/2019-February/032463.html

JDK11u Webrev: http://cr.openjdk.java.net/~zgu/JDK-8200109-11u/webrev.0
0/

Test:
  hotspot_nmt on Linux x64(fastdebug and release)

Thanks,

-Zhengyu

From shade at redhat.com  Thu Feb 14 15:25:55 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 14 Feb 2019 16:25:55 +0100
Subject: [11u] RFR 8200109: NMT: diff_malloc_site assert(early->flags() ==
 current->flags(), "Must be the same memory type")
In-Reply-To: <1550157768.10039.6.camel@redhat.com>
References: <1550157768.10039.6.camel@redhat.com>
Message-ID: <4c8adda3-9b6c-d2d9-55ce-2dee6d2a6f79@redhat.com>

On 2/14/19 4:22 PM, zgu at redhat.com wrote:
> JDK11u Webrev: http://cr.openjdk.java.net/~zgu/JDK-8200109-11u/webrev.00/

This still looks good to me.

-Aleksey


From zgu at redhat.com  Thu Feb 14 15:44:50 2019
From: zgu at redhat.com (zgu at redhat.com)
Date: Thu, 14 Feb 2019 10:44:50 -0500
Subject: [11u] RFR 8200109: NMT: diff_malloc_site assert(early->flags()
 == current->flags(), "Must be the same memory type")
In-Reply-To: <4c8adda3-9b6c-d2d9-55ce-2dee6d2a6f79@redhat.com>
References: <1550157768.10039.6.camel@redhat.com>
 <4c8adda3-9b6c-d2d9-55ce-2dee6d2a6f79@redhat.com>
Message-ID: <1550159090.10039.7.camel@redhat.com>

On Thu, 2019-02-14 at 16:25 +0100, Aleksey Shipilev wrote:
> On 2/14/19 4:22 PM, zgu at redhat.com wrote:
> > JDK11u Webrev: http://cr.openjdk.java.net/~zgu/JDK-8200109-11u/webr
> > ev.00/
> 
> This still looks good to me.

Thanks,

-Zhengyu

> 
> -Aleksey
> 

From shade at redhat.com  Thu Feb 14 18:21:01 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 14 Feb 2019 19:21:01 +0100
Subject: RFR (S) 8217342: Build failed with excluding JFR
Message-ID: <a49c2674-1a9d-f304-fd88-34aa9b97d102@redhat.com>

Please review the backport of build-related change:

  Original Bug:
      URL: https://bugs.openjdk.java.net/browse/JDK-8217342
      Reporter: Zhengyu Gu
      Assignee: Zhengyu Gu
      Priority: P4
      Components: hotspot

  Original Fix:
        13: JDK-8217342, http://hg.openjdk.java.net/jdk/jdk/rev/690aed53fef0, 25 day(s) ago

  Backports and Forwardports:
        12: MISSING
        11: MISSING
         8: Not affected

The patch does not apply cleanly to 12u, because there is a minor conflict in includes in Shenandoah
code that is removed by patch anyway. The patch does not apply cleanly to 11u, because there is no
Shenandoah in jdk-updates/jdk11u repo.

11u backport:
  http://cr.openjdk.java.net/~shade/8217342/webrev.11u.01/

12u backport:
  http://cr.openjdk.java.net/~shade/8217342/webrev.12u.01/

Testing: Linux x86_64 build, no-pch, {fastdebug,release} x {default, -jfr}

Thanks,
-Aleksey


From zgu at redhat.com  Thu Feb 14 18:26:47 2019
From: zgu at redhat.com (zgu at redhat.com)
Date: Thu, 14 Feb 2019 13:26:47 -0500
Subject: RFR (S) 8217342: Build failed with excluding JFR
In-Reply-To: <a49c2674-1a9d-f304-fd88-34aa9b97d102@redhat.com>
References: <a49c2674-1a9d-f304-fd88-34aa9b97d102@redhat.com>
Message-ID: <1550168807.10039.12.camel@redhat.com>

On Thu, 2019-02-14 at 19:21 +0100, Aleksey Shipilev wrote:
> Please review the backport of build-related change:
> 
>   Original Bug:
>       URL: https://bugs.openjdk.java.net/browse/JDK-8217342
>       Reporter: Zhengyu Gu
>       Assignee: Zhengyu Gu
>       Priority: P4
>       Components: hotspot
> 
>   Original Fix:
>         13: JDK-8217342, http://hg.openjdk.java.net/jdk/jdk/rev/690ae
> d53fef0, 25 day(s) ago
> 
>   Backports and Forwardports:
>         12: MISSING
>         11: MISSING
>          8: Not affected
> 
> The patch does not apply cleanly to 12u, because there is a minor
> conflict in includes in Shenandoah
> code that is removed by patch anyway. The patch does not apply
> cleanly to 11u, because there is no
> Shenandoah in jdk-updates/jdk11u repo.
> 
> 11u backport:
>   http://cr.openjdk.java.net/~shade/8217342/webrev.11u.01/
> 
> 12u backport:
>   http://cr.openjdk.java.net/~shade/8217342/webrev.12u.01/
> 
Backport looks good to me.

Thanks,

-Zhengyu


> Testing: Linux x86_64 build, no-pch, {fastdebug,release} x {default,
> -jfr}
> 
> Thanks,
> -Aleksey
> 

From daniel.daugherty at oracle.com  Thu Feb 14 18:30:15 2019
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Thu, 14 Feb 2019 13:30:15 -0500
Subject: [11u-communication] CFV: 11u lead maintainer nomination for
 Andrew Haley
In-Reply-To: <20190212000937.GE5290@vimes>
References: <20190212000937.GE5290@vimes>
Message-ID: <80afbe32-ac09-fd5a-3c04-8bb58b58dd43@oracle.com>

Vote: yes

Dan


On 2/11/19 7:09 PM, Rob McKenna wrote:
> As the Project Lead, I would like to ask for your vote for the
> nomination [0] of Andrew Haley as future lead maintainer.
>
> Votes are due by the 18th of February.
>
> Only current JDK Updates Committers [1] are eligible to vote
> on this nomination.  Votes must be cast in the open by replying
> "Vote: yes" to this mail.
>
> For Lazy Consensus voting instructions, see [2].
>
>    -Rob
>
> [0] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-February/000379.html
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/bylaws#lazy-consensus
>
>


From sean.coffey at oracle.com  Thu Feb 14 18:49:13 2019
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Thu, 14 Feb 2019 18:49:13 +0000
Subject: [11u-communication] CFV: 11u lead maintainer nomination for
 Andrew Haley
In-Reply-To: <20190212000937.GE5290@vimes>
References: <20190212000937.GE5290@vimes>
Message-ID: <5b131840-e34e-1b25-fa92-dd86ce0fcaf1@oracle.com>

Vote: yes

regards,
Sean.

On 12/02/2019 00:09, Rob McKenna wrote:
> As the Project Lead, I would like to ask for your vote for the
> nomination [0] of Andrew Haley as future lead maintainer.
>
> Votes are due by the 18th of February.
>
> Only current JDK Updates Committers [1] are eligible to vote
> on this nomination.  Votes must be cast in the open by replying
> "Vote: yes" to this mail.
>
> For Lazy Consensus voting instructions, see [2].
>
>    -Rob
>
> [0] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-February/000379.html
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/bylaws#lazy-consensus
>

From alexey.ivanov at oracle.com  Thu Feb 14 20:38:47 2019
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Thu, 14 Feb 2019 20:38:47 +0000
Subject: [11u-communication] CFV: 11u lead maintainer nomination for
 Andrew Haley
In-Reply-To: <20190212000937.GE5290@vimes>
References: <20190212000937.GE5290@vimes>
Message-ID: <4bb76619-e3f4-7894-62f4-93fb3b3b47b3@oracle.com>

Vote: yes

-- 
Regards,
Alexey

On 12/02/2019 00:09, Rob McKenna wrote:
> As the Project Lead, I would like to ask for your vote for the
> nomination [0] of Andrew Haley as future lead maintainer.
>
> Votes are due by the 18th of February.
>
> Only current JDK Updates Committers [1] are eligible to vote
> on this nomination.  Votes must be cast in the open by replying
> "Vote: yes" to this mail.
>
> For Lazy Consensus voting instructions, see [2].
>
>    -Rob
>
> [0] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-February/000379.html
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/bylaws#lazy-consensus
>


From gnu.andrew at redhat.com  Thu Feb 14 21:40:00 2019
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Thu, 14 Feb 2019 21:40:00 +0000
Subject: [11u-communication] CFV: 11u lead maintainer nomination for
 Andrew Haley
In-Reply-To: <20190212000937.GE5290@vimes>
References: <20190212000937.GE5290@vimes>
Message-ID: <CABi63P49ob5vwOu__XW4QQJVRQ5qo3edRy5=_vt0SkgNF3WYpg@mail.gmail.com>

On Tue, 12 Feb 2019 at 00:10, Rob McKenna <rob.mckenna at oracle.com> wrote:
>
> As the Project Lead, I would like to ask for your vote for the
> nomination [0] of Andrew Haley as future lead maintainer.
>
> Votes are due by the 18th of February.
>
> Only current JDK Updates Committers [1] are eligible to vote
> on this nomination.  Votes must be cast in the open by replying
> "Vote: yes" to this mail.
>
> For Lazy Consensus voting instructions, see [2].
>
>   -Rob
>
> [0] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-February/000379.html
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/bylaws#lazy-consensus
>

Vote: Yes.
-- 
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 naoto.sato at oracle.com  Thu Feb 14 22:37:57 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Thu, 14 Feb 2019 14:37:57 -0800
Subject: [11u-communication] CFV: 11u lead maintainer nomination for
 Andrew Haley
In-Reply-To: <20190212000937.GE5290@vimes>
References: <20190212000937.GE5290@vimes>
Message-ID: <56cd4258-27bf-1742-0cb7-2d67daa2170c@oracle.com>

Vote: yes

Naoto

On 2/11/19 4:09 PM, Rob McKenna wrote:
> As the Project Lead, I would like to ask for your vote for the
> nomination [0] of Andrew Haley as future lead maintainer.
> 
> Votes are due by the 18th of February.
> 
> Only current JDK Updates Committers [1] are eligible to vote
> on this nomination.  Votes must be cast in the open by replying
> "Vote: yes" to this mail.
> 
> For Lazy Consensus voting instructions, see [2].
> 
>    -Rob
> 
> [0] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-February/000379.html
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/bylaws#lazy-consensus
> 

From volker.simonis at gmail.com  Fri Feb 15 09:14:39 2019
From: volker.simonis at gmail.com (Volker Simonis)
Date: Fri, 15 Feb 2019 10:14:39 +0100
Subject: JDK 11.0.3 Update process
In-Reply-To: <586ca28f-83c9-1703-040c-f9cb1f3b6180@redhat.com>
References: <c7027fa19a28408e83461360f3ce6974@sap.com>
 <CA+3eh12Rtb1MQt2xr-Tu8svvZ0+NEWs4bsn0oRpnHyGhXF0fqA@mail.gmail.com>
 <be92b505-d50b-097c-d26f-f9768c90cbd0@redhat.com>
 <CA+3eh13GiMDF-8_kofUqzZvCWK2_va+DRMJDtYm6COSDLzQV6g@mail.gmail.com>
 <586ca28f-83c9-1703-040c-f9cb1f3b6180@redhat.com>
Message-ID: <CA+3eh13WReDH2JHfAQDhRwxMnhQOvPt3Ab7D_eMN_eYdunnbmw@mail.gmail.com>

As it seems we all agree on having a second jdk11u-dev repository,
maybe we can already request it?

I'm not sure about the exact process here, but I think the jdk-updates
project lead has to do this?

@Rob: could you please request the creation of a new
jdk-updates/jdk11u-dev repository or otherwise tell us what we'll have
to do in order to get such a repository?

Thank you and best regards,
Volker

On Wed, Feb 13, 2019 at 7:38 PM Andrew Haley <aph at redhat.com> wrote:
>
> On 2/13/19 6:30 PM, Volker Simonis wrote:
> >> There are potentially some issues here. We may have to integrate
> >> non-security fixes into the hidden CPU tree, and we may have to do
> >> that in a way that people outside the VG cannot see. So yes, that's
> >> highly desirable, but no promises.
> >>
> > Yes, but this should be only for the fairly rare cases, where a
> > security fix has some dependency on a non-security change and pulling
> > that non-security change in via jdk-updates/jdk11u would disclose
> > something about the upcoming security change. Otherwise, I still think
> > it would be advisable to do such changes in jdk-updates/jdk11u and
> > regularly merge them into jdk-updates/jdk11u-sec.
>
> Well, yes, but not if doing so impacts our ability to deliver the CPU in
> a timely way. We'll try.
>
> > Sorry if my insistence in doing as much as possible of the
> > non-security work in in jdk-updates/jdk11u (and pulling it from there
> > into jdk-updates/jdk11u-sec) seems stubborn. I understand that it may
> > produce a little extra-overhead on the side of the
> > jdk-updates/jdk11u-sec maintainers. On the other side, it makes the
> > live for all the other down-stream consumers easier, leads to better
> > test coverage for the update release and keeps the VG mailing list
> > focused on vulnerability issues. Otherwise, it would be necessary to
> > also communicate and discuss the non-security fixes done in the
> > "closed" jdk-updates/jdk11u-sec over the VG mailing list.
>
> Yes, I get that. But I will not tie the hands of the developers in the
> critical path.
>
> --
> 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 aph at redhat.com  Fri Feb 15 09:50:10 2019
From: aph at redhat.com (Andrew Haley)
Date: Fri, 15 Feb 2019 09:50:10 +0000
Subject: JDK 11.0.3 Update process
In-Reply-To: <CA+3eh13WReDH2JHfAQDhRwxMnhQOvPt3Ab7D_eMN_eYdunnbmw@mail.gmail.com>
References: <c7027fa19a28408e83461360f3ce6974@sap.com>
 <CA+3eh12Rtb1MQt2xr-Tu8svvZ0+NEWs4bsn0oRpnHyGhXF0fqA@mail.gmail.com>
 <be92b505-d50b-097c-d26f-f9768c90cbd0@redhat.com>
 <CA+3eh13GiMDF-8_kofUqzZvCWK2_va+DRMJDtYm6COSDLzQV6g@mail.gmail.com>
 <586ca28f-83c9-1703-040c-f9cb1f3b6180@redhat.com>
 <CA+3eh13WReDH2JHfAQDhRwxMnhQOvPt3Ab7D_eMN_eYdunnbmw@mail.gmail.com>
Message-ID: <eadfaea4-b1f2-e15f-56f4-aa120072b14b@redhat.com>

On 2/15/19 9:14 AM, Volker Simonis wrote:
> @Rob: could you please request the creation of a new
> jdk-updates/jdk11u-dev repository or otherwise tell us what we'll have
> to do in order to get such a repository?

The project lead requests ops@ to do it.

-- 
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 dmitry.markov at oracle.com  Fri Feb 15 11:44:13 2019
From: dmitry.markov at oracle.com (Dmitry Markov)
Date: Fri, 15 Feb 2019 11:44:13 +0000
Subject: [11u-communication] CFV: 11u lead maintainer nomination for
 Andrew Haley
In-Reply-To: <20190212000937.GE5290@vimes>
References: <20190212000937.GE5290@vimes>
Message-ID: <6DDF139C-E10C-45FF-B9DF-B38E03FFCC09@oracle.com>

Vote: Yes

Thanks,
Dmitry

> On 12 Feb 2019, at 00:09, Rob McKenna <rob.mckenna at oracle.com> wrote:
> 
> As the Project Lead, I would like to ask for your vote for the
> nomination [0] of Andrew Haley as future lead maintainer.
> 
> Votes are due by the 18th of February.
> 
> Only current JDK Updates Committers [1] are eligible to vote
> on this nomination.  Votes must be cast in the open by replying
> "Vote: yes" to this mail.
> 
> For Lazy Consensus voting instructions, see [2].
> 
>  -Rob
> 
> [0] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-February/000379.html
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/bylaws#lazy-consensus
> 


From christoph.langer at sap.com  Fri Feb 15 13:32:39 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 15 Feb 2019 13:32:39 +0000
Subject: JDK 11.0.3 Update process
In-Reply-To: <eadfaea4-b1f2-e15f-56f4-aa120072b14b@redhat.com>
References: <c7027fa19a28408e83461360f3ce6974@sap.com>
 <CA+3eh12Rtb1MQt2xr-Tu8svvZ0+NEWs4bsn0oRpnHyGhXF0fqA@mail.gmail.com>
 <be92b505-d50b-097c-d26f-f9768c90cbd0@redhat.com>
 <CA+3eh13GiMDF-8_kofUqzZvCWK2_va+DRMJDtYm6COSDLzQV6g@mail.gmail.com>
 <586ca28f-83c9-1703-040c-f9cb1f3b6180@redhat.com>
 <CA+3eh13WReDH2JHfAQDhRwxMnhQOvPt3Ab7D_eMN_eYdunnbmw@mail.gmail.com>
 <eadfaea4-b1f2-e15f-56f4-aa120072b14b@redhat.com>
Message-ID: <1c9f80b75b7b492b9e463445eafd7c3d@sap.com>

Hi folks,

generally, I think we should definitely request the jdk11u-dev repository asap and at that very moment branch JDK 11.0.3 stabilization work from JDK 11.0.4 commits.

Currently the process around the jdk11u repository is that once a change gets pushed in there, a JBS issue is created, indicating that the issue was fixed/backported to release "11.0.3". When we have the new jdk11u-dev repository and made the cutoff, changes pushed to jdk11u-dev should be backported as 11.0.4 while changes pushed to jdk11u need to be tagged 11.0.3.

So, I suggest the following process when creating jdk11u-dev (The Andrews/Redhat need to confirm whether it fits for them...)

1. Close the jdk11u repository for commits (only the maintainers of jdk11 should have push authority).
2. Request the new repo jdk11u-dev as a clone of jdk11u (no commits yet allowed).
3. Make sure the system is set up to automatically create backport bugs for 11.0.4 when commits are made in jdk11u-dev.
4. Open jdk11u-dev for commits for the world.

Then the jdk 11.0.3 stabilization work can start. And once jdk 11.0.4 stabilization work starts, the system has to be changed in that jdk11u will create 11.0.4 backports and jdk11u-dev will do 11.0.5.

Does that make sense?

Thanks
Christoph


> -----Original Message-----
> From: Andrew Haley <aph at redhat.com>
> Sent: Freitag, 15. Februar 2019 10:50
> To: Volker Simonis <volker.simonis at gmail.com>; Rob McKenna
> <rob.mckenna at oracle.com>
> Cc: jdk-updates-dev at openjdk.java.net; Andrew Hughes
> <gnu.andrew at redhat.com>; Zeller, Arno <arno.zeller at sap.com>; Ren?
> Sch?nemann <rene.schuenemann at gmail.com>; Langer, Christoph
> <christoph.langer at sap.com>
> Subject: Re: JDK 11.0.3 Update process
> 
> On 2/15/19 9:14 AM, Volker Simonis wrote:
> > @Rob: could you please request the creation of a new
> > jdk-updates/jdk11u-dev repository or otherwise tell us what we'll have
> > to do in order to get such a repository?
> 
> The project lead requests ops@ to do it.
> 
> --
> 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 aph at redhat.com  Fri Feb 15 13:44:11 2019
From: aph at redhat.com (Andrew Haley)
Date: Fri, 15 Feb 2019 13:44:11 +0000
Subject: JDK 11.0.3 Update process
In-Reply-To: <1c9f80b75b7b492b9e463445eafd7c3d@sap.com>
References: <c7027fa19a28408e83461360f3ce6974@sap.com>
 <CA+3eh12Rtb1MQt2xr-Tu8svvZ0+NEWs4bsn0oRpnHyGhXF0fqA@mail.gmail.com>
 <be92b505-d50b-097c-d26f-f9768c90cbd0@redhat.com>
 <CA+3eh13GiMDF-8_kofUqzZvCWK2_va+DRMJDtYm6COSDLzQV6g@mail.gmail.com>
 <586ca28f-83c9-1703-040c-f9cb1f3b6180@redhat.com>
 <CA+3eh13WReDH2JHfAQDhRwxMnhQOvPt3Ab7D_eMN_eYdunnbmw@mail.gmail.com>
 <eadfaea4-b1f2-e15f-56f4-aa120072b14b@redhat.com>
 <1c9f80b75b7b492b9e463445eafd7c3d@sap.com>
Message-ID: <cbaa356a-54b2-7c18-5b0b-3cdc12f58f46@redhat.com>

On 2/15/19 1:32 PM, Langer, Christoph wrote:

> So, I suggest the following process when creating jdk11u-dev (The
> Andrews/Redhat need to confirm whether it fits for them...)
> 
> 1. Close the jdk11u repository for commits (only the maintainers of
> jdk11 should have push authority).

Let's not. There's more of a risk that we get stuck on something
urgent for lack of a maintainer to push than there is of unauthorized
committers pushing bad patches. Committers can be trusted.

> 2. Request the new repo jdk11u-dev as a clone of jdk11u (no commits
> yet allowed).

> 3. Make sure the system is set up to automatically create backport
> bugs for 11.0.4 when commits are made in jdk11u-dev.

I have no idea how to do that.

> 4. Open jdk11u-dev for commits for the world.

-- 
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 christoph.langer at sap.com  Fri Feb 15 13:48:23 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 15 Feb 2019 13:48:23 +0000
Subject: JDK 11.0.3 Update process
In-Reply-To: <cbaa356a-54b2-7c18-5b0b-3cdc12f58f46@redhat.com>
References: <c7027fa19a28408e83461360f3ce6974@sap.com>
 <CA+3eh12Rtb1MQt2xr-Tu8svvZ0+NEWs4bsn0oRpnHyGhXF0fqA@mail.gmail.com>
 <be92b505-d50b-097c-d26f-f9768c90cbd0@redhat.com>
 <CA+3eh13GiMDF-8_kofUqzZvCWK2_va+DRMJDtYm6COSDLzQV6g@mail.gmail.com>
 <586ca28f-83c9-1703-040c-f9cb1f3b6180@redhat.com>
 <CA+3eh13WReDH2JHfAQDhRwxMnhQOvPt3Ab7D_eMN_eYdunnbmw@mail.gmail.com>
 <eadfaea4-b1f2-e15f-56f4-aa120072b14b@redhat.com>
 <1c9f80b75b7b492b9e463445eafd7c3d@sap.com>
 <cbaa356a-54b2-7c18-5b0b-3cdc12f58f46@redhat.com>
Message-ID: <ac14d4d8395f45059ad9855d6e354ed8@sap.com>

Hi Andrew,

> > 1. Close the jdk11u repository for commits (only the maintainers of
> > jdk11 should have push authority).
> 
> Let's not. There's more of a risk that we get stuck on something
> urgent for lack of a maintainer to push than there is of unauthorized
> committers pushing bad patches. Committers can be trusted.

Ok, why not ??


> > 2. Request the new repo jdk11u-dev as a clone of jdk11u (no commits
> > yet allowed).
> 
> > 3. Make sure the system is set up to automatically create backport
> > bugs for 11.0.4 when commits are made in jdk11u-dev.
> 
> I have no idea how to do that.

@Rob McKenna: Can you help us with that? Is that something which can be requested by mail to ops at ... ?

> 
> > 4. Open jdk11u-dev for commits for the world.
> 

Best regards
Christoph

From christoph.langer at sap.com  Fri Feb 15 13:58:36 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 15 Feb 2019 13:58:36 +0000
Subject: 11.0.3-oracle issues in openjdk 11.0.3
Message-ID: <a1feaea79b634373bef62e7f471c5418@sap.com>

Hi again,

it?s common knowledge amongst those engaged here, that there will be an Oracle JDK 11.0.3 update and an OpenJDK 11.0.3 edition. In the JBS bug system, we can see fixes marked as ?11.0.3? if they target the OpenJDK and those going into Oracle are marked ?11.0.3-oracle?. As the OpenJDK updates should be at least as good as the Oracle editions I think we should port the fixes that are in Oracle?s 11.0.3-oracle version to OpenJDK 11u.

I?ve created a JBS filter that lists all issues that have been backported to 11.0.3-oracle but don?t have 11.0.3 backports yet [1]. As the filter uses some more advanced Jira queries, you?ll need to be logged in to find it working. Maybe the query also has a bug or two ? I?m looking forward for comments/suggestions ??

So, looking at my query, I can see that there?s some 43 issues which ought to be brought to jdk11u.

I would volunteer for doing the work to go through the list and do the downporting. I would first check if the upstream patches apply, then request the downport approval and do the pushes. If the changes don?t apply cleanly I would ask for help by the original authors/reviewers of the patches or ask for help in the mailing lists. Please let me know if I should do this or not. If I don?t hear objections until Monday (02/18) EOB, I?d take it as approval and would start the works.

Thanks
Christoph


[1] https://bugs.openjdk.java.net/issues/?filter=36366


From shade at redhat.com  Fri Feb 15 15:45:29 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Fri, 15 Feb 2019 16:45:29 +0100
Subject: 11.0.3-oracle issues in openjdk 11.0.3
In-Reply-To: <a1feaea79b634373bef62e7f471c5418@sap.com>
References: <a1feaea79b634373bef62e7f471c5418@sap.com>
Message-ID: <54dc52ed-cc5f-2387-f186-1bbe2eee2e73@redhat.com>

On 2/15/19 2:58 PM, Langer, Christoph wrote:
> I?ve created a JBS filter that lists all issues that have been backported to 11.0.3-oracle but
> don?t have 11.0.3 backports yet [1]. As the filter uses some more advanced Jira queries, you?ll
> need to be logged in to find it working. Maybe the query also has a bug or two ? I?m looking
> forward for comments/suggestions ??

I find JIRA query language confusing at times. Some of us at Red Hat have scripted the JIRA clients
to produce reports for backports. Our latest attempt uses JIRA REST client:
  https://github.com/shipilev/jdk-backports-monitor/

...and it produces reports like these:
  https://builds.shipilev.net/backports-monitor/redhat-openjdk.txt

It uses special "redhat-openjdk" label to get issues on our radar. I should extend this to get
-oracle-only tagged issues there as well.

> I would volunteer for doing the work to go through the list and do the downporting. I would first
> check if the upstream patches apply, then request the downport approval and do the pushes. If the
> changes don?t apply cleanly I would ask for help by the original authors/reviewers of the patches
> or ask for help in the mailing lists. Please let me know if I should do this or not. 

I'll join you. Have already put some "redhat-openjdk" tags on issues that should be uncontroversial,
and am proceeding to request backports for them.

> If I don?t hear objections until Monday (02/18) EOB, I?d take it as approval and would start the
> works.
Not sure who's approval you are seeking here :) I think objections and maintainer approvals are per
backport anyway.

-Aleksey


From christoph.langer at sap.com  Fri Feb 15 16:00:38 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 15 Feb 2019 16:00:38 +0000
Subject: 11.0.3-oracle issues in openjdk 11.0.3
In-Reply-To: <54dc52ed-cc5f-2387-f186-1bbe2eee2e73@redhat.com>
References: <a1feaea79b634373bef62e7f471c5418@sap.com>
 <54dc52ed-cc5f-2387-f186-1bbe2eee2e73@redhat.com>
Message-ID: <bcd95e4d8bf94e88a482df98ef1be75b@sap.com>

> I find JIRA query language confusing at times. Some of us at Red Hat have
> scripted the JIRA clients
> to produce reports for backports. Our latest attempt uses JIRA REST client:
>   https://github.com/shipilev/jdk-backports-monitor/
> 
> ...and it produces reports like these:
>   https://builds.shipilev.net/backports-monitor/redhat-openjdk.txt

Looks nice.

> > I would volunteer for doing the work to go through the list and do the
> downporting. I would first
> > check if the upstream patches apply, then request the downport approval
> and do the pushes. If the
> > changes don?t apply cleanly I would ask for help by the original
> authors/reviewers of the patches
> > or ask for help in the mailing lists. Please let me know if I should do this or
> not.
> 
> I'll join you. Have already put some "redhat-openjdk" tags on issues that
> should be uncontroversial,
> and am proceeding to request backports for them.

Sounds good.

> > If I don?t hear objections until Monday (02/18) EOB, I?d take it as approval
> and would start the
> > works.
> Not sure who's approval you are seeking here :) I think objections and
> maintainer approvals are per
> backport anyway.

Yep, as per the update rules, approvals are per backport and nobody can keep me from asking for it. However, I'd try to figure out whether such an overall effort would be appreciated in general or people would say I rather shouldn't do that for whatever reason...

/Christoph


From gnu.andrew at redhat.com  Fri Feb 15 18:06:43 2019
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Fri, 15 Feb 2019 18:06:43 +0000
Subject: JDK 11.0.3 Update process
In-Reply-To: <cbaa356a-54b2-7c18-5b0b-3cdc12f58f46@redhat.com>
References: <c7027fa19a28408e83461360f3ce6974@sap.com>
 <CA+3eh12Rtb1MQt2xr-Tu8svvZ0+NEWs4bsn0oRpnHyGhXF0fqA@mail.gmail.com>
 <be92b505-d50b-097c-d26f-f9768c90cbd0@redhat.com>
 <CA+3eh13GiMDF-8_kofUqzZvCWK2_va+DRMJDtYm6COSDLzQV6g@mail.gmail.com>
 <586ca28f-83c9-1703-040c-f9cb1f3b6180@redhat.com>
 <CA+3eh13WReDH2JHfAQDhRwxMnhQOvPt3Ab7D_eMN_eYdunnbmw@mail.gmail.com>
 <eadfaea4-b1f2-e15f-56f4-aa120072b14b@redhat.com>
 <1c9f80b75b7b492b9e463445eafd7c3d@sap.com>
 <cbaa356a-54b2-7c18-5b0b-3cdc12f58f46@redhat.com>
Message-ID: <CABi63P4HtF+48sZszoonKTKA+ysuCEBrVg64bvOw52EKPS4hRA@mail.gmail.com>

On Fri, 15 Feb 2019 at 13:44, Andrew Haley <aph at redhat.com> wrote:
>
> On 2/15/19 1:32 PM, Langer, Christoph wrote:
>
> > So, I suggest the following process when creating jdk11u-dev (The
> > Andrews/Redhat need to confirm whether it fits for them...)
> >
> > 1. Close the jdk11u repository for commits (only the maintainers of
> > jdk11 should have push authority).
>
> Let's not. There's more of a risk that we get stuck on something
> urgent for lack of a maintainer to push than there is of unauthorized
> committers pushing bad patches. Committers can be trusted.

As I said before [0], I think the jdkxxu repository should be restricted,
maintaining a clear distinction between a jdkxxu-dev branch for developers
to commit to, and the jdkxxu for consumption. The latter is the one that
would be frozen and used as the base for releases around CPU time.
That avoids a situation where people push stuff to jdkxxu in the interim
and then are surprised when it's not in the release.

If there's an issue with a lack of a maintainer, then that's a sign we
need to appoint more, not abandon the whole idea.

That said, I think it's too early to be branching for 11.0.4, especially given
processes are still in a state of flux. I'd expect that more around mid-March.

[0] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-February/000416.html
-- 
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  Fri Feb 15 18:37:51 2019
From: volker.simonis at gmail.com (Volker Simonis)
Date: Fri, 15 Feb 2019 19:37:51 +0100
Subject: JDK 11.0.3 Update process
In-Reply-To: <eadfaea4-b1f2-e15f-56f4-aa120072b14b@redhat.com>
References: <c7027fa19a28408e83461360f3ce6974@sap.com>
 <CA+3eh12Rtb1MQt2xr-Tu8svvZ0+NEWs4bsn0oRpnHyGhXF0fqA@mail.gmail.com>
 <be92b505-d50b-097c-d26f-f9768c90cbd0@redhat.com>
 <CA+3eh13GiMDF-8_kofUqzZvCWK2_va+DRMJDtYm6COSDLzQV6g@mail.gmail.com>
 <586ca28f-83c9-1703-040c-f9cb1f3b6180@redhat.com>
 <CA+3eh13WReDH2JHfAQDhRwxMnhQOvPt3Ab7D_eMN_eYdunnbmw@mail.gmail.com>
 <eadfaea4-b1f2-e15f-56f4-aa120072b14b@redhat.com>
Message-ID: <CA+3eh10MM3dXhqtkm2TBAcZ_jDLh4+2Wj-SZs7ErdgOLmjEmJA@mail.gmail.com>

On Fri, Feb 15, 2019 at 10:50 AM Andrew Haley <aph at redhat.com> wrote:
>
> On 2/15/19 9:14 AM, Volker Simonis wrote:
> > @Rob: could you please request the creation of a new
> > jdk-updates/jdk11u-dev repository or otherwise tell us what we'll have
> > to do in order to get such a repository?
>
> The project lead requests ops@ to do it.
>

Yes, exactly. But Rob is the jdk-updates project lead, that's why I
was asking him to request it.

> --
> 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 john.r.rose at oracle.com  Fri Feb 15 20:24:09 2019
From: john.r.rose at oracle.com (John Rose)
Date: Fri, 15 Feb 2019 12:24:09 -0800
Subject: [11u-communication] CFV: 11u lead maintainer nomination for
 Andrew Haley
In-Reply-To: <20190212000937.GE5290@vimes>
References: <20190212000937.GE5290@vimes>
Message-ID: <2D693EB7-58EE-448F-8DDE-76DB94E7E469@oracle.com>

Vote: yes (with pleasure)

From christoph.langer at sap.com  Fri Feb 15 22:15:21 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 15 Feb 2019 22:15:21 +0000
Subject: JDK 11.0.3 Update process
In-Reply-To: <CABi63P4HtF+48sZszoonKTKA+ysuCEBrVg64bvOw52EKPS4hRA@mail.gmail.com>
References: <c7027fa19a28408e83461360f3ce6974@sap.com>
 <CA+3eh12Rtb1MQt2xr-Tu8svvZ0+NEWs4bsn0oRpnHyGhXF0fqA@mail.gmail.com>
 <be92b505-d50b-097c-d26f-f9768c90cbd0@redhat.com>
 <CA+3eh13GiMDF-8_kofUqzZvCWK2_va+DRMJDtYm6COSDLzQV6g@mail.gmail.com>
 <586ca28f-83c9-1703-040c-f9cb1f3b6180@redhat.com>
 <CA+3eh13WReDH2JHfAQDhRwxMnhQOvPt3Ab7D_eMN_eYdunnbmw@mail.gmail.com>
 <eadfaea4-b1f2-e15f-56f4-aa120072b14b@redhat.com>
 <1c9f80b75b7b492b9e463445eafd7c3d@sap.com>
 <cbaa356a-54b2-7c18-5b0b-3cdc12f58f46@redhat.com>
 <CABi63P4HtF+48sZszoonKTKA+ysuCEBrVg64bvOw52EKPS4hRA@mail.gmail.com>
Message-ID: <4c96311d2d4c49d18691d19c8ea94723@sap.com>

Hi,

> On Fri, 15 Feb 2019 at 13:44, Andrew Haley <aph at redhat.com> wrote:
> >
> > On 2/15/19 1:32 PM, Langer, Christoph wrote:
> >
> > > So, I suggest the following process when creating jdk11u-dev (The
> > > Andrews/Redhat need to confirm whether it fits for them...)
> > >
> > > 1. Close the jdk11u repository for commits (only the maintainers of
> > > jdk11 should have push authority).
> >
> > Let's not. There's more of a risk that we get stuck on something
> > urgent for lack of a maintainer to push than there is of unauthorized
> > committers pushing bad patches. Committers can be trusted.
> 
> As I said before [0], I think the jdkxxu repository should be restricted,
> maintaining a clear distinction between a jdkxxu-dev branch for developers
> to commit to, and the jdkxxu for consumption. The latter is the one that
> would be frozen and used as the base for releases around CPU time.
> That avoids a situation where people push stuff to jdkxxu in the interim
> and then are surprised when it's not in the release.

That's exactly my point of view.

> If there's an issue with a lack of a maintainer, then that's a sign we
> need to appoint more, not abandon the whole idea.

For jdk11 updates, the SAP team is definitely willing to help.

> That said, I think it's too early to be branching for 11.0.4, especially given
> processes are still in a state of flux. I'd expect that more around mid-March.

Sounds reasonable. Nevertheless, we should start the work to get the repos and the infrastructure (e.g. fix version labeling) set up now to get a smooth process for 11.0.3 delivery.

Best
Christoph


From aph at redhat.com  Sat Feb 16 09:45:31 2019
From: aph at redhat.com (Andrew Haley)
Date: Sat, 16 Feb 2019 09:45:31 +0000
Subject: JDK 11.0.3 Update process
In-Reply-To: <CABi63P4HtF+48sZszoonKTKA+ysuCEBrVg64bvOw52EKPS4hRA@mail.gmail.com>
References: <c7027fa19a28408e83461360f3ce6974@sap.com>
 <CA+3eh12Rtb1MQt2xr-Tu8svvZ0+NEWs4bsn0oRpnHyGhXF0fqA@mail.gmail.com>
 <be92b505-d50b-097c-d26f-f9768c90cbd0@redhat.com>
 <CA+3eh13GiMDF-8_kofUqzZvCWK2_va+DRMJDtYm6COSDLzQV6g@mail.gmail.com>
 <586ca28f-83c9-1703-040c-f9cb1f3b6180@redhat.com>
 <CA+3eh13WReDH2JHfAQDhRwxMnhQOvPt3Ab7D_eMN_eYdunnbmw@mail.gmail.com>
 <eadfaea4-b1f2-e15f-56f4-aa120072b14b@redhat.com>
 <1c9f80b75b7b492b9e463445eafd7c3d@sap.com>
 <cbaa356a-54b2-7c18-5b0b-3cdc12f58f46@redhat.com>
 <CABi63P4HtF+48sZszoonKTKA+ysuCEBrVg64bvOw52EKPS4hRA@mail.gmail.com>
Message-ID: <98ff609e-91f2-f84f-07b0-5dbafb98f802@redhat.com>

On 2/15/19 6:06 PM, Andrew Hughes wrote:

> If there's an issue with a lack of a maintainer, then that's a sign we
> need to appoint more, not abandon the whole idea.

I'm not suggesting we abandon it. I am suggesting that we do not need
to enforce that rule by write-protecting the tree. I don't believe it
to be necessary.

-- 
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 aph at redhat.com  Mon Feb 18 09:42:18 2019
From: aph at redhat.com (Andrew Haley)
Date: Mon, 18 Feb 2019 09:42:18 +0000
Subject: JDK 11.0.3 Update process
In-Reply-To: <CABi63P4HtF+48sZszoonKTKA+ysuCEBrVg64bvOw52EKPS4hRA@mail.gmail.com>
References: <c7027fa19a28408e83461360f3ce6974@sap.com>
 <CA+3eh12Rtb1MQt2xr-Tu8svvZ0+NEWs4bsn0oRpnHyGhXF0fqA@mail.gmail.com>
 <be92b505-d50b-097c-d26f-f9768c90cbd0@redhat.com>
 <CA+3eh13GiMDF-8_kofUqzZvCWK2_va+DRMJDtYm6COSDLzQV6g@mail.gmail.com>
 <586ca28f-83c9-1703-040c-f9cb1f3b6180@redhat.com>
 <CA+3eh13WReDH2JHfAQDhRwxMnhQOvPt3Ab7D_eMN_eYdunnbmw@mail.gmail.com>
 <eadfaea4-b1f2-e15f-56f4-aa120072b14b@redhat.com>
 <1c9f80b75b7b492b9e463445eafd7c3d@sap.com>
 <cbaa356a-54b2-7c18-5b0b-3cdc12f58f46@redhat.com>
 <CABi63P4HtF+48sZszoonKTKA+ysuCEBrVg64bvOw52EKPS4hRA@mail.gmail.com>
Message-ID: <3b877136-b4be-ff3e-e972-df402c816e1d@redhat.com>

On 2/15/19 6:06 PM, Andrew Hughes wrote:

> As I said before [0], I think the jdkxxu repository should be
> restricted, maintaining a clear distinction between a jdkxxu-dev
> branch for developers to commit to, and the jdkxxu for
> consumption. The latter is the one that would be frozen and used as
> the base for releases around CPU time.  That avoids a situation
> where people push stuff to jdkxxu in the interim and then are
> surprised when it's not in the release.
> 
> If there's an issue with a lack of a maintainer, then that's a sign
> we need to appoint more, not abandon the whole idea.

I have thought some more about this, and I now believe there is a
deeper issue.

The problem is that we've been conflating two roles in the
"maintainer". One is someone whose role is essentially judgemental:
they decide whether a patch is suitable for a particular release. The
other role is integrative: they merge a patch into a release branch
and make sure the result works by testing it. These two roles are not
the same thing, and require different skills.

We are likely to encounter scaling problems as we work on the updates
projects and we will do ourselves no favours by creating bottlenecks
to efficient parallel working. A mature updates project would allow
many people, with different skills, to work together on a release
branch. Not all of these people would have the authority (or even the
desire) to approve patches.

-- 
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 aph at redhat.com  Mon Feb 18 12:23:41 2019
From: aph at redhat.com (Andrew Haley)
Date: Mon, 18 Feb 2019 12:23:41 +0000
Subject: 11.0.3-oracle issues in openjdk 11.0.3
In-Reply-To: <54dc52ed-cc5f-2387-f186-1bbe2eee2e73@redhat.com>
References: <a1feaea79b634373bef62e7f471c5418@sap.com>
 <54dc52ed-cc5f-2387-f186-1bbe2eee2e73@redhat.com>
Message-ID: <3dbdc01d-060f-a3cc-6202-971836398e89@redhat.com>

On 2/15/19 3:45 PM, Aleksey Shipilev wrote:
> On 2/15/19 2:58 PM, Langer, Christoph wrote:
>> I would volunteer for doing the work to go through the list and do the downporting. I would first
>> check if the upstream patches apply, then request the downport approval and do the pushes. If the
>> changes don?t apply cleanly I would ask for help by the original authors/reviewers of the patches
>> or ask for help in the mailing lists. Please let me know if I should do this or not. 
>
> I'll join you. Have already put some "redhat-openjdk" tags on issues that should be uncontroversial,
> and am proceeding to request backports for them.
> 

Sounds great, let's get it done. Thanks.

-- 
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 shade at redhat.com  Mon Feb 18 12:26:24 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 18 Feb 2019 13:26:24 +0100
Subject: 11.0.3-oracle issues in openjdk 11.0.3
In-Reply-To: <3dbdc01d-060f-a3cc-6202-971836398e89@redhat.com>
References: <a1feaea79b634373bef62e7f471c5418@sap.com>
 <54dc52ed-cc5f-2387-f186-1bbe2eee2e73@redhat.com>
 <3dbdc01d-060f-a3cc-6202-971836398e89@redhat.com>
Message-ID: <1c26e241-43eb-2e70-a8b9-d4fe01c80b54@redhat.com>

On 2/18/19 1:23 PM, Andrew Haley wrote:
> On 2/15/19 3:45 PM, Aleksey Shipilev wrote:
>> On 2/15/19 2:58 PM, Langer, Christoph wrote:
>>> I would volunteer for doing the work to go through the list and do the downporting. I would first
>>> check if the upstream patches apply, then request the downport approval and do the pushes. If the
>>> changes don?t apply cleanly I would ask for help by the original authors/reviewers of the patches
>>> or ask for help in the mailing lists. Please let me know if I should do this or not. 
>>
>> I'll join you. Have already put some "redhat-openjdk" tags on issues that should be uncontroversial,
>> and am proceeding to request backports for them.
>>
> 
> Sounds great, let's get it done. Thanks.

The first salvo of 10+ backports had landed in jdk-updates/jdk11u a few hours ago. Working through
others. Christoph, at some point we would need to coordinate to avoid duplicate work. I am trying to
put "redhat-openjdk" the moment I start working on a bug. Otherwise, I am at #openjdk @ OFTC.

-Aleksey


From christoph.langer at sap.com  Mon Feb 18 13:09:53 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 18 Feb 2019 13:09:53 +0000
Subject: 11.0.3-oracle issues in openjdk 11.0.3
In-Reply-To: <1c26e241-43eb-2e70-a8b9-d4fe01c80b54@redhat.com>
References: <a1feaea79b634373bef62e7f471c5418@sap.com>
 <54dc52ed-cc5f-2387-f186-1bbe2eee2e73@redhat.com>
 <3dbdc01d-060f-a3cc-6202-971836398e89@redhat.com>
 <1c26e241-43eb-2e70-a8b9-d4fe01c80b54@redhat.com>
Message-ID: <a2768895fb7843bba1c6961662cfb772@sap.com>

Hi Aleksey

> The first salvo of 10+ backports had landed in jdk-updates/jdk11u a few
> hours ago. Working through
> others. Christoph, at some point we would need to coordinate to avoid
> duplicate work. I am trying to
> put "redhat-openjdk" the moment I start working on a bug. Otherwise, I am
> at #openjdk @ OFTC.

OK, I'll watch out for your "redhat-openjdk" claim then. Let's see if that's enough to sync...

Best
Christoph


From rob.mckenna at oracle.com  Mon Feb 18 14:30:52 2019
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Mon, 18 Feb 2019 14:30:52 +0000
Subject: New Lead Maintainer for the JDK11 Updates repository: Andrew Haley
Message-ID: <20190218143052.GB5015@vimes>

Voting for Andrew Haley as the new Lead Maintainer [0] for the JDK11
Updates repository has now closed.

Yes: 33
Veto: 0
Abstain: 0
Invalid: 0

According to the Bylaws definition of Lazy Consensus [1], this is
sufficient to approve the nomination.

[0] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-February/000389.html
[1] https://openjdk.java.net/bylaws#lazy-consensus

    -Rob


From rob.mckenna at oracle.com  Mon Feb 18 14:35:20 2019
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Mon, 18 Feb 2019 14:35:20 +0000
Subject: JDK 11.0.3 Update process
In-Reply-To: <eadfaea4-b1f2-e15f-56f4-aa120072b14b@redhat.com>
References: <c7027fa19a28408e83461360f3ce6974@sap.com>
 <CA+3eh12Rtb1MQt2xr-Tu8svvZ0+NEWs4bsn0oRpnHyGhXF0fqA@mail.gmail.com>
 <be92b505-d50b-097c-d26f-f9768c90cbd0@redhat.com>
 <CA+3eh13GiMDF-8_kofUqzZvCWK2_va+DRMJDtYm6COSDLzQV6g@mail.gmail.com>
 <586ca28f-83c9-1703-040c-f9cb1f3b6180@redhat.com>
 <CA+3eh13WReDH2JHfAQDhRwxMnhQOvPt3Ab7D_eMN_eYdunnbmw@mail.gmail.com>
 <eadfaea4-b1f2-e15f-56f4-aa120072b14b@redhat.com>
Message-ID: <20190218143520.GD5015@vimes>

Hi folks,

On 15/02/19 09:50, Andrew Haley wrote:
> On 2/15/19 9:14 AM, Volker Simonis wrote:
> > @Rob: could you please request the creation of a new
> > jdk-updates/jdk11u-dev repository or otherwise tell us what we'll have
> > to do in order to get such a repository?
> 
> The project lead requests ops@ to do it.

If you have no objections, I would like to ask the Lead Maintainer to send
the email to ops@ and cc me explicitly. I will approve the request.

    -Rob

> 
> -- 
> 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 shade at redhat.com  Mon Feb 18 14:39:34 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 18 Feb 2019 15:39:34 +0100
Subject: 11.0.3-oracle issues in openjdk 11.0.3
In-Reply-To: <a2768895fb7843bba1c6961662cfb772@sap.com>
References: <a1feaea79b634373bef62e7f471c5418@sap.com>
 <54dc52ed-cc5f-2387-f186-1bbe2eee2e73@redhat.com>
 <3dbdc01d-060f-a3cc-6202-971836398e89@redhat.com>
 <1c26e241-43eb-2e70-a8b9-d4fe01c80b54@redhat.com>
 <a2768895fb7843bba1c6961662cfb772@sap.com>
Message-ID: <6e44cd54-44ed-1868-74a7-dd8143640b92@redhat.com>

On 2/18/19 2:09 PM, Langer, Christoph wrote:
> Hi Aleksey
> 
>> The first salvo of 10+ backports had landed in jdk-updates/jdk11u a few hours ago. Working
>> through others. Christoph, at some point we would need to coordinate to avoid duplicate work. I
>> am trying to put "redhat-openjdk" the moment I start working on a bug. Otherwise, I am at
>> #openjdk @ OFTC.
> 
> OK, I'll watch out for your "redhat-openjdk" claim then. Let's see if that's enough to sync...
I pushed another salvo to 11u. Down to 26 issues now.

CI reports there are two failures in langtools tier1, that were there before we started backporting
11.0.3-oracle changes. Failing tests are:
  jdk/javadoc/doclet/testLinkOption/TestLinkOptionWithAutomaticModule
  jdk/internal/shellsupport/doc/JavadocHelperTest.java

Let me look into that instead of backporting more 11.0.3-oracle things. This also would let
Christoph work on 11u backports without colliding with my work.

-Aleksey


From christoph.langer at sap.com  Mon Feb 18 15:02:43 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 18 Feb 2019 15:02:43 +0000
Subject: JDK 11.0.3 Update process
In-Reply-To: <20190218143520.GD5015@vimes>
References: <c7027fa19a28408e83461360f3ce6974@sap.com>
 <CA+3eh12Rtb1MQt2xr-Tu8svvZ0+NEWs4bsn0oRpnHyGhXF0fqA@mail.gmail.com>
 <be92b505-d50b-097c-d26f-f9768c90cbd0@redhat.com>
 <CA+3eh13GiMDF-8_kofUqzZvCWK2_va+DRMJDtYm6COSDLzQV6g@mail.gmail.com>
 <586ca28f-83c9-1703-040c-f9cb1f3b6180@redhat.com>
 <CA+3eh13WReDH2JHfAQDhRwxMnhQOvPt3Ab7D_eMN_eYdunnbmw@mail.gmail.com>
 <eadfaea4-b1f2-e15f-56f4-aa120072b14b@redhat.com>
 <20190218143520.GD5015@vimes>
Message-ID: <ce5948c57b0243c98b5802655e5bf8d6@sap.com>

Hi Rob,

> On 15/02/19 09:50, Andrew Haley wrote:
> > On 2/15/19 9:14 AM, Volker Simonis wrote:
> > > @Rob: could you please request the creation of a new
> > > jdk-updates/jdk11u-dev repository or otherwise tell us what we'll have
> > > to do in order to get such a repository?
> >
> > The project lead requests ops@ to do it.
> 
> If you have no objections, I would like to ask the Lead Maintainer to send
> the email to ops@ and cc me explicitly. I will approve the request.

Are you also the person to talk to when it comes to requests for the hgupdater tool and openjdk fix versions in JBS Jira?

We'd need a setup like it was before, e.g. 11.0.3, 11.0.4, 11.0.5 etc.

And I'm also assuming the community has interest in setting up a similar thing for jdk8u as well.

Thanks
Christoph


From rob.mckenna at oracle.com  Mon Feb 18 15:28:33 2019
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Mon, 18 Feb 2019 15:28:33 +0000
Subject: JDK 11.0.3 Update process
In-Reply-To: <ce5948c57b0243c98b5802655e5bf8d6@sap.com>
References: <c7027fa19a28408e83461360f3ce6974@sap.com>
 <CA+3eh12Rtb1MQt2xr-Tu8svvZ0+NEWs4bsn0oRpnHyGhXF0fqA@mail.gmail.com>
 <be92b505-d50b-097c-d26f-f9768c90cbd0@redhat.com>
 <CA+3eh13GiMDF-8_kofUqzZvCWK2_va+DRMJDtYm6COSDLzQV6g@mail.gmail.com>
 <586ca28f-83c9-1703-040c-f9cb1f3b6180@redhat.com>
 <CA+3eh13WReDH2JHfAQDhRwxMnhQOvPt3Ab7D_eMN_eYdunnbmw@mail.gmail.com>
 <eadfaea4-b1f2-e15f-56f4-aa120072b14b@redhat.com>
 <20190218143520.GD5015@vimes>
 <ce5948c57b0243c98b5802655e5bf8d6@sap.com>
Message-ID: <20190218152833.GE5015@vimes>

Hi Christoph,

All such requests should be sent to ops@ by the Lead Maintainer cc'ing
the project lead.

In the case of 8, the Project Lead can send the request to ops@
directly.

    -Rob

On 18/02/19 15:02, Langer, Christoph wrote:
> Hi Rob,
> 
> > On 15/02/19 09:50, Andrew Haley wrote:
> > > On 2/15/19 9:14 AM, Volker Simonis wrote:
> > > > @Rob: could you please request the creation of a new
> > > > jdk-updates/jdk11u-dev repository or otherwise tell us what we'll have
> > > > to do in order to get such a repository?
> > >
> > > The project lead requests ops@ to do it.
> > 
> > If you have no objections, I would like to ask the Lead Maintainer to send
> > the email to ops@ and cc me explicitly. I will approve the request.
> 
> Are you also the person to talk to when it comes to requests for the hgupdater tool and openjdk fix versions in JBS Jira?
> 
> We'd need a setup like it was before, e.g. 11.0.3, 11.0.4, 11.0.5 etc.
> 
> And I'm also assuming the community has interest in setting up a similar thing for jdk8u as well.
> 
> Thanks
> Christoph
> 

From aph at redhat.com  Mon Feb 18 16:03:57 2019
From: aph at redhat.com (Andrew Haley)
Date: Mon, 18 Feb 2019 16:03:57 +0000
Subject: JDK 11.0.3 Update process
In-Reply-To: <20190218152833.GE5015@vimes>
References: <c7027fa19a28408e83461360f3ce6974@sap.com>
 <CA+3eh12Rtb1MQt2xr-Tu8svvZ0+NEWs4bsn0oRpnHyGhXF0fqA@mail.gmail.com>
 <be92b505-d50b-097c-d26f-f9768c90cbd0@redhat.com>
 <CA+3eh13GiMDF-8_kofUqzZvCWK2_va+DRMJDtYm6COSDLzQV6g@mail.gmail.com>
 <586ca28f-83c9-1703-040c-f9cb1f3b6180@redhat.com>
 <CA+3eh13WReDH2JHfAQDhRwxMnhQOvPt3Ab7D_eMN_eYdunnbmw@mail.gmail.com>
 <eadfaea4-b1f2-e15f-56f4-aa120072b14b@redhat.com>
 <20190218143520.GD5015@vimes> <ce5948c57b0243c98b5802655e5bf8d6@sap.com>
 <20190218152833.GE5015@vimes>
Message-ID: <6883507c-c8bf-3f67-e5e3-2d6ec937a903@redhat.com>

On 2/18/19 3:28 PM, Rob McKenna wrote:
> All such requests should be sent to ops@ by the Lead Maintainer cc'ing
> the project lead.
> 
> In the case of 8, the Project Lead can send the request to ops@
> directly.

OK, but this is an area with which I am unfamiliar. I'll get there,
but right now I don't know how to ask for what is required. If someone
could provide me with an unambiguous paragraph which is the request to
ops@ I'd be grateful.

-- 
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 aph at redhat.com  Mon Feb 18 16:04:57 2019
From: aph at redhat.com (Andrew Haley)
Date: Mon, 18 Feb 2019 16:04:57 +0000
Subject: JDK 11.0.3 Update process
In-Reply-To: <20190218143520.GD5015@vimes>
References: <c7027fa19a28408e83461360f3ce6974@sap.com>
 <CA+3eh12Rtb1MQt2xr-Tu8svvZ0+NEWs4bsn0oRpnHyGhXF0fqA@mail.gmail.com>
 <be92b505-d50b-097c-d26f-f9768c90cbd0@redhat.com>
 <CA+3eh13GiMDF-8_kofUqzZvCWK2_va+DRMJDtYm6COSDLzQV6g@mail.gmail.com>
 <586ca28f-83c9-1703-040c-f9cb1f3b6180@redhat.com>
 <CA+3eh13WReDH2JHfAQDhRwxMnhQOvPt3Ab7D_eMN_eYdunnbmw@mail.gmail.com>
 <eadfaea4-b1f2-e15f-56f4-aa120072b14b@redhat.com>
 <20190218143520.GD5015@vimes>
Message-ID: <e824f069-0415-cd57-67e6-aea45c2d539c@redhat.com>

On 2/18/19 2:35 PM, Rob McKenna wrote:
> Hi folks,
> 
> On 15/02/19 09:50, Andrew Haley wrote:
>> On 2/15/19 9:14 AM, Volker Simonis wrote:
>>> @Rob: could you please request the creation of a new
>>> jdk-updates/jdk11u-dev repository or otherwise tell us what we'll have
>>> to do in order to get such a repository?
>>
>> The project lead requests ops@ to do it.
> 
> If you have no objections, I would like to ask the Lead Maintainer to send
> the email to ops@ and cc me explicitly. I will approve the request.

I'm going to request that we clone
http://hg.openjdk.java.net/jdk-updates/jdk11u/ into
jdk-updates/jdk11u-dev now. jdk11u-dev becomes the always-open repo,
and the existing jdk-updates/jdk11u becomes the consolidation repo for
the next update release.

OK?

-- 
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 goetz.lindenmaier at sap.com  Mon Feb 18 16:08:21 2019
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Mon, 18 Feb 2019 16:08:21 +0000
Subject: JDK 11.0.3 Update process
In-Reply-To: <e824f069-0415-cd57-67e6-aea45c2d539c@redhat.com>
References: <c7027fa19a28408e83461360f3ce6974@sap.com>
 <CA+3eh12Rtb1MQt2xr-Tu8svvZ0+NEWs4bsn0oRpnHyGhXF0fqA@mail.gmail.com>
 <be92b505-d50b-097c-d26f-f9768c90cbd0@redhat.com>
 <CA+3eh13GiMDF-8_kofUqzZvCWK2_va+DRMJDtYm6COSDLzQV6g@mail.gmail.com>
 <586ca28f-83c9-1703-040c-f9cb1f3b6180@redhat.com>
 <CA+3eh13WReDH2JHfAQDhRwxMnhQOvPt3Ab7D_eMN_eYdunnbmw@mail.gmail.com>
 <eadfaea4-b1f2-e15f-56f4-aa120072b14b@redhat.com>
 <20190218143520.GD5015@vimes>
 <e824f069-0415-cd57-67e6-aea45c2d539c@redhat.com>
Message-ID: <58534f726d014bf4a16af26bcb4a5919@sap.com>

Thanks Andrew!

Best regards,
  Goetz.

> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> Behalf Of Andrew Haley
> Sent: Montag, 18. Februar 2019 17:05
> To: Rob McKenna <rob.mckenna at oracle.com>
> Cc: Ren? Sch?nemann <rene.schuenemann at gmail.com>; jdk-updates-
> dev at openjdk.java.net
> Subject: Re: JDK 11.0.3 Update process
> 
> On 2/18/19 2:35 PM, Rob McKenna wrote:
> > Hi folks,
> >
> > On 15/02/19 09:50, Andrew Haley wrote:
> >> On 2/15/19 9:14 AM, Volker Simonis wrote:
> >>> @Rob: could you please request the creation of a new
> >>> jdk-updates/jdk11u-dev repository or otherwise tell us what we'll have
> >>> to do in order to get such a repository?
> >>
> >> The project lead requests ops@ to do it.
> >
> > If you have no objections, I would like to ask the Lead Maintainer to send
> > the email to ops@ and cc me explicitly. I will approve the request.
> 
> I'm going to request that we clone
> http://hg.openjdk.java.net/jdk-updates/jdk11u/ into
> jdk-updates/jdk11u-dev now. jdk11u-dev becomes the always-open repo,
> and the existing jdk-updates/jdk11u becomes the consolidation repo for
> the next update release.
> 
> OK?
> 
> --
> 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 rob.mckenna at oracle.com  Mon Feb 18 16:22:31 2019
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Mon, 18 Feb 2019 16:22:31 +0000
Subject: JDK 11.0.3 Update process
In-Reply-To: <6883507c-c8bf-3f67-e5e3-2d6ec937a903@redhat.com>
References: <CA+3eh12Rtb1MQt2xr-Tu8svvZ0+NEWs4bsn0oRpnHyGhXF0fqA@mail.gmail.com>
 <be92b505-d50b-097c-d26f-f9768c90cbd0@redhat.com>
 <CA+3eh13GiMDF-8_kofUqzZvCWK2_va+DRMJDtYm6COSDLzQV6g@mail.gmail.com>
 <586ca28f-83c9-1703-040c-f9cb1f3b6180@redhat.com>
 <CA+3eh13WReDH2JHfAQDhRwxMnhQOvPt3Ab7D_eMN_eYdunnbmw@mail.gmail.com>
 <eadfaea4-b1f2-e15f-56f4-aa120072b14b@redhat.com>
 <20190218143520.GD5015@vimes>
 <ce5948c57b0243c98b5802655e5bf8d6@sap.com>
 <20190218152833.GE5015@vimes>
 <6883507c-c8bf-3f67-e5e3-2d6ec937a903@redhat.com>
Message-ID: <20190218162231.GF5015@vimes>

Correct me if I have the wrong fix versions here, but the following email
should suffice for both requests:

-------------------------

Hi Ops,

I'd like to request the creation of a new forest for jdk11u:

http://hg.openjdk.java.net/jdk-updates/jdk11u-dev

This forest should be cloned from
http://hg.openjdk.java.net/jdk-updates/jdk11u

In addition to this I would like to request that the fix versions for
hgupdater be set to:

jdk-updates/jdk11u-dev: 11.0.4
jdk-updates/jdk11u: 11.0.3

Thanks,

-------------------------

    -Rob

On 18/02/19 16:03, Andrew Haley wrote:
> On 2/18/19 3:28 PM, Rob McKenna wrote:
> > All such requests should be sent to ops@ by the Lead Maintainer cc'ing
> > the project lead.
> > 
> > In the case of 8, the Project Lead can send the request to ops@
> > directly.
> 
> OK, but this is an area with which I am unfamiliar. I'll get there,
> but right now I don't know how to ask for what is required. If someone
> could provide me with an unambiguous paragraph which is the request to
> ops@ I'd be grateful.
> 
> -- 
> 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 aph at redhat.com  Mon Feb 18 17:01:20 2019
From: aph at redhat.com (Andrew Haley)
Date: Mon, 18 Feb 2019 17:01:20 +0000
Subject: JDK 11.0.3 Update process
In-Reply-To: <20190218162231.GF5015@vimes>
References: <CA+3eh12Rtb1MQt2xr-Tu8svvZ0+NEWs4bsn0oRpnHyGhXF0fqA@mail.gmail.com>
 <be92b505-d50b-097c-d26f-f9768c90cbd0@redhat.com>
 <CA+3eh13GiMDF-8_kofUqzZvCWK2_va+DRMJDtYm6COSDLzQV6g@mail.gmail.com>
 <586ca28f-83c9-1703-040c-f9cb1f3b6180@redhat.com>
 <CA+3eh13WReDH2JHfAQDhRwxMnhQOvPt3Ab7D_eMN_eYdunnbmw@mail.gmail.com>
 <eadfaea4-b1f2-e15f-56f4-aa120072b14b@redhat.com>
 <20190218143520.GD5015@vimes> <ce5948c57b0243c98b5802655e5bf8d6@sap.com>
 <20190218152833.GE5015@vimes>
 <6883507c-c8bf-3f67-e5e3-2d6ec937a903@redhat.com>
 <20190218162231.GF5015@vimes>
Message-ID: <90d036e5-c629-9d1e-1150-eb85b37ab91b@redhat.com>

On 2/18/19 4:22 PM, Rob McKenna wrote:
> Correct me if I have the wrong fix versions here, but the following email
> should suffice for both requests:

Thanks. I'll wait for an ACK from someone else contributing to this discussion,
then send the request.

-- 
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 volker.simonis at gmail.com  Mon Feb 18 18:05:39 2019
From: volker.simonis at gmail.com (Volker Simonis)
Date: Mon, 18 Feb 2019 19:05:39 +0100
Subject: JDK 11.0.3 Update process
In-Reply-To: <90d036e5-c629-9d1e-1150-eb85b37ab91b@redhat.com>
References: <CA+3eh12Rtb1MQt2xr-Tu8svvZ0+NEWs4bsn0oRpnHyGhXF0fqA@mail.gmail.com>
 <be92b505-d50b-097c-d26f-f9768c90cbd0@redhat.com>
 <CA+3eh13GiMDF-8_kofUqzZvCWK2_va+DRMJDtYm6COSDLzQV6g@mail.gmail.com>
 <586ca28f-83c9-1703-040c-f9cb1f3b6180@redhat.com>
 <CA+3eh13WReDH2JHfAQDhRwxMnhQOvPt3Ab7D_eMN_eYdunnbmw@mail.gmail.com>
 <eadfaea4-b1f2-e15f-56f4-aa120072b14b@redhat.com>
 <20190218143520.GD5015@vimes>
 <ce5948c57b0243c98b5802655e5bf8d6@sap.com> <20190218152833.GE5015@vimes>
 <6883507c-c8bf-3f67-e5e3-2d6ec937a903@redhat.com>
 <20190218162231.GF5015@vimes>
 <90d036e5-c629-9d1e-1150-eb85b37ab91b@redhat.com>
Message-ID: <CA+3eh13=JmXOkQOUShKw5ZA-nSA0JM-rwbb7qdeAs4B_WPFBVg@mail.gmail.com>

I'm fine with the wording in Rob's "request template" (thanks for
providing it!). I think it expresses exactly what we've proposed so
far.

It actually means that once it is executed, all the 11-update
downports will have to go to "jdk11u-dev" repository and will be
scheduled for 11.0.4. Only the changes which are already in 11u at the
time of cloning will automatically become part of 11.0.3.

We will have to somehow communicate this fact very prominently (or
maybe even restrict commits to 11u for some time) because until now
all the downports for 11-updates went into 11u. 11-update downporters
will have to adjust their habit once we have jdk-updates/jdk11u-dev!

Besides that, I have another question which I kindly ask Rob to answer :)

> In addition to this I would like to request that the fix versions for
> hgupdater be set to:
>
> jdk-updates/jdk11u-dev: 11.0.4
> jdk-updates/jdk11u: 11.0.3

Once this is done, how best proceed with a change (say a P1) which
needs to go into both 11.0.3 and 11.0.4. My idea was to downport it
directly to jdk-updates/jdk11u and regularly push from
jdk-updates/jdk11u to jdk-updates/jdk11u-dev. Is this the way it was
previously done at Oracle?

The other possiblity would be to instantly downport it to both
jdk-updates/jdk11u and jdk-updates/jdk11u-dev. But in the end, this
would leave us (after 11.0.3 will be merged back into
jdk-updates/jdk11u) with two different instances of the same change in
jdk11u-dev and all subsequent releases. I think that would be not very
nice and quite confusing. If possible I'd like to avoid that.

Thanks for your support,
Volker

On Mon, Feb 18, 2019 at 6:01 PM Andrew Haley <aph at redhat.com> wrote:
>
> On 2/18/19 4:22 PM, Rob McKenna wrote:
> > Correct me if I have the wrong fix versions here, but the following email
> > should suffice for both requests:
>
> Thanks. I'll wait for an ACK from someone else contributing to this discussion,
> then send the request.
>
> --
> 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 shade at redhat.com  Mon Feb 18 18:15:25 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 18 Feb 2019 19:15:25 +0100
Subject: JDK 11.0.3 Update process
In-Reply-To: <CA+3eh13=JmXOkQOUShKw5ZA-nSA0JM-rwbb7qdeAs4B_WPFBVg@mail.gmail.com>
References: <CA+3eh12Rtb1MQt2xr-Tu8svvZ0+NEWs4bsn0oRpnHyGhXF0fqA@mail.gmail.com>
 <be92b505-d50b-097c-d26f-f9768c90cbd0@redhat.com>
 <CA+3eh13GiMDF-8_kofUqzZvCWK2_va+DRMJDtYm6COSDLzQV6g@mail.gmail.com>
 <586ca28f-83c9-1703-040c-f9cb1f3b6180@redhat.com>
 <CA+3eh13WReDH2JHfAQDhRwxMnhQOvPt3Ab7D_eMN_eYdunnbmw@mail.gmail.com>
 <eadfaea4-b1f2-e15f-56f4-aa120072b14b@redhat.com>
 <20190218143520.GD5015@vimes> <ce5948c57b0243c98b5802655e5bf8d6@sap.com>
 <20190218152833.GE5015@vimes>
 <6883507c-c8bf-3f67-e5e3-2d6ec937a903@redhat.com>
 <20190218162231.GF5015@vimes>
 <90d036e5-c629-9d1e-1150-eb85b37ab91b@redhat.com>
 <CA+3eh13=JmXOkQOUShKw5ZA-nSA0JM-rwbb7qdeAs4B_WPFBVg@mail.gmail.com>
Message-ID: <8d1f4dcd-7031-4e7e-e569-42d0ce21c9ca@redhat.com>

On 2/18/19 7:05 PM, Volker Simonis wrote:
> It actually means that once it is executed, all the 11-update
> downports will have to go to "jdk11u-dev" repository and will be
> scheduled for 11.0.4. Only the changes which are already in 11u at the
> time of cloning will automatically become part of 11.0.3.

Please note: we are in process of backporting 11.0.3-oracle issues to jdk-updates/jdk11u. If you
want to have all 11.0.3-oracle fixes in 11.0.3, those fixes would end in -dev for a while, and you
need to consider pulling them to master some time later. If anything we do today precludes that, I
would be very unhappy.

-Aleksey


From aph at redhat.com  Mon Feb 18 18:20:31 2019
From: aph at redhat.com (Andrew Haley)
Date: Mon, 18 Feb 2019 18:20:31 +0000
Subject: JDK 11.0.3 Update process
In-Reply-To: <8d1f4dcd-7031-4e7e-e569-42d0ce21c9ca@redhat.com>
References: <CA+3eh12Rtb1MQt2xr-Tu8svvZ0+NEWs4bsn0oRpnHyGhXF0fqA@mail.gmail.com>
 <be92b505-d50b-097c-d26f-f9768c90cbd0@redhat.com>
 <CA+3eh13GiMDF-8_kofUqzZvCWK2_va+DRMJDtYm6COSDLzQV6g@mail.gmail.com>
 <586ca28f-83c9-1703-040c-f9cb1f3b6180@redhat.com>
 <CA+3eh13WReDH2JHfAQDhRwxMnhQOvPt3Ab7D_eMN_eYdunnbmw@mail.gmail.com>
 <eadfaea4-b1f2-e15f-56f4-aa120072b14b@redhat.com>
 <20190218143520.GD5015@vimes> <ce5948c57b0243c98b5802655e5bf8d6@sap.com>
 <20190218152833.GE5015@vimes>
 <6883507c-c8bf-3f67-e5e3-2d6ec937a903@redhat.com>
 <20190218162231.GF5015@vimes>
 <90d036e5-c629-9d1e-1150-eb85b37ab91b@redhat.com>
 <CA+3eh13=JmXOkQOUShKw5ZA-nSA0JM-rwbb7qdeAs4B_WPFBVg@mail.gmail.com>
 <8d1f4dcd-7031-4e7e-e569-42d0ce21c9ca@redhat.com>
Message-ID: <5ec1a955-db90-a83b-fc49-277664ada52a@redhat.com>

On 2/18/19 6:15 PM, Aleksey Shipilev wrote:
> Please note: we are in process of backporting 11.0.3-oracle issues to jdk-updates/jdk11u. If you
> want to have all 11.0.3-oracle fixes in 11.0.3, those fixes would end in -dev for a while, and you
> need to consider pulling them to master some time later. If anything we do today precludes that, I
> would be very unhappy.

Yo're mostly done with these backports, right?
Please finish what you are doing, then tell me when you're 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 shade at redhat.com  Mon Feb 18 18:22:30 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 18 Feb 2019 19:22:30 +0100
Subject: JDK 11.0.3 Update process
In-Reply-To: <5ec1a955-db90-a83b-fc49-277664ada52a@redhat.com>
References: <CA+3eh12Rtb1MQt2xr-Tu8svvZ0+NEWs4bsn0oRpnHyGhXF0fqA@mail.gmail.com>
 <be92b505-d50b-097c-d26f-f9768c90cbd0@redhat.com>
 <CA+3eh13GiMDF-8_kofUqzZvCWK2_va+DRMJDtYm6COSDLzQV6g@mail.gmail.com>
 <586ca28f-83c9-1703-040c-f9cb1f3b6180@redhat.com>
 <CA+3eh13WReDH2JHfAQDhRwxMnhQOvPt3Ab7D_eMN_eYdunnbmw@mail.gmail.com>
 <eadfaea4-b1f2-e15f-56f4-aa120072b14b@redhat.com>
 <20190218143520.GD5015@vimes> <ce5948c57b0243c98b5802655e5bf8d6@sap.com>
 <20190218152833.GE5015@vimes>
 <6883507c-c8bf-3f67-e5e3-2d6ec937a903@redhat.com>
 <20190218162231.GF5015@vimes>
 <90d036e5-c629-9d1e-1150-eb85b37ab91b@redhat.com>
 <CA+3eh13=JmXOkQOUShKw5ZA-nSA0JM-rwbb7qdeAs4B_WPFBVg@mail.gmail.com>
 <8d1f4dcd-7031-4e7e-e569-42d0ce21c9ca@redhat.com>
 <5ec1a955-db90-a83b-fc49-277664ada52a@redhat.com>
Message-ID: <a1ab759a-f171-5bf4-0f03-6b24c409bf58@redhat.com>

On 2/18/19 7:20 PM, Andrew Haley wrote:
> On 2/18/19 6:15 PM, Aleksey Shipilev wrote:
>> Please note: we are in process of backporting 11.0.3-oracle issues to jdk-updates/jdk11u. If you
>> want to have all 11.0.3-oracle fixes in 11.0.3, those fixes would end in -dev for a while, and you
>> need to consider pulling them to master some time later. If anything we do today precludes that, I
>> would be very unhappy.
> 
> Yo're mostly done with these backports, right?
> Please finish what you are doing, then tell me when you're done.

No, we are not even half-way done. I expect we are done by the end of the week, *IF* there are no
surprises.

-Aleksey


From aph at redhat.com  Mon Feb 18 18:48:09 2019
From: aph at redhat.com (Andrew Haley)
Date: Mon, 18 Feb 2019 18:48:09 +0000
Subject: JDK 11.0.3 Update process
In-Reply-To: <a1ab759a-f171-5bf4-0f03-6b24c409bf58@redhat.com>
References: <CA+3eh12Rtb1MQt2xr-Tu8svvZ0+NEWs4bsn0oRpnHyGhXF0fqA@mail.gmail.com>
 <be92b505-d50b-097c-d26f-f9768c90cbd0@redhat.com>
 <CA+3eh13GiMDF-8_kofUqzZvCWK2_va+DRMJDtYm6COSDLzQV6g@mail.gmail.com>
 <586ca28f-83c9-1703-040c-f9cb1f3b6180@redhat.com>
 <CA+3eh13WReDH2JHfAQDhRwxMnhQOvPt3Ab7D_eMN_eYdunnbmw@mail.gmail.com>
 <eadfaea4-b1f2-e15f-56f4-aa120072b14b@redhat.com>
 <20190218143520.GD5015@vimes> <ce5948c57b0243c98b5802655e5bf8d6@sap.com>
 <20190218152833.GE5015@vimes>
 <6883507c-c8bf-3f67-e5e3-2d6ec937a903@redhat.com>
 <20190218162231.GF5015@vimes>
 <90d036e5-c629-9d1e-1150-eb85b37ab91b@redhat.com>
 <CA+3eh13=JmXOkQOUShKw5ZA-nSA0JM-rwbb7qdeAs4B_WPFBVg@mail.gmail.com>
 <8d1f4dcd-7031-4e7e-e569-42d0ce21c9ca@redhat.com>
 <5ec1a955-db90-a83b-fc49-277664ada52a@redhat.com>
 <a1ab759a-f171-5bf4-0f03-6b24c409bf58@redhat.com>
Message-ID: <4f6ee3a1-138f-84b7-edc6-252d750fca5b@redhat.com>

On 2/18/19 6:22 PM, Aleksey Shipilev wrote:
> On 2/18/19 7:20 PM, Andrew Haley wrote:
>> On 2/18/19 6:15 PM, Aleksey Shipilev wrote:
>>> Please note: we are in process of backporting 11.0.3-oracle issues to jdk-updates/jdk11u. If you
>>> want to have all 11.0.3-oracle fixes in 11.0.3, those fixes would end in -dev for a while, and you
>>> need to consider pulling them to master some time later. If anything we do today precludes that, I
>>> would be very unhappy.
>>
>> Yo're mostly done with these backports, right?
>> Please finish what you are doing, then tell me when you're done.
> 
> No, we are not even half-way done. I expect we are done by the end of the week, *IF* there are no
> surprises.

I'm happy to wait. Is everyone else?

-- 
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  Mon Feb 18 19:02:53 2019
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 18 Feb 2019 11:02:53 -0800
Subject: RFR: 8212233: javadoc fails on jdk12 with "The code being
 documented uses modules but the packages defined in $URL are in the unnamed
 module."
In-Reply-To: <d4d16942-231b-9a1d-b05a-11a6248c6b02@redhat.com>
References: <CA+kOe092oR8sKJKuDAEGmKGGbpLWXGhEKCgpxQ55RDKUxQ0n1w@mail.gmail.com>
 <CA+kOe0-SLbqefMsz41AYvzi_++zv6wqei8YFR4uf59w_quNwvg@mail.gmail.com>
 <d4d16942-231b-9a1d-b05a-11a6248c6b02@redhat.com>
Message-ID: <CA+kOe0_iOcySmqeiX8U9hFiViRa2zMmj0d2ijvoFvF84YeBxkA@mail.gmail.com>

Adding Robert Scholte, who may best know if this backport would fix a
problem related to
https://issues.apache.org/jira/browse/MJAVADOC-555

Adding jdk-updates-dev, as suggested at
https://openjdk.java.net/projects/jdk-updates/codereview.html

On Mon, Feb 18, 2019 at 10:04 AM Aleksey Shipilev <shade at redhat.com> wrote:

> On 2/18/19 6:51 PM, Martin Buchholz wrote:
> > Over in
> https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-February/000452.html
> you
> > volunteered to look at javadoc problems, and this bug is one of them, so
> perhaps you can add it
> > to your list?
>
> Yeah, the test failure I mentioned at jdk-updates-dev@ is the leftover
> from applying your backport.
> I did not manage to test it properly yet before suggesting for jdk11u
> backport.
>
> > I expected this bug to be backported to Oracle jdk11, but there's no
> backport record in JIRA. I
> > don't know why my bug fix apparently does not resolve the serious
> maven-related problems seen in
> > jdk11. My own backport seems to "work", but I don't whether an actual
> important bug is being
> > fixed.
> There is no record for 11u in JIRA, because there is no backport to 11u.
> Replying in JIRA comment is
> not enough, you need to follow this process:
> https://openjdk.java.net/projects/jdk-updates/ -- and,
> given the patch does not apply cleanly to 11u, the additional RFR for 11u.
>

I am trying to follow the process - this thread is the RFR for 11u !

From shade at redhat.com  Mon Feb 18 19:07:06 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 18 Feb 2019 20:07:06 +0100
Subject: RFR: 8212233: javadoc fails on jdk12 with "The code being
 documented uses modules but the packages defined in $URL are in the unnamed
 module."
In-Reply-To: <CA+kOe0_iOcySmqeiX8U9hFiViRa2zMmj0d2ijvoFvF84YeBxkA@mail.gmail.com>
References: <CA+kOe092oR8sKJKuDAEGmKGGbpLWXGhEKCgpxQ55RDKUxQ0n1w@mail.gmail.com>
 <CA+kOe0-SLbqefMsz41AYvzi_++zv6wqei8YFR4uf59w_quNwvg@mail.gmail.com>
 <d4d16942-231b-9a1d-b05a-11a6248c6b02@redhat.com>
 <CA+kOe0_iOcySmqeiX8U9hFiViRa2zMmj0d2ijvoFvF84YeBxkA@mail.gmail.com>
Message-ID: <455fd9a0-839a-17a5-df38-8ec83dfe4371@redhat.com>

On 2/18/19 8:02 PM, Martin Buchholz wrote:
> I am trying to follow the process - this thread is the RFR for 11u !?

No, it is not.

Please put yourself into the shoes of reviewers and maintainers: they need to have all the context
at once, not reading through tens of messages and replies spread across the mailing lists.

Try again, by starting a new thread, spelling out the exact thing you want to backport, the history
behind the issue, etc. Here is the template:
  https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-February/000425.html

-Aleksey


From christoph.langer at sap.com  Mon Feb 18 19:26:16 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 18 Feb 2019 19:26:16 +0000
Subject: JDK 11.0.3 Update process
In-Reply-To: <4f6ee3a1-138f-84b7-edc6-252d750fca5b@redhat.com>
References: <CA+3eh12Rtb1MQt2xr-Tu8svvZ0+NEWs4bsn0oRpnHyGhXF0fqA@mail.gmail.com>
 <be92b505-d50b-097c-d26f-f9768c90cbd0@redhat.com>
 <CA+3eh13GiMDF-8_kofUqzZvCWK2_va+DRMJDtYm6COSDLzQV6g@mail.gmail.com>
 <586ca28f-83c9-1703-040c-f9cb1f3b6180@redhat.com>
 <CA+3eh13WReDH2JHfAQDhRwxMnhQOvPt3Ab7D_eMN_eYdunnbmw@mail.gmail.com>
 <eadfaea4-b1f2-e15f-56f4-aa120072b14b@redhat.com>
 <20190218143520.GD5015@vimes> <ce5948c57b0243c98b5802655e5bf8d6@sap.com>
 <20190218152833.GE5015@vimes>
 <6883507c-c8bf-3f67-e5e3-2d6ec937a903@redhat.com>
 <20190218162231.GF5015@vimes>
 <90d036e5-c629-9d1e-1150-eb85b37ab91b@redhat.com>
 <CA+3eh13=JmXOkQOUShKw5ZA-nSA0JM-rwbb7qdeAs4B_WPFBVg@mail.gmail.com>
 <8d1f4dcd-7031-4e7e-e569-42d0ce21c9ca@redhat.com>
 <5ec1a955-db90-a83b-fc49-277664ada52a@redhat.com>
 <a1ab759a-f171-5bf4-0f03-6b24c409bf58@redhat.com>
 <4f6ee3a1-138f-84b7-edc6-252d750fca5b@redhat.com>
Message-ID: <4563e824781546caad34bc27e6d4c13b@sap.com>

Hi,

I agree with Aleksey's point of view on the backports. We're currently processing them and I believe it'll take a little bit of time until we're done. Today, for instance, I stumbled over a JFR change which needs some more thinking/testing. So, for the time being I think it's best we keep jdk11u open for that work. So hopefully some time next week we'll be done with the main bulk and can proceed going towards the new setup.

I also think, we should get the answer to Volker's questions about the right way to do merges with these mercurial trees and the hgupdater tool before we install the new repository setup.

Consider a point when we have the target setup in place (as per Rob's mail which fits perfectly by the way, thanks Rob):
jdk11u         -> 11.0.3 (Changes pushed to jdk11u will create a JBS backport issue targeted for version 11.0.3)
jdk11u-dev -> 11.0.4 (Changes pushed to jdk11u-dev will create a JBS backport issue targeted for version 11.0.4)

I would think we should then push changes targeting version 11.0.3 into the jdk11u repo. Then, by merging jdk11u regularly into jdk11u-dev, we'll get the 11.0.4 backport items created by hgupdater. Rob needs to confirm that. And what happens, if a change in jdk11u-dev needs to be cherry-picked to jdk11u? will hgupdater be smart enough to cope with that when merging back jdk11u into jdk11u-dev? And, what happens, if after April we set jdk11u to target 11.04 in hgupdater and then merge jdk11u-dev into jdk11u? Will hgupdater be smart enough to handle that? I believe/hope the answer to both questions is a yes, but I'd like to have Rob or somebody from the Oracle ops team confirm.

We should also find an agreement on the question what the restrictions for jdk11u repository will be eventually? Shall it be all jdk-updates committers or only a subset of people performing the release work? I'm open here.

And last but not least, Andrew (APH): As of today you are the appointed jdk11u maintainer [0]. Congratulations ?? Now I think this means that you'll need to approve our "jdk11u-fix-request" labeling in JBS. And there are quite a few of them. I suggest you name a few additional maintainers like Oracle has for the jdk12u updates project [1], that have the powers to approve these fix requests. I'd like to hereby nominate Aleksey, Andrew (Hughes) and myself for this role. We should of course stick to Alekseys suggested rule that if one of us requests a backport, somebody else from the maintainers group has to approve to follow a 4-eyes principle. Would you agree to that?

Thanks and Best regards
Christoph

[0] https://wiki.openjdk.java.net/display/JDKUpdates/JDK11u
[1] https://wiki.openjdk.java.net/display/JDKUpdates/JDK12u 

> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> Behalf Of Andrew Haley
> Sent: Montag, 18. Februar 2019 19:48
> To: Aleksey Shipilev <shade at redhat.com>; Volker Simonis
> <volker.simonis at gmail.com>
> Cc: Ren? Sch?nemann <rene.schuenemann at gmail.com>; jdk-updates-
> dev at openjdk.java.net
> Subject: Re: JDK 11.0.3 Update process
> 
> On 2/18/19 6:22 PM, Aleksey Shipilev wrote:
> > On 2/18/19 7:20 PM, Andrew Haley wrote:
> >> On 2/18/19 6:15 PM, Aleksey Shipilev wrote:
> >>> Please note: we are in process of backporting 11.0.3-oracle issues to jdk-
> updates/jdk11u. If you
> >>> want to have all 11.0.3-oracle fixes in 11.0.3, those fixes would end in -
> dev for a while, and you
> >>> need to consider pulling them to master some time later. If anything we
> do today precludes that, I
> >>> would be very unhappy.
> >>
> >> Yo're mostly done with these backports, right?
> >> Please finish what you are doing, then tell me when you're done.
> >
> > No, we are not even half-way done. I expect we are done by the end of
> the week, *IF* there are no
> > surprises.
> 
> I'm happy to wait. Is everyone else?
> 
> --
> 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 rfscholte at apache.org  Mon Feb 18 19:15:21 2019
From: rfscholte at apache.org (Robert Scholte)
Date: Mon, 18 Feb 2019 20:15:21 +0100
Subject: RFR: 8212233: javadoc fails on jdk12 with "The code being
 documented uses modules but the packages defined in $URL are in the unnamed
 module."
In-Reply-To: <CA+kOe0_iOcySmqeiX8U9hFiViRa2zMmj0d2ijvoFvF84YeBxkA@mail.gmail.com>
References: <CA+kOe092oR8sKJKuDAEGmKGGbpLWXGhEKCgpxQ55RDKUxQ0n1w@mail.gmail.com>
 <CA+kOe0-SLbqefMsz41AYvzi_++zv6wqei8YFR4uf59w_quNwvg@mail.gmail.com>
 <d4d16942-231b-9a1d-b05a-11a6248c6b02@redhat.com>
 <CA+kOe0_iOcySmqeiX8U9hFiViRa2zMmj0d2ijvoFvF84YeBxkA@mail.gmail.com>
Message-ID: <op.zxe83vwqkdkhrr@desktop-2khsk44>

We're close to a new release of the javadoc-maven-plugin, which will have  
support for javadoc with the modular system.

This would be a good moment to verify if it works as expected:

<plugin>
     <groupId>org.apache.maven.plugins</groupId>
     <artifactId>maven-javadoc-plugin</artifactId>
     <version>3.1.0-SNAPSHOT</version>
</plugin>

<repository>
     <id>apache.snapshots</id>
     <name>Apache Development Snapshot Repository</name>
     <url>https://repository.apache.org/content/repositories/snapshots/</url>
     <releases>
       <enabled>false</enabled>
     </releases>
     <snapshots>
       <enabled>true</enabled>
     </snapshots>
</repository>

Any feedback is appreciated

thanks,
Robert


On Mon, 18 Feb 2019 20:02:53 +0100, Martin Buchholz <martinrb at google.com>  
wrote:

> Adding Robert Scholte, who may best know if this backport would fix a  
> problem related tohttps://issues.apache.org/jira/browse/MJAVADOC-555
>
> Adding jdk-updates-dev, as suggested at 
> https://openjdk.java.net/projects/jdk-updates/codereview.html
>
> On Mon, Feb 18, 2019 at 10:04 AM Aleksey Shipilev <shade at redhat.com>  
> wrote:
>> On 2/18/19 6:51 PM, Martin Buchholz wrote:
>>> Over in  
>>> https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-February/000452.html  
>>> youvolunteered to look at javadoc problems, and this bug is one of  
>>> them, so perhaps you can add itto your list?
>>
>> Yeah, the test failure I mentioned at jdk-updates-dev@ is the leftover  
>> from applying your backport.
>> I did not manage to test it properly yet before suggesting for jdk11u  
>> backport.
>>
>>> I expected this bug to be backported to Oracle jdk11, but there's no  
>>> backport record in JIRA. Idon't know why my bug fix apparently does  
>>> not resolve the serious maven-related problems seen in
>>> jdk11. My own backport seems to "work", but I don't whether an actual  
>>> important bug is beingfixed.
>> There is no record for 11u in JIRA, because there is no backport to  
>> 11u. Replying in JIRA comment is
>> not enough, you need to follow this process:  
>> https://openjdk.java.net/projects/jdk-updates/ -- and,
>> given the patch does not apply cleanly to 11u, the additional RFR for  
>> 11u.
>
> I am trying to follow the process - this thread is the RFR for 11u !

From martinrb at google.com  Mon Feb 18 20:43:57 2019
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 18 Feb 2019 12:43:57 -0800
Subject: RFR: 8212233: javadoc fails on jdk12 with "The code being
 documented uses modules but the packages defined in $URL are in the unnamed
 module."
In-Reply-To: <455fd9a0-839a-17a5-df38-8ec83dfe4371@redhat.com>
References: <CA+kOe092oR8sKJKuDAEGmKGGbpLWXGhEKCgpxQ55RDKUxQ0n1w@mail.gmail.com>
 <CA+kOe0-SLbqefMsz41AYvzi_++zv6wqei8YFR4uf59w_quNwvg@mail.gmail.com>
 <d4d16942-231b-9a1d-b05a-11a6248c6b02@redhat.com>
 <CA+kOe0_iOcySmqeiX8U9hFiViRa2zMmj0d2ijvoFvF84YeBxkA@mail.gmail.com>
 <455fd9a0-839a-17a5-df38-8ec83dfe4371@redhat.com>
Message-ID: <CA+kOe0_AZvD7hysXyqZAhrMM1jB8O4Yd8CR0-OudVX57d26_2w@mail.gmail.com>

Sigh.

On Mon, Feb 18, 2019 at 11:07 AM Aleksey Shipilev <shade at redhat.com> wrote:

> On 2/18/19 8:02 PM, Martin Buchholz wrote:
> > I am trying to follow the process - this thread is the RFR for 11u !
>
> No, it is not.
>
> Please put yourself into the shoes of reviewers and maintainers: they need
> to have all the context
> at once, not reading through tens of messages and replies spread across
> the mailing lists.
>
> Try again, by starting a new thread, spelling out the exact thing you want
> to backport, the history
> behind the issue, etc. Here is the template:
>
> https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-February/000425.html


Your backporting and JIRA REST automation is totally awesome, but I think
it would be an excessive burden to expect everyone doing backports to clear
such a high bar.

All the javadoc tests pass
./test/langtools/jdk/internal/shellsupport/doc/ $(find test -name javadoc)

At Google, we originally backported  8212233 with the hope that it would
fix problems with maven, but the problems did not get resolved.  Although
we are "using" this backport, perhaps it is not needed in jdk11u.  I'm not
at all sure what to do here.

From martinrb at google.com  Mon Feb 18 20:49:34 2019
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 18 Feb 2019 12:49:34 -0800
Subject: RFR: 8212233: javadoc fails on jdk12 with "The code being
 documented uses modules but the packages defined in $URL are in the unnamed
 module."
In-Reply-To: <op.zxe83vwqkdkhrr@desktop-2khsk44>
References: <CA+kOe092oR8sKJKuDAEGmKGGbpLWXGhEKCgpxQ55RDKUxQ0n1w@mail.gmail.com>
 <CA+kOe0-SLbqefMsz41AYvzi_++zv6wqei8YFR4uf59w_quNwvg@mail.gmail.com>
 <d4d16942-231b-9a1d-b05a-11a6248c6b02@redhat.com>
 <CA+kOe0_iOcySmqeiX8U9hFiViRa2zMmj0d2ijvoFvF84YeBxkA@mail.gmail.com>
 <op.zxe83vwqkdkhrr@desktop-2khsk44>
Message-ID: <CA+kOe09wzvOx1p9rXEDtYQutzZW8rfMiB=oUfJBjz4VKrveaqA@mail.gmail.com>

Thanks, Robert.

On Mon, Feb 18, 2019 at 11:15 AM Robert Scholte <rfscholte at apache.org>
wrote:

> We're close to a new release of the javadoc-maven-plugin
>

Did you mean maven-javadoc-plugin ?


> , which will have support for javadoc with the modular system.
>

So perhaps we don't need to fix jdk11 at all, and just adopt the new
release of maven-javadoc-plugin when it comes out?

In other words, are you aware of anything that needs fixing/backporting to
jdk11?  Do we need to fix JDK-8212233 ?

>
> This would be a good moment to verify if it works as expected:
>

From shade at redhat.com  Mon Feb 18 21:43:22 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 18 Feb 2019 22:43:22 +0100
Subject: RFR+RFA [11u] (S) 8219260: Default number of test jobs needs to be
 consistently calculated
Message-ID: <a7829c67-ab30-d5af-995e-7135ea06847f@redhat.com>

Bug:
  https://bugs.openjdk.java.net/browse/JDK-8219260

Fix:
  http://cr.openjdk.java.net/~shade/8219260/webrev.01/

This is the 11u-specific fix, the partial backport of the large change in 12u. See the full story in
the bug. This fix is needed to pass tier1 on decently large machine with not much memory. For
example, this allows my 32-thread Threadripper with 64 GB of memory to pass tier1 test suite with
elevated heap size due to JDK-8219251. The alternative is to guess and put TEST_JOBS param to the
test line.

Testing: Linux x86_64 fastdebug, test/langtools, tier1 on a few machines

Thanks,
-Aleksey


From shade at redhat.com  Mon Feb 18 21:42:47 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 18 Feb 2019 22:42:47 +0100
Subject: RFR+RFA [11u] (XS) 8219251: Langtools tests default memory size needs
 to be 768m
Message-ID: <b734e045-a08c-6aea-7c1b-5b953afdaf15@redhat.com>

Bug:
  https://bugs.openjdk.java.net/browse/JDK-8219251

Fix:
  http://cr.openjdk.java.net/~shade/8219251/webrev.01/

This is the high priority 11u-specific fix, the partial backport of the large change in 12u. This
makes tier1 testing possible with "make run-test TEST=tier1". Having tests passing cleanly is
necessary for doing anything else in 11u. Read the full story in the bug.

Testing: Linux x86_64 fastdebug, jtreg:test/langtools, tier1

Thanks,
-Aleksey


From martijnverburg at gmail.com  Mon Feb 18 21:52:15 2019
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Mon, 18 Feb 2019 21:52:15 +0000
Subject: 11.0.3-oracle issues in openjdk 11.0.3
In-Reply-To: <6e44cd54-44ed-1868-74a7-dd8143640b92@redhat.com>
References: <a1feaea79b634373bef62e7f471c5418@sap.com>
 <54dc52ed-cc5f-2387-f186-1bbe2eee2e73@redhat.com>
 <3dbdc01d-060f-a3cc-6202-971836398e89@redhat.com>
 <1c26e241-43eb-2e70-a8b9-d4fe01c80b54@redhat.com>
 <a2768895fb7843bba1c6961662cfb772@sap.com>
 <6e44cd54-44ed-1868-74a7-dd8143640b92@redhat.com>
Message-ID: <CAP7YuAQyFPLWwuUhvT8oTYZHNobCphmdfCJiXBg8sh8mwuVyUw@mail.gmail.com>

Hi Both,

Thanks for tackling this on behalf of the OpenJDK updates 11 stream!  Would
it be sensible to keep tagging these if people use <vendor>-openjdk |
<individual>-openjdk as a label so if more of us pile in we don't clash?

Hmm, that said perhaps just co-ordinating in IRC and here is sufficient.

Cheers,
Martijn


On Mon, 18 Feb 2019 at 14:40, Aleksey Shipilev <shade at redhat.com> wrote:

> On 2/18/19 2:09 PM, Langer, Christoph wrote:
> > Hi Aleksey
> >
> >> The first salvo of 10+ backports had landed in jdk-updates/jdk11u a few
> hours ago. Working
> >> through others. Christoph, at some point we would need to coordinate to
> avoid duplicate work. I
> >> am trying to put "redhat-openjdk" the moment I start working on a bug.
> Otherwise, I am at
> >> #openjdk @ OFTC.
> >
> > OK, I'll watch out for your "redhat-openjdk" claim then. Let's see if
> that's enough to sync...
> I pushed another salvo to 11u. Down to 26 issues now.
>
> CI reports there are two failures in langtools tier1, that were there
> before we started backporting
> 11.0.3-oracle changes. Failing tests are:
>   jdk/javadoc/doclet/testLinkOption/TestLinkOptionWithAutomaticModule
>   jdk/internal/shellsupport/doc/JavadocHelperTest.java
>
> Let me look into that instead of backporting more 11.0.3-oracle things.
> This also would let
> Christoph work on 11u backports without colliding with my work.
>
> -Aleksey
>
>

From gnu.andrew at redhat.com  Mon Feb 18 22:44:49 2019
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Mon, 18 Feb 2019 22:44:49 +0000
Subject: JDK 11.0.3 Update process
In-Reply-To: <4563e824781546caad34bc27e6d4c13b@sap.com>
References: <CA+3eh12Rtb1MQt2xr-Tu8svvZ0+NEWs4bsn0oRpnHyGhXF0fqA@mail.gmail.com>
 <be92b505-d50b-097c-d26f-f9768c90cbd0@redhat.com>
 <CA+3eh13GiMDF-8_kofUqzZvCWK2_va+DRMJDtYm6COSDLzQV6g@mail.gmail.com>
 <586ca28f-83c9-1703-040c-f9cb1f3b6180@redhat.com>
 <CA+3eh13WReDH2JHfAQDhRwxMnhQOvPt3Ab7D_eMN_eYdunnbmw@mail.gmail.com>
 <eadfaea4-b1f2-e15f-56f4-aa120072b14b@redhat.com>
 <20190218143520.GD5015@vimes>
 <ce5948c57b0243c98b5802655e5bf8d6@sap.com> <20190218152833.GE5015@vimes>
 <6883507c-c8bf-3f67-e5e3-2d6ec937a903@redhat.com>
 <20190218162231.GF5015@vimes>
 <90d036e5-c629-9d1e-1150-eb85b37ab91b@redhat.com>
 <CA+3eh13=JmXOkQOUShKw5ZA-nSA0JM-rwbb7qdeAs4B_WPFBVg@mail.gmail.com>
 <8d1f4dcd-7031-4e7e-e569-42d0ce21c9ca@redhat.com>
 <5ec1a955-db90-a83b-fc49-277664ada52a@redhat.com>
 <a1ab759a-f171-5bf4-0f03-6b24c409bf58@redhat.com>
 <4f6ee3a1-138f-84b7-edc6-252d750fca5b@redhat.com>
 <4563e824781546caad34bc27e6d4c13b@sap.com>
Message-ID: <CABi63P6+M-36xPnXriHv1GizGu12ntcmvRdARnFQWqBuZUyjpA@mail.gmail.com>

On Mon, 18 Feb 2019 at 19:26, Langer, Christoph
<christoph.langer at sap.com> wrote:
>
> Hi,
>
> I agree with Aleksey's point of view on the backports. We're currently processing them and I believe it'll take a little bit of time until we're done. Today, for instance, I stumbled over a JFR change which needs some more thinking/testing. So, for the time being I think it's best we keep jdk11u open for that work. So hopefully some time next week we'll be done with the main bulk and can proceed going towards the new setup.
>
> I also think, we should get the answer to Volker's questions about the right way to do merges with these mercurial trees and the hgupdater tool before we install the new repository setup.
>
> Consider a point when we have the target setup in place (as per Rob's mail which fits perfectly by the way, thanks Rob):
> jdk11u         -> 11.0.3 (Changes pushed to jdk11u will create a JBS backport issue targeted for version 11.0.3)
> jdk11u-dev -> 11.0.4 (Changes pushed to jdk11u-dev will create a JBS backport issue targeted for version 11.0.4)
>
> I would think we should then push changes targeting version 11.0.3 into the jdk11u repo. Then, by merging jdk11u regularly into jdk11u-dev, we'll get the 11.0.4 backport items created by hgupdater. Rob needs to confirm that. And what happens, if a change in jdk11u-dev needs to be cherry-picked to jdk11u? will hgupdater be smart enough to cope with that when merging back jdk11u into jdk11u-dev? And, what happens, if after April we set jdk11u to target 11.04 in hgupdater and then merge jdk11u-dev into jdk11u? Will hgupdater be smart enough to handle that? I believe/hope the answer to both questions is a yes, but I'd like to have Rob or somebody from the Oracle ops team confirm.
>
> We should also find an agreement on the question what the restrictions for jdk11u repository will be eventually? Shall it be all jdk-updates committers or only a subset of people performing the release work? I'm open here.
>
> And last but not least, Andrew (APH): As of today you are the appointed jdk11u maintainer [0]. Congratulations Now I think this means that you'll need to approve our "jdk11u-fix-request" labeling in JBS. And there are quite a few of them. I suggest you name a few additional maintainers like Oracle has for the jdk12u updates project [1], that have the powers to approve these fix requests. I'd like to hereby nominate Aleksey, Andrew (Hughes) and myself for this role. We should of course stick to Alekseys suggested rule that if one of us requests a backport, somebody else from the maintainers group has to approve to follow a 4-eyes principle. Would you agree to that?
>
> Thanks and Best regards
> Christoph
>
> [0] https://wiki.openjdk.java.net/display/JDKUpdates/JDK11u
> [1] https://wiki.openjdk.java.net/display/JDKUpdates/JDK12u
>

It does seem a bit early to me for 11.0.4, especially with the
transition from Oracle ownership. I was expecting
the branch to happen more around the time we received the security
patches, but then I also feel that the lead
time under Oracle was too long, leading to patches taking a long time
to actually appear in releases. It really
depends on what testing one wants to do prior to release.

Thank you for the nomination, by the way. Accepted :-)
-- 
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  Mon Feb 18 22:49:56 2019
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Mon, 18 Feb 2019 22:49:56 +0000
Subject: JDK 11.0.3 Update process
In-Reply-To: <3b877136-b4be-ff3e-e972-df402c816e1d@redhat.com>
References: <c7027fa19a28408e83461360f3ce6974@sap.com>
 <CA+3eh12Rtb1MQt2xr-Tu8svvZ0+NEWs4bsn0oRpnHyGhXF0fqA@mail.gmail.com>
 <be92b505-d50b-097c-d26f-f9768c90cbd0@redhat.com>
 <CA+3eh13GiMDF-8_kofUqzZvCWK2_va+DRMJDtYm6COSDLzQV6g@mail.gmail.com>
 <586ca28f-83c9-1703-040c-f9cb1f3b6180@redhat.com>
 <CA+3eh13WReDH2JHfAQDhRwxMnhQOvPt3Ab7D_eMN_eYdunnbmw@mail.gmail.com>
 <eadfaea4-b1f2-e15f-56f4-aa120072b14b@redhat.com>
 <1c9f80b75b7b492b9e463445eafd7c3d@sap.com>
 <cbaa356a-54b2-7c18-5b0b-3cdc12f58f46@redhat.com>
 <CABi63P4HtF+48sZszoonKTKA+ysuCEBrVg64bvOw52EKPS4hRA@mail.gmail.com>
 <3b877136-b4be-ff3e-e972-df402c816e1d@redhat.com>
Message-ID: <CABi63P7Gv7K8kp8Yg=AE-8EgHXjvw_cnsGL-yKNttzpONY7Big@mail.gmail.com>

n Mon, 18 Feb 2019 at 09:42, Andrew Haley <aph at redhat.com> wrote:
>
> On 2/15/19 6:06 PM, Andrew Hughes wrote:
>
> > As I said before [0], I think the jdkxxu repository should be
> > restricted, maintaining a clear distinction between a jdkxxu-dev
> > branch for developers to commit to, and the jdkxxu for
> > consumption. The latter is the one that would be frozen and used as
> > the base for releases around CPU time.  That avoids a situation
> > where people push stuff to jdkxxu in the interim and then are
> > surprised when it's not in the release.
> >
> > If there's an issue with a lack of a maintainer, then that's a sign
> > we need to appoint more, not abandon the whole idea.
>
> I have thought some more about this, and I now believe there is a
> deeper issue.
>
> The problem is that we've been conflating two roles in the
> "maintainer". One is someone whose role is essentially judgemental:
> they decide whether a patch is suitable for a particular release. The
> other role is integrative: they merge a patch into a release branch
> and make sure the result works by testing it. These two roles are not
> the same thing, and require different skills.
>
> We are likely to encounter scaling problems as we work on the updates
> projects and we will do ourselves no favours by creating bottlenecks
> to efficient parallel working. A mature updates project would allow
> many people, with different skills, to work together on a release
> branch. Not all of these people would have the authority (or even the
> desire) to approve patches.
>
> --
> Andrew Haley
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

Indeed. In the Oracle sense, it is very much the former role of
adjudicating on which changes make it to the release and which don't.

The other role has been largely nameless, because that process is
basically opaque under Oracle ownership; once they branch the tree
(privately) for "RDP2", the only evidence we have of activity is entries
in the bug database.

So this is the area we really need to define more in-depth. At the end of
day, primary responsibility will have to go to someone who can do TCK
testing as any release should pass that. On what platforms that is the
case is yet another issue, so the work may need to be distributed against
multiple interested parties.

OpenJDK 6 & 7 have been much lower traffic, so we have generally got away
with doing our Red Hat builds and TCK testing, and then just doing the final
push & release in public. The process will need to be formalised for 8u & 11u.
-- 
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 aleksei.voitylov at bell-sw.com  Tue Feb 19 05:37:39 2019
From: aleksei.voitylov at bell-sw.com (Aleksei Voitylov)
Date: Tue, 19 Feb 2019 08:37:39 +0300
Subject: JDK 11.0.3 Update process
In-Reply-To: <CABi63P7Gv7K8kp8Yg=AE-8EgHXjvw_cnsGL-yKNttzpONY7Big@mail.gmail.com>
References: <c7027fa19a28408e83461360f3ce6974@sap.com>
 <CA+3eh12Rtb1MQt2xr-Tu8svvZ0+NEWs4bsn0oRpnHyGhXF0fqA@mail.gmail.com>
 <be92b505-d50b-097c-d26f-f9768c90cbd0@redhat.com>
 <CA+3eh13GiMDF-8_kofUqzZvCWK2_va+DRMJDtYm6COSDLzQV6g@mail.gmail.com>
 <586ca28f-83c9-1703-040c-f9cb1f3b6180@redhat.com>
 <CA+3eh13WReDH2JHfAQDhRwxMnhQOvPt3Ab7D_eMN_eYdunnbmw@mail.gmail.com>
 <eadfaea4-b1f2-e15f-56f4-aa120072b14b@redhat.com>
 <1c9f80b75b7b492b9e463445eafd7c3d@sap.com>
 <cbaa356a-54b2-7c18-5b0b-3cdc12f58f46@redhat.com>
 <CABi63P4HtF+48sZszoonKTKA+ysuCEBrVg64bvOw52EKPS4hRA@mail.gmail.com>
 <3b877136-b4be-ff3e-e972-df402c816e1d@redhat.com>
 <CABi63P7Gv7K8kp8Yg=AE-8EgHXjvw_cnsGL-yKNttzpONY7Big@mail.gmail.com>
Message-ID: <ab24062e-6c6e-427c-7efb-30093c9d6262@bell-sw.com>


On 19/02/2019 01:49, Andrew Hughes wrote:
> n Mon, 18 Feb 2019 at 09:42, Andrew Haley <aph at redhat.com> wrote:
>> On 2/15/19 6:06 PM, Andrew Hughes wrote:
>>
>>> As I said before [0], I think the jdkxxu repository should be
>>> restricted, maintaining a clear distinction between a jdkxxu-dev
>>> branch for developers to commit to, and the jdkxxu for
>>> consumption. The latter is the one that would be frozen and used as
>>> the base for releases around CPU time.  That avoids a situation
>>> where people push stuff to jdkxxu in the interim and then are
>>> surprised when it's not in the release.
>>>
>>> If there's an issue with a lack of a maintainer, then that's a sign
>>> we need to appoint more, not abandon the whole idea.
>> I have thought some more about this, and I now believe there is a
>> deeper issue.
>>
>> The problem is that we've been conflating two roles in the
>> "maintainer". One is someone whose role is essentially judgemental:
>> they decide whether a patch is suitable for a particular release. The
>> other role is integrative: they merge a patch into a release branch
>> and make sure the result works by testing it. These two roles are not
>> the same thing, and require different skills.
>>
>> We are likely to encounter scaling problems as we work on the updates
>> projects and we will do ourselves no favours by creating bottlenecks
>> to efficient parallel working. A mature updates project would allow
>> many people, with different skills, to work together on a release
>> branch. Not all of these people would have the authority (or even the
>> desire) to approve patches.
>>
>> --
>> Andrew Haley
>> Java Platform Lead Engineer
>> Red Hat UK Ltd. <https://www.redhat.com>
>> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
> Indeed. In the Oracle sense, it is very much the former role of
> adjudicating on which changes make it to the release and which don't.
>
> The other role has been largely nameless, because that process is
> basically opaque under Oracle ownership; once they branch the tree
> (privately) for "RDP2", the only evidence we have of activity is entries
> in the bug database.
>
> So this is the area we really need to define more in-depth. At the end of
> day, primary responsibility will have to go to someone who can do TCK
> testing as any release should pass that. On what platforms that is the
> case is yet another issue, so the work may need to be distributed against
> multiple interested parties.
>
> OpenJDK 6 & 7 have been much lower traffic, so we have generally got away
> with doing our Red Hat builds and TCK testing, and then just doing the final
> push & release in public. The process will need to be formalised for 8u & 11u.

It's too late to run TCK and other suites by the time the release is 
about to happen to have a healthy release (yet, I'm not suggesting such 
a procedure should not happen in the end). It has to be an on-going 
process, and a repository where functional and regression fixes are 
accumulating is going to help with that, since this is the repository 
where changes most likely to cause regressions will happen.

As far as TCK is concerned, it's binaries that are certified, and there 
is a thousand ways to produce a binary that won't pass TCK from the 
sources someone else uses to produce a good one.

I believe companies willing to participate in this effort are mostly 
represented here and the process should be just continuous testing and 
bug fixing. From BellSoft end, we are willing to participate focusing on 
some platforms which are less covered by others, such as ARM32, some 
AARCH64 microarchitectures, Solaris SPARC and x86. I believe the rest 
are better covered by other companies testing (SAP, Red Hat). I'm not 
suggesting there should not be some overlap.


From christoph.langer at sap.com  Tue Feb 19 07:31:41 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 19 Feb 2019 07:31:41 +0000
Subject: CSRs and OpenJDK (11.0.3) Updates
Message-ID: <26321955331640dea328a2f79b39fc29@sap.com>

Hi,

I have a question regarding the downport of fixes when a CSR is involved.

Look at issue JDK-8213952 [0]. It has a CSR: JDK-8214270 [1]. When Oracle backported it to 11.0.3-oracle, there is issue JDK-8215883 [2] for the backport and the CSR has been downported separately: JDK-8215884. Aleksey has brought the fix to OpenJDK 11.0.3 yesterday with JDK-8219240. But no CSR downport happened for that.

I guess in principle I'm fine if we skip CSR downports as I think only Oracle is involved in the CSR group so far. Maybe we should link the original CSR to the downports. Otherwise, we'd also have to have a CSR group or subgroup reviewing backport CSRs for OpenJDK community downports. Any thoughts on this? We should at least come up with a current rule how to handle such issues. Until then I'll leave those bugs alone that involve a CSRs in my backporting efforts.

Thanks & Best regards
Christoph


[0] https://bugs.openjdk.java.net/browse/JDK-8213952
[1] https://bugs.openjdk.java.net/browse/JDK-8214270
[2] https://bugs.openjdk.java.net/browse/JDK-8215883
[3] https://bugs.openjdk.java.net/browse/JDK-8215884
[4] https://bugs.openjdk.java.net/browse/JDK-8219240


From david.holmes at oracle.com  Tue Feb 19 08:00:16 2019
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 19 Feb 2019 18:00:16 +1000
Subject: CSRs and OpenJDK (11.0.3) Updates
In-Reply-To: <26321955331640dea328a2f79b39fc29@sap.com>
References: <26321955331640dea328a2f79b39fc29@sap.com>
Message-ID: <a96ca44d-fb72-1d6a-3830-41edf010bc8a@oracle.com>

Hi Christoph,

Wearing my CSR Group members hat ...

On 19/02/2019 5:31 pm, Langer, Christoph wrote:
> Hi,
> 
> I have a question regarding the downport of fixes when a CSR is involved.
> 
> Look at issue JDK-8213952 [0]. It has a CSR: JDK-8214270 [1]. When Oracle backported it to 11.0.3-oracle, there is issue JDK-8215883 [2] for the backport and the CSR has been downported separately: JDK-8215884. Aleksey has brought the fix to OpenJDK 11.0.3 yesterday with JDK-8219240. But no CSR downport happened for that.
> 
> I guess in principle I'm fine if we skip CSR downports as I think only Oracle is involved in the CSR group so far. Maybe we should link the original CSR to the downports. Otherwise, we'd also have to have a CSR group or subgroup reviewing backport CSRs for OpenJDK community downports. Any thoughts on this? We should at least come up with a current rule how to handle such issues. Until then I'll leave those bugs alone that involve a CSRs in my backporting efforts.

First, the CSR Group doesn't consist only of Oracle people - Doug Lea is 
also a member.

Second, it's unusual to "backport" a CSR request, but may be needed if 
the backported fix has different compatibility concerns on the backport 
version than the main version. IMHO the backport of the CSR for 
11.0.3-oracle applies exactly the same to 11.0.3 as it does to 
11.0.3-oracle and I would think it a waste of everyone's time to create 
a third backport for 11.0.3. But that is for the 11u maintainers to decide.

Cheers,
David

> Thanks & Best regards
> Christoph
> 
> 
> [0] https://bugs.openjdk.java.net/browse/JDK-8213952
> [1] https://bugs.openjdk.java.net/browse/JDK-8214270
> [2] https://bugs.openjdk.java.net/browse/JDK-8215883
> [3] https://bugs.openjdk.java.net/browse/JDK-8215884
> [4] https://bugs.openjdk.java.net/browse/JDK-8219240
> 

From christoph.langer at sap.com  Tue Feb 19 08:08:05 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 19 Feb 2019 08:08:05 +0000
Subject: CSRs and OpenJDK (11.0.3) Updates
In-Reply-To: <a96ca44d-fb72-1d6a-3830-41edf010bc8a@oracle.com>
References: <26321955331640dea328a2f79b39fc29@sap.com>
 <a96ca44d-fb72-1d6a-3830-41edf010bc8a@oracle.com>
Message-ID: <ab4d13805f264360a18122a092ad6193@sap.com>

Hi David,

> First, the CSR Group doesn't consist only of Oracle people - Doug Lea is
> also a member.

Ok, ok, I shot out of my hip ??

> Second, it's unusual to "backport" a CSR request, but may be needed if
> the backported fix has different compatibility concerns on the backport
> version than the main version. IMHO the backport of the CSR for
> 11.0.3-oracle applies exactly the same to 11.0.3 as it does to
> 11.0.3-oracle and I would think it a waste of everyone's time to create
> a third backport for 11.0.3. But that is for the 11u maintainers to decide.

So, do you say, it's not a requirement to downport CSRs but sometimes done on the updates maintainers request at their discretion? I was under the impression that CSR downports are mandatory. Maybe there's some lack in process documentation here?

Other than that, I fully agree that it should suffice for OpenJDK update downports to refer to Oracle CSR backports for the same update releases.

Thanks
Christoph


From david.holmes at oracle.com  Tue Feb 19 08:10:53 2019
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 19 Feb 2019 18:10:53 +1000
Subject: CSRs and OpenJDK (11.0.3) Updates
In-Reply-To: <ab4d13805f264360a18122a092ad6193@sap.com>
References: <26321955331640dea328a2f79b39fc29@sap.com>
 <a96ca44d-fb72-1d6a-3830-41edf010bc8a@oracle.com>
 <ab4d13805f264360a18122a092ad6193@sap.com>
Message-ID: <1fde8c4c-9a5c-734b-850f-148330cf3f69@oracle.com>

On 19/02/2019 6:08 pm, Langer, Christoph wrote:
> Hi David,
> 
>> First, the CSR Group doesn't consist only of Oracle people - Doug Lea is
>> also a member.
> 
> Ok, ok, I shot out of my hip ??

:)

>> Second, it's unusual to "backport" a CSR request, but may be needed if
>> the backported fix has different compatibility concerns on the backport
>> version than the main version. IMHO the backport of the CSR for
>> 11.0.3-oracle applies exactly the same to 11.0.3 as it does to
>> 11.0.3-oracle and I would think it a waste of everyone's time to create
>> a third backport for 11.0.3. But that is for the 11u maintainers to decide.
> 
> So, do you say, it's not a requirement to downport CSRs but sometimes done on the updates maintainers request at their discretion? I was under the impression that CSR downports are mandatory. Maybe there's some lack in process documentation here?

If the compatibility concerns of the backport are different to the 
original then it warrants its own CSR (lets not call it a backport-CSR).

Cheers,
David
-----

> Other than that, I fully agree that it should suffice for OpenJDK update downports to refer to Oracle CSR backports for the same update releases.
> 
> Thanks
> Christoph
> 

From christoph.langer at sap.com  Tue Feb 19 09:04:06 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 19 Feb 2019 09:04:06 +0000
Subject: JDK 11.0.3 Update process
In-Reply-To: <CABi63P6+M-36xPnXriHv1GizGu12ntcmvRdARnFQWqBuZUyjpA@mail.gmail.com>
References: <CA+3eh12Rtb1MQt2xr-Tu8svvZ0+NEWs4bsn0oRpnHyGhXF0fqA@mail.gmail.com>
 <be92b505-d50b-097c-d26f-f9768c90cbd0@redhat.com>
 <CA+3eh13GiMDF-8_kofUqzZvCWK2_va+DRMJDtYm6COSDLzQV6g@mail.gmail.com>
 <586ca28f-83c9-1703-040c-f9cb1f3b6180@redhat.com>
 <CA+3eh13WReDH2JHfAQDhRwxMnhQOvPt3Ab7D_eMN_eYdunnbmw@mail.gmail.com>
 <eadfaea4-b1f2-e15f-56f4-aa120072b14b@redhat.com>
 <20190218143520.GD5015@vimes> <ce5948c57b0243c98b5802655e5bf8d6@sap.com>
 <20190218152833.GE5015@vimes>
 <6883507c-c8bf-3f67-e5e3-2d6ec937a903@redhat.com>
 <20190218162231.GF5015@vimes>
 <90d036e5-c629-9d1e-1150-eb85b37ab91b@redhat.com>
 <CA+3eh13=JmXOkQOUShKw5ZA-nSA0JM-rwbb7qdeAs4B_WPFBVg@mail.gmail.com>
 <8d1f4dcd-7031-4e7e-e569-42d0ce21c9ca@redhat.com>
 <5ec1a955-db90-a83b-fc49-277664ada52a@redhat.com>
 <a1ab759a-f171-5bf4-0f03-6b24c409bf58@redhat.com>
 <4f6ee3a1-138f-84b7-edc6-252d750fca5b@redhat.com>
 <4563e824781546caad34bc27e6d4c13b@sap.com>
 <CABi63P6+M-36xPnXriHv1GizGu12ntcmvRdARnFQWqBuZUyjpA@mail.gmail.com>
Message-ID: <d79a9aba5c6b412c803cb76e8a10b4eb@sap.com>

Hi Andrew,

> It does seem a bit early to me for 11.0.4, especially with the
> transition from Oracle ownership. I was expecting
> the branch to happen more around the time we received the security
> patches, but then I also feel that the lead
> time under Oracle was too long, leading to patches taking a long time
> to actually appear in releases. It really
> depends on what testing one wants to do prior to release.

I tend to agree. Maybe a good time to do the 11.0.4 switch (or subsequent patch release switches) is about 4 weeks before the planned release date.

For the community I guess it is important, that you at Redhat do the security patching based on the stabilized repository and are in a position to immediately merge the security changes back to the public repositories on the release day. All the downstream OpenJDK builds will rely on that.

So you have a certain degree of freedom to choose the timing for branching according to your needs.

Best regards
Christoph


From aph at redhat.com  Tue Feb 19 09:29:54 2019
From: aph at redhat.com (Andrew Haley)
Date: Tue, 19 Feb 2019 09:29:54 +0000
Subject: RFR+RFA [11u] (XS) 8219251: Langtools tests default memory size
 needs to be 768m
In-Reply-To: <b734e045-a08c-6aea-7c1b-5b953afdaf15@redhat.com>
References: <b734e045-a08c-6aea-7c1b-5b953afdaf15@redhat.com>
Message-ID: <812f91e6-ca88-ff4c-2a90-8dbc8aa76b4f@redhat.com>

On 2/18/19 9:42 PM, Aleksey Shipilev wrote:
> Bug:
>   https://bugs.openjdk.java.net/browse/JDK-8219251
> 
> Fix:
>   http://cr.openjdk.java.net/~shade/8219251/webrev.01/

OK, thanks.

-- 
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 aph at redhat.com  Tue Feb 19 09:40:43 2019
From: aph at redhat.com (Andrew Haley)
Date: Tue, 19 Feb 2019 09:40:43 +0000
Subject: JDK 11.0.3 Update process
In-Reply-To: <CABi63P7Gv7K8kp8Yg=AE-8EgHXjvw_cnsGL-yKNttzpONY7Big@mail.gmail.com>
References: <c7027fa19a28408e83461360f3ce6974@sap.com>
 <CA+3eh12Rtb1MQt2xr-Tu8svvZ0+NEWs4bsn0oRpnHyGhXF0fqA@mail.gmail.com>
 <be92b505-d50b-097c-d26f-f9768c90cbd0@redhat.com>
 <CA+3eh13GiMDF-8_kofUqzZvCWK2_va+DRMJDtYm6COSDLzQV6g@mail.gmail.com>
 <586ca28f-83c9-1703-040c-f9cb1f3b6180@redhat.com>
 <CA+3eh13WReDH2JHfAQDhRwxMnhQOvPt3Ab7D_eMN_eYdunnbmw@mail.gmail.com>
 <eadfaea4-b1f2-e15f-56f4-aa120072b14b@redhat.com>
 <1c9f80b75b7b492b9e463445eafd7c3d@sap.com>
 <cbaa356a-54b2-7c18-5b0b-3cdc12f58f46@redhat.com>
 <CABi63P4HtF+48sZszoonKTKA+ysuCEBrVg64bvOw52EKPS4hRA@mail.gmail.com>
 <3b877136-b4be-ff3e-e972-df402c816e1d@redhat.com>
 <CABi63P7Gv7K8kp8Yg=AE-8EgHXjvw_cnsGL-yKNttzpONY7Big@mail.gmail.com>
Message-ID: <08dbb661-55c3-6c8d-89f1-4d90f7aa29ae@redhat.com>

On 2/18/19 10:49 PM, Andrew Hughes wrote:
> Indeed. In the Oracle sense, it is very much the former role of
> adjudicating on which changes make it to the release and which don't.
> 
> The other role has been largely nameless, because that process is
> basically opaque under Oracle ownership; once they branch the tree
> (privately) for "RDP2", the only evidence we have of activity is entries
> in the bug database.
> 
> So this is the area we really need to define more in-depth. At the
> end of day, primary responsibility will have to go to someone who
> can do TCK testing as any release should pass that. On what
> platforms that is the case is yet another issue, so the work may
> need to be distributed against multiple interested parties.

Probably, yes. But we have to be clear what exactly is meant by
"primary responsibility". From context I believe you're talking about
responsibility for doing the patch integration into the release
branch. And yes, they have to do TCK testing.

> OpenJDK 6 & 7 have been much lower traffic, so we have generally got
> away with doing our Red Hat builds and TCK testing, and then just
> doing the final push & release in public. The process will need to
> be formalised for 8u & 11u.

I'm reluctant. The problem with formalizing process even more is that
it becomes incomprehensible to anyone except the two or threee people
working on a release full time.

-- 
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 shade at redhat.com  Tue Feb 19 09:46:41 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 19 Feb 2019 10:46:41 +0100
Subject: RFR+RFA [11u] (XS) 8219251: Langtools tests default memory size
 needs to be 768m
In-Reply-To: <812f91e6-ca88-ff4c-2a90-8dbc8aa76b4f@redhat.com>
References: <b734e045-a08c-6aea-7c1b-5b953afdaf15@redhat.com>
 <812f91e6-ca88-ff4c-2a90-8dbc8aa76b4f@redhat.com>
Message-ID: <c0fe308c-0aaa-b628-4a79-547dd1cc64c8@redhat.com>

On 2/19/19 10:29 AM, Andrew Haley wrote:
> On 2/18/19 9:42 PM, Aleksey Shipilev wrote:
>> Bug:
>>   https://bugs.openjdk.java.net/browse/JDK-8219251
>>
>> Fix:
>>   http://cr.openjdk.java.net/~shade/8219251/webrev.01/
> 
> OK, thanks.

Thanks. Are you having your maintainer powers yet? We need jdk11u-fix-yes on the issue to proceed, I
think.

Other reviews are appreciated too!

-Aleksey


From TOSHIONA at jp.ibm.com  Tue Feb 19 09:51:57 2019
From: TOSHIONA at jp.ibm.com (Toshio 5 Nakamura)
Date: Tue, 19 Feb 2019 18:51:57 +0900
Subject: Question about backport process
Message-ID: <OF23B915D7.5A07F788-ON002583A6.00322B72-492583A6.003631F5@notes.na.collabserv.com>


Hi,

The following my backport requests had had jdk11u-fix-yes tag.
Then, should I look for a volunteer to push the changesets?
If so, can I ask that in this mailing list?
(I'm an author and have no right to push them. )

Since we have some more fixes which we'd like to request backport,
we'd like to know the appropriate process.
I'm sorry if something was wrong.

https://bugs.openjdk.java.net/browse/JDK-8211295
https://bugs.openjdk.java.net/browse/JDK-8211163
https://bugs.openjdk.java.net/browse/JDK-8211382

Thanks,
Toshio Nakamura

From shade at redhat.com  Tue Feb 19 09:56:52 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 19 Feb 2019 10:56:52 +0100
Subject: Question about backport process
In-Reply-To: <OF23B915D7.5A07F788-ON002583A6.00322B72-492583A6.003631F5@notes.na.collabserv.com>
References: <OF23B915D7.5A07F788-ON002583A6.00322B72-492583A6.003631F5@notes.na.collabserv.com>
Message-ID: <c7fbf07d-a225-93d5-1171-fd88c450fd56@redhat.com>

On 2/19/19 10:51 AM, Toshio 5 Nakamura wrote:
> The following my backport requests had had jdk11u-fix-yes tag.
> Then, should I look for a volunteer to push the changesets?
> If so, can I ask that in this mailing list?
> (I'm an author and have no right to push them. )

Yes, you need a sponsor: anyone who has the right to push to 11u. I will sponsor this for you.

> Since we have some more fixes which we'd like to request backport,
> we'd like to know the appropriate process.
> I'm sorry if something was wrong.

You did nothing wrong.

> https://bugs.openjdk.java.net/browse/JDK-8211295
> https://bugs.openjdk.java.net/browse/JDK-8211163
> https://bugs.openjdk.java.net/browse/JDK-8211382

One of this patches is already in my queue to push, so that's helpful.

-Aleksey


From shade at redhat.com  Tue Feb 19 10:01:58 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 19 Feb 2019 11:01:58 +0100
Subject: Question about backport process
In-Reply-To: <c7fbf07d-a225-93d5-1171-fd88c450fd56@redhat.com>
References: <OF23B915D7.5A07F788-ON002583A6.00322B72-492583A6.003631F5@notes.na.collabserv.com>
 <c7fbf07d-a225-93d5-1171-fd88c450fd56@redhat.com>
Message-ID: <6190f24b-de3f-93c5-fcba-38cfd2514b7a@redhat.com>

On 2/19/19 10:56 AM, Aleksey Shipilev wrote:
>> Since we have some more fixes which we'd like to request backport,
>> we'd like to know the appropriate process.
>> I'm sorry if something was wrong.
> 
> You did nothing wrong.

One minor thing here:
 https://bugs.openjdk.java.net/browse/JDK-8211382

Have you created the backport issues yourself? If so, can you please remove them? The backport
issues are created automatically on push.

-Aleksey


From christoph.langer at sap.com  Tue Feb 19 10:00:58 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 19 Feb 2019 10:00:58 +0000
Subject: RFR+RFA [11u] (XS) 8219251: Langtools tests default memory size
 needs to be 768m
In-Reply-To: <c0fe308c-0aaa-b628-4a79-547dd1cc64c8@redhat.com>
References: <b734e045-a08c-6aea-7c1b-5b953afdaf15@redhat.com>
 <812f91e6-ca88-ff4c-2a90-8dbc8aa76b4f@redhat.com>
 <c0fe308c-0aaa-b628-4a79-547dd1cc64c8@redhat.com>
Message-ID: <1ae4bb779c3a4cd18c5f8fdfdfb11dc2@sap.com>

> Thanks. Are you having your maintainer powers yet? We need jdk11u-fix-yes
> on the issue to proceed, I
> think.

The powers are there: https://wiki.openjdk.java.net/display/JDKUpdates/JDK11u :)

From christoph.langer at sap.com  Tue Feb 19 10:09:09 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 19 Feb 2019 10:09:09 +0000
Subject: Question about backport process
In-Reply-To: <6190f24b-de3f-93c5-fcba-38cfd2514b7a@redhat.com>
References: <OF23B915D7.5A07F788-ON002583A6.00322B72-492583A6.003631F5@notes.na.collabserv.com>
 <c7fbf07d-a225-93d5-1171-fd88c450fd56@redhat.com>
 <6190f24b-de3f-93c5-fcba-38cfd2514b7a@redhat.com>
Message-ID: <72d8e237eb49410598eff132f7596301@sap.com>

Hi Aleksey,

> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> Behalf Of Aleksey Shipilev
> Sent: Dienstag, 19. Februar 2019 11:02
> To: Toshio 5 Nakamura <TOSHIONA at jp.ibm.com>; jdk-updates-
> dev at openjdk.java.net
> Subject: Re: Question about backport process
> 
> On 2/19/19 10:56 AM, Aleksey Shipilev wrote:
> >> Since we have some more fixes which we'd like to request backport,
> >> we'd like to know the appropriate process.
> >> I'm sorry if something was wrong.
> >
> > You did nothing wrong.
> 
> One minor thing here:
>  https://bugs.openjdk.java.net/browse/JDK-8211382
> 
> Have you created the backport issues yourself? If so, can you please remove
> them? The backport
> issues are created automatically on push.

I think 8-pool and 11-pool issues are good. hgupdater will recognize these and resolve them instead of creating new backport items. So, no need to delete them. Try it ??

/Christoph


From TOSHIONA at jp.ibm.com  Tue Feb 19 10:09:47 2019
From: TOSHIONA at jp.ibm.com (Toshio 5 Nakamura)
Date: Tue, 19 Feb 2019 19:09:47 +0900
Subject: Question about backport process
In-Reply-To: <6190f24b-de3f-93c5-fcba-38cfd2514b7a@redhat.com>
References: <OF23B915D7.5A07F788-ON002583A6.00322B72-492583A6.003631F5@notes.na.collabserv.com>
 <c7fbf07d-a225-93d5-1171-fd88c450fd56@redhat.com>
 <6190f24b-de3f-93c5-fcba-38cfd2514b7a@redhat.com>
Message-ID: <OFD2352C14.5DA6ED32-ON002583A6.00376DC7-492583A6.0037D41C@notes.na.collabserv.com>

Hi Aleksey,

Thank you for your quick reply and support.

No, these backport issues (8-pool and 11-pool) were not created by us.

Thanks,
Toshio Nakamura

Aleksey Shipilev <shade at redhat.com> wrote on 2019/02/19 19:01:58:

> From: Aleksey Shipilev <shade at redhat.com>
> To: Toshio 5 Nakamura <TOSHIONA at jp.ibm.com>,
jdk-updates-dev at openjdk.java.net
> Date: 2019/02/19 19:02
> Subject: Re: Question about backport process
>
> On 2/19/19 10:56 AM, Aleksey Shipilev wrote:
> >> Since we have some more fixes which we'd like to request backport,
> >> we'd like to know the appropriate process.
> >> I'm sorry if something was wrong.
> >
> > You did nothing wrong.
>
> One minor thing here:
>  https://bugs.openjdk.java.net/browse/JDK-8211382
>
> Have you created the backport issues yourself? If so, can you please
> remove them? The backport
> issues are created automatically on push.
>
> -Aleksey

From shade at redhat.com  Tue Feb 19 10:10:33 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 19 Feb 2019 11:10:33 +0100
Subject: Question about backport process
In-Reply-To: <72d8e237eb49410598eff132f7596301@sap.com>
References: <OF23B915D7.5A07F788-ON002583A6.00322B72-492583A6.003631F5@notes.na.collabserv.com>
 <c7fbf07d-a225-93d5-1171-fd88c450fd56@redhat.com>
 <6190f24b-de3f-93c5-fcba-38cfd2514b7a@redhat.com>
 <72d8e237eb49410598eff132f7596301@sap.com>
Message-ID: <c614af60-6699-ae7f-3e9b-94db9f438636@redhat.com>

On 2/19/19 11:09 AM, Langer, Christoph wrote:
> I think 8-pool and 11-pool issues are good. hgupdater will recognize these and resolve them
> instead of creating new backport items. So, no need to delete them. Try it ??

Okay, let's try it. Here goes nothing :)

-Aleksey


From aph at redhat.com  Tue Feb 19 10:25:31 2019
From: aph at redhat.com (Andrew Haley)
Date: Tue, 19 Feb 2019 10:25:31 +0000
Subject: RFR+RFA [11u] (XS) 8219251: Langtools tests default memory size
 needs to be 768m
In-Reply-To: <c0fe308c-0aaa-b628-4a79-547dd1cc64c8@redhat.com>
References: <b734e045-a08c-6aea-7c1b-5b953afdaf15@redhat.com>
 <812f91e6-ca88-ff4c-2a90-8dbc8aa76b4f@redhat.com>
 <c0fe308c-0aaa-b628-4a79-547dd1cc64c8@redhat.com>
Message-ID: <b24ea0bb-8701-0b64-a885-57ac9e9f827f@redhat.com>

On 2/19/19 9:46 AM, Aleksey Shipilev wrote:
> We need jdk11u-fix-yes on the issue to proceed, I
> think.

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 goetz.lindenmaier at sap.com  Tue Feb 19 10:25:41 2019
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Tue, 19 Feb 2019 10:25:41 +0000
Subject: Question about backport process
In-Reply-To: <6190f24b-de3f-93c5-fcba-38cfd2514b7a@redhat.com>
References: <OF23B915D7.5A07F788-ON002583A6.00322B72-492583A6.003631F5@notes.na.collabserv.com>
 <c7fbf07d-a225-93d5-1171-fd88c450fd56@redhat.com>
 <6190f24b-de3f-93c5-fcba-38cfd2514b7a@redhat.com>
Message-ID: <ca56ca4fce66464887b7e0b386a9bffe@sap.com>

Hi,

he does not need to remove it. 
If it is there, it will be automatically found and closed
when the change is pushed. 

At least that is how it worked when we had to create
some manually so we could add a downport-CSR to it.

Best regards,
  Goetz.

> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> Behalf Of Aleksey Shipilev
> Sent: Dienstag, 19. Februar 2019 11:02
> To: Toshio 5 Nakamura <TOSHIONA at jp.ibm.com>; jdk-updates-
> dev at openjdk.java.net
> Subject: Re: Question about backport process
> 
> On 2/19/19 10:56 AM, Aleksey Shipilev wrote:
> >> Since we have some more fixes which we'd like to request backport,
> >> we'd like to know the appropriate process.
> >> I'm sorry if something was wrong.
> >
> > You did nothing wrong.
> 
> One minor thing here:
>  https://bugs.openjdk.java.net/browse/JDK-8211382
> 
> Have you created the backport issues yourself? If so, can you please remove
> them? The backport
> issues are created automatically on push.
> 
> -Aleksey


From shade at redhat.com  Tue Feb 19 11:09:55 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 19 Feb 2019 12:09:55 +0100
Subject: Question about backport process
In-Reply-To: <c614af60-6699-ae7f-3e9b-94db9f438636@redhat.com>
References: <OF23B915D7.5A07F788-ON002583A6.00322B72-492583A6.003631F5@notes.na.collabserv.com>
 <c7fbf07d-a225-93d5-1171-fd88c450fd56@redhat.com>
 <6190f24b-de3f-93c5-fcba-38cfd2514b7a@redhat.com>
 <72d8e237eb49410598eff132f7596301@sap.com>
 <c614af60-6699-ae7f-3e9b-94db9f438636@redhat.com>
Message-ID: <76d38b28-afc4-f0a1-e132-e75fa8d0c234@redhat.com>

On 2/19/19 11:10 AM, Aleksey Shipilev wrote:
> On 2/19/19 11:09 AM, Langer, Christoph wrote:
>> I think 8-pool and 11-pool issues are good. hgupdater will recognize these and resolve them
>> instead of creating new backport items. So, no need to delete them. Try it ??
> 
> Okay, let's try it. Here goes nothing :)

All done! Toshio, you might want to verify.

Seems to me the charsets change needs the entire JDK to be recompiled to pass tests.

Indeed, the backport targeted to 11-pool got replaced with 11.0.3. Nice.

-Aleksey


From aoqi at loongson.cn  Tue Feb 19 11:16:31 2019
From: aoqi at loongson.cn (Ao Qi)
Date: Tue, 19 Feb 2019 19:16:31 +0800
Subject: Question about backport process
In-Reply-To: <c7fbf07d-a225-93d5-1171-fd88c450fd56@redhat.com>
References: <OF23B915D7.5A07F788-ON002583A6.00322B72-492583A6.003631F5@notes.na.collabserv.com>
 <c7fbf07d-a225-93d5-1171-fd88c450fd56@redhat.com>
Message-ID: <CALjzQn7tkEUZVYURrB5t+WUaDRe6SK=Lb-ewnw4M=6Vs6NC9-A@mail.gmail.com>

Hi,

On Tue, Feb 19, 2019 at 5:56 PM Aleksey Shipilev <shade at redhat.com> wrote:
>
> On 2/19/19 10:51 AM, Toshio 5 Nakamura wrote:
> > The following my backport requests had had jdk11u-fix-yes tag.
> > Then, should I look for a volunteer to push the changesets?
> > If so, can I ask that in this mailing list?
> > (I'm an author and have no right to push them. )
>

I have the same doubt these days. I thought the changeset would be
pushed automatically, but just some time is needed.

Besides, it is said that "An OpenJDK JDK Updates Author, Committer or
Reviewer requesting their .." in Rule 0 [1]. I am not a JDK Updates
Project Author, but a JDK Project Author. And I label the tag, would
it be problematic?

> Yes, you need a sponsor: anyone who has the right to push to 11u. I will sponsor this for you.

Could someone help to push this backport request:
https://bugs.openjdk.java.net/browse/JDK-8217597 ?

Thanks,
Ao Qi

[1] http://openjdk.java.net/projects/jdk-updates/approval.html

>
> > Since we have some more fixes which we'd like to request backport,
> > we'd like to know the appropriate process.
> > I'm sorry if something was wrong.
>
> You did nothing wrong.
>
> > https://bugs.openjdk.java.net/browse/JDK-8211295
> > https://bugs.openjdk.java.net/browse/JDK-8211163
> > https://bugs.openjdk.java.net/browse/JDK-8211382
>
> One of this patches is already in my queue to push, so that's helpful.
>
> -Aleksey
>

From shade at redhat.com  Tue Feb 19 11:32:15 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 19 Feb 2019 12:32:15 +0100
Subject: Question about backport process
In-Reply-To: <CALjzQn7tkEUZVYURrB5t+WUaDRe6SK=Lb-ewnw4M=6Vs6NC9-A@mail.gmail.com>
References: <OF23B915D7.5A07F788-ON002583A6.00322B72-492583A6.003631F5@notes.na.collabserv.com>
 <c7fbf07d-a225-93d5-1171-fd88c450fd56@redhat.com>
 <CALjzQn7tkEUZVYURrB5t+WUaDRe6SK=Lb-ewnw4M=6Vs6NC9-A@mail.gmail.com>
Message-ID: <16fc1ba1-1156-7e49-2d58-9cd705928a6a@redhat.com>

On 2/19/19 12:16 PM, Ao Qi wrote:
>> On 2/19/19 10:51 AM, Toshio 5 Nakamura wrote:
>>> The following my backport requests had had jdk11u-fix-yes tag.
>>> Then, should I look for a volunteer to push the changesets?
>>> If so, can I ask that in this mailing list?
>>> (I'm an author and have no right to push them. )
>>
> 
> I have the same doubt these days. I thought the changeset would be
> pushed automatically, but just some time is needed.

I think you are good with being Author when suggesting the backport. You are encouraged to do all
the bits for Fix Request (applying the patch, authoring the RFR if needed, testing, etc). The only
wrinkle is that you cannot push the result.

It is very unlikely that somebody would invest the time in the backport _just_ because there is Fix
Request. The intent is that whoever does Fix Request does the bulk of the work.

> Could someone help to push this backport request:
> https://bugs.openjdk.java.net/browse/JDK-8217597 ?

I'll sponsor this for you.

Thanks,
-Aleksey



From shade at redhat.com  Tue Feb 19 11:52:49 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 19 Feb 2019 12:52:49 +0100
Subject: RFR+RFA [11u] (XS) 8219251: Langtools tests default memory size
 needs to be 768m
In-Reply-To: <1ae4bb779c3a4cd18c5f8fdfdfb11dc2@sap.com>
References: <b734e045-a08c-6aea-7c1b-5b953afdaf15@redhat.com>
 <812f91e6-ca88-ff4c-2a90-8dbc8aa76b4f@redhat.com>
 <c0fe308c-0aaa-b628-4a79-547dd1cc64c8@redhat.com>
 <1ae4bb779c3a4cd18c5f8fdfdfb11dc2@sap.com>
Message-ID: <61bb1ea7-e514-6627-c784-23f454b58229@redhat.com>

On 2/19/19 11:00 AM, Langer, Christoph wrote:
>> Thanks. Are you having your maintainer powers yet? We need jdk11u-fix-yes
>> on the issue to proceed, I think.
> 
> The powers are there: https://wiki.openjdk.java.net/display/JDKUpdates/JDK11u :)

Hey Christoph, I want to have another reviewer on record for that change. May I put your name there
too, along with aph?

-Aleksey




From shade at redhat.com  Tue Feb 19 11:55:18 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 19 Feb 2019 12:55:18 +0100
Subject: Question about backport process
In-Reply-To: <16fc1ba1-1156-7e49-2d58-9cd705928a6a@redhat.com>
References: <OF23B915D7.5A07F788-ON002583A6.00322B72-492583A6.003631F5@notes.na.collabserv.com>
 <c7fbf07d-a225-93d5-1171-fd88c450fd56@redhat.com>
 <CALjzQn7tkEUZVYURrB5t+WUaDRe6SK=Lb-ewnw4M=6Vs6NC9-A@mail.gmail.com>
 <16fc1ba1-1156-7e49-2d58-9cd705928a6a@redhat.com>
Message-ID: <98bbe7e8-d82b-2e1e-13a4-06fb02851891@redhat.com>

On 2/19/19 12:32 PM, Aleksey Shipilev wrote:
>> Could someone help to push this backport request:
>> https://bugs.openjdk.java.net/browse/JDK-8217597 ?
> 
> I'll sponsor this for you.

All done for 11u and 12u. You might want to check it was done correctly. I had verified both 11u and
12u test works fine with my (new) Docker.

-Aleksey


From aoqi at loongson.cn  Tue Feb 19 12:02:14 2019
From: aoqi at loongson.cn (Ao Qi)
Date: Tue, 19 Feb 2019 20:02:14 +0800
Subject: Question about backport process
In-Reply-To: <16fc1ba1-1156-7e49-2d58-9cd705928a6a@redhat.com>
References: <OF23B915D7.5A07F788-ON002583A6.00322B72-492583A6.003631F5@notes.na.collabserv.com>
 <c7fbf07d-a225-93d5-1171-fd88c450fd56@redhat.com>
 <CALjzQn7tkEUZVYURrB5t+WUaDRe6SK=Lb-ewnw4M=6Vs6NC9-A@mail.gmail.com>
 <16fc1ba1-1156-7e49-2d58-9cd705928a6a@redhat.com>
Message-ID: <CALjzQn4B7DoHQVnSLJ1kyKpFdTEyKx+pe5NjP0d9gdfzO-izUg@mail.gmail.com>

On Tue, Feb 19, 2019 at 7:32 PM Aleksey Shipilev <shade at redhat.com> wrote:
>
> On 2/19/19 12:16 PM, Ao Qi wrote:
> >> On 2/19/19 10:51 AM, Toshio 5 Nakamura wrote:
> >>> The following my backport requests had had jdk11u-fix-yes tag.
> >>> Then, should I look for a volunteer to push the changesets?
> >>> If so, can I ask that in this mailing list?
> >>> (I'm an author and have no right to push them. )
> >>
> >
> > I have the same doubt these days. I thought the changeset would be
> > pushed automatically, but just some time is needed.
>
> I think you are good with being Author when suggesting the backport. You are encouraged to do all
> the bits for Fix Request (applying the patch, authoring the RFR if needed, testing, etc). The only
> wrinkle is that you cannot push the result.
>
> It is very unlikely that somebody would invest the time in the backport _just_ because there is Fix
> Request. The intent is that whoever does Fix Request does the bulk of the work.
>
> > Could someone help to push this backport request:
> > https://bugs.openjdk.java.net/browse/JDK-8217597 ?
>
> I'll sponsor this for you.

Thanks:)

>
> Thanks,
> -Aleksey
>
>

From christoph.langer at sap.com  Tue Feb 19 12:54:43 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 19 Feb 2019 12:54:43 +0000
Subject: RFR+RFA [11u] (XS) 8219251: Langtools tests default memory size
 needs to be 768m
In-Reply-To: <61bb1ea7-e514-6627-c784-23f454b58229@redhat.com>
References: <b734e045-a08c-6aea-7c1b-5b953afdaf15@redhat.com>
 <812f91e6-ca88-ff4c-2a90-8dbc8aa76b4f@redhat.com>
 <c0fe308c-0aaa-b628-4a79-547dd1cc64c8@redhat.com>
 <1ae4bb779c3a4cd18c5f8fdfdfb11dc2@sap.com>
 <61bb1ea7-e514-6627-c784-23f454b58229@redhat.com>
Message-ID: <4bdd0fea3c7e4f5784290d0e0958c88e@sap.com>

Hey Aleksey, looks good. +1

> -----Original Message-----
> From: Aleksey Shipilev <shade at redhat.com>
> Sent: Dienstag, 19. Februar 2019 12:53
> To: Langer, Christoph <christoph.langer at sap.com>; Andrew Haley
> <aph at redhat.com>; jdk-updates-dev at openjdk.java.net
> Subject: Re: RFR+RFA [11u] (XS) 8219251: Langtools tests default memory
> size needs to be 768m
> 
> On 2/19/19 11:00 AM, Langer, Christoph wrote:
> >> Thanks. Are you having your maintainer powers yet? We need jdk11u-fix-
> yes
> >> on the issue to proceed, I think.
> >
> > The powers are there:
> https://wiki.openjdk.java.net/display/JDKUpdates/JDK11u :)
> 
> Hey Christoph, I want to have another reviewer on record for that change.
> May I put your name there
> too, along with aph?
> 
> -Aleksey
> 
> 


From goetz.lindenmaier at sap.com  Tue Feb 19 13:01:17 2019
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Tue, 19 Feb 2019 13:01:17 +0000
Subject: JDK 11.0.3 Update process
In-Reply-To: <CABi63P6+M-36xPnXriHv1GizGu12ntcmvRdARnFQWqBuZUyjpA@mail.gmail.com>
References: <CA+3eh12Rtb1MQt2xr-Tu8svvZ0+NEWs4bsn0oRpnHyGhXF0fqA@mail.gmail.com>
 <be92b505-d50b-097c-d26f-f9768c90cbd0@redhat.com>
 <CA+3eh13GiMDF-8_kofUqzZvCWK2_va+DRMJDtYm6COSDLzQV6g@mail.gmail.com>
 <586ca28f-83c9-1703-040c-f9cb1f3b6180@redhat.com>
 <CA+3eh13WReDH2JHfAQDhRwxMnhQOvPt3Ab7D_eMN_eYdunnbmw@mail.gmail.com>
 <eadfaea4-b1f2-e15f-56f4-aa120072b14b@redhat.com>
 <20190218143520.GD5015@vimes> <ce5948c57b0243c98b5802655e5bf8d6@sap.com>
 <20190218152833.GE5015@vimes>
 <6883507c-c8bf-3f67-e5e3-2d6ec937a903@redhat.com>
 <20190218162231.GF5015@vimes>
 <90d036e5-c629-9d1e-1150-eb85b37ab91b@redhat.com>
 <CA+3eh13=JmXOkQOUShKw5ZA-nSA0JM-rwbb7qdeAs4B_WPFBVg@mail.gmail.com>
 <8d1f4dcd-7031-4e7e-e569-42d0ce21c9ca@redhat.com>
 <5ec1a955-db90-a83b-fc49-277664ada52a@redhat.com>
 <a1ab759a-f171-5bf4-0f03-6b24c409bf58@redhat.com>
 <4f6ee3a1-138f-84b7-edc6-252d750fca5b@redhat.com>
 <4563e824781546caad34bc27e6d4c13b@sap.com>
 <CABi63P6+M-36xPnXriHv1GizGu12ntcmvRdARnFQWqBuZUyjpA@mail.gmail.com>
Message-ID: <f587004d7f82433ea0f6476c8e87d5ca@sap.com>

Hi Andrew, 

> It does seem a bit early to me for 11.0.4, especially with the
> transition from Oracle ownership. I was expecting
> the branch to happen more around the time we received the security
> patches, but then I also feel that the lead
> time under Oracle was too long, leading to patches taking a long time
> to actually appear in releases. It really
> depends on what testing one wants to do prior to release.

what we are proposing is to use jdk11u-dev for 11.0.4, and jdk11u for 
11.0.3 as soon as both are available.

What is the matter with doing this right now?  Not doing it means
that all changes downported will still end up in 11.0.3.  
Actually, I think 11.0.3 should be in stabilization phase currently, 
and it should go there as soon as possible. Aleksey and Christoph
are currently building a repository that resembles 11.0.3-oracle
as good as possible.  We should stabilize this repository starting right 
when they are finished.

At the same time, we should not block others from downporting 
changes needed in 11, but not necessarily in 11.0.3. 
There are already some 30 changes flagged 11.0.4-oracle. We could
start pushing them to jdk11u-dev if we dedicate the two repos for the
two different releases. And I think doing that now would be better than 
starting this business only 8 weeks in advance of the release.
(And if Christoph does not volunteer to do that, I might :))

So, to take up what Volker is proposing, and to put it into my own words,
I would propose:

Once we have jdk11u-dev:
 * let's start pushing 11.0.4-oracle changes to jdk11u-dev.
 * let's continue pushing 11.0.3-oracle changes to jdk11u.
 * let's push changes requested for downport for jdk11u to jdk11u-dev except:
 * let's push changes that fix issues in 11.0.3 that adhere to the RDP2 rules
    to jdk11u. This can be both: downports and fixes crafted for 11.0.3
and finally:
  * on every Thursday (or any other weekly point in time), let's merge all changes
     from jdk11u to jdk11u-dev except if jdk11u has a major issue.
     (I would volunteer to do this for now) )(based on a change that ran through
      our nightly testing as long as there are no build tags)

Best regards,
  Goetz.






> 
> Thank you for the nomination, by the way. Accepted :-)
> --
> 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 shade at redhat.com  Tue Feb 19 13:01:27 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 19 Feb 2019 14:01:27 +0100
Subject: RFR+RFA [11u] (XS) 8219251: Langtools tests default memory size
 needs to be 768m
In-Reply-To: <4bdd0fea3c7e4f5784290d0e0958c88e@sap.com>
References: <b734e045-a08c-6aea-7c1b-5b953afdaf15@redhat.com>
 <812f91e6-ca88-ff4c-2a90-8dbc8aa76b4f@redhat.com>
 <c0fe308c-0aaa-b628-4a79-547dd1cc64c8@redhat.com>
 <1ae4bb779c3a4cd18c5f8fdfdfb11dc2@sap.com>
 <61bb1ea7-e514-6627-c784-23f454b58229@redhat.com>
 <4bdd0fea3c7e4f5784290d0e0958c88e@sap.com>
Message-ID: <0a7b365a-2bc3-233e-6619-7fbaa7825d4b@redhat.com>

On 2/19/19 1:54 PM, Langer, Christoph wrote:
> Hey Aleksey, looks good. +1

Thanks. Pushed! This should make tier1 pass cleanly.

-Aleksey

P.S. If you are running tests on large machines, you might need to have lower TEST_JOBS, until this
is fixed: https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-February/000471.html




From christoph.langer at sap.com  Tue Feb 19 13:03:29 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 19 Feb 2019 13:03:29 +0000
Subject: RFR+RFA [11u] (XS) 8219251: Langtools tests default memory size
 needs to be 768m
In-Reply-To: <b24ea0bb-8701-0b64-a885-57ac9e9f827f@redhat.com>
References: <b734e045-a08c-6aea-7c1b-5b953afdaf15@redhat.com>
 <812f91e6-ca88-ff4c-2a90-8dbc8aa76b4f@redhat.com>
 <c0fe308c-0aaa-b628-4a79-547dd1cc64c8@redhat.com>
 <b24ea0bb-8701-0b64-a885-57ac9e9f827f@redhat.com>
Message-ID: <c6fdaca0181741559e74abe2f4d4ff86@sap.com>

Hi Andrew,

there are a few fixes flagged by me and Alex waiting for approval: https://bugs.openjdk.java.net/issues/?filter=36358

Can you take care of these?

Thanks
Christoph


> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> Behalf Of Andrew Haley
> Sent: Dienstag, 19. Februar 2019 11:26
> To: Aleksey Shipilev <shade at redhat.com>; jdk-updates-
> dev at openjdk.java.net
> Subject: Re: RFR+RFA [11u] (XS) 8219251: Langtools tests default memory
> size needs to be 768m
> 
> On 2/19/19 9:46 AM, Aleksey Shipilev wrote:
> > We need jdk11u-fix-yes on the issue to proceed, I
> > think.
> 
> 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 shade at redhat.com  Tue Feb 19 13:23:52 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 19 Feb 2019 14:23:52 +0100
Subject: RFR+RFA [11u] 8214827: Incorrect call
 ClassLoaders.toFileURL("jrt:/java.compiler")
Message-ID: <5925becf-4bd3-1755-d620-dd3a966b5e6d@redhat.com>

Please review and approve the backport to 11u:

  Original Bug:
      URL: https://bugs.openjdk.java.net/browse/JDK-8214827
      Reporter: Martin Buchholz
      Assignee: Jiangli Zhou
      Priority: P3
      Components: hotspot

  Original Fix:
        12: JDK-8214827, http://hg.openjdk.java.net/jdk/jdk12/rev/fbab5d82f3d7, 40 day(s) ago

  Backports and Forwardports:
        13: 13, JDK-8216526, http://hg.openjdk.java.net/jdk/jdk/rev/fbab5d82f3d7, 40 day(s) ago
        11: MISSING
         8: Not affected


The patch does not apply cleanly to 11u, because it conflicts with non-backported cleanup change
(JDK-8207211) in test/hotspot/jtreg/runtime/appcds/test-classes/ProtDomain.java. Manual merge in
that test was needed.

The resulting 11u webrev:
  http://cr.openjdk.java.net/~shade/8214827/webrev.11u.01/

Testing: new test, entire runtime/appcds suite; verified new regression test fails without patch

Thanks,
-Aleksey


From aph at redhat.com  Tue Feb 19 13:25:12 2019
From: aph at redhat.com (Andrew Haley)
Date: Tue, 19 Feb 2019 13:25:12 +0000
Subject: RFR+RFA [11u] (XS) 8219251: Langtools tests default memory size
 needs to be 768m
In-Reply-To: <c6fdaca0181741559e74abe2f4d4ff86@sap.com>
References: <b734e045-a08c-6aea-7c1b-5b953afdaf15@redhat.com>
 <812f91e6-ca88-ff4c-2a90-8dbc8aa76b4f@redhat.com>
 <c0fe308c-0aaa-b628-4a79-547dd1cc64c8@redhat.com>
 <b24ea0bb-8701-0b64-a885-57ac9e9f827f@redhat.com>
 <c6fdaca0181741559e74abe2f4d4ff86@sap.com>
Message-ID: <766d47e5-5f96-5d01-5a1a-f998b718f532@redhat.com>

On 2/19/19 1:03 PM, Langer, Christoph wrote:
> there are a few fixes flagged by me and Alex waiting for approval: https://bugs.openjdk.java.net/issues/?filter=36358
> 
> Can you take care of these?

Why is JDK-8212828 included in this list? It's not a bug. I can't see any strong
reason to include it. "Nice to have" is not really enough: there are lots of things
that would be nice to have.

I ACK'd the rest.

-- 
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 aph at redhat.com  Tue Feb 19 13:25:24 2019
From: aph at redhat.com (Andrew Haley)
Date: Tue, 19 Feb 2019 13:25:24 +0000
Subject: RFR+RFA [11u] (XS) 8219251: Langtools tests default memory size
 needs to be 768m
In-Reply-To: <c0fe308c-0aaa-b628-4a79-547dd1cc64c8@redhat.com>
References: <b734e045-a08c-6aea-7c1b-5b953afdaf15@redhat.com>
 <812f91e6-ca88-ff4c-2a90-8dbc8aa76b4f@redhat.com>
 <c0fe308c-0aaa-b628-4a79-547dd1cc64c8@redhat.com>
Message-ID: <eace4dc9-fc34-5749-86af-c44f2ed2fd74@redhat.com>

On 2/19/19 9:46 AM, Aleksey Shipilev wrote:
> On 2/19/19 10:29 AM, Andrew Haley wrote:
>> On 2/18/19 9:42 PM, Aleksey Shipilev wrote:
>>> Bug:
>>>   https://bugs.openjdk.java.net/browse/JDK-8219251
>>>
>>> Fix:
>>>   http://cr.openjdk.java.net/~shade/8219251/webrev.01/
>>
>> OK, thanks.
> 
> Thanks. Are you having your maintainer powers yet? We need jdk11u-fix-yes on the issue to proceed, I
> think.

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 christoph.langer at sap.com  Tue Feb 19 13:30:02 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 19 Feb 2019 13:30:02 +0000
Subject: RFR+RFA [11u] (XS) 8219251: Langtools tests default memory size
 needs to be 768m
In-Reply-To: <766d47e5-5f96-5d01-5a1a-f998b718f532@redhat.com>
References: <b734e045-a08c-6aea-7c1b-5b953afdaf15@redhat.com>
 <812f91e6-ca88-ff4c-2a90-8dbc8aa76b4f@redhat.com>
 <c0fe308c-0aaa-b628-4a79-547dd1cc64c8@redhat.com>
 <b24ea0bb-8701-0b64-a885-57ac9e9f827f@redhat.com>
 <c6fdaca0181741559e74abe2f4d4ff86@sap.com>
 <766d47e5-5f96-5d01-5a1a-f998b718f532@redhat.com>
Message-ID: <13a077e8795c4dd1862f3cd9cc9f9919@sap.com>

> Why is JDK-8212828 included in this list? It's not a bug. I can't see any strong
> reason to include it. "Nice to have" is not really enough: there are lots of
> things
> that would be nice to have.

We have to defer this one to Thomas. I think he started the backporting work some days ago when still Oracle was in charge. However, he needed to request a CSR for the backport - that's where this one is stuck at the moment. I agree, it should not be approved at the moment.


> I ACK'd the rest.

Thanks

From rob.mckenna at oracle.com  Tue Feb 19 13:39:34 2019
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Tue, 19 Feb 2019 13:39:34 +0000
Subject: JDK 11.0.3 Update process
In-Reply-To: <CA+3eh13=JmXOkQOUShKw5ZA-nSA0JM-rwbb7qdeAs4B_WPFBVg@mail.gmail.com>
References: <586ca28f-83c9-1703-040c-f9cb1f3b6180@redhat.com>
 <CA+3eh13WReDH2JHfAQDhRwxMnhQOvPt3Ab7D_eMN_eYdunnbmw@mail.gmail.com>
 <eadfaea4-b1f2-e15f-56f4-aa120072b14b@redhat.com>
 <20190218143520.GD5015@vimes>
 <ce5948c57b0243c98b5802655e5bf8d6@sap.com>
 <20190218152833.GE5015@vimes>
 <6883507c-c8bf-3f67-e5e3-2d6ec937a903@redhat.com>
 <20190218162231.GF5015@vimes>
 <90d036e5-c629-9d1e-1150-eb85b37ab91b@redhat.com>
 <CA+3eh13=JmXOkQOUShKw5ZA-nSA0JM-rwbb7qdeAs4B_WPFBVg@mail.gmail.com>
Message-ID: <20190219133934.GA15514@vimes>

On 18/02/19 19:05, Volker Simonis wrote:
> I'm fine with the wording in Rob's "request template" (thanks for
> providing it!). I think it expresses exactly what we've proposed so
> far.
> 
> It actually means that once it is executed, all the 11-update
> downports will have to go to "jdk11u-dev" repository and will be
> scheduled for 11.0.4. Only the changes which are already in 11u at the
> time of cloning will automatically become part of 11.0.3.
> 
> We will have to somehow communicate this fact very prominently (or
> maybe even restrict commits to 11u for some time) because until now
> all the downports for 11-updates went into 11u. 11-update downporters
> will have to adjust their habit once we have jdk-updates/jdk11u-dev!
> 
> Besides that, I have another question which I kindly ask Rob to answer :)
> 
> > In addition to this I would like to request that the fix versions for
> > hgupdater be set to:
> >
> > jdk-updates/jdk11u-dev: 11.0.4
> > jdk-updates/jdk11u: 11.0.3
> 
> Once this is done, how best proceed with a change (say a P1) which
> needs to go into both 11.0.3 and 11.0.4. My idea was to downport it
> directly to jdk-updates/jdk11u and regularly push from
> jdk-updates/jdk11u to jdk-updates/jdk11u-dev. Is this the way it was
> previously done at Oracle?

No, we always push to the always-open repo first. (in this case the
11.0.4 repo) After examining the risk of the fix / impact to testing, if
an issue is approved for the rampdown release it is hg export / imported
to that repo.

    -Rob

> 
> The other possiblity would be to instantly downport it to both
> jdk-updates/jdk11u and jdk-updates/jdk11u-dev. But in the end, this
> would leave us (after 11.0.3 will be merged back into
> jdk-updates/jdk11u) with two different instances of the same change in
> jdk11u-dev and all subsequent releases. I think that would be not very
> nice and quite confusing. If possible I'd like to avoid that.
> 
> Thanks for your support,
> Volker
> 
> On Mon, Feb 18, 2019 at 6:01 PM Andrew Haley <aph at redhat.com> wrote:
> >
> > On 2/18/19 4:22 PM, Rob McKenna wrote:
> > > Correct me if I have the wrong fix versions here, but the following email
> > > should suffice for both requests:
> >
> > Thanks. I'll wait for an ACK from someone else contributing to this discussion,
> > then send the request.
> >
> > --
> > 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 christoph.langer at sap.com  Tue Feb 19 13:40:17 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 19 Feb 2019 13:40:17 +0000
Subject: RFR+RFA [11u] 8197398: (zipfs) Files.walkFileTree walk indefinitelly
 while processing JAR file with "/" as a directory inside.
Message-ID: <1d4d1cc915b549cd87110f12dd5cd8bb@sap.com>

Please review and approve the backport to 11u:



Original Bug: https://bugs.openjdk.java.net/browse/JDK-8197398

Original Fix: http://hg.openjdk.java.net/jdk/jdk/rev/2e4cf4ca074c

11u webrev: http://cr.openjdk.java.net/~clanger/webrevs/8197398.jdk11u/



The patch did not apply cleanly to 11u, because it conflicts with other changes that had already been done in ZipFileSystem.java.

Testing: jdk.zipfs jtreg regression tests ran successfully.


Thanks
Christoph


From christoph.langer at sap.com  Tue Feb 19 13:44:00 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 19 Feb 2019 13:44:00 +0000
Subject: RFR+RFA [11u] 8214827: Incorrect call
 ClassLoaders.toFileURL("jrt:/java.compiler")
In-Reply-To: <5925becf-4bd3-1755-d620-dd3a966b5e6d@redhat.com>
References: <5925becf-4bd3-1755-d620-dd3a966b5e6d@redhat.com>
Message-ID: <c0c8cd9a635d4b898057dd2577a48e10@sap.com>

LGTM +1

> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> Behalf Of Aleksey Shipilev
> Sent: Dienstag, 19. Februar 2019 14:24
> To: jdk-updates-dev at openjdk.java.net
> Subject: RFR+RFA [11u] 8214827: Incorrect call
> ClassLoaders.toFileURL("jrt:/java.compiler")
> 
> Please review and approve the backport to 11u:
> 
>   Original Bug:
>       URL: https://bugs.openjdk.java.net/browse/JDK-8214827
>       Reporter: Martin Buchholz
>       Assignee: Jiangli Zhou
>       Priority: P3
>       Components: hotspot
> 
>   Original Fix:
>         12: JDK-8214827,
> http://hg.openjdk.java.net/jdk/jdk12/rev/fbab5d82f3d7, 40 day(s) ago
> 
>   Backports and Forwardports:
>         13: 13, JDK-8216526,
> http://hg.openjdk.java.net/jdk/jdk/rev/fbab5d82f3d7, 40 day(s) ago
>         11: MISSING
>          8: Not affected
> 
> 
> The patch does not apply cleanly to 11u, because it conflicts with non-
> backported cleanup change
> (JDK-8207211) in test/hotspot/jtreg/runtime/appcds/test-
> classes/ProtDomain.java. Manual merge in
> that test was needed.
> 
> The resulting 11u webrev:
>   http://cr.openjdk.java.net/~shade/8214827/webrev.11u.01/
> 
> Testing: new test, entire runtime/appcds suite; verified new regression test
> fails without patch
> 
> Thanks,
> -Aleksey


From shade at redhat.com  Tue Feb 19 13:54:23 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 19 Feb 2019 14:54:23 +0100
Subject: RFR+RFA [11u] 8197398: (zipfs) Files.walkFileTree walk
 indefinitelly while processing JAR file with "/" as a directory inside.
In-Reply-To: <1d4d1cc915b549cd87110f12dd5cd8bb@sap.com>
References: <1d4d1cc915b549cd87110f12dd5cd8bb@sap.com>
Message-ID: <029cbfc3-ac87-e6d8-be5c-dfdd1eedb1a6@redhat.com>

On 2/19/19 2:40 PM, Langer, Christoph wrote:
> Original Fix: http://hg.openjdk.java.net/jdk/jdk/rev/2e4cf4ca074c
> 11u webrev: http://cr.openjdk.java.net/~clanger/webrevs/8197398.jdk11u/

Looks good to me.

So the difference between two patches are these:

*) This one is fine, because there is no such line in 11u at all:

orig: -                e.method = METHOD_STORED;         // STORED for dir
orig: +                e.method = METHOD_STORED;                // STORED for dir

*) ...and this is fixing the typo:

orig: +        // constructor for cenInit() (1) remove tailing '/' (2) pad leading '/'
11u:  +        // constructor for cenInit() (1) remove trailing '/' (2) pad leading '/'

I prefer to backport changes wholesale, along with typos, expecting the potential follow-up commit
that fixes the typos everywhere. Have no strong opinion, through.

Thanks,
-Aleksey


From christoph.langer at sap.com  Tue Feb 19 14:07:42 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 19 Feb 2019 14:07:42 +0000
Subject: JDK 11.0.3 Update process
In-Reply-To: <20190219133934.GA15514@vimes>
References: <586ca28f-83c9-1703-040c-f9cb1f3b6180@redhat.com>
 <CA+3eh13WReDH2JHfAQDhRwxMnhQOvPt3Ab7D_eMN_eYdunnbmw@mail.gmail.com>
 <eadfaea4-b1f2-e15f-56f4-aa120072b14b@redhat.com>
 <20190218143520.GD5015@vimes> <ce5948c57b0243c98b5802655e5bf8d6@sap.com>
 <20190218152833.GE5015@vimes>
 <6883507c-c8bf-3f67-e5e3-2d6ec937a903@redhat.com>
 <20190218162231.GF5015@vimes>
 <90d036e5-c629-9d1e-1150-eb85b37ab91b@redhat.com>
 <CA+3eh13=JmXOkQOUShKw5ZA-nSA0JM-rwbb7qdeAs4B_WPFBVg@mail.gmail.com>
 <20190219133934.GA15514@vimes>
Message-ID: <2b420d1b5f564f4095ae805aa43404e1@sap.com>

Hi Rob,

> > Besides that, I have another question which I kindly ask Rob to answer :)
> >
> > > In addition to this I would like to request that the fix versions for
> > > hgupdater be set to:
> > >
> > > jdk-updates/jdk11u-dev: 11.0.4
> > > jdk-updates/jdk11u: 11.0.3
> >
> > Once this is done, how best proceed with a change (say a P1) which
> > needs to go into both 11.0.3 and 11.0.4. My idea was to downport it
> > directly to jdk-updates/jdk11u and regularly push from
> > jdk-updates/jdk11u to jdk-updates/jdk11u-dev. Is this the way it was
> > previously done at Oracle?
> 
> No, we always push to the always-open repo first. (in this case the
> 11.0.4 repo) After examining the risk of the fix / impact to testing, if
> an issue is approved for the rampdown release it is hg export / imported
> to that repo.


Interesting. Can you tell how the hgupdater tool reacts to merges? 

a) If you merge 2 repositories and both contain a fix for the same bug (that is, JBS backport items exist) - will hgupdater just ignore the incoming changeset? Or will an additional JBS backport item be created?
b) Imagine the following situation: repository jdk11u is set up for 11.0.3 fixes and jdk11u-dev is set up for 11.04. jdk11u contains a fix for issue A and hgupdater had created a JBS backport item for 11.0.3. At the moment we'd merge back 11u -> 11u-dev the fix for A will land in 11u-dev. Would hgupdater then create an 11.0.4 backport item?

Thanks
Christoph


From aph at redhat.com  Tue Feb 19 14:12:30 2019
From: aph at redhat.com (Andrew Haley)
Date: Tue, 19 Feb 2019 14:12:30 +0000
Subject: JDK 11.0.3 Update process
In-Reply-To: <20190219133934.GA15514@vimes>
References: <586ca28f-83c9-1703-040c-f9cb1f3b6180@redhat.com>
 <CA+3eh13WReDH2JHfAQDhRwxMnhQOvPt3Ab7D_eMN_eYdunnbmw@mail.gmail.com>
 <eadfaea4-b1f2-e15f-56f4-aa120072b14b@redhat.com>
 <20190218143520.GD5015@vimes> <ce5948c57b0243c98b5802655e5bf8d6@sap.com>
 <20190218152833.GE5015@vimes>
 <6883507c-c8bf-3f67-e5e3-2d6ec937a903@redhat.com>
 <20190218162231.GF5015@vimes>
 <90d036e5-c629-9d1e-1150-eb85b37ab91b@redhat.com>
 <CA+3eh13=JmXOkQOUShKw5ZA-nSA0JM-rwbb7qdeAs4B_WPFBVg@mail.gmail.com>
 <20190219133934.GA15514@vimes>
Message-ID: <e9b14904-9eb1-07ee-154d-f9fe139439da@redhat.com>

On 2/19/19 1:39 PM, Rob McKenna wrote:
> No, we always push to the always-open repo first. (in this case the
> 11.0.4 repo) After examining the risk of the fix / impact to testing, if
> an issue is approved for the rampdown release it is hg export / imported
> to that repo.

OK, I see. So it's not a purely mechanical "commit everything" decision, but
it's based on severity and risk.

-- 
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 deepak.kejriwal at oracle.com  Tue Feb 19 14:11:47 2019
From: deepak.kejriwal at oracle.com (Deepak Kejriwal)
Date: Tue, 19 Feb 2019 06:11:47 -0800 (PST)
Subject: RFR: JDK11U JDK-8206120, JDK-8211398, JDK-8218915
Message-ID: <da7604d7-76ea-4a50-9f25-775214628754@default>

Hi All,

Please review the backport of the following bug fixes to jdk8u-dev:

HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8206120"JDK-8206120 : Add test cases for lenient Japanese era parsing
HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8211398"JDK-8211398 : Square character support for the Japanese new era
HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8218915"JDK-8218915 : Change isJavaIdentifierStart and isJavaIdentifierPart to handle new code points

Webrev:  http://cr.openjdk.java.net/~rpatil/JapaneseEra_changes_11u/webrev.00/

These code changes are made possible thanks to specification change already pushed:
http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/c1e1669edace

Regards,
Deepak

 

From deepak.kejriwal at oracle.com  Tue Feb 19 14:15:58 2019
From: deepak.kejriwal at oracle.com (Deepak Kejriwal)
Date: Tue, 19 Feb 2019 06:15:58 -0800 (PST)
Subject: RFR: JDK11U JDK-8206120, JDK-8211398, JDK-8218915
Message-ID: <831af84c-5aa2-44de-b9e4-b5e7aeb876ef@default>

Correcting typo for release.

 

From: Deepak Kejriwal <deepak.kejriwal at oracle.com> 
Sent: Tuesday, February 19, 2019 7:42 PM
To: 'core-libs-dev' <core-libs-dev at openjdk.java.net>; 'jdk-updates-dev at openjdk.java.net' <jdk-updates-dev at openjdk.java.net>
Subject: RFR: JDK11U JDK-8206120, JDK-8211398, JDK-8218915

 

Hi All,

Please review the backport of the following bug fixes to jdk11u-dev:

HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8206120"JDK-8206120 : Add test cases for lenient Japanese era parsing
HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8211398"JDK-8211398 : Square character support for the Japanese new era
HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8218915"JDK-8218915 : Change isJavaIdentifierStart and isJavaIdentifierPart to handle new code points

Webrev:  http://cr.openjdk.java.net/~rpatil/JapaneseEra_changes_11u/webrev.00/

These code changes are made possible thanks to specification change already pushed:
http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/c1e1669edace

Regards,
Deepak

 

From shade at redhat.com  Tue Feb 19 14:25:31 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 19 Feb 2019 15:25:31 +0100
Subject: RFR: JDK11U JDK-8206120, JDK-8211398, JDK-8218915
In-Reply-To: <831af84c-5aa2-44de-b9e4-b5e7aeb876ef@default>
References: <831af84c-5aa2-44de-b9e4-b5e7aeb876ef@default>
Message-ID: <93c82f62-eecd-657c-ea19-acfbe118aec2@redhat.com>

Hi Deepak,

Please follow the jdk-updates approval process:
  https://openjdk.java.net/projects/jdk-updates/approval.html

You need to put appropriate tags at the issues, explain why they are needed, how the changes apply
(if changes do not apply cleanly, ask for RFR -- is this what this thread is? -- and explain what
was done to adapt changes to 11u), what testing is done, etc.

-Aleksey

On 2/19/19 3:15 PM, Deepak Kejriwal wrote:
> Correcting typo for release.
> 
>  
> 
> From: Deepak Kejriwal <deepak.kejriwal at oracle.com> 
> Sent: Tuesday, February 19, 2019 7:42 PM
> To: 'core-libs-dev' <core-libs-dev at openjdk.java.net>; 'jdk-updates-dev at openjdk.java.net' <jdk-updates-dev at openjdk.java.net>
> Subject: RFR: JDK11U JDK-8206120, JDK-8211398, JDK-8218915
> 
>  
> 
> Hi All,
> 
> Please review the backport of the following bug fixes to jdk11u-dev:
> 
> HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8206120"JDK-8206120 : Add test cases for lenient Japanese era parsing
> HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8211398"JDK-8211398 : Square character support for the Japanese new era
> HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8218915"JDK-8218915 : Change isJavaIdentifierStart and isJavaIdentifierPart to handle new code points
> 
> Webrev:  http://cr.openjdk.java.net/~rpatil/JapaneseEra_changes_11u/webrev.00/
> 
> These code changes are made possible thanks to specification change already pushed:
> http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/c1e1669edace
> 
> Regards,
> Deepak
> 
>  
> 



From shade at redhat.com  Tue Feb 19 14:28:22 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 19 Feb 2019 15:28:22 +0100
Subject: RFR+RFA [11u] 8214339: SSLSocketImpl erroneously wraps SocketException
Message-ID: <5bdf8737-6e49-cfac-fe24-4a1af9af3248@redhat.com>

Please review and approve the backport to 11u for this bug.

  Original Bug:
      URL: https://bugs.openjdk.java.net/browse/JDK-8214339
      Reporter: Webbug Group
      Assignee: Xue-Lei Fan
      Priority: P3
      Components: security-libs

  Original Fix:
        12: JDK-8214339, http://hg.openjdk.java.net/jdk/jdk12/rev/9041178a0b69, 66 day(s) ago

  Backports and Forwardports:
        13: 13, JDK-8215663, http://hg.openjdk.java.net/jdk/jdk/rev/9041178a0b69, 62 day(s) ago
        11: MISSING
         8: Not affected

The patch does not apply cleanly to 11u, because it has trivial formatting conflict:

$ cat src/java.base/share/classes/sun/security/ssl/PreSharedKeyExtension.java.rej
--- PreSharedKeyExtension.java
+++ PreSharedKeyExtension.java
@@ -171,7 +171,7 @@

-            for(PskIdentity curId : identities) {
+            for (PskIdentity curId : identities) {
                 idEncodedLength += curId.getEncodedLength();

@@ -194,7 +194,7 @@
             Record.putInt16(m, idsEncodedLength);
-            for(PskIdentity curId : identities) {
+            for (PskIdentity curId : identities) {
                 curId.writeEncoded(m);

That code is already in this form in 11u.

Full webrev for 11u:
  http://cr.openjdk.java.net/~shade/8214339/webrev.11u.01/

Testing: new test, entire jdk_security test suite; verified new test fails without the patch

Thanks,
-Aleksey


From rob.mckenna at oracle.com  Tue Feb 19 14:54:16 2019
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Tue, 19 Feb 2019 14:54:16 +0000
Subject: JDK 11.0.3 Update process
In-Reply-To: <2b420d1b5f564f4095ae805aa43404e1@sap.com>
References: <eadfaea4-b1f2-e15f-56f4-aa120072b14b@redhat.com>
 <20190218143520.GD5015@vimes>
 <ce5948c57b0243c98b5802655e5bf8d6@sap.com>
 <20190218152833.GE5015@vimes>
 <6883507c-c8bf-3f67-e5e3-2d6ec937a903@redhat.com>
 <20190218162231.GF5015@vimes>
 <90d036e5-c629-9d1e-1150-eb85b37ab91b@redhat.com>
 <CA+3eh13=JmXOkQOUShKw5ZA-nSA0JM-rwbb7qdeAs4B_WPFBVg@mail.gmail.com>
 <20190219133934.GA15514@vimes>
 <2b420d1b5f564f4095ae805aa43404e1@sap.com>
Message-ID: <20190219145416.GA16716@vimes>

On 19/02/19 14:07, Langer, Christoph wrote:
> Hi Rob,
> 
> > > Besides that, I have another question which I kindly ask Rob to answer :)
> > >
> > > > In addition to this I would like to request that the fix versions for
> > > > hgupdater be set to:
> > > >
> > > > jdk-updates/jdk11u-dev: 11.0.4
> > > > jdk-updates/jdk11u: 11.0.3
> > >
> > > Once this is done, how best proceed with a change (say a P1) which
> > > needs to go into both 11.0.3 and 11.0.4. My idea was to downport it
> > > directly to jdk-updates/jdk11u and regularly push from
> > > jdk-updates/jdk11u to jdk-updates/jdk11u-dev. Is this the way it was
> > > previously done at Oracle?
> > 
> > No, we always push to the always-open repo first. (in this case the
> > 11.0.4 repo) After examining the risk of the fix / impact to testing, if
> > an issue is approved for the rampdown release it is hg export / imported
> > to that repo.
> 
> 
> Interesting. Can you tell how the hgupdater tool reacts to merges? 

I'm not an authority, but I believe I can:

> 
> a) If you merge 2 repositories and both contain a fix for the same bug (that is, JBS backport items exist) - will hgupdater just ignore the incoming changeset? Or will an additional JBS backport item be created?

HgUpdater monitors its configured repos. Sending the mail to ops and
asking for fix versions to be set on specific paths determines which
repos are configured.

Once you push a fix to a repo, hgupdater will create a backport with the
configured version.

In that sense the merge is incidental. I.e. if you push to repo A and
repo B then hgupdater will create backports for both of those repos if
they have distinct configured fix versions.

> b) Imagine the following situation: repository jdk11u is set up for 11.0.3 fixes and jdk11u-dev is set up for 11.04. jdk11u contains a fix for issue A and hgupdater had created a JBS backport item for 11.0.3. At the moment we'd merge back 11u -> 11u-dev the fix for A will land in 11u-dev. Would hgupdater then create an 11.0.4 backport item?

I hope so!

    -Rob

> 
> Thanks
> Christoph
> 

From Alan.Bateman at oracle.com  Tue Feb 19 14:58:30 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 19 Feb 2019 14:58:30 +0000
Subject: RFR: JDK11U JDK-8206120, JDK-8211398, JDK-8218915
In-Reply-To: <93c82f62-eecd-657c-ea19-acfbe118aec2@redhat.com>
References: <831af84c-5aa2-44de-b9e4-b5e7aeb876ef@default>
 <93c82f62-eecd-657c-ea19-acfbe118aec2@redhat.com>
Message-ID: <641d5002-a5cc-a0f2-7305-23b2cf8c13db@oracle.com>

On 19/02/2019 14:25, Aleksey Shipilev wrote:
> Hi Deepak,
>
> Please follow the jdk-updates approval process:
>    https://openjdk.java.net/projects/jdk-updates/approval.html
>
> You need to put appropriate tags at the issues, explain why they are needed, how the changes apply
> (if changes do not apply cleanly, ask for RFR -- is this what this thread is? -- and explain what
> was done to adapt changes to 11u), what testing is done, etc.
>
I read Deepak's mails as code review requests. The context is issues 
related to support for external standards. There are MRs of both JSR 337 
and JSR 384 in progress. Iris sent a good summary to jdk-update-dev in 
December [1]. Once the changes are reviewed then I assume Deepak will 
figure out the process/tagging to get the changes into the update repos 
but I don't think he's there yet.

-Alan

[1] 
https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2018-December/000308.html

From sean.coffey at oracle.com  Tue Feb 19 15:14:30 2019
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Tue, 19 Feb 2019 15:14:30 +0000
Subject: RFR: JDK11U JDK-8206120, JDK-8211398, JDK-8218915
In-Reply-To: <831af84c-5aa2-44de-b9e4-b5e7aeb876ef@default>
References: <831af84c-5aa2-44de-b9e4-b5e7aeb876ef@default>
Message-ID: <f3020039-e030-5acf-5e1f-2ea8983be8c0@oracle.com>

Deepak,

changes look fine to me. Some minor comments on formatting :

make a space after all? "//" comments

e.g.
+???????? //isJavaIdentifierStart strictly conforms to code points assigned
+???????? //in Unicode 10.0. Since code point {32FF} is not from Unicode 
10.0,
+???????? //return false.

 ? 33???? //New code point(Japanese Era Square character) not present in 
Unicode 10.0
 ? 34???? private static final int newCodePoint = 0x32FF;

 ? 65???????????? //Since Character.isJavaIdentifierPart(int) strictly 
conforms to
 ? 66???????????? //character information from version 10.0 of the 
Unicode Standard,
 ? 67???????????? //check if code point is new code point. If the code 
point is new
 ? 68???????????? //code point, value of variable expected is considered 
false.


 ? typo in comment :
 ? make/data/characterdata/CharacterData00.java.template

 ??????? boolean isJavaIdentifierPart(int ch) {
+???????? //isJavaIdentifierStart strictly conforms to code points assigned
+???????? //in Unicode 10.0. Since code point {32FF} is not from Unicode 
10.0,

regards,
Sean.

On 19/02/2019 14:15, Deepak Kejriwal wrote:
> Correcting typo for release.
>
>   
>
> From: Deepak Kejriwal <deepak.kejriwal at oracle.com>
> Sent: Tuesday, February 19, 2019 7:42 PM
> To: 'core-libs-dev' <core-libs-dev at openjdk.java.net>; 'jdk-updates-dev at openjdk.java.net' <jdk-updates-dev at openjdk.java.net>
> Subject: RFR: JDK11U JDK-8206120, JDK-8211398, JDK-8218915
>
>   
>
> Hi All,
>
> Please review the backport of the following bug fixes to jdk11u-dev:
>
> HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8206120"JDK-8206120 : Add test cases for lenient Japanese era parsing
> HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8211398"JDK-8211398 : Square character support for the Japanese new era
> HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8218915"JDK-8218915 : Change isJavaIdentifierStart and isJavaIdentifierPart to handle new code points
>
> Webrev:  http://cr.openjdk.java.net/~rpatil/JapaneseEra_changes_11u/webrev.00/
>
> These code changes are made possible thanks to specification change already pushed:
> http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/c1e1669edace
>
> Regards,
> Deepak
>
>   

From christoph.langer at sap.com  Tue Feb 19 15:33:39 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 19 Feb 2019 15:33:39 +0000
Subject: RFR+RFA [11u] 8214339: SSLSocketImpl erroneously wraps
 SocketException
In-Reply-To: <5bdf8737-6e49-cfac-fe24-4a1af9af3248@redhat.com>
References: <5bdf8737-6e49-cfac-fe24-4a1af9af3248@redhat.com>
Message-ID: <50414abee6f64d51a7e8d8c4391569c5@sap.com>

Looks good.

> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> Behalf Of Aleksey Shipilev
> Sent: Dienstag, 19. Februar 2019 15:28
> To: jdk-updates-dev at openjdk.java.net
> Subject: RFR+RFA [11u] 8214339: SSLSocketImpl erroneously wraps
> SocketException
> 
> Please review and approve the backport to 11u for this bug.
> 
>   Original Bug:
>       URL: https://bugs.openjdk.java.net/browse/JDK-8214339
>       Reporter: Webbug Group
>       Assignee: Xue-Lei Fan
>       Priority: P3
>       Components: security-libs
> 
>   Original Fix:
>         12: JDK-8214339,
> http://hg.openjdk.java.net/jdk/jdk12/rev/9041178a0b69, 66 day(s) ago
> 
>   Backports and Forwardports:
>         13: 13, JDK-8215663,
> http://hg.openjdk.java.net/jdk/jdk/rev/9041178a0b69, 62 day(s) ago
>         11: MISSING
>          8: Not affected
> 
> The patch does not apply cleanly to 11u, because it has trivial formatting
> conflict:
> 
> $ cat
> src/java.base/share/classes/sun/security/ssl/PreSharedKeyExtension.java.r
> ej
> --- PreSharedKeyExtension.java
> +++ PreSharedKeyExtension.java
> @@ -171,7 +171,7 @@
> 
> -            for(PskIdentity curId : identities) {
> +            for (PskIdentity curId : identities) {
>                  idEncodedLength += curId.getEncodedLength();
> 
> @@ -194,7 +194,7 @@
>              Record.putInt16(m, idsEncodedLength);
> -            for(PskIdentity curId : identities) {
> +            for (PskIdentity curId : identities) {
>                  curId.writeEncoded(m);
> 
> That code is already in this form in 11u.
> 
> Full webrev for 11u:
>   http://cr.openjdk.java.net/~shade/8214339/webrev.11u.01/
> 
> Testing: new test, entire jdk_security test suite; verified new test fails
> without the patch
> 
> Thanks,
> -Aleksey


From christoph.langer at sap.com  Tue Feb 19 15:47:13 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 19 Feb 2019 15:47:13 +0000
Subject: JDK 11.0.3 Update process
In-Reply-To: <20190219145416.GA16716@vimes>
References: <eadfaea4-b1f2-e15f-56f4-aa120072b14b@redhat.com>
 <20190218143520.GD5015@vimes> <ce5948c57b0243c98b5802655e5bf8d6@sap.com>
 <20190218152833.GE5015@vimes>
 <6883507c-c8bf-3f67-e5e3-2d6ec937a903@redhat.com>
 <20190218162231.GF5015@vimes>
 <90d036e5-c629-9d1e-1150-eb85b37ab91b@redhat.com>
 <CA+3eh13=JmXOkQOUShKw5ZA-nSA0JM-rwbb7qdeAs4B_WPFBVg@mail.gmail.com>
 <20190219133934.GA15514@vimes> <2b420d1b5f564f4095ae805aa43404e1@sap.com>
 <20190219145416.GA16716@vimes>
Message-ID: <575778defbf946a39357f21b208b52ca@sap.com>

> > a) If you merge 2 repositories and both contain a fix for the same bug (that
> is, JBS backport items exist) - will hgupdater just ignore the incoming
> changeset? Or will an additional JBS backport item be created?
> 
> HgUpdater monitors its configured repos. Sending the mail to ops and
> asking for fix versions to be set on specific paths determines which
> repos are configured.
> 
> Once you push a fix to a repo, hgupdater will create a backport with the
> configured version.
> 
> In that sense the merge is incidental. I.e. if you push to repo A and
> repo B then hgupdater will create backports for both of those repos if
> they have distinct configured fix versions.

OK, and if hgupdater finds that there already exists a JBS backport item for a distinct bug for the distinct version of the repository, I assume it is smart enough not to create an additional JBS item?



From goetz.lindenmaier at sap.com  Tue Feb 19 15:52:38 2019
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Tue, 19 Feb 2019 15:52:38 +0000
Subject: JDK 11.0.3 Update process
In-Reply-To: <20190219133934.GA15514@vimes>
References: <586ca28f-83c9-1703-040c-f9cb1f3b6180@redhat.com>
 <CA+3eh13WReDH2JHfAQDhRwxMnhQOvPt3Ab7D_eMN_eYdunnbmw@mail.gmail.com>
 <eadfaea4-b1f2-e15f-56f4-aa120072b14b@redhat.com>
 <20190218143520.GD5015@vimes> <ce5948c57b0243c98b5802655e5bf8d6@sap.com>
 <20190218152833.GE5015@vimes>
 <6883507c-c8bf-3f67-e5e3-2d6ec937a903@redhat.com>
 <20190218162231.GF5015@vimes>
 <90d036e5-c629-9d1e-1150-eb85b37ab91b@redhat.com>
 <CA+3eh13=JmXOkQOUShKw5ZA-nSA0JM-rwbb7qdeAs4B_WPFBVg@mail.gmail.com>
 <20190219133934.GA15514@vimes>
Message-ID: <35ccc561616f4c10be7acb3183eae098@sap.com>

> No, we always push to the always-open repo first. (in this case the
> 11.0.4 repo) After examining the risk of the fix / impact to testing, if
> an issue is approved for the rampdown release it is hg export / imported
> to that repo.
@Rob
OK, so is that the reason we see so many redundant changes once the
security fixes are pushed to the open?
And why did you choose to do it differently with a new release (jdk12) 
and jdk/jdk?
@Andrew  
I'm not sure this is desirable ... It means considerable work (what 
Aleksey and Christoph are doing needs to be done twice!) and 
the two repos might look quite differently ...

Best regards,
  Goetz. 



> 
>     -Rob
> 
> >
> > The other possiblity would be to instantly downport it to both
> > jdk-updates/jdk11u and jdk-updates/jdk11u-dev. But in the end, this
> > would leave us (after 11.0.3 will be merged back into
> > jdk-updates/jdk11u) with two different instances of the same change in
> > jdk11u-dev and all subsequent releases. I think that would be not very
> > nice and quite confusing. If possible I'd like to avoid that.
> >
> > Thanks for your support,
> > Volker
> >
> > On Mon, Feb 18, 2019 at 6:01 PM Andrew Haley <aph at redhat.com> wrote:
> > >
> > > On 2/18/19 4:22 PM, Rob McKenna wrote:
> > > > Correct me if I have the wrong fix versions here, but the following email
> > > > should suffice for both requests:
> > >
> > > Thanks. I'll wait for an ACK from someone else contributing to this
> discussion,
> > > then send the request.
> > >
> > > --
> > > 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 zgu at redhat.com  Tue Feb 19 15:55:06 2019
From: zgu at redhat.com (zgu at redhat.com)
Date: Tue, 19 Feb 2019 10:55:06 -0500
Subject: RFR+RFA [11u] 8214339: SSLSocketImpl erroneously wraps
 SocketException
In-Reply-To: <5bdf8737-6e49-cfac-fe24-4a1af9af3248@redhat.com>
References: <5bdf8737-6e49-cfac-fe24-4a1af9af3248@redhat.com>
Message-ID: <1550591706.10039.89.camel@redhat.com>

Looks good to me.

-Zhengyu

On Tue, 2019-02-19 at 15:28 +0100, Aleksey Shipilev wrote:
> Please review and approve the backport to 11u for this bug.
> 
>   Original Bug:
>       URL: https://bugs.openjdk.java.net/browse/JDK-8214339
>       Reporter: Webbug Group
>       Assignee: Xue-Lei Fan
>       Priority: P3
>       Components: security-libs
> 
>   Original Fix:
>         12: JDK-8214339, http://hg.openjdk.java.net/jdk/jdk12/rev/904
> 1178a0b69, 66 day(s) ago
> 
>   Backports and Forwardports:
>         13: 13, JDK-8215663, http://hg.openjdk.java.net/jdk/jdk/rev/9
> 041178a0b69, 62 day(s) ago
>         11: MISSING
>          8: Not affected
> 
> The patch does not apply cleanly to 11u, because it has trivial
> formatting conflict:
> 
> $ cat
> src/java.base/share/classes/sun/security/ssl/PreSharedKeyExtension.ja
> va.rej
> --- PreSharedKeyExtension.java
> +++ PreSharedKeyExtension.java
> @@ -171,7 +171,7 @@
> 
> -            for(PskIdentity curId : identities) {
> +            for (PskIdentity curId : identities) {
>                  idEncodedLength += curId.getEncodedLength();
> 
> @@ -194,7 +194,7 @@
>              Record.putInt16(m, idsEncodedLength);
> -            for(PskIdentity curId : identities) {
> +            for (PskIdentity curId : identities) {
>                  curId.writeEncoded(m);
> 
> That code is already in this form in 11u.
> 
> Full webrev for 11u:
>   http://cr.openjdk.java.net/~shade/8214339/webrev.11u.01/
> 
> Testing: new test, entire jdk_security test suite; verified new test
> fails without the patch
> 
> Thanks,
> -Aleksey
> 

From rob.mckenna at oracle.com  Tue Feb 19 16:21:22 2019
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Tue, 19 Feb 2019 16:21:22 +0000
Subject: JDK 11.0.3 Update process
In-Reply-To: <35ccc561616f4c10be7acb3183eae098@sap.com>
References: <eadfaea4-b1f2-e15f-56f4-aa120072b14b@redhat.com>
 <20190218143520.GD5015@vimes>
 <ce5948c57b0243c98b5802655e5bf8d6@sap.com>
 <20190218152833.GE5015@vimes>
 <6883507c-c8bf-3f67-e5e3-2d6ec937a903@redhat.com>
 <20190218162231.GF5015@vimes>
 <90d036e5-c629-9d1e-1150-eb85b37ab91b@redhat.com>
 <CA+3eh13=JmXOkQOUShKw5ZA-nSA0JM-rwbb7qdeAs4B_WPFBVg@mail.gmail.com>
 <20190219133934.GA15514@vimes>
 <35ccc561616f4c10be7acb3183eae098@sap.com>
Message-ID: <20190219162122.GD16716@vimes>

On 19/02/19 15:52, Lindenmaier, Goetz wrote:
> > No, we always push to the always-open repo first. (in this case the
> > 11.0.4 repo) After examining the risk of the fix / impact to testing, if
> > an issue is approved for the rampdown release it is hg export / imported
> > to that repo.
> @Rob
> OK, so is that the reason we see so many redundant changes once the
> security fixes are pushed to the open?

There was an abberation recently that had far more redundant changes
that should be expected. Usually you would only see a duplicate
changeset for a fix that was approved for inclusion post RDP2.

> And why did you choose to do it differently with a new release (jdk12) 
> and jdk/jdk?

I'm not sure I follow. Post RDP2 of jdk12, all approved changes are first
pushed to jdk/jdk and then to the jdk/jdk12 stabilization repo. In this
case two records will be created, one for 13 and one for 12.

I.e. while the fix versions are different (and span major releases
instead of updates) afaik the mechanics are identical.

    -Rob

> @Andrew  
> I'm not sure this is desirable ... It means considerable work (what 
> Aleksey and Christoph are doing needs to be done twice!) and 
> the two repos might look quite differently ...
> 
> Best regards,
>   Goetz. 
> 
> 
> 
> > 
> >     -Rob
> > 
> > >
> > > The other possiblity would be to instantly downport it to both
> > > jdk-updates/jdk11u and jdk-updates/jdk11u-dev. But in the end, this
> > > would leave us (after 11.0.3 will be merged back into
> > > jdk-updates/jdk11u) with two different instances of the same change in
> > > jdk11u-dev and all subsequent releases. I think that would be not very
> > > nice and quite confusing. If possible I'd like to avoid that.
> > >
> > > Thanks for your support,
> > > Volker
> > >
> > > On Mon, Feb 18, 2019 at 6:01 PM Andrew Haley <aph at redhat.com> wrote:
> > > >
> > > > On 2/18/19 4:22 PM, Rob McKenna wrote:
> > > > > Correct me if I have the wrong fix versions here, but the following email
> > > > > should suffice for both requests:
> > > >
> > > > Thanks. I'll wait for an ACK from someone else contributing to this
> > discussion,
> > > > then send the request.
> > > >
> > > > --
> > > > 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 rob.mckenna at oracle.com  Tue Feb 19 16:24:15 2019
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Tue, 19 Feb 2019 16:24:15 +0000
Subject: JDK 11.0.3 Update process
In-Reply-To: <575778defbf946a39357f21b208b52ca@sap.com>
References: <ce5948c57b0243c98b5802655e5bf8d6@sap.com>
 <20190218152833.GE5015@vimes>
 <6883507c-c8bf-3f67-e5e3-2d6ec937a903@redhat.com>
 <20190218162231.GF5015@vimes>
 <90d036e5-c629-9d1e-1150-eb85b37ab91b@redhat.com>
 <CA+3eh13=JmXOkQOUShKw5ZA-nSA0JM-rwbb7qdeAs4B_WPFBVg@mail.gmail.com>
 <20190219133934.GA15514@vimes>
 <2b420d1b5f564f4095ae805aa43404e1@sap.com>
 <20190219145416.GA16716@vimes>
 <575778defbf946a39357f21b208b52ca@sap.com>
Message-ID: <20190219162415.GE16716@vimes>

> OK, and if hgupdater finds that there already exists a JBS backport item for a distinct bug for the distinct version of the repository, I assume it is smart enough not to create an additional JBS item?

In this case I believe it should add comments to the existing bug. Note:
if the bug is already in the stabilization repo, that would imply it was
pushed before the fork. It would be strange to need to push another
changeset with the same id to the same repo. (unless I misunderstand the
question)

    -Rob


From shade at redhat.com  Tue Feb 19 16:36:46 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 19 Feb 2019 17:36:46 +0100
Subject: RFR+RFA [11u] (S) 8219260: Default number of test jobs needs to
 be consistently calculated
In-Reply-To: <a7829c67-ab30-d5af-995e-7135ea06847f@redhat.com>
References: <a7829c67-ab30-d5af-995e-7135ea06847f@redhat.com>
Message-ID: <e0bd55d1-cd35-b81a-f333-07e186f60119@redhat.com>

On 2/18/19 10:43 PM, Aleksey Shipilev wrote:
> Bug:
>   https://bugs.openjdk.java.net/browse/JDK-8219260
> 
> Fix:
>   http://cr.openjdk.java.net/~shade/8219260/webrev.01/
> 
> This is the 11u-specific fix, the partial backport of the large change in 12u. See the full story in
> the bug. This fix is needed to pass tier1 on decently large machine with not much memory. For
> example, this allows my 32-thread Threadripper with 64 GB of memory to pass tier1 test suite with
> elevated heap size due to JDK-8219251. The alternative is to guess and put TEST_JOBS param to the
> test line.
> 
> Testing: Linux x86_64 fastdebug, test/langtools, tier1 on a few machines

I see jdk11u-fix-yes (maintainer approval) for this backport. But I would also like to have the 11u
reviewers ack about this. Christoph?

-Aleksey


From naoto.sato at oracle.com  Tue Feb 19 16:53:28 2019
From: naoto.sato at oracle.com (Naoto Sato)
Date: Tue, 19 Feb 2019 08:53:28 -0800
Subject: RFR: JDK11U JDK-8206120, JDK-8211398, JDK-8218915
In-Reply-To: <831af84c-5aa2-44de-b9e4-b5e7aeb876ef@default>
References: <831af84c-5aa2-44de-b9e4-b5e7aeb876ef@default>
Message-ID: <fa5ad573-675f-c009-d1fe-e0a90bc07b96@oracle.com>

Hi Deepak,

Here are my comments to the webrev (other than what Sean pointed out):

TestIsJavaIdentifierMethods.java

- @summary: "testIsJavaLetter" -> "isJavaLetter", 
"testIsJavaLetterOrDigit" -> "isJavaLetterOrDigit".

- Line 34: "newCodePoint" does not represent the era character, as "new" 
is subjective. It will become moot in the year 2020. How about 
"JAPANESE_ERA_CODEPOINT"?

- Line 67,68,(...all the comments): Reflect the above change to the 
comments.

- Line 103: "All Unicode chars (0x0000..0xFFFF)" does not sound correct. 
It may be "All Unicode code points in the BMP (0x0000..0xFFFF), and 
remove extra period at the end. This applies to other method descriptions.

- Line 104: The test case returns "void", what does this "Expected 
results" mean?

- Line 140-142,174-176: The condition statement in the document is 
different from JDK11's javadoc. In the API doc, it is (in case of int):

    isLetter(codePoint) returns true
    getType(codePoint) returns LETTER_NUMBER
    the referenced character is a currency symbol (such as '$')
    the referenced character is a connecting punctuation character (such 
as '_').

- Line 163,198: Exception messages are incorrect. they are for 
isJavaIdentifierStart().

Naoto


On 2/19/19 6:15 AM, Deepak Kejriwal wrote:
> Correcting typo for release.
> 
>   
> 
> From: Deepak Kejriwal <deepak.kejriwal at oracle.com>
> Sent: Tuesday, February 19, 2019 7:42 PM
> To: 'core-libs-dev' <core-libs-dev at openjdk.java.net>; 'jdk-updates-dev at openjdk.java.net' <jdk-updates-dev at openjdk.java.net>
> Subject: RFR: JDK11U JDK-8206120, JDK-8211398, JDK-8218915
> 
>   
> 
> Hi All,
> 
> Please review the backport of the following bug fixes to jdk11u-dev:
> 
> HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8206120"JDK-8206120 : Add test cases for lenient Japanese era parsing
> HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8211398"JDK-8211398 : Square character support for the Japanese new era
> HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8218915"JDK-8218915 : Change isJavaIdentifierStart and isJavaIdentifierPart to handle new code points
> 
> Webrev:  http://cr.openjdk.java.net/~rpatil/JapaneseEra_changes_11u/webrev.00/
> 
> These code changes are made possible thanks to specification change already pushed:
> http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/c1e1669edace
> 
> Regards,
> Deepak
> 
>   
> 

From christoph.langer at sap.com  Tue Feb 19 17:26:40 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 19 Feb 2019 17:26:40 +0000
Subject: RFR+RFA [11u] (S) 8219260: Default number of test jobs needs to
 be consistently calculated
In-Reply-To: <e0bd55d1-cd35-b81a-f333-07e186f60119@redhat.com>
References: <a7829c67-ab30-d5af-995e-7135ea06847f@redhat.com>
 <e0bd55d1-cd35-b81a-f333-07e186f60119@redhat.com>
Message-ID: <d6d17e8cdb6f47e1bd7443a3d5847d04@sap.com>

Hi Aleksey,

looks good to me. I also think you did good testing of it ??

Best regards
Christoph

> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> Behalf Of Aleksey Shipilev
> Sent: Dienstag, 19. Februar 2019 17:37
> To: jdk-updates-dev at openjdk.java.net
> Subject: Re: RFR+RFA [11u] (S) 8219260: Default number of test jobs needs
> to be consistently calculated
> 
> On 2/18/19 10:43 PM, Aleksey Shipilev wrote:
> > Bug:
> >   https://bugs.openjdk.java.net/browse/JDK-8219260
> >
> > Fix:
> >   http://cr.openjdk.java.net/~shade/8219260/webrev.01/
> >
> > This is the 11u-specific fix, the partial backport of the large change in 12u.
> See the full story in
> > the bug. This fix is needed to pass tier1 on decently large machine with not
> much memory. For
> > example, this allows my 32-thread Threadripper with 64 GB of memory to
> pass tier1 test suite with
> > elevated heap size due to JDK-8219251. The alternative is to guess and put
> TEST_JOBS param to the
> > test line.
> >
> > Testing: Linux x86_64 fastdebug, test/langtools, tier1 on a few machines
> 
> I see jdk11u-fix-yes (maintainer approval) for this backport. But I would also
> like to have the 11u
> reviewers ack about this. Christoph?
> 
> -Aleksey


From shade at redhat.com  Tue Feb 19 18:09:32 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 19 Feb 2019 19:09:32 +0100
Subject: RFR+RFA [11u] (S) 8219260: Default number of test jobs needs to
 be consistently calculated
In-Reply-To: <a7829c67-ab30-d5af-995e-7135ea06847f@redhat.com>
References: <a7829c67-ab30-d5af-995e-7135ea06847f@redhat.com>
Message-ID: <2016b865-d5f2-64e4-5922-5af5521936f3@redhat.com>

I think it is also a good idea to check with Erik, who's the author of the original bulk change.

Erik, does the patch below look good to you?

-Aleksey

On 2/18/19 10:43 PM, Aleksey Shipilev wrote:
> Bug:
>   https://bugs.openjdk.java.net/browse/JDK-8219260
> 
> Fix:
>   http://cr.openjdk.java.net/~shade/8219260/webrev.01/
> 
> This is the 11u-specific fix, the partial backport of the large change in 12u. See the full story in
> the bug. This fix is needed to pass tier1 on decently large machine with not much memory. For
> example, this allows my 32-thread Threadripper with 64 GB of memory to pass tier1 test suite with
> elevated heap size due to JDK-8219251. The alternative is to guess and put TEST_JOBS param to the
> test line.
> 
> Testing: Linux x86_64 fastdebug, test/langtools, tier1 on a few machines
> 
> Thanks,
> -Aleksey
> 



From erik.joelsson at oracle.com  Tue Feb 19 18:35:45 2019
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 19 Feb 2019 10:35:45 -0800
Subject: RFR+RFA [11u] (S) 8219260: Default number of test jobs needs to
 be consistently calculated
In-Reply-To: <2016b865-d5f2-64e4-5922-5af5521936f3@redhat.com>
References: <a7829c67-ab30-d5af-995e-7135ea06847f@redhat.com>
 <2016b865-d5f2-64e4-5922-5af5521936f3@redhat.com>
Message-ID: <c1e1dde1-a774-b956-0068-f2b0250ff643@oracle.com>

I think it looks ok.

/Erik

On 2019-02-19 10:09, Aleksey Shipilev wrote:
> I think it is also a good idea to check with Erik, who's the author of the original bulk change.
>
> Erik, does the patch below look good to you?
>
> -Aleksey
>
> On 2/18/19 10:43 PM, Aleksey Shipilev wrote:
>> Bug:
>>    https://bugs.openjdk.java.net/browse/JDK-8219260
>>
>> Fix:
>>    http://cr.openjdk.java.net/~shade/8219260/webrev.01/
>>
>> This is the 11u-specific fix, the partial backport of the large change in 12u. See the full story in
>> the bug. This fix is needed to pass tier1 on decently large machine with not much memory. For
>> example, this allows my 32-thread Threadripper with 64 GB of memory to pass tier1 test suite with
>> elevated heap size due to JDK-8219251. The alternative is to guess and put TEST_JOBS param to the
>> test line.
>>
>> Testing: Linux x86_64 fastdebug, test/langtools, tier1 on a few machines
>>
>> Thanks,
>> -Aleksey
>>
>

From shade at redhat.com  Tue Feb 19 18:36:44 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 19 Feb 2019 19:36:44 +0100
Subject: RFR+RFA [11u] (S) 8219260: Default number of test jobs needs to
 be consistently calculated
In-Reply-To: <c1e1dde1-a774-b956-0068-f2b0250ff643@oracle.com>
References: <a7829c67-ab30-d5af-995e-7135ea06847f@redhat.com>
 <2016b865-d5f2-64e4-5922-5af5521936f3@redhat.com>
 <c1e1dde1-a774-b956-0068-f2b0250ff643@oracle.com>
Message-ID: <4270b9fa-a891-25a1-849a-8d690725d2eb@redhat.com>

Thanks!

On 2/19/19 7:35 PM, Erik Joelsson wrote:
> I think it looks ok.
> 
> /Erik
> 
> On 2019-02-19 10:09, Aleksey Shipilev wrote:
>> I think it is also a good idea to check with Erik, who's the author of the original bulk change.
>>
>> Erik, does the patch below look good to you?
>>
>> -Aleksey
>>
>> On 2/18/19 10:43 PM, Aleksey Shipilev wrote:
>>> Bug:
>>> ?? https://bugs.openjdk.java.net/browse/JDK-8219260
>>>
>>> Fix:
>>> ?? http://cr.openjdk.java.net/~shade/8219260/webrev.01/
>>>
>>> This is the 11u-specific fix, the partial backport of the large change in 12u. See the full story in
>>> the bug. This fix is needed to pass tier1 on decently large machine with not much memory. For
>>> example, this allows my 32-thread Threadripper with 64 GB of memory to pass tier1 test suite with
>>> elevated heap size due to JDK-8219251. The alternative is to guess and put TEST_JOBS param to the
>>> test line.
>>>
>>> Testing: Linux x86_64 fastdebug, test/langtools, tier1 on a few machines
>>>
>>> Thanks,
>>> -Aleksey
>>>
>>



From gnu.andrew at redhat.com  Wed Feb 20 00:11:46 2019
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Wed, 20 Feb 2019 00:11:46 +0000
Subject: JDK 11.0.3 Update process
In-Reply-To: <08dbb661-55c3-6c8d-89f1-4d90f7aa29ae@redhat.com>
References: <c7027fa19a28408e83461360f3ce6974@sap.com>
 <CA+3eh12Rtb1MQt2xr-Tu8svvZ0+NEWs4bsn0oRpnHyGhXF0fqA@mail.gmail.com>
 <be92b505-d50b-097c-d26f-f9768c90cbd0@redhat.com>
 <CA+3eh13GiMDF-8_kofUqzZvCWK2_va+DRMJDtYm6COSDLzQV6g@mail.gmail.com>
 <586ca28f-83c9-1703-040c-f9cb1f3b6180@redhat.com>
 <CA+3eh13WReDH2JHfAQDhRwxMnhQOvPt3Ab7D_eMN_eYdunnbmw@mail.gmail.com>
 <eadfaea4-b1f2-e15f-56f4-aa120072b14b@redhat.com>
 <1c9f80b75b7b492b9e463445eafd7c3d@sap.com>
 <cbaa356a-54b2-7c18-5b0b-3cdc12f58f46@redhat.com>
 <CABi63P4HtF+48sZszoonKTKA+ysuCEBrVg64bvOw52EKPS4hRA@mail.gmail.com>
 <3b877136-b4be-ff3e-e972-df402c816e1d@redhat.com>
 <CABi63P7Gv7K8kp8Yg=AE-8EgHXjvw_cnsGL-yKNttzpONY7Big@mail.gmail.com>
 <08dbb661-55c3-6c8d-89f1-4d90f7aa29ae@redhat.com>
Message-ID: <CABi63P6Mz71qjs1J-Qt4D0eXB_OKZ3ovot2wzuxYMO+KkogxqA@mail.gmail.com>

On Tue, 19 Feb 2019 at 09:40, Andrew Haley <aph at redhat.com> wrote:
>
> On 2/18/19 10:49 PM, Andrew Hughes wrote:
> > Indeed. In the Oracle sense, it is very much the former role of
> > adjudicating on which changes make it to the release and which don't.
> >
> > The other role has been largely nameless, because that process is
> > basically opaque under Oracle ownership; once they branch the tree
> > (privately) for "RDP2", the only evidence we have of activity is entries
> > in the bug database.
> >
> > So this is the area we really need to define more in-depth. At the
> > end of day, primary responsibility will have to go to someone who
> > can do TCK testing as any release should pass that. On what
> > platforms that is the case is yet another issue, so the work may
> > need to be distributed against multiple interested parties.
>
> Probably, yes. But we have to be clear what exactly is meant by
> "primary responsibility". From context I believe you're talking about
> responsibility for doing the patch integration into the release
> branch. And yes, they have to do TCK testing.
>

I'm talking not so much about individual patch integration, but the process
of tagging and making a release i.e. deciding that it is good to go.

> > OpenJDK 6 & 7 have been much lower traffic, so we have generally got
> > away with doing our Red Hat builds and TCK testing, and then just
> > doing the final push & release in public. The process will need to
> > be formalised for 8u & 11u.
>
> I'm reluctant. The problem with formalizing process even more is that
> it becomes incomprehensible to anyone except the two or threee people
> working on a release full time.

Ok, let's put it another way; the next security update is on 2019-04-16.
I need to know about a month before then whether I'm following the
same process as for 7 (snapshot the tree, apply security patches,
push them after unembargo and follow up with a release), or if we're
doing something different, or if someone else is doing this.

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



-- 
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  Wed Feb 20 00:19:09 2019
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Wed, 20 Feb 2019 00:19:09 +0000
Subject: JDK 11.0.3 Update process
In-Reply-To: <f587004d7f82433ea0f6476c8e87d5ca@sap.com>
References: <CA+3eh12Rtb1MQt2xr-Tu8svvZ0+NEWs4bsn0oRpnHyGhXF0fqA@mail.gmail.com>
 <be92b505-d50b-097c-d26f-f9768c90cbd0@redhat.com>
 <CA+3eh13GiMDF-8_kofUqzZvCWK2_va+DRMJDtYm6COSDLzQV6g@mail.gmail.com>
 <586ca28f-83c9-1703-040c-f9cb1f3b6180@redhat.com>
 <CA+3eh13WReDH2JHfAQDhRwxMnhQOvPt3Ab7D_eMN_eYdunnbmw@mail.gmail.com>
 <eadfaea4-b1f2-e15f-56f4-aa120072b14b@redhat.com>
 <20190218143520.GD5015@vimes>
 <ce5948c57b0243c98b5802655e5bf8d6@sap.com> <20190218152833.GE5015@vimes>
 <6883507c-c8bf-3f67-e5e3-2d6ec937a903@redhat.com>
 <20190218162231.GF5015@vimes>
 <90d036e5-c629-9d1e-1150-eb85b37ab91b@redhat.com>
 <CA+3eh13=JmXOkQOUShKw5ZA-nSA0JM-rwbb7qdeAs4B_WPFBVg@mail.gmail.com>
 <8d1f4dcd-7031-4e7e-e569-42d0ce21c9ca@redhat.com>
 <5ec1a955-db90-a83b-fc49-277664ada52a@redhat.com>
 <a1ab759a-f171-5bf4-0f03-6b24c409bf58@redhat.com>
 <4f6ee3a1-138f-84b7-edc6-252d750fca5b@redhat.com>
 <4563e824781546caad34bc27e6d4c13b@sap.com>
 <CABi63P6+M-36xPnXriHv1GizGu12ntcmvRdARnFQWqBuZUyjpA@mail.gmail.com>
 <f587004d7f82433ea0f6476c8e87d5ca@sap.com>
Message-ID: <CABi63P4KEVU1SF+0uT_U70Lvw6R-ayUW0r5e6i=+0t-1j+RaFw@mail.gmail.com>

On Tue, 19 Feb 2019 at 13:01, Lindenmaier, Goetz
<goetz.lindenmaier at sap.com> wrote:
>
> Hi Andrew,
>
> > It does seem a bit early to me for 11.0.4, especially with the
> > transition from Oracle ownership. I was expecting
> > the branch to happen more around the time we received the security
> > patches, but then I also feel that the lead
> > time under Oracle was too long, leading to patches taking a long time
> > to actually appear in releases. It really
> > depends on what testing one wants to do prior to release.
>
> what we are proposing is to use jdk11u-dev for 11.0.4, and jdk11u for
> 11.0.3 as soon as both are available.
>
> What is the matter with doing this right now?  Not doing it means
> that all changes downported will still end up in 11.0.3.
> Actually, I think 11.0.3 should be in stabilization phase currently,
> and it should go there as soon as possible. Aleksey and Christoph
> are currently building a repository that resembles 11.0.3-oracle
> as good as possible.  We should stabilize this repository starting right
> when they are finished.
>
> At the same time, we should not block others from downporting
> changes needed in 11, but not necessarily in 11.0.3.
> There are already some 30 changes flagged 11.0.4-oracle. We could
> start pushing them to jdk11u-dev if we dedicate the two repos for the
> two different releases. And I think doing that now would be better than
> starting this business only 8 weeks in advance of the release.
> (And if Christoph does not volunteer to do that, I might :))
>
> So, to take up what Volker is proposing, and to put it into my own words,
> I would propose:
>
> Once we have jdk11u-dev:
>  * let's start pushing 11.0.4-oracle changes to jdk11u-dev.
>  * let's continue pushing 11.0.3-oracle changes to jdk11u.
>  * let's push changes requested for downport for jdk11u to jdk11u-dev except:
>  * let's push changes that fix issues in 11.0.3 that adhere to the RDP2 rules
>     to jdk11u. This can be both: downports and fixes crafted for 11.0.3
> and finally:
>   * on every Thursday (or any other weekly point in time), let's merge all changes
>      from jdk11u to jdk11u-dev except if jdk11u has a major issue.
>      (I would volunteer to do this for now) )(based on a change that ran through
>       our nightly testing as long as there are no build tags)
>
> Best regards,
>   Goetz.
>

I didn't say there was anything the matter with it, more that I was
surprised it was happening so quickly. I'm still wrapping up things from
the last CPU.

>From experience, the earlier you split off a release branch, the more
work has to be done in backporting from the current development branch
to the release branch, or, as you suggest, pulling from the release branch
back into the development branch.

On that latter approach, there's an obvious risk there that you push something
to 11.0.3 first which causes issues. I think there are good reasons for only
determining fixes as worthy for the release branch after they've soaked for
some time in the development branch. It's also not clear to me what the
"RDP2 rules" are.

I would like to see regular tags for both 8u & 11u. This would help testing
of our downstream trees, which currently don't get merged until Oracle push
all their internal work after release.
-- 
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 TOSHIONA at jp.ibm.com  Wed Feb 20 05:48:12 2019
From: TOSHIONA at jp.ibm.com (Toshio 5 Nakamura)
Date: Wed, 20 Feb 2019 14:48:12 +0900
Subject: Question about backport process
In-Reply-To: <76d38b28-afc4-f0a1-e132-e75fa8d0c234@redhat.com>
References: <OF23B915D7.5A07F788-ON002583A6.00322B72-492583A6.003631F5@notes.na.collabserv.com>
 <c7fbf07d-a225-93d5-1171-fd88c450fd56@redhat.com>
 <6190f24b-de3f-93c5-fcba-38cfd2514b7a@redhat.com>
 <72d8e237eb49410598eff132f7596301@sap.com>
 <c614af60-6699-ae7f-3e9b-94db9f438636@redhat.com>
 <76d38b28-afc4-f0a1-e132-e75fa8d0c234@redhat.com>
Message-ID: <OF952EF5EF.AE459455-ON002583A7.001FB8F4-492583A7.001FE12D@notes.na.collabserv.com>

Thank you so much, Aleksey.
I've also verified them.

Toshio

Aleksey Shipilev <shade at redhat.com> wrote on 2019/02/19 20:09:55:

> From: Aleksey Shipilev <shade at redhat.com>
> To: "Langer, Christoph" <christoph.langer at sap.com>, Toshio 5
> Nakamura <TOSHIONA at jp.ibm.com>, "jdk-updates-dev at openjdk.java.net"
> <jdk-updates-dev at openjdk.java.net>
> Date: 2019/02/19 20:11
> Subject: Re: Question about backport process
>
> On 2/19/19 11:10 AM, Aleksey Shipilev wrote:
> > On 2/19/19 11:09 AM, Langer, Christoph wrote:
> >> I think 8-pool and 11-pool issues are good. hgupdater will
> recognize these and resolve them
> >> instead of creating new backport items. So, no need to delete
> them. Try it ??
> >
> > Okay, let's try it. Here goes nothing :)
>
> All done! Toshio, you might want to verify.
>
> Seems to me the charsets change needs the entire JDK to be
> recompiled to pass tests.
>
> Indeed, the backport targeted to 11-pool got replaced with 11.0.3. Nice.
>
> -Aleksey
>
> [attachment "signature.asc" deleted by Toshio 5 Nakamura/Japan/IBM]

From goetz.lindenmaier at sap.com  Wed Feb 20 07:11:25 2019
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Wed, 20 Feb 2019 07:11:25 +0000
Subject: JDK 11.0.3 Update process
In-Reply-To: <20190219162122.GD16716@vimes>
References: <eadfaea4-b1f2-e15f-56f4-aa120072b14b@redhat.com>
 <20190218143520.GD5015@vimes> <ce5948c57b0243c98b5802655e5bf8d6@sap.com>
 <20190218152833.GE5015@vimes>
 <6883507c-c8bf-3f67-e5e3-2d6ec937a903@redhat.com>
 <20190218162231.GF5015@vimes>
 <90d036e5-c629-9d1e-1150-eb85b37ab91b@redhat.com>
 <CA+3eh13=JmXOkQOUShKw5ZA-nSA0JM-rwbb7qdeAs4B_WPFBVg@mail.gmail.com>
 <20190219133934.GA15514@vimes> <35ccc561616f4c10be7acb3183eae098@sap.com>
 <20190219162122.GD16716@vimes>
Message-ID: <56f19b897a2c493fb14841d5e9d3ec0d@sap.com>

Hi Rob,

> I'm not sure I follow. Post RDP2 of jdk12, all approved changes are first
> pushed to jdk/jdk and then to the jdk/jdk12 stabilization repo. In this
> case two records will be created, one for 13 and one for 12.

If you push changes first to jdk/jdk and then to jdk/jdk12 by hg export/import, 
and in the end pull jdk/jdk12 back to jdk/jdk, the changes should be there
twice, shouldn't they? But it's not the case.  E.g., I had a look at
8218662: Allow 204 responses with Content-Length:0

... Obviously, I'm looking at the publicly visible repos. Internally, 
you might be doing something else.

Best regards,
  Goetz.



> 
> I.e. while the fix versions are different (and span major releases
> instead of updates) afaik the mechanics are identical.
> 
>     -Rob
> 
> > @Andrew
> > I'm not sure this is desirable ... It means considerable work (what
> > Aleksey and Christoph are doing needs to be done twice!) and
> > the two repos might look quite differently ...
> >
> > Best regards,
> >   Goetz.
> >
> >
> >
> > >
> > >     -Rob
> > >
> > > >
> > > > The other possiblity would be to instantly downport it to both
> > > > jdk-updates/jdk11u and jdk-updates/jdk11u-dev. But in the end, this
> > > > would leave us (after 11.0.3 will be merged back into
> > > > jdk-updates/jdk11u) with two different instances of the same change in
> > > > jdk11u-dev and all subsequent releases. I think that would be not very
> > > > nice and quite confusing. If possible I'd like to avoid that.
> > > >
> > > > Thanks for your support,
> > > > Volker
> > > >
> > > > On Mon, Feb 18, 2019 at 6:01 PM Andrew Haley <aph at redhat.com>
> wrote:
> > > > >
> > > > > On 2/18/19 4:22 PM, Rob McKenna wrote:
> > > > > > Correct me if I have the wrong fix versions here, but the following
> email
> > > > > > should suffice for both requests:
> > > > >
> > > > > Thanks. I'll wait for an ACK from someone else contributing to this
> > > discussion,
> > > > > then send the request.
> > > > >
> > > > > --
> > > > > 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 goetz.lindenmaier at sap.com  Wed Feb 20 07:40:35 2019
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Wed, 20 Feb 2019 07:40:35 +0000
Subject: JDK 11.0.3 Update process
In-Reply-To: <CABi63P6Mz71qjs1J-Qt4D0eXB_OKZ3ovot2wzuxYMO+KkogxqA@mail.gmail.com>
References: <c7027fa19a28408e83461360f3ce6974@sap.com>
 <CA+3eh12Rtb1MQt2xr-Tu8svvZ0+NEWs4bsn0oRpnHyGhXF0fqA@mail.gmail.com>
 <be92b505-d50b-097c-d26f-f9768c90cbd0@redhat.com>
 <CA+3eh13GiMDF-8_kofUqzZvCWK2_va+DRMJDtYm6COSDLzQV6g@mail.gmail.com>
 <586ca28f-83c9-1703-040c-f9cb1f3b6180@redhat.com>
 <CA+3eh13WReDH2JHfAQDhRwxMnhQOvPt3Ab7D_eMN_eYdunnbmw@mail.gmail.com>
 <eadfaea4-b1f2-e15f-56f4-aa120072b14b@redhat.com>
 <1c9f80b75b7b492b9e463445eafd7c3d@sap.com>
 <cbaa356a-54b2-7c18-5b0b-3cdc12f58f46@redhat.com>
 <CABi63P4HtF+48sZszoonKTKA+ysuCEBrVg64bvOw52EKPS4hRA@mail.gmail.com>
 <3b877136-b4be-ff3e-e972-df402c816e1d@redhat.com>
 <CABi63P7Gv7K8kp8Yg=AE-8EgHXjvw_cnsGL-yKNttzpONY7Big@mail.gmail.com>
 <08dbb661-55c3-6c8d-89f1-4d90f7aa29ae@redhat.com>
 <CABi63P6Mz71qjs1J-Qt4D0eXB_OKZ3ovot2wzuxYMO+KkogxqA@mail.gmail.com>
Message-ID: <049a142a58944365a423f88a2ece063a@sap.com>

Hi Andrew, 
 
> Ok, let's put it another way; the next security update is on 2019-04-16.
> I need to know about a month before then whether I'm following the
> same process as for 7 (snapshot the tree, apply security patches,
> push them after unembargo and follow up with a release), or if we're
> doing something different, or if someone else is doing this.
For getting the security changes into the open repo after unembargo
this sounds good.  
To assure you can snapshot the tree 4 weeks in advance, it needs to
be stable at that point. I.e., we should stop pushing new changes 
even before that, say 8 weeks.  And it should be complete wrt. the
11.0.3-oracle changes at that point.

The security changes give an additional dimension to this, as they 
can not be handled in the open.  We would like to have a stable repo, 
and the same repo as you, for testing the security changes. We also 
need to release our OpenJDK deliverable, SapMachine, close to 
the Oracle release date.  And we would like to have the same changes
as you and as are tagged in the open with -ga when we release.
So we need to know in advance which non-security changes this are.
Having a stable version in jdk11u rather early should help with this.
Obviously, the security changes need to be communicated on the 
vulnerability list separately.
Thus, you can still snapshot the repo 4 weeks before the release date.
But it can be closed for new features ("new" in the meaning applicable for
a maintenance release) before that.

Actually, we would appreciate a lot if you could push your tree to the 
open right on the unembargo date - we could compare it to our internal 
SapMachine repo we use for testing the security changes - and if the two
agree build our release on the version you pushed.  If they don't agree, 
there might be a fix that was somehow lost and we could timely publish 
it to OpenJDK.  It would be bad though, if they would not agree on some
changes available in the open.

But actually, for 11.0.3, I think we should agree on how to handle the 
changes that can be done in the open, first.  For 11.0.4, we should look
at the security changes and how we, SAP, can help best with the security
patches.   

Best regards,
  Goetz.

PS: 
> (snapshot the tree, apply security patches,
> push them after unembargo and follow up with a release)
Didn't you only push them this week?



From goetz.lindenmaier at sap.com  Wed Feb 20 07:54:14 2019
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Wed, 20 Feb 2019 07:54:14 +0000
Subject: JDK 11.0.3 Update process
In-Reply-To: <CABi63P4KEVU1SF+0uT_U70Lvw6R-ayUW0r5e6i=+0t-1j+RaFw@mail.gmail.com>
References: <CA+3eh12Rtb1MQt2xr-Tu8svvZ0+NEWs4bsn0oRpnHyGhXF0fqA@mail.gmail.com>
 <be92b505-d50b-097c-d26f-f9768c90cbd0@redhat.com>
 <CA+3eh13GiMDF-8_kofUqzZvCWK2_va+DRMJDtYm6COSDLzQV6g@mail.gmail.com>
 <586ca28f-83c9-1703-040c-f9cb1f3b6180@redhat.com>
 <CA+3eh13WReDH2JHfAQDhRwxMnhQOvPt3Ab7D_eMN_eYdunnbmw@mail.gmail.com>
 <eadfaea4-b1f2-e15f-56f4-aa120072b14b@redhat.com>
 <20190218143520.GD5015@vimes> <ce5948c57b0243c98b5802655e5bf8d6@sap.com>
 <20190218152833.GE5015@vimes>
 <6883507c-c8bf-3f67-e5e3-2d6ec937a903@redhat.com>
 <20190218162231.GF5015@vimes>
 <90d036e5-c629-9d1e-1150-eb85b37ab91b@redhat.com>
 <CA+3eh13=JmXOkQOUShKw5ZA-nSA0JM-rwbb7qdeAs4B_WPFBVg@mail.gmail.com>
 <8d1f4dcd-7031-4e7e-e569-42d0ce21c9ca@redhat.com>
 <5ec1a955-db90-a83b-fc49-277664ada52a@redhat.com>
 <a1ab759a-f171-5bf4-0f03-6b24c409bf58@redhat.com>
 <4f6ee3a1-138f-84b7-edc6-252d750fca5b@redhat.com>
 <4563e824781546caad34bc27e6d4c13b@sap.com>
 <CABi63P6+M-36xPnXriHv1GizGu12ntcmvRdARnFQWqBuZUyjpA@mail.gmail.com>
 <f587004d7f82433ea0f6476c8e87d5ca@sap.com>
 <CABi63P4KEVU1SF+0uT_U70Lvw6R-ayUW0r5e6i=+0t-1j+RaFw@mail.gmail.com>
Message-ID: <ea18c97908204a2da243c9b89556e151@sap.com>

Hi,

well, should have condensed this into one mail ... but nevertheless ...
> I didn't say there was anything the matter with it, more that I was
> surprised it was happening so quickly. I'm still wrapping up things from
> the last CPU.
Guess my other mail explains why we want to engage now.  We want to
release SapMachine as close to 4/15 as possible, and with the same set
of changes as you.

> From experience, the earlier you split off a release branch, the more
> work has to be done in backporting from the current development branch
> to the release branch, or, as you suggest, pulling from the release branch
> back into the development branch.
I don't think the pulling is that much work, but letting the fixes soak makes
sense.

> On that latter approach, there's an obvious risk there that you push something
> to 11.0.3 first which causes issues. I think there are good reasons for only
> determining fixes as worthy for the release branch after they've soaked for
> some time in the development branch. It's also not clear to me what the
> "RDP2 rules" are.
https://openjdk.java.net/jeps/3 
This explains what changes may be pushed in which phase.
We could reuse that.

> I would like to see regular tags for both 8u & 11u. This would help testing
> of our downstream trees, which currently don't get merged until Oracle push
> all their internal work after release.
Yes.  Tags would be great.  I would appreciate weekly builds tags in jdk11u after rdp2,
11.0.3-rdp2 when last jdk11u-dev is pulled to jdk11u, 
11.0.3-rdp1 when you (and us)  snapshot the tree,
11.0.3-ga in the end.

Cheers,
  Goetz.

> --
> 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 christoph.langer at sap.com  Wed Feb 20 08:15:34 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 20 Feb 2019 08:15:34 +0000
Subject: RFR+RFA [11u]: 8165675: Trace event for thread park has incorrect
 unit for timeout
Message-ID: <959cda290ee640a2a1766f91146535ed@sap.com>

Hi,

may I please get reviews for the downport of 8165675 to jdk11u.

Bug: https://bugs.openjdk.java.net/browse/JDK-8165675
Original Change: http://hg.openjdk.java.net/jdk/jdk/rev/4eff16f47ae2
Backport Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8165675.jdk11u/

The patch did not apply cleanly. There were problems:
src/java.base/share/classes/jdk/internal/event/EventHelper.java
-> the file is not there because a prerequisite change (8148188: Enhance the security libraries to record events of interest) is not in jdk11u. So the diff here simply does not apply.

src/jdk.jfr/share/classes/jdk/jfr/consumer/RecordedObject.java.rej
-> there is a failing hunk for method OffsetDateTime getOffsetDateTime(String name). But this method is not part of jdk11u either, so it does not apply.

src/jdk.jfr/share/classes/jdk/jfr/internal/tool/PrettyWriter.java.rej
-> this class is part of the jfr tool, which was not downported to jdk11u so far. Hence no apply.

I'll run the full test suite before pushing.

Best regards
Christoph


From christoph.langer at sap.com  Wed Feb 20 08:31:04 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 20 Feb 2019 08:31:04 +0000
Subject: JDK 11.0.3 Update process
In-Reply-To: <56f19b897a2c493fb14841d5e9d3ec0d@sap.com>
References: <eadfaea4-b1f2-e15f-56f4-aa120072b14b@redhat.com>
 <20190218143520.GD5015@vimes> <ce5948c57b0243c98b5802655e5bf8d6@sap.com>
 <20190218152833.GE5015@vimes>
 <6883507c-c8bf-3f67-e5e3-2d6ec937a903@redhat.com>
 <20190218162231.GF5015@vimes>
 <90d036e5-c629-9d1e-1150-eb85b37ab91b@redhat.com>
 <CA+3eh13=JmXOkQOUShKw5ZA-nSA0JM-rwbb7qdeAs4B_WPFBVg@mail.gmail.com>
 <20190219133934.GA15514@vimes> <35ccc561616f4c10be7acb3183eae098@sap.com>
 <20190219162122.GD16716@vimes> <56f19b897a2c493fb14841d5e9d3ec0d@sap.com>
Message-ID: <faf8df342a524378a0b0e34151406058@sap.com>

Hi Rob, Goetz,

> > I'm not sure I follow. Post RDP2 of jdk12, all approved changes are first
> > pushed to jdk/jdk and then to the jdk/jdk12 stabilization repo. In this
> > case two records will be created, one for 13 and one for 12.
> 
> If you push changes first to jdk/jdk and then to jdk/jdk12 by hg
> export/import,
> and in the end pull jdk/jdk12 back to jdk/jdk, the changes should be there
> twice, shouldn't they? But it's not the case.  E.g., I had a look at
> 8218662: Allow 204 responses with Content-Length:0
> 
> ... Obviously, I'm looking at the publicly visible repos. Internally,
> you might be doing something else.

Goetz is right here. For jdk12/jdk the process is different to the works on the Oracle update releases. If a fix is considered important enough to go into jdk12 (e.g. P1) it is pushed to jdk12. It eventually bubbles back to jdk during a weekly merge of jdk12->jdk. You'll see jdk13 backports in JBS then for an issue that was fixed in jdk12 originally. That's the kind of process that we, the SAP team, think should be established for jdk11 and jdk8 updates.

Best regards
Christoph


From aph at redhat.com  Wed Feb 20 09:26:19 2019
From: aph at redhat.com (Andrew Haley)
Date: Wed, 20 Feb 2019 09:26:19 +0000
Subject: JDK 11.0.3 Update process
In-Reply-To: <CABi63P6Mz71qjs1J-Qt4D0eXB_OKZ3ovot2wzuxYMO+KkogxqA@mail.gmail.com>
References: <c7027fa19a28408e83461360f3ce6974@sap.com>
 <CA+3eh12Rtb1MQt2xr-Tu8svvZ0+NEWs4bsn0oRpnHyGhXF0fqA@mail.gmail.com>
 <be92b505-d50b-097c-d26f-f9768c90cbd0@redhat.com>
 <CA+3eh13GiMDF-8_kofUqzZvCWK2_va+DRMJDtYm6COSDLzQV6g@mail.gmail.com>
 <586ca28f-83c9-1703-040c-f9cb1f3b6180@redhat.com>
 <CA+3eh13WReDH2JHfAQDhRwxMnhQOvPt3Ab7D_eMN_eYdunnbmw@mail.gmail.com>
 <eadfaea4-b1f2-e15f-56f4-aa120072b14b@redhat.com>
 <1c9f80b75b7b492b9e463445eafd7c3d@sap.com>
 <cbaa356a-54b2-7c18-5b0b-3cdc12f58f46@redhat.com>
 <CABi63P4HtF+48sZszoonKTKA+ysuCEBrVg64bvOw52EKPS4hRA@mail.gmail.com>
 <3b877136-b4be-ff3e-e972-df402c816e1d@redhat.com>
 <CABi63P7Gv7K8kp8Yg=AE-8EgHXjvw_cnsGL-yKNttzpONY7Big@mail.gmail.com>
 <08dbb661-55c3-6c8d-89f1-4d90f7aa29ae@redhat.com>
 <CABi63P6Mz71qjs1J-Qt4D0eXB_OKZ3ovot2wzuxYMO+KkogxqA@mail.gmail.com>
Message-ID: <e6dbbab3-8ca4-a8b7-ec89-9a20e02f0653@redhat.com>

On 2/20/19 12:11 AM, Andrew Hughes wrote:

> I'm talking not so much about individual patch integration, but the process
> of tagging and making a release i.e. deciding that it is good to go.

OK.

> On Tue, 19 Feb 2019 at 09:40, Andrew Haley <aph at redhat.com> wrote:
>>
>> On 2/18/19 10:49 PM, Andrew Hughes wrote:
>>> OpenJDK 6 & 7 have been much lower traffic, so we have generally got
>>> away with doing our Red Hat builds and TCK testing, and then just
>>> doing the final push & release in public. The process will need to
>>> be formalised for 8u & 11u.
>>
>> I'm reluctant. The problem with formalizing process even more is that
>> it becomes incomprehensible to anyone except the two or threee people
>> working on a release full time.
> 
> Ok, let's put it another way; the next security update is on 2019-04-16.
> I need to know about a month before then whether I'm following the
> same process as for 7 (snapshot the tree, apply security patches,
> push them after unembargo and follow up with a release), or if we're
> doing something different, or if someone else is doing this.

I don't propose to follow a different process from 7, but I don't
believe it's possible for any individual to do 7, 8, and 11 without
severe delays. Therefore, it'll be necessary to share the work.

-- 
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 christoph.langer at sap.com  Wed Feb 20 09:30:26 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 20 Feb 2019 09:30:26 +0000
Subject: JDK 11.0.3 Update process
In-Reply-To: <ea18c97908204a2da243c9b89556e151@sap.com>
References: <CA+3eh12Rtb1MQt2xr-Tu8svvZ0+NEWs4bsn0oRpnHyGhXF0fqA@mail.gmail.com>
 <be92b505-d50b-097c-d26f-f9768c90cbd0@redhat.com>
 <CA+3eh13GiMDF-8_kofUqzZvCWK2_va+DRMJDtYm6COSDLzQV6g@mail.gmail.com>
 <586ca28f-83c9-1703-040c-f9cb1f3b6180@redhat.com>
 <CA+3eh13WReDH2JHfAQDhRwxMnhQOvPt3Ab7D_eMN_eYdunnbmw@mail.gmail.com>
 <eadfaea4-b1f2-e15f-56f4-aa120072b14b@redhat.com>
 <20190218143520.GD5015@vimes> <ce5948c57b0243c98b5802655e5bf8d6@sap.com>
 <20190218152833.GE5015@vimes>
 <6883507c-c8bf-3f67-e5e3-2d6ec937a903@redhat.com>
 <20190218162231.GF5015@vimes>
 <90d036e5-c629-9d1e-1150-eb85b37ab91b@redhat.com>
 <CA+3eh13=JmXOkQOUShKw5ZA-nSA0JM-rwbb7qdeAs4B_WPFBVg@mail.gmail.com>
 <8d1f4dcd-7031-4e7e-e569-42d0ce21c9ca@redhat.com>
 <5ec1a955-db90-a83b-fc49-277664ada52a@redhat.com>
 <a1ab759a-f171-5bf4-0f03-6b24c409bf58@redhat.com>
 <4f6ee3a1-138f-84b7-edc6-252d750fca5b@redhat.com>
 <4563e824781546caad34bc27e6d4c13b@sap.com>
 <CABi63P6+M-36xPnXriHv1GizGu12ntcmvRdARnFQWqBuZUyjpA@mail.gmail.com>
 <f587004d7f82433ea0f6476c8e87d5ca@sap.com>
 <CABi63P4KEVU1SF+0uT_U70Lvw6R-ayUW0r5e6i=+0t-1j+RaFw@mail.gmail.com>
 <ea18c97908204a2da243c9b89556e151@sap.com>
Message-ID: <67b2ace088494d2c8cc770853392596b@sap.com>

Hi,

I think the picture gets clearer now. Let me try to wrap it up a bit.

Repositories:
jdk11u-dev: The always open repository, where developers can push downports of their fixes after receiving approval via JBS "jdk11u-fix-request" tag
jdk11u: The stabilization branch for working towards the next CPU, should be run under RDP2 rules [0] or something alike
The private security repository: Run at RedHat in the dark

Release process:
For each CPU we define and communicate an RDP2 date or timeframe (like Oracle does [1])
At RDP2, we:
1. increment the hgupdater fix version of jdk11u
2. merge jdk11u-dev into jdk11u
3. increment the hgupdater fix version of jdk11u-dev
4. send a notification to the mailing list that RDP2 branching for 11.0.x has been done

Selection criteria for changes, approval process:
jdk11u-dev: All sorts of fixes/changes that we deem eligible for jdk11u. Developer requests approval via JBS "jdk11u-fix-request" tag, if patch doesn't apply runs an RFR and then pushes
jdk11u: I can see 2 types of changes:
a) changes that meet the RDP2 criteria (E.g. P1 and P2 bugs, test fixes)
b) integration of changes that Oracle brings to their CPU post RDP2 (which will probably be hg export/imports of changes that we then already have in jdk11u-dev)
In case a patch for jdk11u is requested, the JBS "jdk11u-fix-request" tag shall be set and the Fix Request comment needs to state that the request is targeted for jdk11u. The approver needs to check criteria a) and b)

Tagging:
We should tag jdk11u-dev on a weekly basis
We should tag jdk11u regularly... maybe not exactly weekly but when we think it's time for a build. E.g. if there have been significant changes and at the discretion of the CPU release engineers
We should have additional tags as Goetz proposed: 11.0.x-rdp2, 11.0.x-ga

Merging/Integration:
jdk11u-dev shall be merged into jdk11u once at RDP2.
jdk11u shall be merged back into jdk11u-dev regularly, every time we set a build tag.

Security Repo:
Ideally, I believe the security repository at RedHat should be a clone of jdk11u which is regularly refreshed by merges. Then, at the release day, the security repository shall be merged back into jdk11u and from jdk11u we shall immediately merge down to jdk11u-dev.
If it's more suitable for the process at RedHat, you could as well hold a patch queue that is always in a condition to apply to the current jdk11u. The most important thing is, that all is set up to allow an immediate push of security changes to the open on the release day.

Does that describe the process we want to run?

Best regards
Christoph

[0] https://openjdk.java.net/jeps/3
[1] https://wiki.openjdk.java.net/display/JDKUpdates/JDK12u


> -----Original Message-----
> From: Lindenmaier, Goetz
> Sent: Mittwoch, 20. Februar 2019 08:54
> To: Andrew Hughes <gnu.andrew at redhat.com>
> Cc: Langer, Christoph <christoph.langer at sap.com>; jdk-updates-
> dev at openjdk.java.net
> Subject: RE: JDK 11.0.3 Update process
> 
> Hi,
> 
> well, should have condensed this into one mail ... but nevertheless ...
> > I didn't say there was anything the matter with it, more that I was
> > surprised it was happening so quickly. I'm still wrapping up things from
> > the last CPU.
> Guess my other mail explains why we want to engage now.  We want to
> release SapMachine as close to 4/15 as possible, and with the same set
> of changes as you.
> 
> > From experience, the earlier you split off a release branch, the more
> > work has to be done in backporting from the current development branch
> > to the release branch, or, as you suggest, pulling from the release branch
> > back into the development branch.
> I don't think the pulling is that much work, but letting the fixes soak makes
> sense.
> 
> > On that latter approach, there's an obvious risk there that you push
> something
> > to 11.0.3 first which causes issues. I think there are good reasons for only
> > determining fixes as worthy for the release branch after they've soaked for
> > some time in the development branch. It's also not clear to me what the
> > "RDP2 rules" are.
> https://openjdk.java.net/jeps/3
> This explains what changes may be pushed in which phase.
> We could reuse that.
> 
> > I would like to see regular tags for both 8u & 11u. This would help testing
> > of our downstream trees, which currently don't get merged until Oracle
> push
> > all their internal work after release.
> Yes.  Tags would be great.  I would appreciate weekly builds tags in jdk11u
> after rdp2,
> 11.0.3-rdp2 when last jdk11u-dev is pulled to jdk11u,
> 11.0.3-rdp1 when you (and us)  snapshot the tree,
> 11.0.3-ga in the end.
> 
> Cheers,
>   Goetz.
> 
> > --
> > 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 shade at redhat.com  Wed Feb 20 10:16:51 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 20 Feb 2019 11:16:51 +0100
Subject: RFR+RFA [11u]: 8165675: Trace event for thread park has incorrect
 unit for timeout
In-Reply-To: <959cda290ee640a2a1766f91146535ed@sap.com>
References: <959cda290ee640a2a1766f91146535ed@sap.com>
Message-ID: <155e5a7f-6534-b2c5-034b-92342c034656@redhat.com>

On 2/20/19 9:15 AM, Langer, Christoph wrote:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8165675
> Original Change: http://hg.openjdk.java.net/jdk/jdk/rev/4eff16f47ae2
> Backport Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8165675.jdk11u/

Backport change looks good to me -- eyeballed it side-to-side with the original change.

-Aleksey


From christoph.langer at sap.com  Wed Feb 20 11:08:20 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 20 Feb 2019 11:08:20 +0000
Subject: RFR+RFA [11u]: 8213966: The ZGC JFR events should be marked as
 experimental
Message-ID: <49edc2685d224ee487278760f304fa19@sap.com>

Hi,

next one ??

May I please get reviews for the downport of 8213966 to jdk11u.

Bug: https://bugs.openjdk.java.net/browse/JDK-8213966
Original Change: http://hg.openjdk.java.net/jdk/jdk/rev/e0ce50c5e220
Backport Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8213966.jdk11u/

The patch did not apply cleanly. It contained changes to a testcase that doesn?t exist in jdk11u:
test/jdk/jdk/jfr/event/metadata/TestLookForUntestedEvents.java

Now it boils down to a metadata change only (which applies cleanly).

I?ll run the full test suite before pushing.

Best regards
Christoph


From shade at redhat.com  Wed Feb 20 11:11:19 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 20 Feb 2019 12:11:19 +0100
Subject: RFR+RFA [11u]: 8213966: The ZGC JFR events should be marked as
 experimental
In-Reply-To: <49edc2685d224ee487278760f304fa19@sap.com>
References: <49edc2685d224ee487278760f304fa19@sap.com>
Message-ID: <d85197e5-d06c-2af3-610c-d2a1c13cffca@redhat.com>

On 2/20/19 12:08 PM, Langer, Christoph wrote:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8213966
> Original Change: http://hg.openjdk.java.net/jdk/jdk/rev/e0ce50c5e220
> Backport Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8213966.jdk11u/

Looks good to me!

-Aleksey


From goetz.lindenmaier at sap.com  Wed Feb 20 11:20:51 2019
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Wed, 20 Feb 2019 11:20:51 +0000
Subject: JDK 11.0.3 Update process
In-Reply-To: <e6dbbab3-8ca4-a8b7-ec89-9a20e02f0653@redhat.com>
References: <c7027fa19a28408e83461360f3ce6974@sap.com>
 <CA+3eh12Rtb1MQt2xr-Tu8svvZ0+NEWs4bsn0oRpnHyGhXF0fqA@mail.gmail.com>
 <be92b505-d50b-097c-d26f-f9768c90cbd0@redhat.com>
 <CA+3eh13GiMDF-8_kofUqzZvCWK2_va+DRMJDtYm6COSDLzQV6g@mail.gmail.com>
 <586ca28f-83c9-1703-040c-f9cb1f3b6180@redhat.com>
 <CA+3eh13WReDH2JHfAQDhRwxMnhQOvPt3Ab7D_eMN_eYdunnbmw@mail.gmail.com>
 <eadfaea4-b1f2-e15f-56f4-aa120072b14b@redhat.com>
 <1c9f80b75b7b492b9e463445eafd7c3d@sap.com>
 <cbaa356a-54b2-7c18-5b0b-3cdc12f58f46@redhat.com>
 <CABi63P4HtF+48sZszoonKTKA+ysuCEBrVg64bvOw52EKPS4hRA@mail.gmail.com>
 <3b877136-b4be-ff3e-e972-df402c816e1d@redhat.com>
 <CABi63P7Gv7K8kp8Yg=AE-8EgHXjvw_cnsGL-yKNttzpONY7Big@mail.gmail.com>
 <08dbb661-55c3-6c8d-89f1-4d90f7aa29ae@redhat.com>
 <CABi63P6Mz71qjs1J-Qt4D0eXB_OKZ3ovot2wzuxYMO+KkogxqA@mail.gmail.com>
 <e6dbbab3-8ca4-a8b7-ec89-9a20e02f0653@redhat.com>
Message-ID: <7034a35c501645f491eb6a1f46b62009@sap.com>


> I don't propose to follow a different process from 7, but I don't
> believe it's possible for any individual to do 7, 8, and 11 without
> severe delays. Therefore, it'll be necessary to share the work.

For 11, we (SAP) would like to contribute, but we need a process so 
we all pull on the same strings :)
At least for all the work that can be done in the open. 
I think the security changes that must be closed are rather few
if we handle all the other changes beforehand. 

For tagging and syncing the two repos we would volunteer, but we're
also fine if someone else does it.

Best regards,
  Goetz.


> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> Behalf Of Andrew Haley
> Sent: Mittwoch, 20. Februar 2019 10:26
> To: Andrew Hughes <gnu.andrew at redhat.com>
> Cc: Ren? Sch?nemann <rene.schuenemann at gmail.com>; jdk-updates-
> dev at openjdk.java.net
> Subject: Re: JDK 11.0.3 Update process
> 
> On 2/20/19 12:11 AM, Andrew Hughes wrote:
> 
> > I'm talking not so much about individual patch integration, but the process
> > of tagging and making a release i.e. deciding that it is good to go.
> 
> OK.
> 
> > On Tue, 19 Feb 2019 at 09:40, Andrew Haley <aph at redhat.com> wrote:
> >>
> >> On 2/18/19 10:49 PM, Andrew Hughes wrote:
> >>> OpenJDK 6 & 7 have been much lower traffic, so we have generally got
> >>> away with doing our Red Hat builds and TCK testing, and then just
> >>> doing the final push & release in public. The process will need to
> >>> be formalised for 8u & 11u.
> >>
> >> I'm reluctant. The problem with formalizing process even more is that
> >> it becomes incomprehensible to anyone except the two or threee people
> >> working on a release full time.
> >
> > Ok, let's put it another way; the next security update is on 2019-04-16.
> > I need to know about a month before then whether I'm following the
> > same process as for 7 (snapshot the tree, apply security patches,
> > push them after unembargo and follow up with a release), or if we're
> > doing something different, or if someone else is doing this.
> 
> I don't propose to follow a different process from 7, but I don't
> believe it's possible for any individual to do 7, 8, and 11 without
> severe delays. Therefore, it'll be necessary to share the work.
> 
> --
> 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 christoph.langer at sap.com  Wed Feb 20 14:10:31 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 20 Feb 2019 14:10:31 +0000
Subject: RFR+RFA [11u]: 8215175: Inconsistencies in JFR event metadata
Message-ID: <39c61f78c7e4476a9c4828095fd5e404@sap.com>

Hi,

and another one...

May I please get reviews for the downport of 8215175 to jdk11u.

Bug: https://bugs.openjdk.java.net/browse/JDK-8215175
Original Change: http://hg.openjdk.java.net/jdk/jdk/rev/c8b2a408628b
Backport Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8215175.jdk11u/

The patch did not apply cleanly.

src/hotspot/share/jfr/metadata/metadata.xml had some fuzz but change is effectively the same as the original one.
src/jdk.jfr/share/classes/jdk/jfr/internal/Utils.java also failed. I copied the changed methods from the code that can be found in jdk/jdk currently.
src/jdk.jfr/share/classes/jdk/jfr/internal/tool/PrettyWriter.java does not exist because of the missing jfr tool. So patch could obviously not be applied to that file.

I'll run the full test suite before pushing.

Best regards
Christoph


From shade at redhat.com  Wed Feb 20 14:50:56 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 20 Feb 2019 15:50:56 +0100
Subject: RFR+RFA [11u]: 8215175: Inconsistencies in JFR event metadata
In-Reply-To: <39c61f78c7e4476a9c4828095fd5e404@sap.com>
References: <39c61f78c7e4476a9c4828095fd5e404@sap.com>
Message-ID: <574c212a-d75c-5592-ca8b-fc11b07724a3@redhat.com>

On 2/20/19 3:10 PM, Langer, Christoph wrote:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8215175
> Original Change: http://hg.openjdk.java.net/jdk/jdk/rev/c8b2a408628b
> Backport Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8215175.jdk11u/

Backport change looks fine to me. I eyeballed original and backport change side-by-side.

-Aleksey


From rob.mckenna at oracle.com  Wed Feb 20 14:55:16 2019
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Wed, 20 Feb 2019 14:55:16 +0000
Subject: JDK 11.0.3 Update process
In-Reply-To: <faf8df342a524378a0b0e34151406058@sap.com>
References: <20190218152833.GE5015@vimes>
 <6883507c-c8bf-3f67-e5e3-2d6ec937a903@redhat.com>
 <20190218162231.GF5015@vimes>
 <90d036e5-c629-9d1e-1150-eb85b37ab91b@redhat.com>
 <CA+3eh13=JmXOkQOUShKw5ZA-nSA0JM-rwbb7qdeAs4B_WPFBVg@mail.gmail.com>
 <20190219133934.GA15514@vimes>
 <35ccc561616f4c10be7acb3183eae098@sap.com>
 <20190219162122.GD16716@vimes>
 <56f19b897a2c493fb14841d5e9d3ec0d@sap.com>
 <faf8df342a524378a0b0e34151406058@sap.com>
Message-ID: <20190220145516.GB26505@vimes>

Ah, you're both absolutely right. I had forgotten the difference in
process in the JDK Project.

There are a number of duplicate changesets in 12, but these could
be a case of realising after the fact that the fix should be in the
earlier release.

So I can't speak for that project, but with JDK Updates (and JDK 8u
before it) the decision was made to have engineers push to a single
always-open repository in the interests of simplicity. It is a little
extra work for an integrator(*), but it drastically simplifies things from
the perspective of the committer.

(*) That is to say, there is usually only a small number of patches to
bring into a stabilization forest on a weekly basis, and they generally
apply cleanly.

    -Rob


On 20/02/19 08:31, Langer, Christoph wrote:
> Hi Rob, Goetz,
> 
> > > I'm not sure I follow. Post RDP2 of jdk12, all approved changes are first
> > > pushed to jdk/jdk and then to the jdk/jdk12 stabilization repo. In this
> > > case two records will be created, one for 13 and one for 12.
> > 
> > If you push changes first to jdk/jdk and then to jdk/jdk12 by hg
> > export/import,
> > and in the end pull jdk/jdk12 back to jdk/jdk, the changes should be there
> > twice, shouldn't they? But it's not the case.  E.g., I had a look at
> > 8218662: Allow 204 responses with Content-Length:0
> > 
> > ... Obviously, I'm looking at the publicly visible repos. Internally,
> > you might be doing something else.
> 
> Goetz is right here. For jdk12/jdk the process is different to the works on the Oracle update releases. If a fix is considered important enough to go into jdk12 (e.g. P1) it is pushed to jdk12. It eventually bubbles back to jdk during a weekly merge of jdk12->jdk. You'll see jdk13 backports in JBS then for an issue that was fixed in jdk12 originally. That's the kind of process that we, the SAP team, think should be established for jdk11 and jdk8 updates.
> 
> Best regards
> Christoph
> 

From thomas.stuefe at gmail.com  Wed Feb 20 06:45:38 2019
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Wed, 20 Feb 2019 07:45:38 +0100
Subject: RFR+RFA [11u] (XS) 8219251: Langtools tests default memory size
 needs to be 768m
In-Reply-To: <13a077e8795c4dd1862f3cd9cc9f9919@sap.com>
References: <b734e045-a08c-6aea-7c1b-5b953afdaf15@redhat.com>
 <812f91e6-ca88-ff4c-2a90-8dbc8aa76b4f@redhat.com>
 <c0fe308c-0aaa-b628-4a79-547dd1cc64c8@redhat.com>
 <b24ea0bb-8701-0b64-a885-57ac9e9f827f@redhat.com>
 <c6fdaca0181741559e74abe2f4d4ff86@sap.com>
 <766d47e5-5f96-5d01-5a1a-f998b718f532@redhat.com>
 <13a077e8795c4dd1862f3cd9cc9f9919@sap.com>
Message-ID: <CAA-vtUwydEak-Wn-6Df8psa-Ngi37X0fc-oT4APHEq21Et4A4Q@mail.gmail.com>

Can live with the no. Issue was stuck in approvement limbo for ages anyway.

For the record, the reason why I wanted this was not "nice to have" - maybe
the text was too vague.

In very short, Runtime.exec uses vfork() on 11u, which may cause issues
which are extremely difficult to analyse, e.g. sporadic deaths of the
parent process, or trashing the forking threads stack. Since these problems
are so difficult to pinpoint it would have been nice to have an off switch
to try an alternate fork method in cases where we see rare random process
deaths.

..Thomas



On Tue, Feb 19, 2019 at 2:30 PM Langer, Christoph <christoph.langer at sap.com>
wrote:

> > Why is JDK-8212828 included in this list? It's not a bug. I can't see
> any strong
> > reason to include it. "Nice to have" is not really enough: there are
> lots of
> > things
> > that would be nice to have.
>
> We have to defer this one to Thomas. I think he started the backporting
> work some days ago when still Oracle was in charge. However, he needed to
> request a CSR for the backport - that's where this one is stuck at the
> moment. I agree, it should not be approved at the moment.
>
>
> > I ACK'd the rest.
>
> Thanks
>

From deepak.kejriwal at oracle.com  Wed Feb 20 16:53:10 2019
From: deepak.kejriwal at oracle.com (Deepak Kejriwal)
Date: Wed, 20 Feb 2019 08:53:10 -0800 (PST)
Subject: RFR: JDK11U JDK-8206120, JDK-8211398, JDK-8218915
In-Reply-To: <fa5ad573-675f-c009-d1fe-e0a90bc07b96@oracle.com>
References: <831af84c-5aa2-44de-b9e4-b5e7aeb876ef@default>
 <fa5ad573-675f-c009-d1fe-e0a90bc07b96@oracle.com>
Message-ID: <7ac824c2-7299-47a6-92fd-7c7e1238ec97@default>

Thanks Naoto San and Sean for review. I have incorporate all the comments. Please find below updated version of webrev :-

http://cr.openjdk.java.net/~rpatil/JapaneseEra_changes_11u/webrev.01/

Regards,
Deepak

-----Original Message-----
From: Naoto Sato 
Sent: Tuesday, February 19, 2019 10:23 PM
To: Deepak Kejriwal <deepak.kejriwal at oracle.com>; core-libs-dev <core-libs-dev at openjdk.java.net>; jdk-updates-dev at openjdk.java.net
Subject: Re: RFR: JDK11U JDK-8206120, JDK-8211398, JDK-8218915

Hi Deepak,

Here are my comments to the webrev (other than what Sean pointed out):

TestIsJavaIdentifierMethods.java

- @summary: "testIsJavaLetter" -> "isJavaLetter", "testIsJavaLetterOrDigit" -> "isJavaLetterOrDigit".

- Line 34: "newCodePoint" does not represent the era character, as "new" 
is subjective. It will become moot in the year 2020. How about "JAPANESE_ERA_CODEPOINT"?

- Line 67,68,(...all the comments): Reflect the above change to the comments.

- Line 103: "All Unicode chars (0x0000..0xFFFF)" does not sound correct. 
It may be "All Unicode code points in the BMP (0x0000..0xFFFF), and remove extra period at the end. This applies to other method descriptions.

- Line 104: The test case returns "void", what does this "Expected results" mean?

- Line 140-142,174-176: The condition statement in the document is different from JDK11's javadoc. In the API doc, it is (in case of int):

    isLetter(codePoint) returns true
    getType(codePoint) returns LETTER_NUMBER
    the referenced character is a currency symbol (such as '$')
    the referenced character is a connecting punctuation character (such as '_').

- Line 163,198: Exception messages are incorrect. they are for isJavaIdentifierStart().

Naoto


On 2/19/19 6:15 AM, Deepak Kejriwal wrote:
> Correcting typo for release.
> 
>   
> 
> From: Deepak Kejriwal <deepak.kejriwal at oracle.com>
> Sent: Tuesday, February 19, 2019 7:42 PM
> To: 'core-libs-dev' <core-libs-dev at openjdk.java.net>; 
> 'jdk-updates-dev at openjdk.java.net' <jdk-updates-dev at openjdk.java.net>
> Subject: RFR: JDK11U JDK-8206120, JDK-8211398, JDK-8218915
> 
>   
> 
> Hi All,
> 
> Please review the backport of the following bug fixes to jdk11u-dev:
> 
> HYPERLINK 
> "https://bugs.openjdk.java.net/browse/JDK-8206120"JDK-8206120 : Add 
> test cases for lenient Japanese era parsing HYPERLINK 
> "https://bugs.openjdk.java.net/browse/JDK-8211398"JDK-8211398 : Square 
> character support for the Japanese new era HYPERLINK 
> "https://bugs.openjdk.java.net/browse/JDK-8218915"JDK-8218915 : Change 
> isJavaIdentifierStart and isJavaIdentifierPart to handle new code 
> points
> 
> Webrev:  
> http://cr.openjdk.java.net/~rpatil/JapaneseEra_changes_11u/webrev.00/
> 
> These code changes are made possible thanks to specification change already pushed:
> http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/c1e1669edace
> 
> Regards,
> Deepak
> 
>   
> 

From goetz.lindenmaier at sap.com  Wed Feb 20 17:04:34 2019
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Wed, 20 Feb 2019 17:04:34 +0000
Subject: RFR(XS) [11u]: 8219461: Bump update version for OpenJDK jdk11.0.3
Message-ID: <c97bd7a4da26482c843cac3386b9f7c3@sap.com>

Hi,

I think we should bump the version:
http://cr.openjdk.java.net/~goetz/wr19/8219461-11.0.3_version/01/
(In 11.0.4, this should be one of the first changes I think)

See also
http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/2be95a1bf508
http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/1353ec839c82

What date should we use? The date Oracle will deliver it's update?
Did I miss a version field to be bumped?

Best regards,
  Goetz.


From naoto.sato at oracle.com  Wed Feb 20 17:35:45 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Wed, 20 Feb 2019 09:35:45 -0800
Subject: RFR: JDK11U JDK-8206120, JDK-8211398, JDK-8218915
In-Reply-To: <7ac824c2-7299-47a6-92fd-7c7e1238ec97@default>
References: <831af84c-5aa2-44de-b9e4-b5e7aeb876ef@default>
 <fa5ad573-675f-c009-d1fe-e0a90bc07b96@oracle.com>
 <7ac824c2-7299-47a6-92fd-7c7e1238ec97@default>
Message-ID: <36b3dc85-ceaf-eb34-06ef-4cf5c890813a@oracle.com>

Hi Deepak,

I see the following comment is not addressed yet:

 > - Line 163,198: Exception messages are incorrect. they are for 
isJavaIdentifierStart().

Naoto

On 2/20/19 8:53 AM, Deepak Kejriwal wrote:
> Thanks Naoto San and Sean for review. I have incorporate all the comments. Please find below updated version of webrev :-
> 
> http://cr.openjdk.java.net/~rpatil/JapaneseEra_changes_11u/webrev.01/
> 
> Regards,
> Deepak
> 
> -----Original Message-----
> From: Naoto Sato
> Sent: Tuesday, February 19, 2019 10:23 PM
> To: Deepak Kejriwal <deepak.kejriwal at oracle.com>; core-libs-dev <core-libs-dev at openjdk.java.net>; jdk-updates-dev at openjdk.java.net
> Subject: Re: RFR: JDK11U JDK-8206120, JDK-8211398, JDK-8218915
> 
> Hi Deepak,
> 
> Here are my comments to the webrev (other than what Sean pointed out):
> 
> TestIsJavaIdentifierMethods.java
> 
> - @summary: "testIsJavaLetter" -> "isJavaLetter", "testIsJavaLetterOrDigit" -> "isJavaLetterOrDigit".
> 
> - Line 34: "newCodePoint" does not represent the era character, as "new"
> is subjective. It will become moot in the year 2020. How about "JAPANESE_ERA_CODEPOINT"?
> 
> - Line 67,68,(...all the comments): Reflect the above change to the comments.
> 
> - Line 103: "All Unicode chars (0x0000..0xFFFF)" does not sound correct.
> It may be "All Unicode code points in the BMP (0x0000..0xFFFF), and remove extra period at the end. This applies to other method descriptions.
> 
> - Line 104: The test case returns "void", what does this "Expected results" mean?
> 
> - Line 140-142,174-176: The condition statement in the document is different from JDK11's javadoc. In the API doc, it is (in case of int):
> 
>      isLetter(codePoint) returns true
>      getType(codePoint) returns LETTER_NUMBER
>      the referenced character is a currency symbol (such as '$')
>      the referenced character is a connecting punctuation character (such as '_').
> 
> - Line 163,198: Exception messages are incorrect. they are for isJavaIdentifierStart().
> 
> Naoto
> 
> 
> On 2/19/19 6:15 AM, Deepak Kejriwal wrote:
>> Correcting typo for release.
>>
>>    
>>
>> From: Deepak Kejriwal <deepak.kejriwal at oracle.com>
>> Sent: Tuesday, February 19, 2019 7:42 PM
>> To: 'core-libs-dev' <core-libs-dev at openjdk.java.net>;
>> 'jdk-updates-dev at openjdk.java.net' <jdk-updates-dev at openjdk.java.net>
>> Subject: RFR: JDK11U JDK-8206120, JDK-8211398, JDK-8218915
>>
>>    
>>
>> Hi All,
>>
>> Please review the backport of the following bug fixes to jdk11u-dev:
>>
>> HYPERLINK
>> "https://bugs.openjdk.java.net/browse/JDK-8206120"JDK-8206120 : Add
>> test cases for lenient Japanese era parsing HYPERLINK
>> "https://bugs.openjdk.java.net/browse/JDK-8211398"JDK-8211398 : Square
>> character support for the Japanese new era HYPERLINK
>> "https://bugs.openjdk.java.net/browse/JDK-8218915"JDK-8218915 : Change
>> isJavaIdentifierStart and isJavaIdentifierPart to handle new code
>> points
>>
>> Webrev:
>> http://cr.openjdk.java.net/~rpatil/JapaneseEra_changes_11u/webrev.00/
>>
>> These code changes are made possible thanks to specification change already pushed:
>> http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/c1e1669edace
>>
>> Regards,
>> Deepak
>>
>>    
>>

From shade at redhat.com  Wed Feb 20 18:10:30 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 20 Feb 2019 19:10:30 +0100
Subject: Pending pushes for approved 11u backports
Message-ID: <7014a3ae-ebac-c7e6-5658-17fc95e4da55@redhat.com>

Hi,

I have generated "orphans" report for issues that have jdk11u-fix-yes set, but have no actual commits:
  https://builds.shipilev.net/backports-monitor/orphans-11.txt

Looking at this report, I see there are pushes to be done. I have CC'ed original Fix Requesters.

Note: normally, the persons who put Fix Requests should be active and find the sponsor for the push.
But, we also want to wrap up 11.0.3 sooner rather than later without missing simple patches, so
consider this reminder the one-time thing :)

Ningsheng Jian: You need sponsor for this, right? You don't have JDK Updates privileges in Census.
  https://bugs.openjdk.java.net/browse/JDK-8215100
  https://bugs.openjdk.java.net/browse/JDK-8215202

Jamil Nimeh (and Andrew Haley): Does this still apply to 11u? Andrew, do you still want it in 11.0.3?
  https://bugs.openjdk.java.net/browse/JDK-8210989

Toshio Nakamura: You need sponsor for this, right? You don't have JDK Updates privileges in Census.
  https://bugs.openjdk.java.net/browse/JDK-8213183
  https://bugs.openjdk.java.net/browse/JDK-8211267

Man Cao: You need sponsor for this, right? You don't have JDK Updates privileges in Census. I would
prefer this to land to 12u as well.
  https://bugs.openjdk.java.net/browse/JDK-8218192

Martin Buchholz: I think you are all set. Please check it passes tier1 on current 11u?
  https://bugs.openjdk.java.net/browse/JDK-8212233

Others are between me and Christoph, and I know they are on track.

Thanks,
-Aleksey


From christoph.langer at sap.com  Wed Feb 20 18:40:04 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 20 Feb 2019 18:40:04 +0000
Subject: RFR(XS) [11u]: 8219461: Bump update version for OpenJDK jdk11.0.3
In-Reply-To: <c97bd7a4da26482c843cac3386b9f7c3@sap.com>
References: <c97bd7a4da26482c843cac3386b9f7c3@sap.com>
Message-ID: <9df55968e4bc48bba0ff91c342b264f7@sap.com>

Hi Goetz,

to me this looks good. The version date seems to be correct, assuming that 15th of April is the planned release day. Interestingly enough, Oracle did not do the bump to jdk12 12.0.1 in the jdk12u repository yet. I assume they only do it in their release repositories and the master update repository gets the change when merging it back.

Best regards
Christoph

From: Lindenmaier, Goetz
Sent: Mittwoch, 20. Februar 2019 18:05
To: jdk-updates-dev at openjdk.java.net; Andrew Haley (aph at redhat.com) <aph at redhat.com>; Andrew Hughes (gnu.andrew at redhat.com) <gnu.andrew at redhat.com>; Langer, Christoph <christoph.langer at sap.com>; Aleksey Shipilev <shade at redhat.com>
Subject: RFR(XS) [11u]: 8219461: Bump update version for OpenJDK jdk11.0.3

Hi,

I think we should bump the version:
http://cr.openjdk.java.net/~goetz/wr19/8219461-11.0.3_version/01/
(In 11.0.4, this should be one of the first changes I think)

See also
http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/2be95a1bf508
http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/1353ec839c82

What date should we use? The date Oracle will deliver it's update?
Did I miss a version field to be bumped?

Best regards,
  Goetz.


From manc at google.com  Wed Feb 20 22:38:47 2019
From: manc at google.com (Man Cao)
Date: Wed, 20 Feb 2019 14:38:47 -0800
Subject: How to run tests before pushing a backport changeset?
Message-ID: <CA+w6Hxbe+Ye7tqjGxzB8LDHRWZdDLQyT20pWZk_VTDqbc4z4uQ@mail.gmail.com>

Hi all,

I wonder if there is a recommended way to run automated tests before
pushing a changeset to jdk11u or jdk12u.
Is there something like Submit Repo
<https://wiki.openjdk.java.net/display/Build/Submit+Repo> for the
jdk-updates project? Does the backporting process require running such
automated tests before pushing a changeset?
I read the links on https://openjdk.java.net/projects/jdk-updates/, but
couldn't find any description on testing.

Background:
I'm an Author on the JDK project, but new to the jdk-updates project. After
getting an approval tag such as "jdk11u-fix-yes" from JBS for a bug/RFE, I
could ask a colleague in Google's Java platform team with the committer bit
for jdk-updates project to help push the changeset. But we are unsure about
the testing process.

Thanks,
Man Cao

From TOSHIONA at jp.ibm.com  Wed Feb 20 23:14:16 2019
From: TOSHIONA at jp.ibm.com (Toshio 5 Nakamura)
Date: Thu, 21 Feb 2019 08:14:16 +0900
Subject: Pending pushes for approved 11u backports
In-Reply-To: <7014a3ae-ebac-c7e6-5658-17fc95e4da55@redhat.com>
References: <7014a3ae-ebac-c7e6-5658-17fc95e4da55@redhat.com>
Message-ID: <OF1B930E62.46AF257C-ON002583A7.007F731F-492583A7.007FA643@notes.na.collabserv.com>

Hi Aleksey,

Yes, may I ask a sponsor for these requests?

> Toshio Nakamura: You need sponsor for this, right? You don't have
> JDK Updates privileges in Census.
>   https://bugs.openjdk.java.net/browse/JDK-8213183
>   https://bugs.openjdk.java.net/browse/JDK-8211267

Thanks,
Toshio Nakamura

Aleksey Shipilev <shade at redhat.com> wrote on 2019/02/21 03:10:30:

> From: Aleksey Shipilev <shade at redhat.com>
> To: "jdk-updates-dev at openjdk.java.net" <jdk-updates-dev at openjdk.java.net>
> Cc: "Ningsheng Jian (Arm Technology China)"
> <Ningsheng.Jian at arm.com>, Jamil Nimeh <jamil.j.nimeh at oracle.com>,
> Toshio 5 Nakamura <TOSHIONA at jp.ibm.com>, Martin Buchholz
<martinrb at google.com>
> Date: 2019/02/21 03:11
> Subject: Pending pushes for approved 11u backports
>
> Hi,
>
> I have generated "orphans" report for issues that have jdk11u-fix-
> yes set, but have no actual commits:
>   https://builds.shipilev.net/backports-monitor/orphans-11.txt
>
> Looking at this report, I see there are pushes to be done. I have
> CC'ed original Fix Requesters.
>
> Note: normally, the persons who put Fix Requests should be active
> and find the sponsor for the push.
> But, we also want to wrap up 11.0.3 sooner rather than later without
> missing simple patches, so
> consider this reminder the one-time thing :)
>
> Ningsheng Jian: You need sponsor for this, right? You don't have JDK
> Updates privileges in Census.
>   https://bugs.openjdk.java.net/browse/JDK-8215100
>   https://bugs.openjdk.java.net/browse/JDK-8215202
>
> Jamil Nimeh (and Andrew Haley): Does this still apply to 11u?
> Andrew, do you still want it in 11.0.3?
>   https://bugs.openjdk.java.net/browse/JDK-8210989
>
> Toshio Nakamura: You need sponsor for this, right? You don't have
> JDK Updates privileges in Census.
>   https://bugs.openjdk.java.net/browse/JDK-8213183
>   https://bugs.openjdk.java.net/browse/JDK-8211267
>
> Man Cao: You need sponsor for this, right? You don't have JDK
> Updates privileges in Census. I would
> prefer this to land to 12u as well.
>   https://bugs.openjdk.java.net/browse/JDK-8218192
>
> Martin Buchholz: I think you are all set. Please check it passes
> tier1 on current 11u?
>   https://bugs.openjdk.java.net/browse/JDK-8212233
>
> Others are between me and Christoph, and I know they are on track.
>
> Thanks,
> -Aleksey
>
> [attachment "signature.asc" deleted by Toshio 5 Nakamura/Japan/IBM]

From shade at redhat.com  Thu Feb 21 00:01:12 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 21 Feb 2019 01:01:12 +0100
Subject: Pending pushes for approved 11u backports
In-Reply-To: <OF1B930E62.46AF257C-ON002583A7.007F731F-492583A7.007FA643@notes.na.collabserv.com>
References: <7014a3ae-ebac-c7e6-5658-17fc95e4da55@redhat.com>
 <OF1B930E62.46AF257C-ON002583A7.007F731F-492583A7.007FA643@notes.na.collabserv.com>
Message-ID: <005a549e-18f1-e948-78df-abc64f171e8b@redhat.com>

On 2/21/19 12:14 AM, Toshio 5 Nakamura wrote:
> Hi Aleksey,
> 
> Yes, may I ask a sponsor for these requests?
> 
>> Toshio Nakamura: You need sponsor for this, right? You don't have
>> JDK Updates privileges in Census.
>> ? https://bugs.openjdk.java.net/browse/JDK-8213183
>> ? https://bugs.openjdk.java.net/browse/JDK-8211267

No problem, I would sponsor these for you tomorrow.

-Aleksey


From shade at redhat.com  Thu Feb 21 00:09:53 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 21 Feb 2019 01:09:53 +0100
Subject: How to run tests before pushing a backport changeset?
In-Reply-To: <CA+w6Hxbe+Ye7tqjGxzB8LDHRWZdDLQyT20pWZk_VTDqbc4z4uQ@mail.gmail.com>
References: <CA+w6Hxbe+Ye7tqjGxzB8LDHRWZdDLQyT20pWZk_VTDqbc4z4uQ@mail.gmail.com>
Message-ID: <f2a642ff-ff81-f52e-ea50-13b845d52d15@redhat.com>

On 2/20/19 11:38 PM, Man Cao wrote:
> I wonder if there is a recommended way to run automated tests before pushing a changeset to
> jdk11u or jdk12u. Is there something like Submit Repo 
> <https://wiki.openjdk.java.net/display/Build/Submit+Repo> for the jdk-updates project?
There is no submit repo for JDK updates.

> I read the links on https://openjdk.java.net/projects/jdk-updates/, but couldn't find any
> description on testing. Does the backporting process require running such automated tests before
> pushing a changeset?
I think it is maintainer's duty to decide if testing was enough (this is why Fix Request requires
[1] to spell out what testing was done). That said, it seems the more tests you run, the more less
chance backport would be problematic.

In my mind, the bare minimum is to run the regression tests supplied with the backport, and also the
tests for the component you push to. For example, for
https://bugs.openjdk.java.net/browse/JDK-8218192 that you have on your plate, I'd run hotspot_gc:

$ make images run-test TEST=hotspot_gc

Passing tier1 in fastdebug (and release, if you have time) seems to be a good sanity test for all
patches too:

$ make images run-test TEST=tier1

-Aleksey

[1] https://openjdk.java.net/projects/jdk-updates/approval.html


From manc at google.com  Thu Feb 21 01:33:34 2019
From: manc at google.com (Man Cao)
Date: Wed, 20 Feb 2019 17:33:34 -0800
Subject: How to run tests before pushing a backport changeset?
In-Reply-To: <f2a642ff-ff81-f52e-ea50-13b845d52d15@redhat.com>
References: <CA+w6Hxbe+Ye7tqjGxzB8LDHRWZdDLQyT20pWZk_VTDqbc4z4uQ@mail.gmail.com>
 <f2a642ff-ff81-f52e-ea50-13b845d52d15@redhat.com>
Message-ID: <CA+w6Hxa-f6gFagjZCLZQ49K6Cm+K6SnW7r8vH=YQ=b8cm8kG5Q@mail.gmail.com>

Thanks, Aleksey! I will run TEST=tier1 for both fastdebug and release
locally then.

jiangli@ will help me push JDK-8218192 to JDK11u and JDK12u soon.

-Man


On Wed, Feb 20, 2019 at 4:09 PM Aleksey Shipilev <shade at redhat.com> wrote:

> On 2/20/19 11:38 PM, Man Cao wrote:
> > I wonder if there is a recommended way to run automated tests before
> pushing a changeset to
> > jdk11u or jdk12u. Is there something like Submit Repo
> > <https://wiki.openjdk.java.net/display/Build/Submit+Repo> for the
> jdk-updates project?
> There is no submit repo for JDK updates.
>
> > I read the links on https://openjdk.java.net/projects/jdk-updates/, but
> couldn't find any
> > description on testing. Does the backporting process require running
> such automated tests before
> > pushing a changeset?
> I think it is maintainer's duty to decide if testing was enough (this is
> why Fix Request requires
> [1] to spell out what testing was done). That said, it seems the more
> tests you run, the more less
> chance backport would be problematic.
>
> In my mind, the bare minimum is to run the regression tests supplied with
> the backport, and also the
> tests for the component you push to. For example, for
> https://bugs.openjdk.java.net/browse/JDK-8218192 that you have on your
> plate, I'd run hotspot_gc:
>
> $ make images run-test TEST=hotspot_gc
>
> Passing tier1 in fastdebug (and release, if you have time) seems to be a
> good sanity test for all
> patches too:
>
> $ make images run-test TEST=tier1
>
> -Aleksey
>
> [1] https://openjdk.java.net/projects/jdk-updates/approval.html
>
>

From martinrb at google.com  Thu Feb 21 03:55:37 2019
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 20 Feb 2019 19:55:37 -0800
Subject: How to run tests before pushing a backport changeset?
In-Reply-To: <f2a642ff-ff81-f52e-ea50-13b845d52d15@redhat.com>
References: <CA+w6Hxbe+Ye7tqjGxzB8LDHRWZdDLQyT20pWZk_VTDqbc4z4uQ@mail.gmail.com>
 <f2a642ff-ff81-f52e-ea50-13b845d52d15@redhat.com>
Message-ID: <CA+kOe0-7S+2LZEg+ieb0pbQwb=Jd2XTNqjkPfYQTmN4YS_Jnug@mail.gmail.com>

On Wed, Feb 20, 2019 at 4:10 PM Aleksey Shipilev <shade at redhat.com> wrote:

> On 2/20/19 11:38 PM, Man Cao wrote:
> > I wonder if there is a recommended way to run automated tests before
> pushing a changeset to
> > jdk11u or jdk12u. Is there something like Submit Repo
> > <https://wiki.openjdk.java.net/display/Build/Submit+Repo> for the
> jdk-updates project?
> There is no submit repo for JDK updates.
>
> > I read the links on https://openjdk.java.net/projects/jdk-updates/, but
> couldn't find any
> > description on testing. Does the backporting process require running
> such automated tests before
> > pushing a changeset?
> I think it is maintainer's duty to decide if testing was enough (this is
> why Fix Request requires
> [1] to spell out what testing was done). That said, it seems the more
> tests you run, the more less
> chance backport would be problematic.
>

I'm surprised to see you say that, because you are the king of build/test
automation.
I prefer to lessen the burden on backport developers and instead invest in
better release testing automation (e.g. "presubmit queue").

From deepak.kejriwal at oracle.com  Thu Feb 21 08:26:47 2019
From: deepak.kejriwal at oracle.com (Deepak Kejriwal)
Date: Thu, 21 Feb 2019 00:26:47 -0800 (PST)
Subject: RFR: JDK11U JDK-8206120, JDK-8211398, JDK-8218915
In-Reply-To: <36b3dc85-ceaf-eb34-06ef-4cf5c890813a@oracle.com>
References: <831af84c-5aa2-44de-b9e4-b5e7aeb876ef@default>
 <fa5ad573-675f-c009-d1fe-e0a90bc07b96@oracle.com>
 <7ac824c2-7299-47a6-92fd-7c7e1238ec97@default>
 <36b3dc85-ceaf-eb34-06ef-4cf5c890813a@oracle.com>
Message-ID: <672daacf-f12e-47a5-af14-b7ac054a3f1c@default>

Hi Naoto,

Corrected the exception message. Please find below updated version of webrev:-
http://cr.openjdk.java.net/~rpatil/JapaneseEra_changes_11u/webrev.02/

Thanks for review.

Regards,
Deepak

-----Original Message-----
From: Naoto Sato 
Sent: Wednesday, February 20, 2019 11:06 PM
To: Deepak Kejriwal <deepak.kejriwal at oracle.com>; Sean Coffey <sean.coffey at oracle.com>; core-libs-dev <core-libs-dev at openjdk.java.net>; jdk-updates-dev at openjdk.java.net
Subject: Re: RFR: JDK11U JDK-8206120, JDK-8211398, JDK-8218915

Hi Deepak,

I see the following comment is not addressed yet:

 > - Line 163,198: Exception messages are incorrect. they are for isJavaIdentifierStart().

Naoto

On 2/20/19 8:53 AM, Deepak Kejriwal wrote:
> Thanks Naoto San and Sean for review. I have incorporate all the 
> comments. Please find below updated version of webrev :-
> 
> http://cr.openjdk.java.net/~rpatil/JapaneseEra_changes_11u/webrev.01/
> 
> Regards,
> Deepak
> 
> -----Original Message-----
> From: Naoto Sato
> Sent: Tuesday, February 19, 2019 10:23 PM
> To: Deepak Kejriwal <deepak.kejriwal at oracle.com>; core-libs-dev 
> <core-libs-dev at openjdk.java.net>; jdk-updates-dev at openjdk.java.net
> Subject: Re: RFR: JDK11U JDK-8206120, JDK-8211398, JDK-8218915
> 
> Hi Deepak,
> 
> Here are my comments to the webrev (other than what Sean pointed out):
> 
> TestIsJavaIdentifierMethods.java
> 
> - @summary: "testIsJavaLetter" -> "isJavaLetter", "testIsJavaLetterOrDigit" -> "isJavaLetterOrDigit".
> 
> - Line 34: "newCodePoint" does not represent the era character, as "new"
> is subjective. It will become moot in the year 2020. How about "JAPANESE_ERA_CODEPOINT"?
> 
> - Line 67,68,(...all the comments): Reflect the above change to the comments.
> 
> - Line 103: "All Unicode chars (0x0000..0xFFFF)" does not sound correct.
> It may be "All Unicode code points in the BMP (0x0000..0xFFFF), and remove extra period at the end. This applies to other method descriptions.
> 
> - Line 104: The test case returns "void", what does this "Expected results" mean?
> 
> - Line 140-142,174-176: The condition statement in the document is different from JDK11's javadoc. In the API doc, it is (in case of int):
> 
>      isLetter(codePoint) returns true
>      getType(codePoint) returns LETTER_NUMBER
>      the referenced character is a currency symbol (such as '$')
>      the referenced character is a connecting punctuation character (such as '_').
> 
> - Line 163,198: Exception messages are incorrect. they are for isJavaIdentifierStart().
> 
> Naoto
> 
> 
> On 2/19/19 6:15 AM, Deepak Kejriwal wrote:
>> Correcting typo for release.
>>
>>    
>>
>> From: Deepak Kejriwal <deepak.kejriwal at oracle.com>
>> Sent: Tuesday, February 19, 2019 7:42 PM
>> To: 'core-libs-dev' <core-libs-dev at openjdk.java.net>; 
>> 'jdk-updates-dev at openjdk.java.net' <jdk-updates-dev at openjdk.java.net>
>> Subject: RFR: JDK11U JDK-8206120, JDK-8211398, JDK-8218915
>>
>>    
>>
>> Hi All,
>>
>> Please review the backport of the following bug fixes to jdk11u-dev:
>>
>> HYPERLINK
>> "https://bugs.openjdk.java.net/browse/JDK-8206120"JDK-8206120 : Add 
>> test cases for lenient Japanese era parsing HYPERLINK
>> "https://bugs.openjdk.java.net/browse/JDK-8211398"JDK-8211398 : 
>> Square character support for the Japanese new era HYPERLINK
>> "https://bugs.openjdk.java.net/browse/JDK-8218915"JDK-8218915 : 
>> Change isJavaIdentifierStart and isJavaIdentifierPart to handle new 
>> code points
>>
>> Webrev:
>> http://cr.openjdk.java.net/~rpatil/JapaneseEra_changes_11u/webrev.00/
>>
>> These code changes are made possible thanks to specification change already pushed:
>> http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/c1e1669edace
>>
>> Regards,
>> Deepak
>>
>>    
>>

From shade at redhat.com  Thu Feb 21 08:29:32 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 21 Feb 2019 09:29:32 +0100
Subject: How to run tests before pushing a backport changeset?
In-Reply-To: <CA+w6Hxa-f6gFagjZCLZQ49K6Cm+K6SnW7r8vH=YQ=b8cm8kG5Q@mail.gmail.com>
References: <CA+w6Hxbe+Ye7tqjGxzB8LDHRWZdDLQyT20pWZk_VTDqbc4z4uQ@mail.gmail.com>
 <f2a642ff-ff81-f52e-ea50-13b845d52d15@redhat.com>
 <CA+w6Hxa-f6gFagjZCLZQ49K6Cm+K6SnW7r8vH=YQ=b8cm8kG5Q@mail.gmail.com>
Message-ID: <ccc70698-318b-20e6-7611-f2b3cfa5e66b@redhat.com>

On 2/21/19 2:33 AM, Man Cao wrote:
> Thanks, Aleksey! I will run TEST=tier1 for both fastdebug and release locally then.
> 
> jiangli@ will help me push?JDK-8218192 to JDK11u and JDK12u soon.

Sounds good!

-Aleksey


From goetz.lindenmaier at sap.com  Thu Feb 21 08:42:05 2019
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Thu, 21 Feb 2019 08:42:05 +0000
Subject: RFR(XS) [11u]: 8219461: Bump update version for OpenJDK jdk11.0.3
In-Reply-To: <9df55968e4bc48bba0ff91c342b264f7@sap.com>
References: <c97bd7a4da26482c843cac3386b9f7c3@sap.com>
 <9df55968e4bc48bba0ff91c342b264f7@sap.com>
Message-ID: <b778ed5b672a4a67b1efdccb171edc7f@sap.com>

Hi Christoph

Thanks for flagging the fix-request!

> The version date seems to be correct, assuming that
> 15th of April is the planned release day.
It's 4/16: https://www.oracle.com/technetwork/topics/security/alerts-086861.html
Fixed webrev:
http://cr.openjdk.java.net/~goetz/wr19/8219461-11.0.3_version/02/

But the question is more
 - do we want to set a date at all?
 - do we want to set the same date as Oracle?
 - or do we want to set the date when the -ga tag is pushed to the open?

> Oracle did not do the bump to jdk12 12.0.1 in the jdk12u repository yet.
I assume we can not see the change that bumps the version to 12.0.1. 
I also looked for the change that bumps the version to 11.0.3-oracle, but 
could not find that either. But the bugs for the version bumps for 11.0.1 and 11.0.2 are
not visible either, see the changes I referenced.

Best regards,
  Goetz.


> -----Original Message-----
> From: Langer, Christoph
> Sent: Mittwoch, 20. Februar 2019 19:40
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; jdk-updates-
> dev at openjdk.java.net; Andrew Haley (aph at redhat.com) <aph at redhat.com>;
> Andrew Hughes (gnu.andrew at redhat.com) <gnu.andrew at redhat.com>;
> Aleksey Shipilev <shade at redhat.com>
> Subject: RE: RFR(XS) [11u]: 8219461: Bump update version for OpenJDK
> jdk11.0.3
> 
> Hi Goetz,
> 
> 
> 
> to me this looks good. The version date seems to be correct, assuming that
> 15th of April is the planned release day. Interestingly enough, Oracle did not
> do the bump to jdk12 12.0.1 in the jdk12u repository yet. I assume they only
> do it in their release repositories and the master update repository gets the
> change when merging it back.
> 
> 
> 
> Best regards
> 
> Christoph
> 
> 
> 
> From: Lindenmaier, Goetz
> Sent: Mittwoch, 20. Februar 2019 18:05
> To: jdk-updates-dev at openjdk.java.net; Andrew Haley (aph at redhat.com)
> <aph at redhat.com>; Andrew Hughes (gnu.andrew at redhat.com)
> <gnu.andrew at redhat.com>; Langer, Christoph <christoph.langer at sap.com>;
> Aleksey Shipilev <shade at redhat.com>
> Subject: RFR(XS) [11u]: 8219461: Bump update version for OpenJDK jdk11.0.3
> 
> 
> 
> Hi,
> 
> 
> 
> I think we should bump the version:
> 
> http://cr.openjdk.java.net/~goetz/wr19/8219461-11.0.3_version/01/
> 
> (In 11.0.4, this should be one of the first changes I think)
> 
> 
> 
> See also
> 
> http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/2be95a1bf508
> 
> http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/1353ec839c82
> 
> 
> 
> What date should we use? The date Oracle will deliver it's update?
> 
> Did I miss a version field to be bumped?
> 
> 
> 
> Best regards,
> 
>   Goetz.
> 
> 


From sean.coffey at oracle.com  Thu Feb 21 08:41:27 2019
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Thu, 21 Feb 2019 08:41:27 +0000
Subject: RFR: JDK11U JDK-8206120, JDK-8211398, JDK-8218915
In-Reply-To: <672daacf-f12e-47a5-af14-b7ac054a3f1c@default>
References: <831af84c-5aa2-44de-b9e4-b5e7aeb876ef@default>
 <fa5ad573-675f-c009-d1fe-e0a90bc07b96@oracle.com>
 <7ac824c2-7299-47a6-92fd-7c7e1238ec97@default>
 <36b3dc85-ceaf-eb34-06ef-4cf5c890813a@oracle.com>
 <672daacf-f12e-47a5-af14-b7ac054a3f1c@default>
Message-ID: <1bfebd99-bbf4-0a6c-e0e3-7dd8cda73911@oracle.com>

Deepak,

this exception message in new test still needs correction:

>   166                         "Character.isLetter(int) failed for codepoint "
>   167                                 + Integer.toHexString(cp));
As an aside, there's probably no need for such specific exception 
messages in a test case. It's error prone (but you've come this far now)

regards,
Sean.

On 21/02/2019 08:26, Deepak Kejriwal wrote:
> Hi Naoto,
>
> Corrected the exception message. Please find below updated version of webrev:-
> http://cr.openjdk.java.net/~rpatil/JapaneseEra_changes_11u/webrev.02/
>
> Thanks for review.
>
> Regards,
> Deepak
>
> -----Original Message-----
> From: Naoto Sato
> Sent: Wednesday, February 20, 2019 11:06 PM
> To: Deepak Kejriwal <deepak.kejriwal at oracle.com>; Sean Coffey <sean.coffey at oracle.com>; core-libs-dev <core-libs-dev at openjdk.java.net>; jdk-updates-dev at openjdk.java.net
> Subject: Re: RFR: JDK11U JDK-8206120, JDK-8211398, JDK-8218915
>
> Hi Deepak,
>
> I see the following comment is not addressed yet:
>
>   > - Line 163,198: Exception messages are incorrect. they are for isJavaIdentifierStart().
>
> Naoto
>
> On 2/20/19 8:53 AM, Deepak Kejriwal wrote:
>> Thanks Naoto San and Sean for review. I have incorporate all the
>> comments. Please find below updated version of webrev :-
>>
>> http://cr.openjdk.java.net/~rpatil/JapaneseEra_changes_11u/webrev.01/
>>
>> Regards,
>> Deepak
>>
>> -----Original Message-----
>> From: Naoto Sato
>> Sent: Tuesday, February 19, 2019 10:23 PM
>> To: Deepak Kejriwal <deepak.kejriwal at oracle.com>; core-libs-dev
>> <core-libs-dev at openjdk.java.net>; jdk-updates-dev at openjdk.java.net
>> Subject: Re: RFR: JDK11U JDK-8206120, JDK-8211398, JDK-8218915
>>
>> Hi Deepak,
>>
>> Here are my comments to the webrev (other than what Sean pointed out):
>>
>> TestIsJavaIdentifierMethods.java
>>
>> - @summary: "testIsJavaLetter" -> "isJavaLetter", "testIsJavaLetterOrDigit" -> "isJavaLetterOrDigit".
>>
>> - Line 34: "newCodePoint" does not represent the era character, as "new"
>> is subjective. It will become moot in the year 2020. How about "JAPANESE_ERA_CODEPOINT"?
>>
>> - Line 67,68,(...all the comments): Reflect the above change to the comments.
>>
>> - Line 103: "All Unicode chars (0x0000..0xFFFF)" does not sound correct.
>> It may be "All Unicode code points in the BMP (0x0000..0xFFFF), and remove extra period at the end. This applies to other method descriptions.
>>
>> - Line 104: The test case returns "void", what does this "Expected results" mean?
>>
>> - Line 140-142,174-176: The condition statement in the document is different from JDK11's javadoc. In the API doc, it is (in case of int):
>>
>>       isLetter(codePoint) returns true
>>       getType(codePoint) returns LETTER_NUMBER
>>       the referenced character is a currency symbol (such as '$')
>>       the referenced character is a connecting punctuation character (such as '_').
>>
>> - Line 163,198: Exception messages are incorrect. they are for isJavaIdentifierStart().
>>
>> Naoto
>>
>>
>> On 2/19/19 6:15 AM, Deepak Kejriwal wrote:
>>> Correcting typo for release.
>>>
>>>     
>>>
>>> From: Deepak Kejriwal <deepak.kejriwal at oracle.com>
>>> Sent: Tuesday, February 19, 2019 7:42 PM
>>> To: 'core-libs-dev' <core-libs-dev at openjdk.java.net>;
>>> 'jdk-updates-dev at openjdk.java.net' <jdk-updates-dev at openjdk.java.net>
>>> Subject: RFR: JDK11U JDK-8206120, JDK-8211398, JDK-8218915
>>>
>>>     
>>>
>>> Hi All,
>>>
>>> Please review the backport of the following bug fixes to jdk11u-dev:
>>>
>>> HYPERLINK
>>> "https://bugs.openjdk.java.net/browse/JDK-8206120"JDK-8206120 : Add
>>> test cases for lenient Japanese era parsing HYPERLINK
>>> "https://bugs.openjdk.java.net/browse/JDK-8211398"JDK-8211398 :
>>> Square character support for the Japanese new era HYPERLINK
>>> "https://bugs.openjdk.java.net/browse/JDK-8218915"JDK-8218915 :
>>> Change isJavaIdentifierStart and isJavaIdentifierPart to handle new
>>> code points
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~rpatil/JapaneseEra_changes_11u/webrev.00/
>>>
>>> These code changes are made possible thanks to specification change already pushed:
>>> http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/c1e1669edace
>>>
>>> Regards,
>>> Deepak
>>>
>>>     
>>>

From shade at redhat.com  Thu Feb 21 08:44:37 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 21 Feb 2019 09:44:37 +0100
Subject: Pending pushes for approved 11u backports
In-Reply-To: <5c48ed37-1667-0564-94ad-529537295a29@arm.com>
References: <7014a3ae-ebac-c7e6-5658-17fc95e4da55@redhat.com>
 <5c48ed37-1667-0564-94ad-529537295a29@arm.com>
Message-ID: <b073ae86-b6f3-c386-e19c-d865ba9f8795@redhat.com>

On 2/21/19 3:27 AM, Ningsheng Jian (Arm Technology China) wrote:
> Hi Aleksey,
> 
> Thanks for doing this!
> 
> Yes, I need sponsor for my jdk11u backport requests. May I ask a sponsor
> for these:
> 
>  >   https://bugs.openjdk.java.net/browse/JDK-8215100
>  >   https://bugs.openjdk.java.net/browse/JDK-8215202

I will sponsor this for you.

-Aleksey


From Ningsheng.Jian at arm.com  Thu Feb 21 08:57:30 2019
From: Ningsheng.Jian at arm.com (Ningsheng Jian (Arm Technology China))
Date: Thu, 21 Feb 2019 08:57:30 +0000
Subject: Pending pushes for approved 11u backports
In-Reply-To: <b073ae86-b6f3-c386-e19c-d865ba9f8795@redhat.com>
References: <7014a3ae-ebac-c7e6-5658-17fc95e4da55@redhat.com>
 <5c48ed37-1667-0564-94ad-529537295a29@arm.com>
 <b073ae86-b6f3-c386-e19c-d865ba9f8795@redhat.com>
Message-ID: <082525a9-46e0-725b-4435-9b39853b4ebb@arm.com>

Thank you Aleksey!

Regards,
Ningsheng

On 02/21/2019 04:44 PM, Aleksey Shipilev wrote:
> On 2/21/19 3:27 AM, Ningsheng Jian (Arm Technology China) wrote:
>> Hi Aleksey,
>>
>> Thanks for doing this!
>>
>> Yes, I need sponsor for my jdk11u backport requests. May I ask a sponsor
>> for these:
>>
>>  >   https://bugs.openjdk.java.net/browse/JDK-8215100
>>  >   https://bugs.openjdk.java.net/browse/JDK-8215202
>
> I will sponsor this for you.
>
> -Aleksey
>

From shade at redhat.com  Thu Feb 21 09:07:37 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 21 Feb 2019 10:07:37 +0100
Subject: How to run tests before pushing a backport changeset?
In-Reply-To: <CA+kOe0-7S+2LZEg+ieb0pbQwb=Jd2XTNqjkPfYQTmN4YS_Jnug@mail.gmail.com>
References: <CA+w6Hxbe+Ye7tqjGxzB8LDHRWZdDLQyT20pWZk_VTDqbc4z4uQ@mail.gmail.com>
 <f2a642ff-ff81-f52e-ea50-13b845d52d15@redhat.com>
 <CA+kOe0-7S+2LZEg+ieb0pbQwb=Jd2XTNqjkPfYQTmN4YS_Jnug@mail.gmail.com>
Message-ID: <7a3048c2-b493-d3d0-970d-394b5e033aa6@redhat.com>

On 2/21/19 4:55 AM, Martin Buchholz wrote:
> On Wed, Feb 20, 2019 at 4:10 PM Aleksey Shipilev <shade at redhat.com <mailto:shade at redhat.com>> wrote:
>     > I read the links on https://openjdk.java.net/projects/jdk-updates/, but couldn't find any
>     > description on testing. Does the backporting process require running such automated tests before
>     > pushing a changeset?
>     I think it is maintainer's duty to decide if testing was enough (this is why Fix Request requires
>     [1] to spell out what testing was done). That said, it seems the more tests you run, the more less
>     chance backport would be problematic.
> 
> I'm surprised to see you say that, because you are the king of build/test automation.
> I prefer to lessen the burden on backport developers and instead invest in better release testing
> automation (e.g. "presubmit queue").

By all means, you are welcome to invest in better release test automation :)

OpenJDK historically relies heavily on developers doing pre-integration testing themselves, and the
bulk of tests are running in post-integration time. JDK Updates project is not the exception to
this. Maybe Skara would make it better, but this remains to be seen.

There are many tests and test suites to choose from, "tier1" seems to be universally used as the
go-to pre-integration test suite. If tier1 fails, it is likely every other developer would complain
about bugs once you push. If tier1 passes, it is likely there are no bugs on frequent product paths.

-Aleksey



From christoph.langer at sap.com  Thu Feb 21 09:11:08 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 21 Feb 2019 09:11:08 +0000
Subject: RFR(XS) [11u]: 8219461: Bump update version for OpenJDK jdk11.0.3
In-Reply-To: <b778ed5b672a4a67b1efdccb171edc7f@sap.com>
References: <c97bd7a4da26482c843cac3386b9f7c3@sap.com>
 <9df55968e4bc48bba0ff91c342b264f7@sap.com>
 <b778ed5b672a4a67b1efdccb171edc7f@sap.com>
Message-ID: <62050729d179451a9bd3c410782cebbc@sap.com>

Hi Goetz,

> > The version date seems to be correct, assuming that
> > 15th of April is the planned release day.
> It's 4/16: https://www.oracle.com/technetwork/topics/security/alerts-
> 086861.html
> Fixed webrev:
> http://cr.openjdk.java.net/~goetz/wr19/8219461-11.0.3_version/02/

Thanks for looking it up and fixing ??

> But the question is more
>  - do we want to set a date at all?
>  - do we want to set the same date as Oracle?

I think so. See this bug: https://bugs.openjdk.java.net/browse/JDK-8217247 

> > Oracle did not do the bump to jdk12 12.0.1 in the jdk12u repository yet.
> I assume we can not see the change that bumps the version to 12.0.1.
> I also looked for the change that bumps the version to 11.0.3-oracle, but
> could not find that either. But the bugs for the version bumps for 11.0.1 and
> 11.0.2 are
> not visible either, see the changes I referenced.

Yes, I think the JBS bugs would not be visible and the changes have already been done in Oracle's internal repository. But they'll only appear in the open repos once Oracle integrates their release works back to the open which will be on the release day or shortly after that obviously...

/Christoph


From deepak.kejriwal at oracle.com  Thu Feb 21 09:10:21 2019
From: deepak.kejriwal at oracle.com (Deepak Kejriwal)
Date: Thu, 21 Feb 2019 01:10:21 -0800 (PST)
Subject: RFR: JDK11U JDK-8206120, JDK-8211398, JDK-8218915
In-Reply-To: <1bfebd99-bbf4-0a6c-e0e3-7dd8cda73911@oracle.com>
References: <831af84c-5aa2-44de-b9e4-b5e7aeb876ef@default>
 <fa5ad573-675f-c009-d1fe-e0a90bc07b96@oracle.com>
 <7ac824c2-7299-47a6-92fd-7c7e1238ec97@default>
 <36b3dc85-ceaf-eb34-06ef-4cf5c890813a@oracle.com>
 <672daacf-f12e-47a5-af14-b7ac054a3f1c@default>
 <1bfebd99-bbf4-0a6c-e0e3-7dd8cda73911@oracle.com>
Message-ID: <62567a03-7473-4651-b1b3-a338629c6666@default>

Hi Sean,

?

The webrev I shared was not correct. I have corrected the webrev.02 now. Please check now:-

http://cr.openjdk.java.net/~rpatil/JapaneseEra_changes_11u/webrev.02/

?

Regards,

Deepak

?

From: Se?n Coffey 
Sent: Thursday, February 21, 2019 2:11 PM
To: Deepak Kejriwal <deepak.kejriwal at oracle.com>; Naoto Sato <naoto.sato at oracle.com>; core-libs-dev <core-libs-dev at openjdk.java.net>; jdk-updates-dev at openjdk.java.net
Subject: Re: RFR: JDK11U JDK-8206120, JDK-8211398, JDK-8218915

?

Deepak, 

this exception message in new test still needs correction:

 166???????????????????????? "Character.isLetter(int) failed for codepoint "
 167???????????????????????????????? + Integer.toHexString(cp));

As an aside, there's probably no need for such specific exception messages in a test case. It's error prone (but you've come this far now)

regards,
Sean.

On 21/02/2019 08:26, Deepak Kejriwal wrote:

Hi Naoto,
?
Corrected the exception message. Please find below updated version of webrev:-
http://cr.openjdk.java.net/~rpatil/JapaneseEra_changes_11u/webrev.02/
?
Thanks for review.
?
Regards,
Deepak
?
-----Original Message-----
From: Naoto Sato 
Sent: Wednesday, February 20, 2019 11:06 PM
To: Deepak Kejriwal HYPERLINK "mailto:deepak.kejriwal at oracle.com"<deepak.kejriwal at oracle.com>; Sean Coffey HYPERLINK "mailto:sean.coffey at oracle.com"<sean.coffey at oracle.com>; core-libs-dev HYPERLINK "mailto:core-libs-dev at openjdk.java.net"<core-libs-dev at openjdk.java.net>; HYPERLINK "mailto:jdk-updates-dev at openjdk.java.net"jdk-updates-dev at openjdk.java.net
Subject: Re: RFR: JDK11U JDK-8206120, JDK-8211398, JDK-8218915
?
Hi Deepak,
?
I see the following comment is not addressed yet:
?
 > - Line 163,198: Exception messages are incorrect. they are for isJavaIdentifierStart().
?
Naoto
?
On 2/20/19 8:53 AM, Deepak Kejriwal wrote:

Thanks Naoto San and Sean for review. I have incorporate all the 
comments. Please find below updated version of webrev :-
?
http://cr.openjdk.java.net/~rpatil/JapaneseEra_changes_11u/webrev.01/
?
Regards,
Deepak
?
-----Original Message-----
From: Naoto Sato
Sent: Tuesday, February 19, 2019 10:23 PM
To: Deepak Kejriwal HYPERLINK "mailto:deepak.kejriwal at oracle.com"<deepak.kejriwal at oracle.com>; core-libs-dev 
HYPERLINK "mailto:core-libs-dev at openjdk.java.net"<core-libs-dev at openjdk.java.net>; HYPERLINK "mailto:jdk-updates-dev at openjdk.java.net"jdk-updates-dev at openjdk.java.net
Subject: Re: RFR: JDK11U JDK-8206120, JDK-8211398, JDK-8218915
?
Hi Deepak,
?
Here are my comments to the webrev (other than what Sean pointed out):
?
TestIsJavaIdentifierMethods.java
?
- @summary: "testIsJavaLetter" -> "isJavaLetter", "testIsJavaLetterOrDigit" -> "isJavaLetterOrDigit".
?
- Line 34: "newCodePoint" does not represent the era character, as "new"
is subjective. It will become moot in the year 2020. How about "JAPANESE_ERA_CODEPOINT"?
?
- Line 67,68,(...all the comments): Reflect the above change to the comments.
?
- Line 103: "All Unicode chars (0x0000..0xFFFF)" does not sound correct.
It may be "All Unicode code points in the BMP (0x0000..0xFFFF), and remove extra period at the end. This applies to other method descriptions.
?
- Line 104: The test case returns "void", what does this "Expected results" mean?
?
- Line 140-142,174-176: The condition statement in the document is different from JDK11's javadoc. In the API doc, it is (in case of int):
?
???? isLetter(codePoint) returns true
???? getType(codePoint) returns LETTER_NUMBER
???? the referenced character is a currency symbol (such as '$')
???? the referenced character is a connecting punctuation character (such as '_').
?
- Line 163,198: Exception messages are incorrect. they are for isJavaIdentifierStart().
?
Naoto
?
?
On 2/19/19 6:15 AM, Deepak Kejriwal wrote:

Correcting typo for release.
?
?? 
?
From: Deepak Kejriwal HYPERLINK "mailto:deepak.kejriwal at oracle.com"<deepak.kejriwal at oracle.com>
Sent: Tuesday, February 19, 2019 7:42 PM
To: 'core-libs-dev' HYPERLINK "mailto:core-libs-dev at openjdk.java.net"<core-libs-dev at openjdk.java.net>; 
'HYPERLINK "mailto:jdk-updates-dev at openjdk.java.net"jdk-updates-dev at openjdk.java.net' HYPERLINK "mailto:jdk-updates-dev at openjdk.java.net"<jdk-updates-dev at openjdk.java.net>
Subject: RFR: JDK11U JDK-8206120, JDK-8211398, JDK-8218915
?
?? 
?
Hi All,
?
Please review the backport of the following bug fixes to jdk11u-dev:
?
HYPERLINK
HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8206120""https://bugs.openjdk.java.net/browse/JDK-8206120"JDK-8206120 : Add 
test cases for lenient Japanese era parsing HYPERLINK
HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8211398""https://bugs.openjdk.java.net/browse/JDK-8211398"JDK-8211398 : 
Square character support for the Japanese new era HYPERLINK
HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8218915""https://bugs.openjdk.java.net/browse/JDK-8218915"JDK-8218915 : 
Change isJavaIdentifierStart and isJavaIdentifierPart to handle new 
code points
?
Webrev:
http://cr.openjdk.java.net/~rpatil/JapaneseEra_changes_11u/webrev.00/
?
These code changes are made possible thanks to specification change already pushed:
http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/c1e1669edace
?
Regards,
Deepak
?
?? 
?

From aph at redhat.com  Thu Feb 21 09:28:42 2019
From: aph at redhat.com (Andrew Haley)
Date: Thu, 21 Feb 2019 09:28:42 +0000
Subject: How to run tests before pushing a backport changeset?
In-Reply-To: <7a3048c2-b493-d3d0-970d-394b5e033aa6@redhat.com>
References: <CA+w6Hxbe+Ye7tqjGxzB8LDHRWZdDLQyT20pWZk_VTDqbc4z4uQ@mail.gmail.com>
 <f2a642ff-ff81-f52e-ea50-13b845d52d15@redhat.com>
 <CA+kOe0-7S+2LZEg+ieb0pbQwb=Jd2XTNqjkPfYQTmN4YS_Jnug@mail.gmail.com>
 <7a3048c2-b493-d3d0-970d-394b5e033aa6@redhat.com>
Message-ID: <3371d68c-d6ea-7e03-85d2-0b6cfa09b54d@redhat.com>

On 2/21/19 9:07 AM, Aleksey Shipilev wrote:
> On 2/21/19 4:55 AM, Martin Buchholz wrote:
>> On Wed, Feb 20, 2019 at 4:10 PM Aleksey Shipilev <shade at redhat.com <mailto:shade at redhat.com>> wrote:

>>     > I read the links on
>>     > https://openjdk.java.net/projects/jdk-updates/, but couldn't
>>     > find any description on testing. Does the backporting process
>>     > require running such automated tests before pushing a
>>     > changeset?

>>     I think it is maintainer's duty to decide if testing was enough
>>     (this is why Fix Request requires [1] to spell out what testing
>>     was done). That said, it seems the more tests you run, the more
>>     less chance backport would be problematic.

>> I'm surprised to see you say that, because you are the king of
>> build/test automation.  I prefer to lessen the burden on backport
>> developers and instead invest in better release testing automation
>> (e.g. "presubmit queue").
> 
> By all means, you are welcome to invest in better release test
> automation :)
>
> OpenJDK historically relies heavily on developers doing
> pre-integration testing themselves, and the bulk of tests are
> running in post-integration time. JDK Updates project is not the
> exception to this. Maybe Skara would make it better, but this
> remains to be seen.
> 
> There are many tests and test suites to choose from, "tier1" seems
> to be universally used as the go-to pre-integration test suite. If
> tier1 fails, it is likely every other developer would complain about
> bugs once you push. If tier1 passes, it is likely there are no bugs
> on frequent product paths.

Yes, and we'd like to work with AdoptOpenJDK to integrate their testing
into the OpenJDK workflow. It's a work in progress.

-- 
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 sean.coffey at oracle.com  Thu Feb 21 10:24:17 2019
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Thu, 21 Feb 2019 10:24:17 +0000
Subject: RFR: JDK11U JDK-8206120, JDK-8211398, JDK-8218915
In-Reply-To: <62567a03-7473-4651-b1b3-a338629c6666@default>
References: <831af84c-5aa2-44de-b9e4-b5e7aeb876ef@default>
 <fa5ad573-675f-c009-d1fe-e0a90bc07b96@oracle.com>
 <7ac824c2-7299-47a6-92fd-7c7e1238ec97@default>
 <36b3dc85-ceaf-eb34-06ef-4cf5c890813a@oracle.com>
 <672daacf-f12e-47a5-af14-b7ac054a3f1c@default>
 <1bfebd99-bbf4-0a6c-e0e3-7dd8cda73911@oracle.com>
 <62567a03-7473-4651-b1b3-a338629c6666@default>
Message-ID: <400181fb-4e53-3a84-7cc6-cca85bc7207b@oracle.com>

Thanks. Looks good to me.

regards,
Sean.

On 21/02/2019 09:10, Deepak Kejriwal wrote:
>
> Hi Sean,
>
> The webrev I shared was not correct. I have corrected the webrev.02 
> now. Please check now:-
>
> http://cr.openjdk.java.net/~rpatil/JapaneseEra_changes_11u/webrev.02/
>
> Regards,
>
> Deepak
>
> *From:*Se?n Coffey
> *Sent:* Thursday, February 21, 2019 2:11 PM
> *To:* Deepak Kejriwal <deepak.kejriwal at oracle.com>; Naoto Sato 
> <naoto.sato at oracle.com>; core-libs-dev 
> <core-libs-dev at openjdk.java.net>; jdk-updates-dev at openjdk.java.net
> *Subject:* Re: RFR: JDK11U JDK-8206120, JDK-8211398, JDK-8218915
>
> Deepak,
>
> this exception message in new test still needs correction:
>
>       166???????????????????????? "Character.isLetter(int) failed for codepoint "
>
>       167???????????????????????????????? + Integer.toHexString(cp));
>
> As an aside, there's probably no need for such specific exception 
> messages in a test case. It's error prone (but you've come this far now)
>
> regards,
> Sean.
>
> On 21/02/2019 08:26, Deepak Kejriwal wrote:
>
>     Hi Naoto,
>
>     Corrected the exception message. Please find below updated version of webrev:-
>
>     http://cr.openjdk.java.net/~rpatil/JapaneseEra_changes_11u/webrev.02/
>
>     Thanks for review.
>
>     Regards,
>
>     Deepak
>
>     -----Original Message-----
>
>     From: Naoto Sato
>
>     Sent: Wednesday, February 20, 2019 11:06 PM
>
>     To: Deepak Kejriwal<deepak.kejriwal at oracle.com>  <mailto:deepak.kejriwal at oracle.com>; Sean Coffey<sean.coffey at oracle.com>  <mailto:sean.coffey at oracle.com>; core-libs-dev<core-libs-dev at openjdk.java.net>  <mailto:core-libs-dev at openjdk.java.net>;jdk-updates-dev at openjdk.java.net  <mailto:jdk-updates-dev at openjdk.java.net>
>
>     Subject: Re: RFR: JDK11U JDK-8206120, JDK-8211398, JDK-8218915
>
>     Hi Deepak,
>
>     I see the following comment is not addressed yet:
>
>       > - Line 163,198: Exception messages are incorrect. they are for isJavaIdentifierStart().
>
>     Naoto
>
>     On 2/20/19 8:53 AM, Deepak Kejriwal wrote:
>
>         Thanks Naoto San and Sean for review. I have incorporate all the
>
>         comments. Please find below updated version of webrev :-
>
>         http://cr.openjdk.java.net/~rpatil/JapaneseEra_changes_11u/webrev.01/
>
>         Regards,
>
>         Deepak
>
>         -----Original Message-----
>
>         From: Naoto Sato
>
>         Sent: Tuesday, February 19, 2019 10:23 PM
>
>         To: Deepak Kejriwal<deepak.kejriwal at oracle.com>  <mailto:deepak.kejriwal at oracle.com>; core-libs-dev
>
>         <core-libs-dev at openjdk.java.net>  <mailto:core-libs-dev at openjdk.java.net>;jdk-updates-dev at openjdk.java.net  <mailto:jdk-updates-dev at openjdk.java.net>
>
>         Subject: Re: RFR: JDK11U JDK-8206120, JDK-8211398, JDK-8218915
>
>         Hi Deepak,
>
>         Here are my comments to the webrev (other than what Sean pointed out):
>
>         TestIsJavaIdentifierMethods.java
>
>         - @summary: "testIsJavaLetter" -> "isJavaLetter", "testIsJavaLetterOrDigit" -> "isJavaLetterOrDigit".
>
>         - Line 34: "newCodePoint" does not represent the era character, as "new"
>
>         is subjective. It will become moot in the year 2020. How about "JAPANESE_ERA_CODEPOINT"?
>
>         - Line 67,68,(...all the comments): Reflect the above change to the comments.
>
>         - Line 103: "All Unicode chars (0x0000..0xFFFF)" does not sound correct.
>
>         It may be "All Unicode code points in the BMP (0x0000..0xFFFF), and remove extra period at the end. This applies to other method descriptions.
>
>         - Line 104: The test case returns "void", what does this "Expected results" mean?
>
>         - Line 140-142,174-176: The condition statement in the document is different from JDK11's javadoc. In the API doc, it is (in case of int):
>
>          ???? isLetter(codePoint) returns true
>
>          ???? getType(codePoint) returns LETTER_NUMBER
>
>          ???? the referenced character is a currency symbol (such as '$')
>
>          ???? the referenced character is a connecting punctuation character (such as '_').
>
>         - Line 163,198: Exception messages are incorrect. they are for isJavaIdentifierStart().
>
>         Naoto
>
>         On 2/19/19 6:15 AM, Deepak Kejriwal wrote:
>
>             Correcting typo for release.
>
>                 
>
>             From: Deepak Kejriwal<deepak.kejriwal at oracle.com>  <mailto:deepak.kejriwal at oracle.com>
>
>             Sent: Tuesday, February 19, 2019 7:42 PM
>
>             To: 'core-libs-dev'<core-libs-dev at openjdk.java.net>  <mailto:core-libs-dev at openjdk.java.net>;
>
>             'jdk-updates-dev at openjdk.java.net  <mailto:jdk-updates-dev at openjdk.java.net>'<jdk-updates-dev at openjdk.java.net>  <mailto:jdk-updates-dev at openjdk.java.net>
>
>             Subject: RFR: JDK11U JDK-8206120, JDK-8211398, JDK-8218915
>
>                 
>
>             Hi All,
>
>             Please review the backport of the following bug fixes to jdk11u-dev:
>
>             HYPERLINK
>
>             "https://bugs.openjdk.java.net/browse/JDK-8206120"  <https://bugs.openjdk.java.net/browse/JDK-8206120>JDK-8206120 : Add
>
>             test cases for lenient Japanese era parsing HYPERLINK
>
>             "https://bugs.openjdk.java.net/browse/JDK-8211398"  <https://bugs.openjdk.java.net/browse/JDK-8211398>JDK-8211398 :
>
>             Square character support for the Japanese new era HYPERLINK
>
>             "https://bugs.openjdk.java.net/browse/JDK-8218915"  <https://bugs.openjdk.java.net/browse/JDK-8218915>JDK-8218915 :
>
>             Change isJavaIdentifierStart and isJavaIdentifierPart to handle new
>
>             code points
>
>             Webrev:
>
>             http://cr.openjdk.java.net/~rpatil/JapaneseEra_changes_11u/webrev.00/
>
>             These code changes are made possible thanks to specification change already pushed:
>
>             http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/c1e1669edace
>
>             Regards,
>
>             Deepak
>
>                 
>

From christoph.langer at sap.com  Thu Feb 21 10:24:45 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 21 Feb 2019 10:24:45 +0000
Subject: RFR+RFA [11u]: 8215175: Inconsistencies in JFR event metadata
In-Reply-To: <5C6D76C3.4060407@oracle.com>
References: <39c61f78c7e4476a9c4828095fd5e404@sap.com>
 <5C6D76C3.4060407@oracle.com>
Message-ID: <ef8500fa531a417bbc2cd84174520991@sap.com>

Hi,

it turned out that I had to modify the test test/jdk/jdk/jfr/api/metadata/annotations/TestFormatMissingValue.java a little bit to make it pass. PrettyWriter in jdk/jdk is a bit more modern.

Please check my updated webrev: http://cr.openjdk.java.net/~clanger/webrevs/8215175.jdk11u.1/ 

I modified the "assertContains" checks and added a comment.

After that I think I'm good to push the stack of 8165675, 8213966, 8215175 and 8215362 to 11u. The nightly testsuite did not show further regressions in JFR.

Thanks
Christoph

> -----Original Message-----
> From: hotspot-jfr-dev <hotspot-jfr-dev-bounces at openjdk.java.net> On
> Behalf Of Erik Gahlin
> Sent: Mittwoch, 20. Februar 2019 16:48
> To: hotspot-jfr-dev at openjdk.java.net
> Subject: Re: RFR+RFA [11u]: 8215175: Inconsistencies in JFR event metadata
> 
> Great minds think alike. I did something similar for Oracle JDK.
> 
> Not exactly the same down to white spaces and line breaks, but it will
> result in the same output, which is what matters for users and Mission
> Control.
> 
> Erik
> 
> > Hi,
> >
> > and another one...
> >
> > May I please get reviews for the downport of 8215175 to jdk11u.
> >
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8215175
> > Original Change: http://hg.openjdk.java.net/jdk/jdk/rev/c8b2a408628b
> > Backport Webrev:
> http://cr.openjdk.java.net/~clanger/webrevs/8215175.jdk11u/
> >
> > The patch did not apply cleanly.
> >
> > src/hotspot/share/jfr/metadata/metadata.xml had some fuzz but change
> is effectively the same as the original one.
> > src/jdk.jfr/share/classes/jdk/jfr/internal/Utils.java also failed. I copied the
> changed methods from the code that can be found in jdk/jdk currently.
> > src/jdk.jfr/share/classes/jdk/jfr/internal/tool/PrettyWriter.java does not
> exist because of the missing jfr tool. So patch could obviously not be applied
> to that file.
> >
> > I'll run the full test suite before pushing.
> >
> > Best regards
> > Christoph
> >


From shade at redhat.com  Thu Feb 21 10:41:58 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 21 Feb 2019 11:41:58 +0100
Subject: Pending pushes for approved 11u backports
In-Reply-To: <005a549e-18f1-e948-78df-abc64f171e8b@redhat.com>
References: <7014a3ae-ebac-c7e6-5658-17fc95e4da55@redhat.com>
 <OF1B930E62.46AF257C-ON002583A7.007F731F-492583A7.007FA643@notes.na.collabserv.com>
 <005a549e-18f1-e948-78df-abc64f171e8b@redhat.com>
Message-ID: <13833897-b11b-fce2-527b-e73af6c1d811@redhat.com>

On 2/21/19 1:01 AM, Aleksey Shipilev wrote:
> On 2/21/19 12:14 AM, Toshio 5 Nakamura wrote:
>> Hi Aleksey,
>>
>> Yes, may I ask a sponsor for these requests?
>>
>>> Toshio Nakamura: You need sponsor for this, right? You don't have
>>> JDK Updates privileges in Census.
>>> ? https://bugs.openjdk.java.net/browse/JDK-8213183
>>> ? https://bugs.openjdk.java.net/browse/JDK-8211267
> 
> No problem, I would sponsor these for you tomorrow.

Pushed to 11u. Toshio, please look at JDK-8211267, should it be in 12u as well? If so, please work
with 12u update process to get it approved. I can push this to 12u once approved.

-Aleksey



From shade at redhat.com  Thu Feb 21 12:08:25 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 21 Feb 2019 13:08:25 +0100
Subject: Pending pushes for approved 11u backports
In-Reply-To: <b073ae86-b6f3-c386-e19c-d865ba9f8795@redhat.com>
References: <7014a3ae-ebac-c7e6-5658-17fc95e4da55@redhat.com>
 <5c48ed37-1667-0564-94ad-529537295a29@arm.com>
 <b073ae86-b6f3-c386-e19c-d865ba9f8795@redhat.com>
Message-ID: <6cb90ceb-a030-bd25-1bb6-d4a47d0a8c90@redhat.com>

On 2/21/19 9:44 AM, Aleksey Shipilev wrote:
> On 2/21/19 3:27 AM, Ningsheng Jian (Arm Technology China) wrote:
>> Yes, I need sponsor for my jdk11u backport requests. May I ask a sponsor
>> for these:
>>
>>  >   https://bugs.openjdk.java.net/browse/JDK-8215100
>>  >   https://bugs.openjdk.java.net/browse/JDK-8215202
> 
> I will sponsor this for you.

Pushed to 11u. I did some testing on x86_64, and only a few spot checks on AArch64.
Please consider running tests for current 11u on ARM machines you certainly have around? :)

-Aleksey


From TOSHIONA at jp.ibm.com  Thu Feb 21 12:38:13 2019
From: TOSHIONA at jp.ibm.com (Toshio 5 Nakamura)
Date: Thu, 21 Feb 2019 21:38:13 +0900
Subject: Pending pushes for approved 11u backports
In-Reply-To: <13833897-b11b-fce2-527b-e73af6c1d811@redhat.com>
References: <7014a3ae-ebac-c7e6-5658-17fc95e4da55@redhat.com>
 <OF1B930E62.46AF257C-ON002583A7.007F731F-492583A7.007FA643@notes.na.collabserv.com>
 <005a549e-18f1-e948-78df-abc64f171e8b@redhat.com>
 <13833897-b11b-fce2-527b-e73af6c1d811@redhat.com>
Message-ID: <OF1DB419C8.0750B377-ON002583A8.0044F552-492583A8.00456AFB@notes.na.collabserv.com>


Thank you so much for your support, Aleksey.
I've verified them on 11u, also JDK-8211267 started 12u process.

Thanks,
Toshio Nakamura

Aleksey Shipilev <shade at redhat.com> wrote on 2019/02/21 19:41:58:

> From: Aleksey Shipilev <shade at redhat.com>
> To: Toshio 5 Nakamura <TOSHIONA at jp.ibm.com>
> Cc: "jdk-updates-dev at openjdk.java.net" <jdk-updates-dev at openjdk.java.net>
> Date: 2019/02/21 19:42
> Subject: Re: Pending pushes for approved 11u backports
>
> On 2/21/19 1:01 AM, Aleksey Shipilev wrote:
> > On 2/21/19 12:14 AM, Toshio 5 Nakamura wrote:
> >> Hi Aleksey,
> >>
> >> Yes, may I ask a sponsor for these requests?
> >>
> >>> Toshio Nakamura: You need sponsor for this, right? You don't have
> >>> JDK Updates privileges in Census.
> >>> ? https://bugs.openjdk.java.net/browse/JDK-8213183
> >>> ? https://bugs.openjdk.java.net/browse/JDK-8211267
> >
> > No problem, I would sponsor these for you tomorrow.
>
> Pushed to 11u. Toshio, please look at JDK-8211267, should it be in
> 12u as well? If so, please work
> with 12u update process to get it approved. I can push this to 12u
> once approved.
>
> -Aleksey
>
>
> [attachment "signature.asc" deleted by Toshio 5 Nakamura/Japan/IBM]

From Ningsheng.Jian at arm.com  Thu Feb 21 02:27:06 2019
From: Ningsheng.Jian at arm.com (Ningsheng Jian (Arm Technology China))
Date: Thu, 21 Feb 2019 02:27:06 +0000
Subject: Pending pushes for approved 11u backports
In-Reply-To: <7014a3ae-ebac-c7e6-5658-17fc95e4da55@redhat.com>
References: <7014a3ae-ebac-c7e6-5658-17fc95e4da55@redhat.com>
Message-ID: <5c48ed37-1667-0564-94ad-529537295a29@arm.com>

Hi Aleksey,

Thanks for doing this!

Yes, I need sponsor for my jdk11u backport requests. May I ask a sponsor 
for these:

 >   https://bugs.openjdk.java.net/browse/JDK-8215100
 >   https://bugs.openjdk.java.net/browse/JDK-8215202

Thanks,
Ningsheng


On 02/21/2019 02:10 AM, Aleksey Shipilev wrote:
> Hi,
>
> I have generated "orphans" report for issues that have jdk11u-fix-yes set, but have no actual commits:
>   https://builds.shipilev.net/backports-monitor/orphans-11.txt
>
> Looking at this report, I see there are pushes to be done. I have CC'ed original Fix Requesters.
>
> Note: normally, the persons who put Fix Requests should be active and find the sponsor for the push.
> But, we also want to wrap up 11.0.3 sooner rather than later without missing simple patches, so
> consider this reminder the one-time thing :)
>
> Ningsheng Jian: You need sponsor for this, right? You don't have JDK Updates privileges in Census.
>   https://bugs.openjdk.java.net/browse/JDK-8215100
>   https://bugs.openjdk.java.net/browse/JDK-8215202
>
> Jamil Nimeh (and Andrew Haley): Does this still apply to 11u? Andrew, do you still want it in 11.0.3?
>   https://bugs.openjdk.java.net/browse/JDK-8210989
>
> Toshio Nakamura: You need sponsor for this, right? You don't have JDK Updates privileges in Census.
>   https://bugs.openjdk.java.net/browse/JDK-8213183
>   https://bugs.openjdk.java.net/browse/JDK-8211267
>
> Man Cao: You need sponsor for this, right? You don't have JDK Updates privileges in Census. I would
> prefer this to land to 12u as well.
>   https://bugs.openjdk.java.net/browse/JDK-8218192
>
> Martin Buchholz: I think you are all set. Please check it passes tier1 on current 11u?
>   https://bugs.openjdk.java.net/browse/JDK-8212233
>
> Others are between me and Christoph, and I know they are on track.
>
> Thanks,
> -Aleksey
>

From goetz.lindenmaier at sap.com  Thu Feb 21 13:45:03 2019
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Thu, 21 Feb 2019 13:45:03 +0000
Subject: RFR+RFA [11u]: 8215175: Inconsistencies in JFR event metadata
In-Reply-To: <ef8500fa531a417bbc2cd84174520991@sap.com>
References: <39c61f78c7e4476a9c4828095fd5e404@sap.com>
 <5C6D76C3.4060407@oracle.com> <ef8500fa531a417bbc2cd84174520991@sap.com>
Message-ID: <bcb48dd1bd944b1ead8891424ea30bb1@sap.com>

Hi,

the changes to the test look good. 
Also the few edits in the rest of the code wrt. the original
make sense.

Best regards,
  Goetz.

> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> Behalf Of Langer, Christoph
> Sent: Donnerstag, 21. Februar 2019 11:25
> To: Erik Gahlin <erik.gahlin at oracle.com>; hotspot-jfr-dev at openjdk.java.net;
> Aleksey Shipilev <shade at redhat.com>
> Cc: jdk-updates-dev at openjdk.java.net
> Subject: [CAUTION] RE: RFR+RFA [11u]: 8215175: Inconsistencies in JFR event
> metadata
> 
> Hi,
> 
> it turned out that I had to modify the test
> test/jdk/jdk/jfr/api/metadata/annotations/TestFormatMissingValue.java a
> little bit to make it pass. PrettyWriter in jdk/jdk is a bit more modern.
> 
> Please check my updated webrev:
> http://cr.openjdk.java.net/~clanger/webrevs/8215175.jdk11u.1/
> 
> I modified the "assertContains" checks and added a comment.
> 
> After that I think I'm good to push the stack of 8165675, 8213966, 8215175
> and 8215362 to 11u. The nightly testsuite did not show further regressions in
> JFR.
> 
> Thanks
> Christoph
> 
> > -----Original Message-----
> > From: hotspot-jfr-dev <hotspot-jfr-dev-bounces at openjdk.java.net> On
> > Behalf Of Erik Gahlin
> > Sent: Mittwoch, 20. Februar 2019 16:48
> > To: hotspot-jfr-dev at openjdk.java.net
> > Subject: Re: RFR+RFA [11u]: 8215175: Inconsistencies in JFR event metadata
> >
> > Great minds think alike. I did something similar for Oracle JDK.
> >
> > Not exactly the same down to white spaces and line breaks, but it will
> > result in the same output, which is what matters for users and Mission
> > Control.
> >
> > Erik
> >
> > > Hi,
> > >
> > > and another one...
> > >
> > > May I please get reviews for the downport of 8215175 to jdk11u.
> > >
> > > Bug: https://bugs.openjdk.java.net/browse/JDK-8215175
> > > Original Change: http://hg.openjdk.java.net/jdk/jdk/rev/c8b2a408628b
> > > Backport Webrev:
> > http://cr.openjdk.java.net/~clanger/webrevs/8215175.jdk11u/
> > >
> > > The patch did not apply cleanly.
> > >
> > > src/hotspot/share/jfr/metadata/metadata.xml had some fuzz but change
> > is effectively the same as the original one.
> > > src/jdk.jfr/share/classes/jdk/jfr/internal/Utils.java also failed. I copied the
> > changed methods from the code that can be found in jdk/jdk currently.
> > > src/jdk.jfr/share/classes/jdk/jfr/internal/tool/PrettyWriter.java does not
> > exist because of the missing jfr tool. So patch could obviously not be applied
> > to that file.
> > >
> > > I'll run the full test suite before pushing.
> > >
> > > Best regards
> > > Christoph
> > >


From christoph.langer at sap.com  Thu Feb 21 14:19:08 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 21 Feb 2019 14:19:08 +0000
Subject: CSRs and OpenJDK (11.0.3) Updates
In-Reply-To: <1fde8c4c-9a5c-734b-850f-148330cf3f69@oracle.com>
References: <26321955331640dea328a2f79b39fc29@sap.com>
 <a96ca44d-fb72-1d6a-3830-41edf010bc8a@oracle.com>
 <ab4d13805f264360a18122a092ad6193@sap.com>
 <1fde8c4c-9a5c-734b-850f-148330cf3f69@oracle.com>
Message-ID: <d2cad3b1c5a347a385cce862848bde1b@sap.com>

Hi,

in the sense below I have linked CSR JDK-8215884 to the 11.0.3 backport issue JDK-8219240.

Best regards
Christoph

> -----Original Message-----
> From: David Holmes <david.holmes at oracle.com>
> Sent: Dienstag, 19. Februar 2019 09:11
> To: Langer, Christoph <christoph.langer at sap.com>; jdk-updates-
> dev at openjdk.java.net; Andrew Haley <aph at redhat.com>
> Subject: Re: CSRs and OpenJDK (11.0.3) Updates
> 
> On 19/02/2019 6:08 pm, Langer, Christoph wrote:
> > Hi David,
> >
> >> First, the CSR Group doesn't consist only of Oracle people - Doug Lea is
> >> also a member.
> >
> > Ok, ok, I shot out of my hip ??
> 
> :)
> 
> >> Second, it's unusual to "backport" a CSR request, but may be needed if
> >> the backported fix has different compatibility concerns on the backport
> >> version than the main version. IMHO the backport of the CSR for
> >> 11.0.3-oracle applies exactly the same to 11.0.3 as it does to
> >> 11.0.3-oracle and I would think it a waste of everyone's time to create
> >> a third backport for 11.0.3. But that is for the 11u maintainers to decide.
> >
> > So, do you say, it's not a requirement to downport CSRs but sometimes
> done on the updates maintainers request at their discretion? I was under the
> impression that CSR downports are mandatory. Maybe there's some lack in
> process documentation here?
> 
> If the compatibility concerns of the backport are different to the
> original then it warrants its own CSR (lets not call it a backport-CSR).
> 
> Cheers,
> David
> -----
> 
> > Other than that, I fully agree that it should suffice for OpenJDK update
> downports to refer to Oracle CSR backports for the same update releases.
> >
> > Thanks
> > Christoph
> >

From christoph.langer at sap.com  Thu Feb 21 14:42:41 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 21 Feb 2019 14:42:41 +0000
Subject: 11.0.3 backport work completed
Message-ID: <451f03ea054447659313f522fbce3e63@sap.com>

Hi,

the 11.0.3 backport queue [0] is empty. Thanks to all people involved in getting this done!

I think we should now push the change that bumps the default version to 11.0.3 [1]. Andrew can you approve it?

We should also send the mail to ops, requesting the jdk11u-dev repository, using exactly Rob?s template [2]. Andrew?

And once jdk11u-dev is there, we can start tackling 11.0.4-oracle updates [3]. ??

Thanks and best regards,
Christoph

[0] https://bugs.openjdk.java.net/issues/?filter=36366
[1] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-February/000552.html
[2] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-February/000458.html
[3] https://bugs.openjdk.java.net/browse/JDK-8218479?filter=36409


From shade at redhat.com  Thu Feb 21 15:11:57 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 21 Feb 2019 16:11:57 +0100
Subject: 11.0.3 backport work completed
In-Reply-To: <451f03ea054447659313f522fbce3e63@sap.com>
References: <451f03ea054447659313f522fbce3e63@sap.com>
Message-ID: <8fb18912-8033-051f-015e-13d791504a97@redhat.com>

On 2/21/19 3:42 PM, Langer, Christoph wrote:
> I think we should now push the change that bumps the default version to 11.0.3 [1]. Andrew can you
> approve it?

I think we want orphans to be pushed (wait, that sounded wrong):
  https://builds.shipilev.net/backports-monitor/orphans-11.txt

See another thread "Pending pushes for approved 11u backports". At least, Man Cao's one, since we
have already talked about it.

After that, we want to pass at least one cycle of our own builds and tests.

-Aleksey


From christoph.langer at sap.com  Thu Feb 21 15:31:13 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 21 Feb 2019 15:31:13 +0000
Subject: 11.0.3 backport work completed
In-Reply-To: <8fb18912-8033-051f-015e-13d791504a97@redhat.com>
References: <451f03ea054447659313f522fbce3e63@sap.com>
 <8fb18912-8033-051f-015e-13d791504a97@redhat.com>
Message-ID: <301dfd68329b42079bcc06a8e2ef3144@sap.com>

Hi,

> I think we want orphans to be pushed (wait, that sounded wrong):
>   https://builds.shipilev.net/backports-monitor/orphans-11.txt
> 
> See another thread "Pending pushes for approved 11u backports". At least,
> Man Cao's one, since we
> have already talked about it.
> 
> After that, we want to pass at least one cycle of our own builds and tests.

Ok, that sounds reasonable.

Taking JDK-8215318 aside, as it is a closed change and does not affect OpenJDK, we want to see the following changes still pushed to jdk11u before we branch:

JDK-8218192: Aleksey, you are working with Man, I think?
JDK-8210989: Is Jamil helping with that one? Or will you take it, Aleksey?
JDK-8219461: Once approved we can push it.

It's also a good suggestion, to have a few cycles of builds and tests. We're seeing a few issues in our nightlies, too and might request some fixes in the next days.

How are we handling other incoming jdk11u-fix-requests, that don't tackle regressions? Will we stop approving them until jdk11u-dev is there or at least be very cautious (which is what I suggest)?

Thanks
Christoph


From shade at redhat.com  Thu Feb 21 15:37:21 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 21 Feb 2019 16:37:21 +0100
Subject: 11.0.3 backport work completed
In-Reply-To: <301dfd68329b42079bcc06a8e2ef3144@sap.com>
References: <451f03ea054447659313f522fbce3e63@sap.com>
 <8fb18912-8033-051f-015e-13d791504a97@redhat.com>
 <301dfd68329b42079bcc06a8e2ef3144@sap.com>
Message-ID: <025bc9f0-fa24-8a27-ed1c-7c6e09776824@redhat.com>

On 2/21/19 4:31 PM, Langer, Christoph wrote:
> JDK-8218192: Aleksey, you are working with Man, I think?

Man Cao is on this list. Jiangli would sponsor the fix once Man succeeds with tier1 testing.

> JDK-8210989: Is Jamil helping with that one? Or will you take it, Aleksey?

Silence there. We might want to drop it from 11.0.3 and push it to 11.0.4.

> JDK-8219461: Once approved we can push it.

Yes. I think we can push it, because it does _not_ have to be the last changeset in 11.0.3.

> How are we handling other incoming jdk11u-fix-requests, that don't tackle regressions? Will we
stop approving them until jdk11u-dev is there or at least be very cautious (which is what I suggest)?

I say we stop approving them until the fork is done.

-Aleksey


From naoto.sato at oracle.com  Thu Feb 21 15:48:09 2019
From: naoto.sato at oracle.com (Naoto Sato)
Date: Thu, 21 Feb 2019 07:48:09 -0800
Subject: RFR: JDK11U JDK-8206120, JDK-8211398, JDK-8218915
In-Reply-To: <400181fb-4e53-3a84-7cc6-cca85bc7207b@oracle.com>
References: <831af84c-5aa2-44de-b9e4-b5e7aeb876ef@default>
 <fa5ad573-675f-c009-d1fe-e0a90bc07b96@oracle.com>
 <7ac824c2-7299-47a6-92fd-7c7e1238ec97@default>
 <36b3dc85-ceaf-eb34-06ef-4cf5c890813a@oracle.com>
 <672daacf-f12e-47a5-af14-b7ac054a3f1c@default>
 <1bfebd99-bbf4-0a6c-e0e3-7dd8cda73911@oracle.com>
 <62567a03-7473-4651-b1b3-a338629c6666@default>
 <400181fb-4e53-3a84-7cc6-cca85bc7207b@oracle.com>
Message-ID: <8c9ec321-3ed9-1224-0b51-53b0300cbe13@oracle.com>

+1

Please follow the appropriate process to push the changeset.

Naoto

On 2/21/19 2:24 AM, Se?n Coffey wrote:
> Thanks. Looks good to me.
> 
> regards,
> Sean.
> 
> On 21/02/2019 09:10, Deepak Kejriwal wrote:
>>
>> Hi Sean,
>>
>> The webrev I shared was not correct. I have corrected the webrev.02 
>> now. Please check now:-
>>
>> http://cr.openjdk.java.net/~rpatil/JapaneseEra_changes_11u/webrev.02/
>>
>> Regards,
>>
>> Deepak
>>
>> *From:*Se?n Coffey
>> *Sent:* Thursday, February 21, 2019 2:11 PM
>> *To:* Deepak Kejriwal <deepak.kejriwal at oracle.com>; Naoto Sato 
>> <naoto.sato at oracle.com>; core-libs-dev 
>> <core-libs-dev at openjdk.java.net>; jdk-updates-dev at openjdk.java.net
>> *Subject:* Re: RFR: JDK11U JDK-8206120, JDK-8211398, JDK-8218915
>>
>> Deepak,
>>
>> this exception message in new test still needs correction:
>>
>>       166???????????????????????? "Character.isLetter(int) failed for codepoint "
>>
>>       167???????????????????????????????? + Integer.toHexString(cp));
>>
>> As an aside, there's probably no need for such specific exception 
>> messages in a test case. It's error prone (but you've come this far now)
>>
>> regards,
>> Sean.
>>
>> On 21/02/2019 08:26, Deepak Kejriwal wrote:
>>
>>     Hi Naoto,
>>
>>     Corrected the exception message. Please find below updated version of webrev:-
>>
>>     http://cr.openjdk.java.net/~rpatil/JapaneseEra_changes_11u/webrev.02/
>>
>>     Thanks for review.
>>
>>     Regards,
>>
>>     Deepak
>>
>>     -----Original Message-----
>>
>>     From: Naoto Sato
>>
>>     Sent: Wednesday, February 20, 2019 11:06 PM
>>
>>     To: Deepak Kejriwal<deepak.kejriwal at oracle.com>  <mailto:deepak.kejriwal at oracle.com>; Sean Coffey<sean.coffey at oracle.com>  <mailto:sean.coffey at oracle.com>; core-libs-dev<core-libs-dev at openjdk.java.net>  <mailto:core-libs-dev at openjdk.java.net>;jdk-updates-dev at openjdk.java.net  <mailto:jdk-updates-dev at openjdk.java.net>
>>
>>     Subject: Re: RFR: JDK11U JDK-8206120, JDK-8211398, JDK-8218915
>>
>>     Hi Deepak,
>>
>>     I see the following comment is not addressed yet:
>>
>>       > - Line 163,198: Exception messages are incorrect. they are for isJavaIdentifierStart().
>>
>>     Naoto
>>
>>     On 2/20/19 8:53 AM, Deepak Kejriwal wrote:
>>
>>         Thanks Naoto San and Sean for review. I have incorporate all the
>>
>>         comments. Please find below updated version of webrev :-
>>
>>         http://cr.openjdk.java.net/~rpatil/JapaneseEra_changes_11u/webrev.01/
>>
>>         Regards,
>>
>>         Deepak
>>
>>         -----Original Message-----
>>
>>         From: Naoto Sato
>>
>>         Sent: Tuesday, February 19, 2019 10:23 PM
>>
>>         To: Deepak Kejriwal<deepak.kejriwal at oracle.com>  <mailto:deepak.kejriwal at oracle.com>; core-libs-dev
>>
>>         <core-libs-dev at openjdk.java.net>  <mailto:core-libs-dev at openjdk.java.net>;jdk-updates-dev at openjdk.java.net  <mailto:jdk-updates-dev at openjdk.java.net>
>>
>>         Subject: Re: RFR: JDK11U JDK-8206120, JDK-8211398, JDK-8218915
>>
>>         Hi Deepak,
>>
>>         Here are my comments to the webrev (other than what Sean pointed out):
>>
>>         TestIsJavaIdentifierMethods.java
>>
>>         - @summary: "testIsJavaLetter" -> "isJavaLetter", "testIsJavaLetterOrDigit" -> "isJavaLetterOrDigit".
>>
>>         - Line 34: "newCodePoint" does not represent the era character, as "new"
>>
>>         is subjective. It will become moot in the year 2020. How about "JAPANESE_ERA_CODEPOINT"?
>>
>>         - Line 67,68,(...all the comments): Reflect the above change to the comments.
>>
>>         - Line 103: "All Unicode chars (0x0000..0xFFFF)" does not sound correct.
>>
>>         It may be "All Unicode code points in the BMP (0x0000..0xFFFF), and remove extra period at the end. This applies to other method descriptions.
>>
>>         - Line 104: The test case returns "void", what does this "Expected results" mean?
>>
>>         - Line 140-142,174-176: The condition statement in the document is different from JDK11's javadoc. In the API doc, it is (in case of int):
>>
>>          ???? isLetter(codePoint) returns true
>>
>>          ???? getType(codePoint) returns LETTER_NUMBER
>>
>>          ???? the referenced character is a currency symbol (such as '$')
>>
>>          ???? the referenced character is a connecting punctuation character (such as '_').
>>
>>         - Line 163,198: Exception messages are incorrect. they are for isJavaIdentifierStart().
>>
>>         Naoto
>>
>>         On 2/19/19 6:15 AM, Deepak Kejriwal wrote:
>>
>>             Correcting typo for release.
>>
>>                 
>>
>>             From: Deepak Kejriwal<deepak.kejriwal at oracle.com>  <mailto:deepak.kejriwal at oracle.com>
>>
>>             Sent: Tuesday, February 19, 2019 7:42 PM
>>
>>             To: 'core-libs-dev'<core-libs-dev at openjdk.java.net>  <mailto:core-libs-dev at openjdk.java.net>;
>>
>>             'jdk-updates-dev at openjdk.java.net  <mailto:jdk-updates-dev at openjdk.java.net>'<jdk-updates-dev at openjdk.java.net>  <mailto:jdk-updates-dev at openjdk.java.net>
>>
>>             Subject: RFR: JDK11U JDK-8206120, JDK-8211398, JDK-8218915
>>
>>                 
>>
>>             Hi All,
>>
>>             Please review the backport of the following bug fixes to jdk11u-dev:
>>
>>             HYPERLINK
>>
>>             "https://bugs.openjdk.java.net/browse/JDK-8206120"  <https://bugs.openjdk.java.net/browse/JDK-8206120>JDK-8206120 : Add
>>
>>             test cases for lenient Japanese era parsing HYPERLINK
>>
>>             "https://bugs.openjdk.java.net/browse/JDK-8211398"  <https://bugs.openjdk.java.net/browse/JDK-8211398>JDK-8211398 :
>>
>>             Square character support for the Japanese new era HYPERLINK
>>
>>             "https://bugs.openjdk.java.net/browse/JDK-8218915"  <https://bugs.openjdk.java.net/browse/JDK-8218915>JDK-8218915 :
>>
>>             Change isJavaIdentifierStart and isJavaIdentifierPart to handle new
>>
>>             code points
>>
>>             Webrev:
>>
>>             http://cr.openjdk.java.net/~rpatil/JapaneseEra_changes_11u/webrev.00/
>>
>>             These code changes are made possible thanks to specification change already pushed:
>>
>>             http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/c1e1669edace
>>
>>             Regards,
>>
>>             Deepak
>>
>>                 
>>

From aph at redhat.com  Thu Feb 21 15:55:50 2019
From: aph at redhat.com (Andrew Haley)
Date: Thu, 21 Feb 2019 15:55:50 +0000
Subject: 11.0.3 backport work completed
In-Reply-To: <025bc9f0-fa24-8a27-ed1c-7c6e09776824@redhat.com>
References: <451f03ea054447659313f522fbce3e63@sap.com>
 <8fb18912-8033-051f-015e-13d791504a97@redhat.com>
 <301dfd68329b42079bcc06a8e2ef3144@sap.com>
 <025bc9f0-fa24-8a27-ed1c-7c6e09776824@redhat.com>
Message-ID: <1d95d0dc-226d-cf72-0a01-db6c0d5aed2b@redhat.com>

On 2/21/19 3:37 PM, Aleksey Shipilev wrote:
>> How are we handling other incoming jdk11u-fix-requests, that don't tackle regressions? Will we
> stop approving them until jdk11u-dev is there or at least be very cautious (which is what I suggest)?
> 
> I say we stop approving them until the fork is done.

OK. I'm ready to push the button when you tell me testing is 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 martijnverburg at gmail.com  Thu Feb 21 16:23:06 2019
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Thu, 21 Feb 2019 16:23:06 +0000
Subject: 11.0.3 backport work completed
In-Reply-To: <1d95d0dc-226d-cf72-0a01-db6c0d5aed2b@redhat.com>
References: <451f03ea054447659313f522fbce3e63@sap.com>
 <8fb18912-8033-051f-015e-13d791504a97@redhat.com>
 <301dfd68329b42079bcc06a8e2ef3144@sap.com>
 <025bc9f0-fa24-8a27-ed1c-7c6e09776824@redhat.com>
 <1d95d0dc-226d-cf72-0a01-db6c0d5aed2b@redhat.com>
Message-ID: <CAP7YuAR7sS41GssTNROu534NN0LNq2dgbXe9y9R+2hHajjAsfg@mail.gmail.com>

We will run this across a multitude of platforms overnight when it lands.
I?ll get the test team to raise JBS tickets as needed

On Thu, 21 Feb 2019 at 15:56, Andrew Haley <aph at redhat.com> wrote:

> On 2/21/19 3:37 PM, Aleksey Shipilev wrote:
> >> How are we handling other incoming jdk11u-fix-requests, that don't
> tackle regressions? Will we
> > stop approving them until jdk11u-dev is there or at least be very
> cautious (which is what I suggest)?
> >
> > I say we stop approving them until the fork is done.
>
> OK. I'm ready to push the button when you tell me testing is done.
>
> --
> Andrew Haley
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035
> <https://maps.google.com/?q=5CD+6035+&entry=gmail&source=g>332F A671
>
-- 
Cheers, Martijn (Sent from Gmail Mobile)

From martijnverburg at gmail.com  Thu Feb 21 16:25:46 2019
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Thu, 21 Feb 2019 16:25:46 +0000
Subject: How to run tests before pushing a backport changeset?
In-Reply-To: <3371d68c-d6ea-7e03-85d2-0b6cfa09b54d@redhat.com>
References: <CA+w6Hxbe+Ye7tqjGxzB8LDHRWZdDLQyT20pWZk_VTDqbc4z4uQ@mail.gmail.com>
 <f2a642ff-ff81-f52e-ea50-13b845d52d15@redhat.com>
 <CA+kOe0-7S+2LZEg+ieb0pbQwb=Jd2XTNqjkPfYQTmN4YS_Jnug@mail.gmail.com>
 <7a3048c2-b493-d3d0-970d-394b5e033aa6@redhat.com>
 <3371d68c-d6ea-7e03-85d2-0b6cfa09b54d@redhat.com>
Message-ID: <CAP7YuASoLMowQL3a-+UXKzZ_pnsUbD8bocadG-CkrHo0rw420w@mail.gmail.com>

We?ve added this to the steering committee discussion next week.  Will
likely then hold a conversation here? On what the requirements for a patch
submission system might look like.

On Thu, 21 Feb 2019 at 09:29, Andrew Haley <aph at redhat.com> wrote:

> On 2/21/19 9:07 AM, Aleksey Shipilev wrote:
> > On 2/21/19 4:55 AM, Martin Buchholz wrote:
> >> On Wed, Feb 20, 2019 at 4:10 PM Aleksey Shipilev <shade at redhat.com
> <mailto:shade at redhat.com>> wrote:
>
> >>     > I read the links on
> >>     > https://openjdk.java.net/projects/jdk-updates/, but couldn't
> >>     > find any description on testing. Does the backporting process
> >>     > require running such automated tests before pushing a
> >>     > changeset?
>
> >>     I think it is maintainer's duty to decide if testing was enough
> >>     (this is why Fix Request requires [1] to spell out what testing
> >>     was done). That said, it seems the more tests you run, the more
> >>     less chance backport would be problematic.
>
> >> I'm surprised to see you say that, because you are the king of
> >> build/test automation.  I prefer to lessen the burden on backport
> >> developers and instead invest in better release testing automation
> >> (e.g. "presubmit queue").
> >
> > By all means, you are welcome to invest in better release test
> > automation :)
> >
> > OpenJDK historically relies heavily on developers doing
> > pre-integration testing themselves, and the bulk of tests are
> > running in post-integration time. JDK Updates project is not the
> > exception to this. Maybe Skara would make it better, but this
> > remains to be seen.
> >
> > There are many tests and test suites to choose from, "tier1" seems
> > to be universally used as the go-to pre-integration test suite. If
> > tier1 fails, it is likely every other developer would complain about
> > bugs once you push. If tier1 passes, it is likely there are no bugs
> > on frequent product paths.
>
> Yes, and we'd like to work with AdoptOpenJDK to integrate their testing
> into the OpenJDK workflow. It's a work in progress.
>
> --
> Andrew Haley
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
>
-- 
Cheers, Martijn (Sent from Gmail Mobile)

From christoph.langer at sap.com  Thu Feb 21 16:43:11 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 21 Feb 2019 16:43:11 +0000
Subject: 11.0.3 backport work completed
In-Reply-To: <CAP7YuAR7sS41GssTNROu534NN0LNq2dgbXe9y9R+2hHajjAsfg@mail.gmail.com>
References: <451f03ea054447659313f522fbce3e63@sap.com>
 <8fb18912-8033-051f-015e-13d791504a97@redhat.com>
 <301dfd68329b42079bcc06a8e2ef3144@sap.com>
 <025bc9f0-fa24-8a27-ed1c-7c6e09776824@redhat.com>
 <1d95d0dc-226d-cf72-0a01-db6c0d5aed2b@redhat.com>
 <CAP7YuAR7sS41GssTNROu534NN0LNq2dgbXe9y9R+2hHajjAsfg@mail.gmail.com>
Message-ID: <57b677e489f34272b881b75ab9de1e1b@sap.com>

Hi Martijn,

> We will run this across a multitude of platforms overnight when it lands. I?ll
> get the test team to raise JBS tickets as needed

Sounds great.

Is there some public interface to your testing where one could check your results? Maybe you can give me some pointer.

Also, do you need some tagging in the repository for your AdoptOpenJDK machinery? E.g. some 11.0.3-b1 tag or such?

Best regards
Christoph


From christoph.langer at sap.com  Thu Feb 21 16:45:47 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 21 Feb 2019 16:45:47 +0000
Subject: 11.0.3 backport work completed
In-Reply-To: <025bc9f0-fa24-8a27-ed1c-7c6e09776824@redhat.com>
References: <451f03ea054447659313f522fbce3e63@sap.com>
 <8fb18912-8033-051f-015e-13d791504a97@redhat.com>
 <301dfd68329b42079bcc06a8e2ef3144@sap.com>
 <025bc9f0-fa24-8a27-ed1c-7c6e09776824@redhat.com>
Message-ID: <166ad50df39e447e80104292a31c8a4b@sap.com>

> > JDK-8210989: Is Jamil helping with that one? Or will you take it, Aleksey?
> 
> Silence there. We might want to drop it from 11.0.3 and push it to 11.0.4.

The patch looks quite small and Jamil claims that it applies. Might wait for a reaction until tomorrow and then we could handle it for 11.0.3...

/Christoph

From martijnverburg at gmail.com  Thu Feb 21 17:05:01 2019
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Thu, 21 Feb 2019 17:05:01 +0000
Subject: 11.0.3 backport work completed
In-Reply-To: <57b677e489f34272b881b75ab9de1e1b@sap.com>
References: <451f03ea054447659313f522fbce3e63@sap.com>
 <8fb18912-8033-051f-015e-13d791504a97@redhat.com>
 <301dfd68329b42079bcc06a8e2ef3144@sap.com>
 <025bc9f0-fa24-8a27-ed1c-7c6e09776824@redhat.com>
 <1d95d0dc-226d-cf72-0a01-db6c0d5aed2b@redhat.com>
 <CAP7YuAR7sS41GssTNROu534NN0LNq2dgbXe9y9R+2hHajjAsfg@mail.gmail.com>
 <57b677e489f34272b881b75ab9de1e1b@sap.com>
Message-ID: <CAP7YuAR-n=29OZ6j9RkSUswO4y0t__ka6jnoMrJ=NDFoLDbwtg@mail.gmail.com>

We'll build from jdk11u (HEAD) for our nightly builds and the 11.0.3+x tag
when a release gets officially tagged. See https://ci.adoptopenjdk.net for
the raw CI builds and test results.  It's non-trivial to navigate at this
stage so you're probably best off joining adoptopenjdk/slack.html (yes I
know, evil Slack) saying Hi and one of us can set up a guided tour.

Cheers,
Martijn


On Thu, 21 Feb 2019 at 16:43, Langer, Christoph <christoph.langer at sap.com>
wrote:

> Hi Martijn,
>
> > We will run this across a multitude of platforms overnight when it
> lands. I?ll
> > get the test team to raise JBS tickets as needed
>
> Sounds great.
>
> Is there some public interface to your testing where one could check your
> results? Maybe you can give me some pointer.
>
> Also, do you need some tagging in the repository for your AdoptOpenJDK
> machinery? E.g. some 11.0.3-b1 tag or such?
>
> Best regards
> Christoph
>
>

From martinrb at google.com  Thu Feb 21 17:13:34 2019
From: martinrb at google.com (Martin Buchholz)
Date: Thu, 21 Feb 2019 09:13:34 -0800
Subject: How to run tests before pushing a backport changeset?
In-Reply-To: <CAP7YuASoLMowQL3a-+UXKzZ_pnsUbD8bocadG-CkrHo0rw420w@mail.gmail.com>
References: <CA+w6Hxbe+Ye7tqjGxzB8LDHRWZdDLQyT20pWZk_VTDqbc4z4uQ@mail.gmail.com>
 <f2a642ff-ff81-f52e-ea50-13b845d52d15@redhat.com>
 <CA+kOe0-7S+2LZEg+ieb0pbQwb=Jd2XTNqjkPfYQTmN4YS_Jnug@mail.gmail.com>
 <7a3048c2-b493-d3d0-970d-394b5e033aa6@redhat.com>
 <3371d68c-d6ea-7e03-85d2-0b6cfa09b54d@redhat.com>
 <CAP7YuASoLMowQL3a-+UXKzZ_pnsUbD8bocadG-CkrHo0rw420w@mail.gmail.com>
Message-ID: <CA+kOe0_0JnoZQ3wQNigx_YG_ZhFSdVzL2yDY4Noox04w4FtF+g@mail.gmail.com>

On Thu, Feb 21, 2019 at 8:25 AM Martijn Verburg <martijnverburg at gmail.com>
wrote:

> We?ve added this to the steering committee discussion next week.  Will
> likely then hold a conversation here? On what the requirements for a patch
> submission system might look like.
>

Thanks for working on this.
(As usual, it's a project I would like to work on myself, but won't have
the time)
Conceptually, it's very simple - developers produce changesets and place
them in a presubmit queue for their chosen repo, and they end up in the
repo when they have passed all the tests.  The maintainers of the repo
define the set of tests - "how high to set the bar".  When tests fail, the
changeset is rejected and (only!) the submitter is notified.  Meta-tests
like "must have jdk11u-fix-yes label in JIRA" count!

From shade at redhat.com  Thu Feb 21 19:45:11 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 21 Feb 2019 20:45:11 +0100
Subject: Pending pushes for approved 11u backports
In-Reply-To: <7014a3ae-ebac-c7e6-5658-17fc95e4da55@redhat.com>
References: <7014a3ae-ebac-c7e6-5658-17fc95e4da55@redhat.com>
Message-ID: <83ef02b5-9aa4-c759-d327-7ddd16f71b92@redhat.com>

On 2/20/19 7:10 PM, Aleksey Shipilev wrote:
> Man Cao: You need sponsor for this, right? You don't have JDK Updates privileges in Census. I would
> prefer this to land to 12u as well.
>   https://bugs.openjdk.java.net/browse/JDK-8218192

FWIW, I ran Linux x86_64 {fastdebug, release} tier1 with this patch without problems.
Man, are you (and your sponsor, Jiangli?) up to push this to 11u?

-Aleksey


From manc at google.com  Thu Feb 21 20:34:34 2019
From: manc at google.com (Man Cao)
Date: Thu, 21 Feb 2019 12:34:34 -0800
Subject: Pending pushes for approved 11u backports
In-Reply-To: <83ef02b5-9aa4-c759-d327-7ddd16f71b92@redhat.com>
References: <7014a3ae-ebac-c7e6-5658-17fc95e4da55@redhat.com>
 <83ef02b5-9aa4-c759-d327-7ddd16f71b92@redhat.com>
Message-ID: <CA+w6HxbtxfJMcr93qXnRreqY1Y=KCL_Ze7RoBJQm3HPHoctySw@mail.gmail.com>

Hi Aleksey,

Yes, Jiangli pushed it to 11u about 1 hour ago.

-Man


On Thu, Feb 21, 2019 at 11:45 AM Aleksey Shipilev <shade at redhat.com> wrote:

> On 2/20/19 7:10 PM, Aleksey Shipilev wrote:
> > Man Cao: You need sponsor for this, right? You don't have JDK Updates
> privileges in Census. I would
> > prefer this to land to 12u as well.
> >   https://bugs.openjdk.java.net/browse/JDK-8218192
>
> FWIW, I ran Linux x86_64 {fastdebug, release} tier1 with this patch
> without problems.
> Man, are you (and your sponsor, Jiangli?) up to push this to 11u?
>
> -Aleksey
>
>

From goetz.lindenmaier at sap.com  Thu Feb 21 22:26:01 2019
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Thu, 21 Feb 2019 22:26:01 +0000
Subject: 11.0.3 backport work completed
In-Reply-To: <025bc9f0-fa24-8a27-ed1c-7c6e09776824@redhat.com>
References: <451f03ea054447659313f522fbce3e63@sap.com>
 <8fb18912-8033-051f-015e-13d791504a97@redhat.com>
 <301dfd68329b42079bcc06a8e2ef3144@sap.com>
 <025bc9f0-fa24-8a27-ed1c-7c6e09776824@redhat.com>
Message-ID: <8af2d8cca364425c9d81592086b00e86@sap.com>

Hi,
> > JDK-8219461: Once approved we can push it.
> Yes. I think we can push it, because it does _not_ have to be the last
> changeset in 11.0.3.
Usually, it's the first ??
 
> > How are we handling other incoming jdk11u-fix-requests, that don't tackle
> regressions? Will we
> stop approving them until jdk11u-dev is there or at least be very cautious
> (which is what I suggest)?
> I say we stop approving them until the fork is done.
Yes, I agree.

Best regards,
  Goetz.


> 
> -Aleksey


From aph at redhat.com  Fri Feb 22 09:05:50 2019
From: aph at redhat.com (Andrew Haley)
Date: Fri, 22 Feb 2019 09:05:50 +0000
Subject: 11.0.3 backport work completed
In-Reply-To: <8af2d8cca364425c9d81592086b00e86@sap.com>
References: <451f03ea054447659313f522fbce3e63@sap.com>
 <8fb18912-8033-051f-015e-13d791504a97@redhat.com>
 <301dfd68329b42079bcc06a8e2ef3144@sap.com>
 <025bc9f0-fa24-8a27-ed1c-7c6e09776824@redhat.com>
 <8af2d8cca364425c9d81592086b00e86@sap.com>
Message-ID: <f11c6dc8-8608-a702-c696-b8e676e0eb55@redhat.com>

On 2/21/19 10:26 PM, Lindenmaier, Goetz wrote:
>>> How are we handling other incoming jdk11u-fix-requests, that don't tackle
>> regressions? Will we
>> stop approving them until jdk11u-dev is there or at least be very cautious
>> (which is what I suggest)?
>> I say we stop approving them until the fork is done.
> Yes, I agree.

Status? Ready to clone the tree?

-- 
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 shade at redhat.com  Fri Feb 22 09:07:53 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Fri, 22 Feb 2019 10:07:53 +0100
Subject: 11.0.3 backport work completed
In-Reply-To: <f11c6dc8-8608-a702-c696-b8e676e0eb55@redhat.com>
References: <451f03ea054447659313f522fbce3e63@sap.com>
 <8fb18912-8033-051f-015e-13d791504a97@redhat.com>
 <301dfd68329b42079bcc06a8e2ef3144@sap.com>
 <025bc9f0-fa24-8a27-ed1c-7c6e09776824@redhat.com>
 <8af2d8cca364425c9d81592086b00e86@sap.com>
 <f11c6dc8-8608-a702-c696-b8e676e0eb55@redhat.com>
Message-ID: <38406a6c-410f-50ca-ca8c-2550a2fa57f0@redhat.com>

On 2/22/19 10:05 AM, Andrew Haley wrote:
> On 2/21/19 10:26 PM, Lindenmaier, Goetz wrote:
>>>> How are we handling other incoming jdk11u-fix-requests, that don't tackle
>>> regressions? Will we
>>> stop approving them until jdk11u-dev is there or at least be very cautious
>>> (which is what I suggest)?
>>> I say we stop approving them until the fork is done.
>> Yes, I agree.
> 
> Status? Ready to clone the tree?

Tests are still running. Linux tests seem good.

We also still haven't pushed the change that bumps version to 11.0.3. What's up with that, Christoph?

-Aleksey



From christoph.langer at sap.com  Fri Feb 22 09:13:46 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 22 Feb 2019 09:13:46 +0000
Subject: 11.0.3 backport work completed
In-Reply-To: <38406a6c-410f-50ca-ca8c-2550a2fa57f0@redhat.com>
References: <451f03ea054447659313f522fbce3e63@sap.com>
 <8fb18912-8033-051f-015e-13d791504a97@redhat.com>
 <301dfd68329b42079bcc06a8e2ef3144@sap.com>
 <025bc9f0-fa24-8a27-ed1c-7c6e09776824@redhat.com>
 <8af2d8cca364425c9d81592086b00e86@sap.com>
 <f11c6dc8-8608-a702-c696-b8e676e0eb55@redhat.com>
 <38406a6c-410f-50ca-ca8c-2550a2fa57f0@redhat.com>
Message-ID: <05722d4b361e4e94b002df1fdd994473@sap.com>

Hi,

our tests look quite good as far as I can tell. There are some longstanding test failures which we might want to tackle somehow in the next days but I guess that's something which we can/should do in stabilization mode. That's what it is for. But it seems no regressions due to our latest pushes.

> We also still haven't pushed the change that bumps version to 11.0.3. What's
> up with that, Christoph?
Goetz, that's yours. Can you push it?

I've also just figured we missed one important 11.0.3-oracle P2 item: https://bugs.openjdk.java.net/browse/JDK-8214118. It fell through both mine and Aleksey's filter because there's already a bug for 11.0.3. This one has status "Open". I modified my filter to check explicitly for status "Resolved" now. Then it would bubble up. Aleksey, would you take this one or shall I?

Thanks
Christoph


From christoph.langer at sap.com  Fri Feb 22 09:15:05 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 22 Feb 2019 09:15:05 +0000
Subject: 11.0.3 backport work completed
In-Reply-To: <05722d4b361e4e94b002df1fdd994473@sap.com>
References: <451f03ea054447659313f522fbce3e63@sap.com>
 <8fb18912-8033-051f-015e-13d791504a97@redhat.com>
 <301dfd68329b42079bcc06a8e2ef3144@sap.com>
 <025bc9f0-fa24-8a27-ed1c-7c6e09776824@redhat.com>
 <8af2d8cca364425c9d81592086b00e86@sap.com>
 <f11c6dc8-8608-a702-c696-b8e676e0eb55@redhat.com>
 <38406a6c-410f-50ca-ca8c-2550a2fa57f0@redhat.com>
 <05722d4b361e4e94b002df1fdd994473@sap.com>
Message-ID: <7db5075a91fb41a1a3fb765887782928@sap.com>

> I've also just figured we missed one important 11.0.3-oracle P2 item:
> https://bugs.openjdk.java.net/browse/JDK-8214118. It fell through both
> mine and Aleksey's filter because there's already a bug for 11.0.3. This one
> has status "Open". I modified my filter to check explicitly for status
> "Resolved" now. Then it would bubble up. Aleksey, would you take this one
> or shall I?

PS: The open 11.0.3 bug is JDK-8214313...


From shade at redhat.com  Fri Feb 22 09:21:54 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Fri, 22 Feb 2019 10:21:54 +0100
Subject: 11.0.3 backport work completed
In-Reply-To: <05722d4b361e4e94b002df1fdd994473@sap.com>
References: <451f03ea054447659313f522fbce3e63@sap.com>
 <8fb18912-8033-051f-015e-13d791504a97@redhat.com>
 <301dfd68329b42079bcc06a8e2ef3144@sap.com>
 <025bc9f0-fa24-8a27-ed1c-7c6e09776824@redhat.com>
 <8af2d8cca364425c9d81592086b00e86@sap.com>
 <f11c6dc8-8608-a702-c696-b8e676e0eb55@redhat.com>
 <38406a6c-410f-50ca-ca8c-2550a2fa57f0@redhat.com>
 <05722d4b361e4e94b002df1fdd994473@sap.com>
Message-ID: <e2b96506-adc1-a3c8-5100-1d5db6e48a96@redhat.com>

On 2/22/19 10:13 AM, Langer, Christoph wrote:
> I've also just figured we missed one important 11.0.3-oracle P2 item:
> https://bugs.openjdk.java.net/browse/JDK-8214118. It fell through both mine and Aleksey's filter
> because there's already a bug for 11.0.3. This one has status "Open". I modified my filter to
> check explicitly for status "Resolved" now. Then it would bubble up. Aleksey, would you take this
> one or shall I?

Dammit. The patch does not apply cleanly, let me see what is up.

-Aleksey


From shade at redhat.com  Fri Feb 22 09:46:32 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Fri, 22 Feb 2019 10:46:32 +0100
Subject: [11u] RFR (S) 8214118: HeapRegions marked as archive even if CDS
 mapping fails
Message-ID: <7c4d7949-5619-a611-837a-445cc06ccc1b@redhat.com>

Please review the backport to 11u.

Original bug:
  https://bugs.openjdk.java.net/browse/JDK-8214118

Original fix:
  http://hg.openjdk.java.net/jdk/jdk/rev/c9325aa887da

The patch does not apply cleanly to 11u, because there are minute differences in the code. Notably,
there is no closed_archive_heap_ranges, and as I see from the code, string_ranges is the old name
for it. It was renamed in JDK-8212995.

I also see there is Oracle-closed backport to 11u-oracle, can we compare the patches with Oracle
folks, maybe?

11u webrev:
  http://cr.openjdk.java.net/~shade/8214118/webrev.11u.01/

Testing: Linux x86_64 tier1

Thanks,
-Aleksey


From christoph.langer at sap.com  Fri Feb 22 09:59:29 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 22 Feb 2019 09:59:29 +0000
Subject: 11.0.3 backport work completed
In-Reply-To: <05722d4b361e4e94b002df1fdd994473@sap.com>
References: <451f03ea054447659313f522fbce3e63@sap.com>
 <8fb18912-8033-051f-015e-13d791504a97@redhat.com>
 <301dfd68329b42079bcc06a8e2ef3144@sap.com>
 <025bc9f0-fa24-8a27-ed1c-7c6e09776824@redhat.com>
 <8af2d8cca364425c9d81592086b00e86@sap.com>
 <f11c6dc8-8608-a702-c696-b8e676e0eb55@redhat.com>
 <38406a6c-410f-50ca-ca8c-2550a2fa57f0@redhat.com>
 <05722d4b361e4e94b002df1fdd994473@sap.com>
Message-ID: <88b9ba117fdb4cd2bba6341e610898c9@sap.com>

> > We also still haven't pushed the change that bumps version to 11.0.3.
> What's up with that, Christoph?
> Goetz, that's yours. Can you push it?

I just learned that Goetz is on vacation today, so I'll push it now.

/Christoph


From Ningsheng.Jian at arm.com  Fri Feb 22 10:22:56 2019
From: Ningsheng.Jian at arm.com (Ningsheng Jian (Arm Technology China))
Date: Fri, 22 Feb 2019 10:22:56 +0000
Subject: Pending pushes for approved 11u backports
In-Reply-To: <6cb90ceb-a030-bd25-1bb6-d4a47d0a8c90@redhat.com>
References: <7014a3ae-ebac-c7e6-5658-17fc95e4da55@redhat.com>
 <5c48ed37-1667-0564-94ad-529537295a29@arm.com>
 <b073ae86-b6f3-c386-e19c-d865ba9f8795@redhat.com>
 <6cb90ceb-a030-bd25-1bb6-d4a47d0a8c90@redhat.com>
Message-ID: <3b26d28a-23bb-de4b-678c-ae8893176e23@arm.com>

Hi Aleksey,

On 02/21/2019 08:08 PM, Aleksey Shipilev wrote:
> On 2/21/19 9:44 AM, Aleksey Shipilev wrote:
>> On 2/21/19 3:27 AM, Ningsheng Jian (Arm Technology China) wrote:
>>> Yes, I need sponsor for my jdk11u backport requests. May I ask a sponsor
>>> for these:
>>>
>>>  >   https://bugs.openjdk.java.net/browse/JDK-8215100
>>>  >   https://bugs.openjdk.java.net/browse/JDK-8215202
>>
>> I will sponsor this for you.
>
> Pushed to 11u. I did some testing on x86_64, and only a few spot checks on AArch64.
> Please consider running tests for current 11u on ARM machines you certainly have around? :)
>

Yes, I have verified it on my AArch64 box with jtreg tests. Thanks!

Regards,
Ningsheng

From christoph.langer at sap.com  Fri Feb 22 10:32:14 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 22 Feb 2019 10:32:14 +0000
Subject: 11.0.3 backport work completed
In-Reply-To: <CAP7YuAR-n=29OZ6j9RkSUswO4y0t__ka6jnoMrJ=NDFoLDbwtg@mail.gmail.com>
References: <451f03ea054447659313f522fbce3e63@sap.com>
 <8fb18912-8033-051f-015e-13d791504a97@redhat.com>
 <301dfd68329b42079bcc06a8e2ef3144@sap.com>
 <025bc9f0-fa24-8a27-ed1c-7c6e09776824@redhat.com>
 <1d95d0dc-226d-cf72-0a01-db6c0d5aed2b@redhat.com>
 <CAP7YuAR7sS41GssTNROu534NN0LNq2dgbXe9y9R+2hHajjAsfg@mail.gmail.com>
 <57b677e489f34272b881b75ab9de1e1b@sap.com>
 <CAP7YuAR-n=29OZ6j9RkSUswO4y0t__ka6jnoMrJ=NDFoLDbwtg@mail.gmail.com>
Message-ID: <a8451f72d2e3463fbd4e12b734b3d357@sap.com>

Hi Martijn,

> We'll build from jdk11u (HEAD) for our nightly builds and the 11.0.3+x tag
> when a release gets officially?tagged. See https://ci.adoptopenjdk.net for
> the raw CI builds and test results.? It's non-trivial to navigate at this stage
> so?you're probably best off joining adoptopenjdk/slack.html (yes I know, evil
> Slack) saying Hi and one of us can set up a guided tour.

I just glanced around a bit on https://ci.adoptopenjdk.net and I guess I've even found the jobs for the jtreg tests. ??

As I'm already in the slack channel,I'll direct my further questions there...

Thanks
Christoph


From christoph.langer at sap.com  Fri Feb 22 10:46:37 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 22 Feb 2019 10:46:37 +0000
Subject: JDK-8210989 in 11.0.3
Message-ID: <58f638c6e320492f81cbd47e4915281a@sap.com>

Hi,

I've just checked that the change for the already jdk11u-approved bug JDK-8210989 [0] applies cleanly to jkd11u. I also think that it is a reasonable fix to do in jdk11u after reading the bug description and looking at the code. I've put it in our test queue for the nightly tests.

If nobody objects and I don't see regressions, I will push it in the next days.

Best regards
Christoph

[0] https://bugs.openjdk.java.net/browse/JDK-8210989 

> -----Original Message-----
> From: Langer, Christoph
> Sent: Donnerstag, 21. Februar 2019 17:46
> To: 'Aleksey Shipilev' <shade at redhat.com>; jdk-updates-
> dev at openjdk.java.net; Andrew Haley <aph at redhat.com>
> Cc: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; Andrew Hughes
> (gnu.andrew at redhat.com) <gnu.andrew at redhat.com>
> Subject: RE: 11.0.3 backport work completed
> 
> > > JDK-8210989: Is Jamil helping with that one? Or will you take it, Aleksey?
> >
> > Silence there. We might want to drop it from 11.0.3 and push it to 11.0.4.
> 
> The patch looks quite small and Jamil claims that it applies. Might wait for a
> reaction until tomorrow and then we could handle it for 11.0.3...
> 
> /Christoph

From shade at redhat.com  Fri Feb 22 10:50:39 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Fri, 22 Feb 2019 11:50:39 +0100
Subject: JDK-8210989 in 11.0.3
In-Reply-To: <58f638c6e320492f81cbd47e4915281a@sap.com>
References: <58f638c6e320492f81cbd47e4915281a@sap.com>
Message-ID: <292d1a03-64b7-a31c-7d82-55beaf1bf14d@redhat.com>

On 2/22/19 11:46 AM, Langer, Christoph wrote:
> I've just checked that the change for the already jdk11u-approved bug JDK-8210989 [0] applies
> cleanly to jkd11u. I also think that it is a reasonable fix to do in jdk11u after reading the bug
> description and looking at the code. I've put it in our test queue for the nightly tests.
> 
> If nobody objects and I don't see regressions, I will push it in the next days.

Fine with me. It is probably better to be deferred to 11.0.4, so not to hold 11.0.3? It does not
look to be critical and/or present in 11.0.3-oracle.

-Aleksey


From christoph.langer at sap.com  Fri Feb 22 11:23:01 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 22 Feb 2019 11:23:01 +0000
Subject: RFR+RFA [11u]: 8214189:
 test/hotspot/jtreg/compiler/intrinsics/mathexact/MulExactLConstantTest.java
 fails on Windows x64 when run with -XX:-TieredCompilation
Message-ID: <b9a112ebf7204663accfb66d7a276f12@sap.com>

Hi,

we have observed a regression in JCK testing of jkd11u since 19/02/07. Running JCK lang tests with -Xcomp -Xbatch -XX:-TieredCompilation show failures on Windows x64 in:
lang/EXPR/expr260/expr26001/expr26001_rt
vm/instr/lmul/lmul002/lmul00201m1/lmul00201m1
vm/instr/lmul/lmul002/lmul00201m1t/lmul00201m1t

I think the regression was introduced when https://bugs.openjdk.java.net/browse/JDK-8213419 and https://bugs.openjdk.java.net/browse/JDK-8214206 were brought to jdk11u at about that time. The issue is fixed with 8214189. I consider this severe enough to warrant a backport of the fix to 11.0.3.

Bug: https://bugs.openjdk.java.net/browse/JDK-8214189
Original Change: http://hg.openjdk.java.net/jdk/jdk/rev/0037ea3c7322
Backport Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8214189.jdk11u/

The patch applies cleanly, apart from the change to the exclusion list test/hotspot/jtreg/ProblemList.txt which is not valid in 11u. It did also not show further regressions in the nightly tests.

I guess it should also be brought to 8u as well, since the regressing patches have been checked in there as well.

Best regards
Christoph


From shade at redhat.com  Fri Feb 22 11:38:13 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Fri, 22 Feb 2019 12:38:13 +0100
Subject: RFR+RFA [11u]: 8214189:
 test/hotspot/jtreg/compiler/intrinsics/mathexact/MulExactLConstantTest.java
 fails on Windows x64 when run with -XX:-TieredCompilation
In-Reply-To: <b9a112ebf7204663accfb66d7a276f12@sap.com>
References: <b9a112ebf7204663accfb66d7a276f12@sap.com>
Message-ID: <5069611d-f80c-724c-7414-8db967fe6a99@redhat.com>

On 2/22/19 12:23 PM, Langer, Christoph wrote:
> I think the regression was introduced when https://bugs.openjdk.java.net/browse/JDK-8213419 and
> https://bugs.openjdk.java.net/browse/JDK-8214206 were brought to jdk11u at about that time. The
> issue is fixed with 8214189. I consider this severe enough to warrant a backport of the fix to 11.0.3.

I agree, this should go to 11.0.3. No way we would release 11.0.3 without passing JCK.

Andrew, please approve?

> Bug: https://bugs.openjdk.java.net/browse/JDK-8214189
> Original Change: http://hg.openjdk.java.net/jdk/jdk/rev/0037ea3c7322
> Backport Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8214189.jdk11u/

Looks good.

> The patch applies cleanly, apart from the change to the exclusion list
> test/hotspot/jtreg/ProblemList.txt which is not valid in 11u. It did also not show further
> regressions in the nightly tests.

Since patch applies cleanly and fixes the tests, I don't think it needs more reviews.

> I guess it should also be brought to 8u as well, since the regressing patches have been checked in
> there as well.

Marked for 8u backport.

-Aleksey


From shade at redhat.com  Fri Feb 22 16:06:19 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Fri, 22 Feb 2019 17:06:19 +0100
Subject: [11u] RFR (S) 8214118: HeapRegions marked as archive even if CDS
 mapping fails
In-Reply-To: <98c313be-864b-8b82-00a5-a92afe2b7996@redhat.com>
References: <7c4d7949-5619-a611-837a-445cc06ccc1b@redhat.com>
 <CALrW1jwXxNtoYRDZMm4eo1sE4Ayqn-S_Dm0aoi1NpDaJhN=WyA@mail.gmail.com>
 <98c313be-864b-8b82-00a5-a92afe2b7996@redhat.com>
Message-ID: <727c84d3-d004-09c0-eef9-378f3cf72f4d@redhat.com>

On 2/22/19 5:05 PM, Aleksey Shipilev wrote:
> On 2/22/19 4:47 PM, Jiangli Zhou wrote:
>> The backport looks good to me.?
> 
> Thanks. I am going to push to 11u soon then.

Wait. Christoph, please eyeball as well?

-Aleksey


From shade at redhat.com  Fri Feb 22 16:05:45 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Fri, 22 Feb 2019 17:05:45 +0100
Subject: [11u] RFR (S) 8214118: HeapRegions marked as archive even if CDS
 mapping fails
In-Reply-To: <CALrW1jwXxNtoYRDZMm4eo1sE4Ayqn-S_Dm0aoi1NpDaJhN=WyA@mail.gmail.com>
References: <7c4d7949-5619-a611-837a-445cc06ccc1b@redhat.com>
 <CALrW1jwXxNtoYRDZMm4eo1sE4Ayqn-S_Dm0aoi1NpDaJhN=WyA@mail.gmail.com>
Message-ID: <98c313be-864b-8b82-00a5-a92afe2b7996@redhat.com>

On 2/22/19 4:47 PM, Jiangli Zhou wrote:
> The backport looks good to me.?

Thanks. I am going to push to 11u soon then.

-Aleksey


From jianglizhou at google.com  Fri Feb 22 15:47:23 2019
From: jianglizhou at google.com (Jiangli Zhou)
Date: Fri, 22 Feb 2019 07:47:23 -0800
Subject: [11u] RFR (S) 8214118: HeapRegions marked as archive even if CDS
 mapping fails
In-Reply-To: <7c4d7949-5619-a611-837a-445cc06ccc1b@redhat.com>
References: <7c4d7949-5619-a611-837a-445cc06ccc1b@redhat.com>
Message-ID: <CALrW1jwXxNtoYRDZMm4eo1sE4Ayqn-S_Dm0aoi1NpDaJhN=WyA@mail.gmail.com>

Hi Aleksey,

The backport looks good to me.

On Fri, Feb 22, 2019 at 1:48 AM Aleksey Shipilev <shade at redhat.com> wrote:

> Please review the backport to 11u.
>
> Original bug:
>   https://bugs.openjdk.java.net/browse/JDK-8214118
>
> Original fix:
>   http://hg.openjdk.java.net/jdk/jdk/rev/c9325aa887da
>
> The patch does not apply cleanly to 11u, because there are minute
> differences in the code. Notably,
> there is no closed_archive_heap_ranges, and as I see from the code,
> string_ranges is the old name
> for it. It was renamed in JDK-8212995.
>

Right.  The renaming happened when graphs of non-string objects were
supported in the closed region.

Thanks,
Jiangli


> I also see there is Oracle-closed backport to 11u-oracle, can we compare
> the patches with Oracle
> folks, maybe?
>
> 11u webrev:
>   http://cr.openjdk.java.net/~shade/8214118/webrev.11u.01/
>
> Testing: Linux x86_64 tier1
>
> Thanks,
> -Aleksey
>
>

From shade at redhat.com  Fri Feb 22 17:37:20 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Fri, 22 Feb 2019 18:37:20 +0100
Subject: [11u] RFR (S) 8214118: HeapRegions marked as archive even if CDS
 mapping fails
In-Reply-To: <727c84d3-d004-09c0-eef9-378f3cf72f4d@redhat.com>
References: <7c4d7949-5619-a611-837a-445cc06ccc1b@redhat.com>
 <CALrW1jwXxNtoYRDZMm4eo1sE4Ayqn-S_Dm0aoi1NpDaJhN=WyA@mail.gmail.com>
 <98c313be-864b-8b82-00a5-a92afe2b7996@redhat.com>
 <727c84d3-d004-09c0-eef9-378f3cf72f4d@redhat.com>
Message-ID: <54fb7dcf-1377-59bb-b97e-41f4a7cde906@redhat.com>

On 2/22/19 5:06 PM, Aleksey Shipilev wrote:
> On 2/22/19 5:05 PM, Aleksey Shipilev wrote:
>> On 2/22/19 4:47 PM, Jiangli Zhou wrote:
>>> The backport looks good to me.?
>>
>> Thanks. I am going to push to 11u soon then.
> 
> Wait. Christoph, please eyeball as well?

Or not. Jiangli's review in CDS area should be good enough. Pushed.

-Aleksey,


From christoph.langer at sap.com  Fri Feb 22 22:06:02 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 22 Feb 2019 22:06:02 +0000
Subject: [11u] RFR (S) 8214118: HeapRegions marked as archive even if CDS
 mapping fails
In-Reply-To: <54fb7dcf-1377-59bb-b97e-41f4a7cde906@redhat.com>
References: <7c4d7949-5619-a611-837a-445cc06ccc1b@redhat.com>
 <CALrW1jwXxNtoYRDZMm4eo1sE4Ayqn-S_Dm0aoi1NpDaJhN=WyA@mail.gmail.com>
 <98c313be-864b-8b82-00a5-a92afe2b7996@redhat.com>
 <727c84d3-d004-09c0-eef9-378f3cf72f4d@redhat.com>
 <54fb7dcf-1377-59bb-b97e-41f4a7cde906@redhat.com>
Message-ID: <2a8ccf3c22a9484aa41e56a7f7923793@sap.com>

> > Wait. Christoph, please eyeball as well?
> 
> Or not. Jiangli's review in CDS area should be good enough. Pushed.

Yes. I could not have added to the value of this review ??

Thanks guys.

From christoph.langer at sap.com  Sat Feb 23 15:03:41 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Sat, 23 Feb 2019 15:03:41 +0000
Subject: JDK-8210989 in 11.0.3
In-Reply-To: <292d1a03-64b7-a31c-7d82-55beaf1bf14d@redhat.com>
References: <58f638c6e320492f81cbd47e4915281a@sap.com>
 <292d1a03-64b7-a31c-7d82-55beaf1bf14d@redhat.com>
Message-ID: <4acd8516a55644389de38f2d85ed398c@sap.com>

Hi,

> On 2/22/19 11:46 AM, Langer, Christoph wrote:
> > I've just checked that the change for the already jdk11u-approved bug JDK-
> 8210989 [0] applies
> > cleanly to jkd11u. I also think that it is a reasonable fix to do in jdk11u after
> reading the bug
> > description and looking at the code. I've put it in our test queue for the
> nightly tests.
> >
> > If nobody objects and I don't see regressions, I will push it in the next days.
> 
> Fine with me. It is probably better to be deferred to 11.0.4, so not to hold
> 11.0.3? It does not
> look to be critical and/or present in 11.0.3-oracle.

I just pushed it because
a) It has been approved for a long time already
b) it seems reasonable and a real bugfix
c) it shows no regressions
d) Oracle has integrated it into 11.0.4-oracle yesterday

Best regards
Christoph


From shade at redhat.com  Mon Feb 25 08:27:10 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 25 Feb 2019 09:27:10 +0100
Subject: 11.0.3 backport work completed
In-Reply-To: <f11c6dc8-8608-a702-c696-b8e676e0eb55@redhat.com>
References: <451f03ea054447659313f522fbce3e63@sap.com>
 <8fb18912-8033-051f-015e-13d791504a97@redhat.com>
 <301dfd68329b42079bcc06a8e2ef3144@sap.com>
 <025bc9f0-fa24-8a27-ed1c-7c6e09776824@redhat.com>
 <8af2d8cca364425c9d81592086b00e86@sap.com>
 <f11c6dc8-8608-a702-c696-b8e676e0eb55@redhat.com>
Message-ID: <1e84e75b-c9a9-d1b3-ae57-58407b380d82@redhat.com>

On 2/22/19 10:05 AM, Andrew Haley wrote:
> On 2/21/19 10:26 PM, Lindenmaier, Goetz wrote:
>>>> How are we handling other incoming jdk11u-fix-requests, that don't tackle
>>> regressions? Will we
>>> stop approving them until jdk11u-dev is there or at least be very cautious
>>> (which is what I suggest)?
>>> I say we stop approving them until the fork is done.
>> Yes, I agree.
> 
> Status? Ready to clone the tree?

As far as I can see, jdk-updates/jdk11u is complete, sanity tested and forkable.

Christoph, do you concur?

-Aleksey





From christoph.langer at sap.com  Mon Feb 25 08:29:19 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 25 Feb 2019 08:29:19 +0000
Subject: 11.0.3 backport work completed
In-Reply-To: <1e84e75b-c9a9-d1b3-ae57-58407b380d82@redhat.com>
References: <451f03ea054447659313f522fbce3e63@sap.com>
 <8fb18912-8033-051f-015e-13d791504a97@redhat.com>
 <301dfd68329b42079bcc06a8e2ef3144@sap.com>
 <025bc9f0-fa24-8a27-ed1c-7c6e09776824@redhat.com>
 <8af2d8cca364425c9d81592086b00e86@sap.com>
 <f11c6dc8-8608-a702-c696-b8e676e0eb55@redhat.com>
 <1e84e75b-c9a9-d1b3-ae57-58407b380d82@redhat.com>
Message-ID: <816cf81d510b443283d07a4c61521788@sap.com>

> > Status? Ready to clone the tree?
> 
> As far as I can see, jdk-updates/jdk11u is complete, sanity tested and
> forkable.
> 
> Christoph, do you concur?

Absolutely. Let's go create jdk11u-dev.

Best regards
Christoph

From shade at redhat.com  Mon Feb 25 08:30:54 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 25 Feb 2019 09:30:54 +0100
Subject: JDK-8210989 in 11.0.3
In-Reply-To: <4acd8516a55644389de38f2d85ed398c@sap.com>
References: <58f638c6e320492f81cbd47e4915281a@sap.com>
 <292d1a03-64b7-a31c-7d82-55beaf1bf14d@redhat.com>
 <4acd8516a55644389de38f2d85ed398c@sap.com>
Message-ID: <56e0f0a8-35ed-6c51-eb46-022227dcb288@redhat.com>

On 2/23/19 4:03 PM, Langer, Christoph wrote:
>> On 2/22/19 11:46 AM, Langer, Christoph wrote:
>>> I've just checked that the change for the already jdk11u-approved bug JDK-
>> 8210989 [0] applies
>>> cleanly to jkd11u. I also think that it is a reasonable fix to do in jdk11u after
>> reading the bug
>>> description and looking at the code. I've put it in our test queue for the
>> nightly tests.
>>>
>>> If nobody objects and I don't see regressions, I will push it in the next days.
>>
>> Fine with me. It is probably better to be deferred to 11.0.4, so not to hold
>> 11.0.3? It does not
>> look to be critical and/or present in 11.0.3-oracle.
> 
> I just pushed it because
> a) It has been approved for a long time already
> b) it seems reasonable and a real bugfix
> c) it shows no regressions
> d) Oracle has integrated it into 11.0.4-oracle yesterday

Thanks, that's fine.

-Aleksey


From Michael.Rasmussen at roguewave.com  Mon Feb 25 15:42:33 2019
From: Michael.Rasmussen at roguewave.com (Michael Rasmussen)
Date: Mon, 25 Feb 2019 15:42:33 +0000
Subject: Backport of fix for CDS and JVM-TI agent crash ?
In-Reply-To: <eb98d80d-fe24-b3b9-d9ad-ca5ef2eb933a@oracle.com>
References: <BL0PR02MB4914211925A8983AAC97AA35E0960@BL0PR02MB4914.namprd02.prod.outlook.com>
 <CA+3eh13_1-icmPiUgs9DjBAhErOD0c3pcV-oXQfTMcWn+m9G3w@mail.gmail.com>
 <b9093af843ae4a609b21492c36ae6149@sap.com>,
 <eb98d80d-fe24-b3b9-d9ad-ca5ef2eb933a@oracle.com>
Message-ID: <BYAPR02MB42636486A39E7D07893316EEE07A0@BYAPR02MB4263.namprd02.prod.outlook.com>

> There are CDS 3 bugs that I plan to backport to 11. I hope to post the
> requests this week.
> https://bugs.openjdk.java.net/issues/?filter=36209
> Thanks
> - Ioi

Did you ever get a chance to do so, or has it all changed now after maintenance has been handed over?

/Michael

From aph at redhat.com  Mon Feb 25 17:23:23 2019
From: aph at redhat.com (Andrew Haley)
Date: Mon, 25 Feb 2019 17:23:23 +0000
Subject: 11.0.3 backport work completed
In-Reply-To: <816cf81d510b443283d07a4c61521788@sap.com>
References: <451f03ea054447659313f522fbce3e63@sap.com>
 <8fb18912-8033-051f-015e-13d791504a97@redhat.com>
 <301dfd68329b42079bcc06a8e2ef3144@sap.com>
 <025bc9f0-fa24-8a27-ed1c-7c6e09776824@redhat.com>
 <8af2d8cca364425c9d81592086b00e86@sap.com>
 <f11c6dc8-8608-a702-c696-b8e676e0eb55@redhat.com>
 <1e84e75b-c9a9-d1b3-ae57-58407b380d82@redhat.com>
 <816cf81d510b443283d07a4c61521788@sap.com>
Message-ID: <ac11cb20-d8da-0b0a-de43-d495e7c663b0@redhat.com>

On 2/25/19 8:29 AM, Langer, Christoph wrote:
> Absolutely. Let's go create jdk11u-dev.

I sent the request.

-- 
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 TOSHIONA at jp.ibm.com  Tue Feb 26 06:59:26 2019
From: TOSHIONA at jp.ibm.com (Toshio 5 Nakamura)
Date: Tue, 26 Feb 2019 15:59:26 +0900
Subject: JDK-8211267[12u] (Re: Pending pushes for approved 11u backports)
In-Reply-To: <13833897-b11b-fce2-527b-e73af6c1d811@redhat.com>
References: <7014a3ae-ebac-c7e6-5658-17fc95e4da55@redhat.com>
 <OF1B930E62.46AF257C-ON002583A7.007F731F-492583A7.007FA643@notes.na.collabserv.com>
 <005a549e-18f1-e948-78df-abc64f171e8b@redhat.com>
 <13833897-b11b-fce2-527b-e73af6c1d811@redhat.com>
Message-ID: <OFF1AE8F43.A450A740-ON002583AD.001C528C-492583AD.00266682@notes.na.collabserv.com>


Hi Aleksey,

Thank you for your kind support.
Since JDK-8211267 got jdk12u-fix-yes, could you sponsor this request for
12u?

Thanks,
Toshio Nakamura

Aleksey Shipilev <shade at redhat.com> wrote on 2019/02/21 19:41:58:

> From: Aleksey Shipilev <shade at redhat.com>
> To: Toshio 5 Nakamura <TOSHIONA at jp.ibm.com>
> Cc: "jdk-updates-dev at openjdk.java.net" <jdk-updates-dev at openjdk.java.net>
> Date: 2019/02/21 19:42
> Subject: Re: Pending pushes for approved 11u backports
>
> On 2/21/19 1:01 AM, Aleksey Shipilev wrote:
> > On 2/21/19 12:14 AM, Toshio 5 Nakamura wrote:
> >> Hi Aleksey,
> >>
> >> Yes, may I ask a sponsor for these requests?
> >>
> >>> Toshio Nakamura: You need sponsor for this, right? You don't have
> >>> JDK Updates privileges in Census.
> >>> ? https://bugs.openjdk.java.net/browse/JDK-8213183
> >>> ? https://bugs.openjdk.java.net/browse/JDK-8211267
> >
> > No problem, I would sponsor these for you tomorrow.
>
> Pushed to 11u. Toshio, please look at JDK-8211267, should it be in
> 12u as well? If so, please work
> with 12u update process to get it approved. I can push this to 12u
> once approved.
>
> -Aleksey

From shade at redhat.com  Tue Feb 26 08:52:20 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 26 Feb 2019 09:52:20 +0100
Subject: JDK-8211267[12u] (Re: Pending pushes for approved 11u backports)
In-Reply-To: <OFF1AE8F43.A450A740-ON002583AD.001C528C-492583AD.00266682@notes.na.collabserv.com>
References: <7014a3ae-ebac-c7e6-5658-17fc95e4da55@redhat.com>
 <OF1B930E62.46AF257C-ON002583A7.007F731F-492583A7.007FA643@notes.na.collabserv.com>
 <005a549e-18f1-e948-78df-abc64f171e8b@redhat.com>
 <13833897-b11b-fce2-527b-e73af6c1d811@redhat.com>
 <OFF1AE8F43.A450A740-ON002583AD.001C528C-492583AD.00266682@notes.na.collabserv.com>
Message-ID: <01d81669-1327-3c8c-6b30-379e964ed150@redhat.com>

On 2/26/19 7:59 AM, Toshio 5 Nakamura wrote:
> Hi Aleksey,
> 
> Thank you for your kind support.
> Since JDK-8211267 got jdk12u-fix-yes, could you sponsor this request for 12u?

I think I already did yesterday:
  http://hg.openjdk.java.net/jdk-updates/jdk12u/rev/c9cf91c3949c

-Aleksey



From christoph.langer at sap.com  Tue Feb 26 10:18:37 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 26 Feb 2019 10:18:37 +0000
Subject: jdk11 updates: furhter process and tagging
Message-ID: <c90e9edf546c47ff8dc7de587441e7a6@sap.com>

Hi,

I?ve seen that jdk11u-dev is there [0]. Yey. ??

As per the usual tagging in update releases (for details I suggest to read JDK-8180946 [1]), I propose to add the following tags now:
1. Add tag jdk-11.0.4+0 to jdk11u-dev
2. Add tag jdk-11.0.3+1 to jdk11u

For 11u-dev it basically means that this is the moment when we start working on 11.0.4 in there.
For 11u the new tag is motivated by the fact that all targeted 11.0.3 updates are contained in the repo and some comprehensive testing has been done (at SAP and at RedHat, I suppose).

If you concur, I would set both tags.

Further tagging shall be done in jdk11u once additional fixes arrive and testing has proved that no regressions have been introduced. Eventually, we?ll also need to define our testing and quality criteria. Until we have that, I propose the SAP team and the RedHat team shall sync about their quality status before adding a further tag. Are there any other contributors that can/want to help with quality assessment at this point?

I also suggest that as of now our criteria for accepting fixes to jkd11u will be similar to those of RDP2 of JEP 3 [2]:
- P1 and P2 issues
- Issues that Oracle brings to 11.0.3-oracle
- Test fixes

All fixes, obviously, will need maintainer approval.

Thanks & Best regards
Christoph

[0] http://hg.openjdk.java.net/jdk-updates/jdk11u-dev/
[1] https://bugs.openjdk.java.net/browse/JDK-8180946
[2] https://openjdk.java.net/jeps/3


From goetz.lindenmaier at sap.com  Tue Feb 26 10:23:49 2019
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Tue, 26 Feb 2019 10:23:49 +0000
Subject: jdk11 updates: furhter process and tagging
In-Reply-To: <c90e9edf546c47ff8dc7de587441e7a6@sap.com>
References: <c90e9edf546c47ff8dc7de587441e7a6@sap.com>
Message-ID: <2acd92bbdfd8428985d998da889dff3d@sap.com>

Hi Christoph,

What you propose makes sense to me. I would appreciate if we go this way.

Best regards,
  Goetz.

From: Langer, Christoph
Sent: Dienstag, 26. Februar 2019 11:19
To: jdk-updates-dev at openjdk.java.net; Andrew Haley <aph at redhat.com>
Cc: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; Aleksey Shipilev <shade at redhat.com>
Subject: jdk11 updates: furhter process and tagging

Hi,

I?ve seen that jdk11u-dev is there [0]. Yey. ??

As per the usual tagging in update releases (for details I suggest to read JDK-8180946 [1]), I propose to add the following tags now:
1. Add tag jdk-11.0.4+0 to jdk11u-dev
2. Add tag jdk-11.0.3+1 to jdk11u

For 11u-dev it basically means that this is the moment when we start working on 11.0.4 in there.
For 11u the new tag is motivated by the fact that all targeted 11.0.3 updates are contained in the repo and some comprehensive testing has been done (at SAP and at RedHat, I suppose).

If you concur, I would set both tags.

Further tagging shall be done in jdk11u once additional fixes arrive and testing has proved that no regressions have been introduced. Eventually, we?ll also need to define our testing and quality criteria. Until we have that, I propose the SAP team and the RedHat team shall sync about their quality status before adding a further tag. Are there any other contributors that can/want to help with quality assessment at this point?

I also suggest that as of now our criteria for accepting fixes to jkd11u will be similar to those of RDP2 of JEP 3 [2]:
- P1 and P2 issues
- Issues that Oracle brings to 11.0.3-oracle
- Test fixes

All fixes, obviously, will need maintainer approval.

Thanks & Best regards
Christoph

[0] http://hg.openjdk.java.net/jdk-updates/jdk11u-dev/
[1] https://bugs.openjdk.java.net/browse/JDK-8180946
[2] https://openjdk.java.net/jeps/3


From christoph.langer at sap.com  Tue Feb 26 13:12:02 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 26 Feb 2019 13:12:02 +0000
Subject: RFR + RFA [XS]: 8219710: Bump update version for OpenJDK: jdk11.0.4
Message-ID: <69d45176681a477194056d9eecf67697@sap.com>

Hi,

with the jdk11u-dev repo available, it is time to update the version number in there to start OpenJDK 11.0.4 activities.

Please review and approve:

Bug: https://bugs.openjdk.java.net/browse/JDK-8219710
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8219710.0/

I would push this as the first change in jdk11u-dev after tagging the current state as jdk-11.0.4+0. (https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-February/000621.html)

Best regards
Christoph


From shade at redhat.com  Tue Feb 26 13:15:29 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 26 Feb 2019 14:15:29 +0100
Subject: jdk-updates/jdk11u-dev tarball
Message-ID: <6de7d6cf-a6ba-8710-63e4-6a08b2f3adfe@redhat.com>

In case hg.o.j.n is too slow for you, jdk-updates/jdk11u-dev tarball is available:
  https://builds.shipilev.net/workspaces/
  https://builds.shipilev.net/workspaces/jdk-updates-jdk11u-dev.tar.xz

-Aleksey


From goetz.lindenmaier at sap.com  Tue Feb 26 13:35:52 2019
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Tue, 26 Feb 2019 13:35:52 +0000
Subject: RFR + RFA [XS]: 8219710: Bump update version for OpenJDK:
 jdk11.0.4
In-Reply-To: <69d45176681a477194056d9eecf67697@sap.com>
References: <69d45176681a477194056d9eecf67697@sap.com>
Message-ID: <1930a352a3e44771b587a6517f66d496@sap.com>

Hi Christoph,

the change looks good. 
Do you need a jdk11u-fix-request for this? 

Best regards,
  Goetz.

> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> Behalf Of Langer, Christoph
> Sent: Dienstag, 26. Februar 2019 14:12
> To: jdk-updates-dev at openjdk.java.net
> Subject: [CAUTION] RFR + RFA [XS]: 8219710: Bump update version for
> OpenJDK: jdk11.0.4
> 
> Hi,
> 
> with the jdk11u-dev repo available, it is time to update the version number in
> there to start OpenJDK 11.0.4 activities.
> 
> Please review and approve:
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8219710
> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8219710.0/
> 
> I would push this as the first change in jdk11u-dev after tagging the current
> state as jdk-11.0.4+0. (https://mail.openjdk.java.net/pipermail/jdk-updates-
> dev/2019-February/000621.html)
> 
> Best regards
> Christoph


From christoph.langer at sap.com  Tue Feb 26 13:46:14 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 26 Feb 2019 13:46:14 +0000
Subject: RFR + RFA [XS]: 8219710: Bump update version for OpenJDK:
 jdk11.0.4
In-Reply-To: <1930a352a3e44771b587a6517f66d496@sap.com>
References: <69d45176681a477194056d9eecf67697@sap.com>
 <1930a352a3e44771b587a6517f66d496@sap.com>
Message-ID: <9c3673abd53c49a0b02afba79c6f01ff@sap.com>

> the change looks good.
> Do you need a jdk11u-fix-request for this?

Aah, right, I forgot. ?? Just added it...

Thanks for reviewing.

/Christoph


From GIDON at il.ibm.com  Tue Feb 26 13:55:58 2019
From: GIDON at il.ibm.com (Gidon Gershinsky)
Date: Tue, 26 Feb 2019 15:55:58 +0200
Subject: Encryption fix in HotSpot
Message-ID: <OFADE95772.64B449E3-ONC22583AD.004B8E66-C22583AD.004C8913@notes.na.collabserv.com>

An AES-GCM encryption problem, causing a glacially slow startup, had been 
recently fixed in Java 13.
https://hg.openjdk.java.net/jdk/jdk/rev/f35a8aaabcb9

The fix has also been backported to Java 12 and Oracle Java 11.
https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8201633

Can it also be backported to OpenJDK Java 11? This is a very significant 
performance problem, that needs to be fixed in order for AES-GCM (one of 
the main encryption modes today) to be really workable in Java 11.



Regards, 
Gidon




From shade at redhat.com  Tue Feb 26 13:59:12 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 26 Feb 2019 14:59:12 +0100
Subject: Encryption fix in HotSpot
In-Reply-To: <OFADE95772.64B449E3-ONC22583AD.004B8E66-C22583AD.004C8913@notes.na.collabserv.com>
References: <OFADE95772.64B449E3-ONC22583AD.004B8E66-C22583AD.004C8913@notes.na.collabserv.com>
Message-ID: <2cb2c58f-1345-9bc3-b665-750abe3e4c7a@redhat.com>

On 2/26/19 2:55 PM, Gidon Gershinsky wrote:
> An AES-GCM encryption problem, causing a glacially slow startup, had been 
> recently fixed in Java 13.
> https://hg.openjdk.java.net/jdk/jdk/rev/f35a8aaabcb9
> 
> The fix has also been backported to Java 12 and Oracle Java 11.
> https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8201633
> 
> Can it also be backported to OpenJDK Java 11? This is a very significant 
> performance problem, that needs to be fixed in order for AES-GCM (one of 
> the main encryption modes today) to be really workable in Java 11.

It is on the list to backport to 11.0.4:
  https://bugs.openjdk.java.net/issues/?filter=36409

Once 11.0.4 opens, we can start backporting these. You are welcome to do it :)

-Aleksey


From aph at redhat.com  Tue Feb 26 18:21:50 2019
From: aph at redhat.com (Andrew Haley)
Date: Tue, 26 Feb 2019 18:21:50 +0000
Subject: 8u/11u repo access and Jira changes
Message-ID: <372f2232-1c3d-a358-17d7-28fa1d563995@redhat.com>

https://hg.openjdk.java.net/jdk8u/jdk8u is now writable by all JDK 8u
Reviewers and Committers. HOWEVER, don't commit anything to
it. Instead, commit to jdk8u-dev.

hgupdater is set to openjdk8u211 for jdk8u.

jdk-updates/jdk11u-dev now exists, and it's the commit repo for
jdk11u.

jdk8u/jdk8u-jfr-incubator/ now exists for JFR integration. As far as I
can see, dicussion is still in progress.  Right now, a bugid and
review is required. Do we want that for JFR? We could relax the
requirement while work is in progress, and commit the JFR port as a
single change later.

hgupdater is not set for jdk8u-jfr-incubator. I think that's probably
the right for the time being.

-- 
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 aph at redhat.com  Tue Feb 26 18:26:24 2019
From: aph at redhat.com (Andrew Haley)
Date: Tue, 26 Feb 2019 18:26:24 +0000
Subject: jdk11 updates: furhter process and tagging
In-Reply-To: <c90e9edf546c47ff8dc7de587441e7a6@sap.com>
References: <c90e9edf546c47ff8dc7de587441e7a6@sap.com>
Message-ID: <ce547bbc-dada-44fb-14c1-576c63496b14@redhat.com>

On 2/26/19 10:18 AM, Langer, Christoph wrote:
> I?ve seen that jdk11u-dev is there [0]. Yey. ??
> 
> As per the usual tagging in update releases (for details I suggest to read JDK-8180946 [1]), I propose to add the following tags now:
> 1. Add tag jdk-11.0.4+0 to jdk11u-dev
> 2. Add tag jdk-11.0.3+1 to jdk11u

Sounds good.

> For 11u-dev it basically means that this is the moment when we start
> working on 11.0.4 in there.  For 11u the new tag is motivated by the
> fact that all targeted 11.0.3 updates are contained in the repo and
> some comprehensive testing has been done (at SAP and at RedHat, I
> suppose).

Hmm, I think so. Does anyone know otherwise? Scream now!

> I also suggest that as of now our criteria for accepting fixes to
> jkd11u will be similar to those of RDP2 of JEP 3 [2]:
> - P1 and P2 issues
> - Issues that Oracle brings to 11.0.3-oracle
> - Test fixes

In other words, anything that the maintainers think needs to go in and
has been targeted to jdk-11.0.3.

-- 
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 shade at redhat.com  Tue Feb 26 18:30:18 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 26 Feb 2019 19:30:18 +0100
Subject: 8u/11u repo access and Jira changes
In-Reply-To: <372f2232-1c3d-a358-17d7-28fa1d563995@redhat.com>
References: <372f2232-1c3d-a358-17d7-28fa1d563995@redhat.com>
Message-ID: <242e376c-0b96-1d87-dd51-e9d35844d021@redhat.com>

On 2/26/19 7:21 PM, Andrew Haley wrote:
> https://hg.openjdk.java.net/jdk8u/jdk8u is now writable by all JDK 8u
> Reviewers and Committers. HOWEVER, don't commit anything to
> it. Instead, commit to jdk8u-dev.

Wait, can't we limit the push privileges to jdk8u/jdk8u to avoid surprises? I would prefer computers
do things for us for a change. No matter how we try to follow the processes, mistakes would happen,
and we better catch them mechanically. Ditto for jdk-updates/jdk11u.

-Aleksey


From aph at redhat.com  Tue Feb 26 18:46:57 2019
From: aph at redhat.com (Andrew Haley)
Date: Tue, 26 Feb 2019 18:46:57 +0000
Subject: 8u/11u repo access and Jira changes
In-Reply-To: <242e376c-0b96-1d87-dd51-e9d35844d021@redhat.com>
References: <372f2232-1c3d-a358-17d7-28fa1d563995@redhat.com>
 <242e376c-0b96-1d87-dd51-e9d35844d021@redhat.com>
Message-ID: <9d4c5d26-b02e-daac-0ba4-9780412451a5@redhat.com>

On 2/26/19 6:30 PM, Aleksey Shipilev wrote:
> On 2/26/19 7:21 PM, Andrew Haley wrote:
>> https://hg.openjdk.java.net/jdk8u/jdk8u is now writable by all JDK 8u
>> Reviewers and Committers. HOWEVER, don't commit anything to
>> it. Instead, commit to jdk8u-dev.
> 
> Wait, can't we limit the push privileges to jdk8u/jdk8u to avoid
> surprises?

We could, but...

> I would prefer computers do things for us for a change. No matter
> how we try to follow the processes, mistakes would happen, and we
> better catch them mechanically. Ditto for jdk-updates/jdk11u.

As I said in
https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-February/000446.html,

  The problem is that we've been conflating two roles in the
  "maintainer". One is someone whose role is essentially judgmental:
  they decide whether a patch is suitable for a particular
  release. The other role is integrative: they merge a patch into a
  release branch and make sure the result works by testing it. These
  two roles are not the same thing, and require different skills.

  We are likely to encounter scaling problems as we work on the
  updates projects and we will do ourselves no favours by creating
  bottlenecks to efficient parallel working. A mature updates project
  would allow many people, with different skills, to work together on
  a release branch. Not all of these people would have the authority
  (or even the desire) to approve patches.

We have a group responsible for managing the release branch, and these
could be the people with commit access to that tree. But I
don't want to restrict that group necessarily to be the maintainers.

-- 
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 shade at redhat.com  Tue Feb 26 18:54:50 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 26 Feb 2019 19:54:50 +0100
Subject: 8u/11u repo access and Jira changes
In-Reply-To: <9d4c5d26-b02e-daac-0ba4-9780412451a5@redhat.com>
References: <372f2232-1c3d-a358-17d7-28fa1d563995@redhat.com>
 <242e376c-0b96-1d87-dd51-e9d35844d021@redhat.com>
 <9d4c5d26-b02e-daac-0ba4-9780412451a5@redhat.com>
Message-ID: <2f1b50ed-bb26-add1-bc64-012f6e5fc208@redhat.com>

On 2/26/19 7:46 PM, Andrew Haley wrote:
> We have a group responsible for managing the release branch, and these
> could be the people with commit access to that tree. But I
> don't want to restrict that group necessarily to be the maintainers.

I do want it, though.

We would have lots of committers that come and push changesets to update projects. I would very much
prefer that machines prohibit us from committing (pun intended) mistakes that can be mechanically
checked. Regular Reviewers and Committers have no business pushing into stable tree, and this should
be mechanically forbidden. There is no need to restrict the push privileges to stable tree to
maintainers only, but it should be restricted to some subset of users who have the need to modify it.

In other needs, trust people, but also set up processes so that they cannot make simple mistakes.

-Aleksey



From manc at google.com  Tue Feb 26 19:04:36 2019
From: manc at google.com (Man Cao)
Date: Tue, 26 Feb 2019 11:04:36 -0800
Subject: How to run tests before pushing a backport changeset?
In-Reply-To: <CA+kOe0_0JnoZQ3wQNigx_YG_ZhFSdVzL2yDY4Noox04w4FtF+g@mail.gmail.com>
References: <CA+w6Hxbe+Ye7tqjGxzB8LDHRWZdDLQyT20pWZk_VTDqbc4z4uQ@mail.gmail.com>
 <f2a642ff-ff81-f52e-ea50-13b845d52d15@redhat.com>
 <CA+kOe0-7S+2LZEg+ieb0pbQwb=Jd2XTNqjkPfYQTmN4YS_Jnug@mail.gmail.com>
 <7a3048c2-b493-d3d0-970d-394b5e033aa6@redhat.com>
 <3371d68c-d6ea-7e03-85d2-0b6cfa09b54d@redhat.com>
 <CAP7YuASoLMowQL3a-+UXKzZ_pnsUbD8bocadG-CkrHo0rw420w@mail.gmail.com>
 <CA+kOe0_0JnoZQ3wQNigx_YG_ZhFSdVzL2yDY4Noox04w4FtF+g@mail.gmail.com>
Message-ID: <CA+w6HxZq9omdmcRPEonzTN37nYkLxqN++Jr76+cGru=QhFcTRg@mail.gmail.com>

Hi,

We have a follow-up question: is there any difference on the testing policy
for JDK12u? Should we seek sponsorship from one of the maintainers from
Oracle to run tests before pushing a backport changeset to JDK12u? Or could
we just run tier1 tests for fastdebug|release locally and then push?
Also, any changeset that goes into jdk-updates/jdk12u should NOT affect the
soon-to-be-released JDK12 that is currently in Release Candidate phase,
right?

Could one of the CCed JDK12u maintainers also provide some clarification?

-Man

From aph at redhat.com  Tue Feb 26 19:06:40 2019
From: aph at redhat.com (Andrew Haley)
Date: Tue, 26 Feb 2019 19:06:40 +0000
Subject: 8u/11u repo access and Jira changes
In-Reply-To: <2f1b50ed-bb26-add1-bc64-012f6e5fc208@redhat.com>
References: <372f2232-1c3d-a358-17d7-28fa1d563995@redhat.com>
 <242e376c-0b96-1d87-dd51-e9d35844d021@redhat.com>
 <9d4c5d26-b02e-daac-0ba4-9780412451a5@redhat.com>
 <2f1b50ed-bb26-add1-bc64-012f6e5fc208@redhat.com>
Message-ID: <3dd8687d-e9c6-4f1b-ec47-a8d9506894dd@redhat.com>

On 2/26/19 6:54 PM, Aleksey Shipilev wrote:
> On 2/26/19 7:46 PM, Andrew Haley wrote:
>> We have a group responsible for managing the release branch, and these
>> could be the people with commit access to that tree. But I
>> don't want to restrict that group necessarily to be the maintainers.
> 
> I do want it, though.

I am aware of that. However, I disgree, and I explained why, but this
response does not address my reasons.

> We would have lots of committers that come and push changesets to
> update projects.

I don't quite understand this sentence.

> I would very much prefer that machines prohibit us from committing
> (pun intended) mistakes that can be mechanically checked. Regular
> Reviewers and Committers have no business pushing into stable tree,
> and this should be mechanically forbidden. There is no need to
> restrict the push privileges to stable tree to maintainers only, but
> it should be restricted to some subset of users who have the need to
> modify it.

I don't object to that, as long as it's flexible enough to allow us
quickly to authorize people to work on the release tree.

> In other needs, trust people, but also set up processes so that they
> cannot make simple mistakes.

This seems to contradict your earlier statement. blocking access
to only allow maintainers doesn't only prevent mistakes.

-- 
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 christoph.langer at sap.com  Tue Feb 26 19:41:39 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 26 Feb 2019 19:41:39 +0000
Subject: 8u/11u repo access and Jira changes
In-Reply-To: <3dd8687d-e9c6-4f1b-ec47-a8d9506894dd@redhat.com>
References: <372f2232-1c3d-a358-17d7-28fa1d563995@redhat.com>
 <242e376c-0b96-1d87-dd51-e9d35844d021@redhat.com>
 <9d4c5d26-b02e-daac-0ba4-9780412451a5@redhat.com>
 <2f1b50ed-bb26-add1-bc64-012f6e5fc208@redhat.com>
 <3dd8687d-e9c6-4f1b-ec47-a8d9506894dd@redhat.com>
Message-ID: <3c1178e962ac45448349d6d4f56ba976@sap.com>

Hi,

I'd rather second Andrew in this discussion.

Initially I also thought it might be more sensible to restrict the subset of people with commit permissions to jdk8u/jdk11u. But if I think more about it I rather think we should keep it open. At least try to get some experiences.

Here are my reasons:
- Look at how it works with the jdk/jdk12 repositories for upstream development. There, jdk12 got more and more restrictions applied and in fact it's virtually closed now at release candidate phase. But the repository is not closed, theoretically everybody could push
- If somebody pushes by mistake to the non dev repository, this can always be backouted
- I think some changes can/will still need to go to jdk11u first (e.g. certain test fixes, changes that Oracle promotes to 11.0.3-oracle, P1 issues that we approve). For these scenarios it would be beneficial if no restrictions apply to the set of allowed committers.
- process wise it's easier to handle

Best regards
Christoph

> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> Behalf Of Andrew Haley
> Sent: Dienstag, 26. Februar 2019 20:07
> To: Aleksey Shipilev <shade at redhat.com>; jdk-updates-
> dev at openjdk.java.net; jdk8u-dev at openjdk.java.net
> Subject: Re: 8u/11u repo access and Jira changes
> 
> On 2/26/19 6:54 PM, Aleksey Shipilev wrote:
> > On 2/26/19 7:46 PM, Andrew Haley wrote:
> >> We have a group responsible for managing the release branch, and these
> >> could be the people with commit access to that tree. But I
> >> don't want to restrict that group necessarily to be the maintainers.
> >
> > I do want it, though.
> 
> I am aware of that. However, I disgree, and I explained why, but this
> response does not address my reasons.
> 
> > We would have lots of committers that come and push changesets to
> > update projects.
> 
> I don't quite understand this sentence.
> 
> > I would very much prefer that machines prohibit us from committing
> > (pun intended) mistakes that can be mechanically checked. Regular
> > Reviewers and Committers have no business pushing into stable tree,
> > and this should be mechanically forbidden. There is no need to
> > restrict the push privileges to stable tree to maintainers only, but
> > it should be restricted to some subset of users who have the need to
> > modify it.
> 
> I don't object to that, as long as it's flexible enough to allow us
> quickly to authorize people to work on the release tree.
> 
> > In other needs, trust people, but also set up processes so that they
> > cannot make simple mistakes.
> 
> This seems to contradict your earlier statement. blocking access
> to only allow maintainers doesn't only prevent mistakes.
> 
> --
> 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 aph at redhat.com  Tue Feb 26 19:43:27 2019
From: aph at redhat.com (Andrew Haley)
Date: Tue, 26 Feb 2019 19:43:27 +0000
Subject: 8u/11u repo access and Jira changes
In-Reply-To: <3c1178e962ac45448349d6d4f56ba976@sap.com>
References: <372f2232-1c3d-a358-17d7-28fa1d563995@redhat.com>
 <242e376c-0b96-1d87-dd51-e9d35844d021@redhat.com>
 <9d4c5d26-b02e-daac-0ba4-9780412451a5@redhat.com>
 <2f1b50ed-bb26-add1-bc64-012f6e5fc208@redhat.com>
 <3dd8687d-e9c6-4f1b-ec47-a8d9506894dd@redhat.com>
 <3c1178e962ac45448349d6d4f56ba976@sap.com>
Message-ID: <667c6c9e-fbe1-0474-8ad7-3f30130a4761@redhat.com>

On 2/26/19 7:41 PM, Langer, Christoph wrote:
> I'd rather second Andrew in this discussion.

Well, thank you. I wasn't expecting that. :-)

-- 
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 shade at redhat.com  Tue Feb 26 19:46:34 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 26 Feb 2019 20:46:34 +0100
Subject: 8u/11u repo access and Jira changes
In-Reply-To: <3dd8687d-e9c6-4f1b-ec47-a8d9506894dd@redhat.com>
References: <372f2232-1c3d-a358-17d7-28fa1d563995@redhat.com>
 <242e376c-0b96-1d87-dd51-e9d35844d021@redhat.com>
 <9d4c5d26-b02e-daac-0ba4-9780412451a5@redhat.com>
 <2f1b50ed-bb26-add1-bc64-012f6e5fc208@redhat.com>
 <3dd8687d-e9c6-4f1b-ec47-a8d9506894dd@redhat.com>
Message-ID: <06f09798-cade-b882-fb3e-4049733fa8cc@redhat.com>

On 2/26/19 8:06 PM, Andrew Haley wrote:
> On 2/26/19 6:54 PM, Aleksey Shipilev wrote:
>> We would have lots of committers that come and push changesets to
>> update projects.
> 
> I don't quite understand this sentence.

Trying again: in update projects, we have lots of committers that are not intimately aware of all
the codified rules and conventions of the update project, no matter in how many words it is written
somewhere. The newcomer can just push to jdk8u/jdk8u without thinking twice. The experienced
committer can push to jdk8u/jdk8u by mistake. I do expect accidental pushes to jdk-updates/jdk11u
just because somebody forgot to switch to jdk-updates/jdk11u-dev.


>> I would very much prefer that machines prohibit us from committing
>> (pun intended) mistakes that can be mechanically checked. Regular
>> Reviewers and Committers have no business pushing into stable tree,
>> and this should be mechanically forbidden. There is no need to
>> restrict the push privileges to stable tree to maintainers only, but
>> it should be restricted to some subset of users who have the need to
>> modify it.
> 
> I don't object to that, as long as it's flexible enough to allow us
> quickly to authorize people to work on the release tree.

I think that: a) traffic to stable release should be small; b) traffic that goes to stable release
is probably coming through the maintainers anyway; c) ops@ are pretty responsive.

>> In other needs, trust people, but also set up processes so that they
>> cannot make simple mistakes.
> 
> This seems to contradict your earlier statement. blocking access
> to only allow maintainers doesn't only prevent mistakes.

Yes, that introduces barriers, friction, and more work. That is actually a good thing: good systems
provide barriers that prevent the majority of people from making simple mistakes at the cost of some
friction and making a few people lives a bit harder.

Maintainers basically subscribe themselves for maintenance chores. There are two ways to deal with
the additional work: a) Elect/designate more maintainers; b) Authorize _someone else_, not
necessarily a maintainer, to push to stable tree; this gets us out of this maintainer-committer
dichotomy to begin with.

I have no energy to fight it, though. If you want to keep stable tree pushable for everyone, fine. I
do reserve the right to say "told you so" every time the "Oops, I pushed to the wrong tree, sorry"
thread appears, requiring the backout, cleaning up the hgupdater mess in JIRA (I don't even want to
think how backouts work with backports...), and perhaps invalidating the testing done for the stable
release (which are also time-sensitive, tick-tock...) ;)

-Aleksey



From shade at redhat.com  Tue Feb 26 19:57:27 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 26 Feb 2019 20:57:27 +0100
Subject: 8u/11u repo access and Jira changes
In-Reply-To: <3c1178e962ac45448349d6d4f56ba976@sap.com>
References: <372f2232-1c3d-a358-17d7-28fa1d563995@redhat.com>
 <242e376c-0b96-1d87-dd51-e9d35844d021@redhat.com>
 <9d4c5d26-b02e-daac-0ba4-9780412451a5@redhat.com>
 <2f1b50ed-bb26-add1-bc64-012f6e5fc208@redhat.com>
 <3dd8687d-e9c6-4f1b-ec47-a8d9506894dd@redhat.com>
 <3c1178e962ac45448349d6d4f56ba976@sap.com>
Message-ID: <12aded5c-c2c6-8ac4-41b8-cca7a740fc12@redhat.com>

On 2/26/19 8:41 PM, Langer, Christoph wrote:
> - Look at how it works with the jdk/jdk12 repositories for upstream development. There, jdk12 got more and more restrictions applied and in fact it's virtually closed now at release candidate phase. But the repository is not closed, theoretically everybody could push

Yes, and jdk/jdk12 is the interesting example.

First, jdk/jdk12 is really a separate repository that you would not have on your machine, unless you
had the intent to push to jdk12 at least once. The majority of committers don't, which makes the
mistakes less frequent. It is one of the very good process moves to have jdk/jdk that is always
catch-all, and any stabilization forests fork off separately, requiring separate action to work with
it. Note it is exactly the opposite of jdk-updates/jdk11u and jdk-updates/jdk11u-dev situation: most
people have the _wrong_ repository locally.

Second, people (experienced people!) who have both jdk/jdk and jdk/jdk12 trees routinely mix them up
and push the change designated to one repository, into the other one. I did it at least once. People
around me did it at least twice. The saving grace there is pushing to "wrong" repository does not
require the backout there, so these mistakes are rectified cleanly.

> - If somebody pushes by mistake to the non dev repository, this can always be backouted

Right. Do we know how hgupdater and backports backouts work? Do we really want to test it during the
maintainership takeover? Do we need to modify reports to avoid backouted backports too?

-Aleksey


From aph at redhat.com  Tue Feb 26 20:04:17 2019
From: aph at redhat.com (Andrew Haley)
Date: Tue, 26 Feb 2019 20:04:17 +0000
Subject: 8u/11u repo access and Jira changes
In-Reply-To: <06f09798-cade-b882-fb3e-4049733fa8cc@redhat.com>
References: <372f2232-1c3d-a358-17d7-28fa1d563995@redhat.com>
 <242e376c-0b96-1d87-dd51-e9d35844d021@redhat.com>
 <9d4c5d26-b02e-daac-0ba4-9780412451a5@redhat.com>
 <2f1b50ed-bb26-add1-bc64-012f6e5fc208@redhat.com>
 <3dd8687d-e9c6-4f1b-ec47-a8d9506894dd@redhat.com>
 <06f09798-cade-b882-fb3e-4049733fa8cc@redhat.com>
Message-ID: <8bba13dc-53f6-90c1-a379-d43adc528d97@redhat.com>

On 2/26/19 7:46 PM, Aleksey Shipilev wrote:

> Maintainers basically subscribe themselves for maintenance
> chores. There are two ways to deal with the additional work: a)
> Elect/designate more maintainers; b) Authorize _someone else_, not
> necessarily a maintainer, to push to stable tree; this gets us out
> of this maintainer-committer dichotomy to begin with.

I would prefer b), at least in theory.

> I have no energy to fight it, though. If you want to keep stable
> tree pushable for everyone, fine. I do reserve the right to say
> "told you so" every time the

Oh, sure, it'll probably happen.

> "Oops, I pushed to the wrong tree, sorry" thread appears, requiring
> the backout, cleaning up the hgupdater mess in JIRA (I don't even
> want to think how backouts work with backports...), and perhaps
> invalidating the testing done for the stable release (which are also
> time-sensitive, tick-tock...) ;)

I'm prepared to be proved wrong.

Maybe it's a cultural thing. I've worked on other large-scale free
software projects (GCC, in particular) where it just wasn't an issue
because people knew when they should be working on a release branch
and it simply wasn't an issue, but equally it was obvious which were
the release branches. Perhaps people working on OpenJDK aren't up to
it. :-)

-- 
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 aph at redhat.com  Tue Feb 26 20:05:20 2019
From: aph at redhat.com (Andrew Haley)
Date: Tue, 26 Feb 2019 20:05:20 +0000
Subject: 8u/11u repo access and Jira changes
In-Reply-To: <12aded5c-c2c6-8ac4-41b8-cca7a740fc12@redhat.com>
References: <372f2232-1c3d-a358-17d7-28fa1d563995@redhat.com>
 <242e376c-0b96-1d87-dd51-e9d35844d021@redhat.com>
 <9d4c5d26-b02e-daac-0ba4-9780412451a5@redhat.com>
 <2f1b50ed-bb26-add1-bc64-012f6e5fc208@redhat.com>
 <3dd8687d-e9c6-4f1b-ec47-a8d9506894dd@redhat.com>
 <3c1178e962ac45448349d6d4f56ba976@sap.com>
 <12aded5c-c2c6-8ac4-41b8-cca7a740fc12@redhat.com>
Message-ID: <26796f51-2eb8-7a9c-825c-24fa544220fd@redhat.com>

On 2/26/19 7:57 PM, Aleksey Shipilev wrote:
>> - If somebody pushes by mistake to the non dev repository, this can always be backouted
> Right. Do we know how hgupdater and backports backouts work? Do we really want to test it during the
> maintainership takeover? Do we need to modify reports to avoid backouted backports too?

Well, hold on. If we can't back out backports on the release branch
because of hgupdater problems then that's a problem we need to fix.

-- 
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 shade at redhat.com  Tue Feb 26 20:23:04 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 26 Feb 2019 21:23:04 +0100
Subject: 8u/11u repo access and Jira changes
In-Reply-To: <8bba13dc-53f6-90c1-a379-d43adc528d97@redhat.com>
References: <372f2232-1c3d-a358-17d7-28fa1d563995@redhat.com>
 <242e376c-0b96-1d87-dd51-e9d35844d021@redhat.com>
 <9d4c5d26-b02e-daac-0ba4-9780412451a5@redhat.com>
 <2f1b50ed-bb26-add1-bc64-012f6e5fc208@redhat.com>
 <3dd8687d-e9c6-4f1b-ec47-a8d9506894dd@redhat.com>
 <06f09798-cade-b882-fb3e-4049733fa8cc@redhat.com>
 <8bba13dc-53f6-90c1-a379-d43adc528d97@redhat.com>
Message-ID: <0a0ac28e-438f-7a07-56c3-664b8cd3a97e@redhat.com>

On 2/26/19 9:04 PM, Andrew Haley wrote:
> On 2/26/19 7:46 PM, Aleksey Shipilev wrote:
> Maybe it's a cultural thing. I've worked on other large-scale free
> software projects (GCC, in particular) where it just wasn't an issue
> because people knew when they should be working on a release branch
> and it simply wasn't an issue, but equally it was obvious which were
> the release branches. Perhaps people working on OpenJDK aren't up to
> it. :-)

It partially is a cultural thing. I grew up in the culture that assigned all the responsibility to
the individual workers, and no fault was ever systemic; I saw how devastating that is for both the
workers and the system. I understand the reverse side of this: when everything is system fault,
there is no personal responsibility; equally devastating.

So, the limited set of power users that can push to the stable tree is a happy amalgamation of both
approaches: stable tree is "free for all, but not for everybody". ;)

Speaking of large software projects, I think Linux gets it right: maintainers "pull" changes into
upper repositories rather than technically allowing anyone from downstream to push on their own. For
all the perfect people who are working on Linux, that is a saner approach for a responsible
maintainer, in my mind. I think this basically happened with jdk8u/jdk8u and jdk8u/jdk8u-dev split,
and once again I question why do we need to deviate...

-Aleksey



From gnu.andrew at redhat.com  Tue Feb 26 21:10:47 2019
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Tue, 26 Feb 2019 21:10:47 +0000
Subject: 8u/11u repo access and Jira changes
In-Reply-To: <06f09798-cade-b882-fb3e-4049733fa8cc@redhat.com>
References: <372f2232-1c3d-a358-17d7-28fa1d563995@redhat.com>
 <242e376c-0b96-1d87-dd51-e9d35844d021@redhat.com>
 <9d4c5d26-b02e-daac-0ba4-9780412451a5@redhat.com>
 <2f1b50ed-bb26-add1-bc64-012f6e5fc208@redhat.com>
 <3dd8687d-e9c6-4f1b-ec47-a8d9506894dd@redhat.com>
 <06f09798-cade-b882-fb3e-4049733fa8cc@redhat.com>
Message-ID: <CABi63P4FaxHW8enL-ERhwpi=1Des6dWcy5py7um8-yYUOPvE-A@mail.gmail.com>

On Tue, 26 Feb 2019 at 19:47, Aleksey Shipilev <shade at redhat.com> wrote:

snip...

> I have no energy to fight it, though. If you want to keep stable tree pushable for everyone, fine. I
> do reserve the right to say "told you so" every time the "Oops, I pushed to the wrong tree, sorry"
> thread appears, requiring the backout, cleaning up the hgupdater mess in JIRA (I don't even want to
> think how backouts work with backports...), and perhaps invalidating the testing done for the stable
> release (which are also time-sensitive, tick-tock...) ;)
>
> -Aleksey
>
>

Yeah, I really have no energy to argue about this further either, and
I can see both sides;
I've worked on projects, like aph, where the release branch is only
socially restricted, and it works,
but having it done technically does add a bit of peace of mind to
those of us trying to cut releases.

The questions I really need answers to are:

1. Who is going to push from jdk8u-dev -> jdk8u?

2. What is the frequency of these pushes going to be?

3. What testing is going to be performed prior to these pushes?

I'd prefer regular pushes with tags, because that would help us
downstream (aarch64-port/jdk8u-shenandoah,
shenandoah/jdk11) in being able to integrate changes more frequently.
Under Oracle, we've had to do that
at GA time only.

Thanks,
-- 
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 christoph.langer at sap.com  Tue Feb 26 21:24:57 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 26 Feb 2019 21:24:57 +0000
Subject: jdk11 updates: furhter process and tagging
In-Reply-To: <ce547bbc-dada-44fb-14c1-576c63496b14@redhat.com>
References: <c90e9edf546c47ff8dc7de587441e7a6@sap.com>
 <ce547bbc-dada-44fb-14c1-576c63496b14@redhat.com>
Message-ID: <6bb5e84c23314b3880fc703d9e5d7d55@sap.com>

Hi Andrew,

> > As per the usual tagging in update releases (for details I suggest to read
> JDK-8180946 [1]), I propose to add the following tags now:
> > 1. Add tag jdk-11.0.4+0 to jdk11u-dev
> > 2. Add tag jdk-11.0.3+1 to jdk11u
> 
> Sounds good.

Fine. So I'll add the tags tomorrow as proposed.

I'd also ask you to approve https://bugs.openjdk.java.net/browse/JDK-8219710 as the first change for 11.04. I would push it after 11.0.4+0 then.

Thanks
Christoph


From christoph.langer at sap.com  Tue Feb 26 21:40:34 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 26 Feb 2019 21:40:34 +0000
Subject: 8u/11u repo access and Jira changes
In-Reply-To: <CABi63P4FaxHW8enL-ERhwpi=1Des6dWcy5py7um8-yYUOPvE-A@mail.gmail.com>
References: <372f2232-1c3d-a358-17d7-28fa1d563995@redhat.com>
 <242e376c-0b96-1d87-dd51-e9d35844d021@redhat.com>
 <9d4c5d26-b02e-daac-0ba4-9780412451a5@redhat.com>
 <2f1b50ed-bb26-add1-bc64-012f6e5fc208@redhat.com>
 <3dd8687d-e9c6-4f1b-ec47-a8d9506894dd@redhat.com>
 <06f09798-cade-b882-fb3e-4049733fa8cc@redhat.com>
 <CABi63P4FaxHW8enL-ERhwpi=1Des6dWcy5py7um8-yYUOPvE-A@mail.gmail.com>
Message-ID: <3f49543e8bd14cf5b3ed7381abaad339@sap.com>

Hi Andrew,

> The questions I really need answers to are:
> 
> 1. Who is going to push from jdk8u-dev -> jdk8u?

The maintainers (you, Aleksey, me, Goetz, ...)

> 2. What is the frequency of these pushes going to be?

Ok, again, here's our proposal (from the SAP folks):

We sync once per CPU release cycle from jdk8u-dev -> jdk8u, respectively from jdk11u-dev to jdk11u. For jdk11u, we've kind of done it now by the creation of the jdk11u-dev repo. For jdk8u I propose to do the initial push to jdk8u once all open Oracle backports were integrated.
Then, I expect a few pushes to jdk8u/jdk11u and we'll tag these once in a while like jdk-11.0.3+1 etc. These tags will be integrated back to dev regularly (by those who set the tags, that is, the maintainers).
At the release day, you'll sync your security work on top of jdk8u/jdk11u and add a final jdk-11.0.3+xx tag and the jdk-11.0.3-ga tag (which should point to the same change). And this will be integrated back to jdk11u-dev.

What do you think of that?

> 3. What testing is going to be performed prior to these pushes?

Good question, currently I guess it's our quality testing at SAP plus whatever you have at RedHat. We should eventually get to something better, e.g. have some open test results from AdoptOpenJDK...??

> I'd prefer regular pushes with tags, because that would help us
> downstream (aarch64-port/jdk8u-shenandoah,
> shenandoah/jdk11) in being able to integrate changes more frequently.
> Under Oracle, we've had to do that at GA time only.

That should be helped with our concept.

Best regards
Christoph


From christoph.langer at sap.com  Tue Feb 26 22:14:48 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 26 Feb 2019 22:14:48 +0000
Subject: RFA [11u]: JDK-8206120, JDK-8211398, JDK-8218915
Message-ID: <5bbacf965a2c4e1a9e2d952a2c2ad407@sap.com>

Hi,

I hereby request the approval to push the change that fixes JDK-8206120, JDK-8211398 and JDK-8218915 directly to jk11u. The fix is contained in jdk11.0.3-oracle now.

The backport has been reviewed in: https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-February/058596.html.

@Deepak: Would you want to push the change yourself, once approved? Or shall I do it for you, based on the webrev?

Best regards
Christoph


From goetz.lindenmaier at sap.com  Wed Feb 27 06:43:57 2019
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Wed, 27 Feb 2019 06:43:57 +0000
Subject: RFA [11u]: JDK-8206120, JDK-8211398, JDK-8218915
In-Reply-To: <5bbacf965a2c4e1a9e2d952a2c2ad407@sap.com>
References: <5bbacf965a2c4e1a9e2d952a2c2ad407@sap.com>
Message-ID: <4836758fa91f41a18274e2fc5a007805@sap.com>

Hi Christoph, 

Yes, I think too that the Japanese Era changes need to go to jdk11u aka 11.0.3.

Best regards,
  Goetz.

> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> Behalf Of Langer, Christoph
> Sent: Tuesday, February 26, 2019 11:15 PM
> To: Andrew Haley <aph at redhat.com>; jdk-updates-dev at openjdk.java.net;
> Deepak Kejriwal <deepak.kejriwal at oracle.com>
> Subject: [CAUTION] RFA [11u]: JDK-8206120, JDK-8211398, JDK-8218915
> 
> Hi,
> 
> I hereby request the approval to push the change that fixes JDK-8206120,
> JDK-8211398 and JDK-8218915 directly to jk11u. The fix is contained in
> jdk11.0.3-oracle now.
> 
> The backport has been reviewed in:
> https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-
> February/058596.html.
> 
> @Deepak: Would you want to push the change yourself, once approved? Or
> shall I do it for you, based on the webrev?
> 
> Best regards
> Christoph


From goetz.lindenmaier at sap.com  Wed Feb 27 08:09:40 2019
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Wed, 27 Feb 2019 08:09:40 +0000
Subject: 8u/11u repo access and Jira changes
In-Reply-To: <3f49543e8bd14cf5b3ed7381abaad339@sap.com>
References: <372f2232-1c3d-a358-17d7-28fa1d563995@redhat.com>
 <242e376c-0b96-1d87-dd51-e9d35844d021@redhat.com>
 <9d4c5d26-b02e-daac-0ba4-9780412451a5@redhat.com>
 <2f1b50ed-bb26-add1-bc64-012f6e5fc208@redhat.com>
 <3dd8687d-e9c6-4f1b-ec47-a8d9506894dd@redhat.com>
 <06f09798-cade-b882-fb3e-4049733fa8cc@redhat.com>
 <CABi63P4FaxHW8enL-ERhwpi=1Des6dWcy5py7um8-yYUOPvE-A@mail.gmail.com>
 <3f49543e8bd14cf5b3ed7381abaad339@sap.com>
Message-ID: <90c57878b5254c6ca2d496a2a59b8eb8@sap.com>

Hi,



Two points to this lengthy mail thread ??



Rights to push to jdk11u:



I also see that there are a lot of people that may push to jdk11u,

which might be a problem. On the census page, there are 140

reviewers and 155 committers listed for the jdk-updates project.

But so far very few people actually pushed to jdk11u, so I don't

think it's a unbearable risk to keep general push rights.

The people in committer and reviewer roles have proven to

act responsible in this matter.

And it keeps things simple. After all, it is possible to backout

a change that was pushed wrongly.

If we make bad experience, we still can change the policy.



Merging to jdk11u-dev



> Then, I expect a few pushes to jdk8u/jdk11u and we'll tag these once in a

> while like jdk-11.0.3+1 etc. These tags will be integrated back to dev regularly

> (by those who set the tags, that is, the maintainers).

> At the release day, you'll sync your security work on top of jdk8u/jdk11u and

> add a final jdk-11.0.3+xx tag and the jdk-11.0.3-ga tag (which should point to

> the same change). And this will be integrated back to jdk11u-dev.

I think there should be one single person dedicated to do this job. It should

be someone that has backup to keep the job up if on vacation etc.



I (backed up by Christoph and the rest of the SAP team)  would volunteer to

 1. tag jdk11u on a weekly basis after running our tests (if there was a change)

2. merge the tag to jdk11u-dev and run tests on the merged repo

3. push the changes to jdk11u-dev the day after.



I would propose to tag the change that is built by our infrastructure on

the night Tuesday-Wednesday,  which is usually pulled on Tuesday 18:00 CET.

In the night Wednesday-Thursday, the tests would run on jdk11u-dev including

the changes merged from jdk11u.  Test results will pop up during the day (Thursday),

the merged changes could be pushed on Thursday evening or Friday morning.



Our testing currently covers the following:



We build the following platforms:

  Aix

 Linux ppc64

 Linux ppc64le

 Linux s390x

 Linux x86_64

  mac

 Solaris sparc

  Windows x86_64

  Windows x86_32

We finally got an aarch64 machine, we could add that to the tests.



We run the following tests every night:

  A big part of the jck tests (excluding those requiring  manual testing, and a list of shaky tests)

  The jck tests with -Xcomp and C1, and with -Xcomp and C2.

  The hotspot and jdk jtreg tests, excluding those marked with key "headful", "printer" and "intermittent"

  Jvm2008, jbb2015, jvm98

  And finally some SAP applications.



But I'm also fine with leaving this task to RedHat, Aleksey or Andrew Hughes or whoever

would be available on your side.



For the move jdk11u-dev-->jdk11u, which happens only once a release, we should

do this by communication on the mailing list.



Best regards,

  Goetz.







> -----Original Message-----

> From: Langer, Christoph

> Sent: Tuesday, February 26, 2019 10:41 PM

> To: Andrew Hughes <gnu.andrew at redhat.com>

> Cc: jdk8u-dev at openjdk.java.net; jdk-updates-dev at openjdk.java.net;

> Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; Aleksey Shipilev

> <shade at redhat.com>

> Subject: RE: 8u/11u repo access and Jira changes

>

> Hi Andrew,

>

> > The questions I really need answers to are:

> >

> > 1. Who is going to push from jdk8u-dev -> jdk8u?

>

> The maintainers (you, Aleksey, me, Goetz, ...)

>

> > 2. What is the frequency of these pushes going to be?

>

> Ok, again, here's our proposal (from the SAP folks):

>

> We sync once per CPU release cycle from jdk8u-dev -> jdk8u, respectively

> from jdk11u-dev to jdk11u. For jdk11u, we've kind of done it now by the

> creation of the jdk11u-dev repo. For jdk8u I propose to do the initial push to

> jdk8u once all open Oracle backports were integrated.

> Then, I expect a few pushes to jdk8u/jdk11u and we'll tag these once in a

> while like jdk-11.0.3+1 etc. These tags will be integrated back to dev regularly

> (by those who set the tags, that is, the maintainers).

> At the release day, you'll sync your security work on top of jdk8u/jdk11u and

> add a final jdk-11.0.3+xx tag and the jdk-11.0.3-ga tag (which should point to

> the same change). And this will be integrated back to jdk11u-dev.

>

> What do you think of that?

>

> > 3. What testing is going to be performed prior to these pushes?

>

> Good question, currently I guess it's our quality testing at SAP plus whatever

> you have at RedHat. We should eventually get to something better, e.g. have

> some open test results from AdoptOpenJDK...??

>

> > I'd prefer regular pushes with tags, because that would help us

> > downstream (aarch64-port/jdk8u-shenandoah,

> > shenandoah/jdk11) in being able to integrate changes more frequently.

> > Under Oracle, we've had to do that at GA time only.

>

> That should be helped with our concept.

>

> Best regards

> Christoph



From sean.coffey at oracle.com  Wed Feb 27 08:34:09 2019
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Wed, 27 Feb 2019 08:34:09 +0000
Subject: RFA [11u]: JDK-8206120, JDK-8211398, JDK-8218915
In-Reply-To: <4836758fa91f41a18274e2fc5a007805@sap.com>
References: <5bbacf965a2c4e1a9e2d952a2c2ad407@sap.com>
 <4836758fa91f41a18274e2fc5a007805@sap.com>
Message-ID: <981a0221-2299-09a9-ad34-01822fac8400@oracle.com>

I'm happy to push this for Deepak once the requests are approved. I 
sponsored the original changes related to the specification changes for 
Deepak also.

regards,
Sean.

On 27/02/2019 06:43, Lindenmaier, Goetz wrote:
> Hi Christoph,
>
> Yes, I think too that the Japanese Era changes need to go to jdk11u aka 11.0.3.
>
> Best regards,
>    Goetz.
>
>> -----Original Message-----
>> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
>> Behalf Of Langer, Christoph
>> Sent: Tuesday, February 26, 2019 11:15 PM
>> To: Andrew Haley <aph at redhat.com>; jdk-updates-dev at openjdk.java.net;
>> Deepak Kejriwal <deepak.kejriwal at oracle.com>
>> Subject: [CAUTION] RFA [11u]: JDK-8206120, JDK-8211398, JDK-8218915
>>
>> Hi,
>>
>> I hereby request the approval to push the change that fixes JDK-8206120,
>> JDK-8211398 and JDK-8218915 directly to jk11u. The fix is contained in
>> jdk11.0.3-oracle now.
>>
>> The backport has been reviewed in:
>> https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-
>> February/058596.html.
>>
>> @Deepak: Would you want to push the change yourself, once approved? Or
>> shall I do it for you, based on the webrev?
>>
>> Best regards
>> Christoph

From shade at redhat.com  Wed Feb 27 09:43:24 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 27 Feb 2019 10:43:24 +0100
Subject: How to run tests before pushing a backport changeset?
In-Reply-To: <CA+w6HxZq9omdmcRPEonzTN37nYkLxqN++Jr76+cGru=QhFcTRg@mail.gmail.com>
References: <CA+w6Hxbe+Ye7tqjGxzB8LDHRWZdDLQyT20pWZk_VTDqbc4z4uQ@mail.gmail.com>
 <f2a642ff-ff81-f52e-ea50-13b845d52d15@redhat.com>
 <CA+kOe0-7S+2LZEg+ieb0pbQwb=Jd2XTNqjkPfYQTmN4YS_Jnug@mail.gmail.com>
 <7a3048c2-b493-d3d0-970d-394b5e033aa6@redhat.com>
 <3371d68c-d6ea-7e03-85d2-0b6cfa09b54d@redhat.com>
 <CAP7YuASoLMowQL3a-+UXKzZ_pnsUbD8bocadG-CkrHo0rw420w@mail.gmail.com>
 <CA+kOe0_0JnoZQ3wQNigx_YG_ZhFSdVzL2yDY4Noox04w4FtF+g@mail.gmail.com>
 <CA+w6HxZq9omdmcRPEonzTN37nYkLxqN++Jr76+cGru=QhFcTRg@mail.gmail.com>
Message-ID: <4d61b5a1-c16d-8842-66d5-ed8e17267338@redhat.com>

Hi,

I see actual 12u maintainers have not replied yet, so I am willing to share my understanding.

On 2/26/19 8:04 PM, Man Cao wrote:
> We have a follow-up question: is there any difference on the testing policy
> for JDK12u? Should we seek sponsorship from one of the maintainers from
> Oracle to run tests before pushing a backport changeset to JDK12u? Or could
> we just run tier1 tests for fastdebug|release locally and then push?

It seems that jdk12u-fix-yes is only set when jdk12u-fix-SQE-ok is set. jdk12u-fix-SQE-ok is
apparently done by Oracle-internal QA department, which probably indicates the patch went through
the internal QA process? Anyway, jdk12u-fix-yes and local testing should be enough to push.

> Also, any changeset that goes into jdk-updates/jdk12u should NOT affect the
> soon-to-be-released JDK12 that is currently in Release Candidate phase,
> right?

Yes, that is correct. JDK 12 Release Candidate is in jdk/jdk12, not in jdk-updates/jdk12u. Whatever
you push to jdk-updates/jdk12u now would be in 12.0.2.

-Aleksey



From aph at redhat.com  Wed Feb 27 09:46:14 2019
From: aph at redhat.com (Andrew Haley)
Date: Wed, 27 Feb 2019 09:46:14 +0000
Subject: 8u/11u repo access and Jira changes
In-Reply-To: <0a0ac28e-438f-7a07-56c3-664b8cd3a97e@redhat.com>
References: <372f2232-1c3d-a358-17d7-28fa1d563995@redhat.com>
 <242e376c-0b96-1d87-dd51-e9d35844d021@redhat.com>
 <9d4c5d26-b02e-daac-0ba4-9780412451a5@redhat.com>
 <2f1b50ed-bb26-add1-bc64-012f6e5fc208@redhat.com>
 <3dd8687d-e9c6-4f1b-ec47-a8d9506894dd@redhat.com>
 <06f09798-cade-b882-fb3e-4049733fa8cc@redhat.com>
 <8bba13dc-53f6-90c1-a379-d43adc528d97@redhat.com>
 <0a0ac28e-438f-7a07-56c3-664b8cd3a97e@redhat.com>
Message-ID: <23cb5d83-f43b-69ee-84f3-4cd3fc0d94fb@redhat.com>

On 2/26/19 8:23 PM, Aleksey Shipilev wrote:

> Speaking of large software projects, I think Linux gets it right:
> maintainers "pull" changes into upper repositories rather than
> technically allowing anyone from downstream to push on their
> own. For all the perfect people who are working on Linux, that is a
> saner approach for a responsible maintainer, in my mind.

OMG, I cannot find words adequate to tell you how much I hate that:
pull requests are the worst part of the GitHub process. Firstly, it is
far too much of a bottleneck. Better to distribute the workload, with
people testing and pushing their own patches. It also reinforces the
power and status of the high priesthood, leading to an unhealthy
culture of insiders and outsiders. Some of this is inevitable in that
we must not break stuff, of course, but I believe we should do
everything to break down those insider/outsider barriers short of
introducing extra risk. That's why things like automated testing
available to everyone are so good.

Individual responsibility FTW!

-- 
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 aph at redhat.com  Wed Feb 27 09:50:20 2019
From: aph at redhat.com (Andrew Haley)
Date: Wed, 27 Feb 2019 09:50:20 +0000
Subject: RFA [11u]: JDK-8206120, JDK-8211398, JDK-8218915
In-Reply-To: <5bbacf965a2c4e1a9e2d952a2c2ad407@sap.com>
References: <5bbacf965a2c4e1a9e2d952a2c2ad407@sap.com>
Message-ID: <a5920e74-d5e8-53a7-b11d-0a336cbf2420@redhat.com>

On 2/26/19 10:14 PM, Langer, Christoph wrote:
> I hereby request the approval to push the change that fixes JDK-8206120, JDK-8211398 and JDK-8218915 directly to jk11u. The fix is contained in jdk11.0.3-oracle now.

OK.

-- 
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 christoph.langer at sap.com  Wed Feb 27 13:24:58 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 27 Feb 2019 13:24:58 +0000
Subject: jdk11 updates: furhter process and tagging
In-Reply-To: <6bb5e84c23314b3880fc703d9e5d7d55@sap.com>
References: <c90e9edf546c47ff8dc7de587441e7a6@sap.com>
 <ce547bbc-dada-44fb-14c1-576c63496b14@redhat.com>
 <6bb5e84c23314b3880fc703d9e5d7d55@sap.com>
Message-ID: <3aa6f1d1b9a64721ba8e3b3d413beb6c@sap.com>

Hi Andrew,

> > > As per the usual tagging in update releases (for details I suggest to read
> > JDK-8180946 [1]), I propose to add the following tags now:
> > > 1. Add tag jdk-11.0.4+0 to jdk11u-dev
> > > 2. Add tag jdk-11.0.3+1 to jdk11u
> >
> > Sounds good.
> 
> Fine. So I'll add the tags tomorrow as proposed.
> 
> I'd also ask you to approve https://bugs.openjdk.java.net/browse/JDK-
> 8219710 as the first change for 11.04. I would push it after 11.0.4+0 then.

I've pushed the tags and JDK-8219710 (thanks for approving).

If you all agree we can now open jdk11u-dev for updates that go into 11.0.4. In that case I'd ask you to communicate this in a separate mail to this list, strongly pointing out and emphasizing that pushes need to go to jdk11u-dev (to reduce the cases where Aleksey will come and say "I told you" ??). And you can then start the regular business of going through the "jdk11u-fix-request" list and approve the items.

Best regards
Christoph


From christoph.langer at sap.com  Wed Feb 27 14:34:45 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 27 Feb 2019 14:34:45 +0000
Subject: JBS Filters for JDK update work
Message-ID: <3fa6de91b4c44736a6570256851c52d3@sap.com>

Hi all,

after putting some more efforts into my issue filters for jdk-updates projects, here is a current list of the available ones. It might be of value to some folks? As always: You need to be logged in to JBS, otherwise these won?t work. If you find bugs, please report to me.

Unapproved requests (for the maintainers/approvers):
8u: https://bugs.openjdk.java.net/issues/?filter=36415
11u: https://bugs.openjdk.java.net/issues/?filter=36358
12u: https://bugs.openjdk.java.net/issues/?filter=36359

Approved requests without push (?orphans?):
8u: https://bugs.openjdk.java.net/issues/?filter=36427
11u: https://bugs.openjdk.java.net/issues/?filter=36412
12u: https://bugs.openjdk.java.net/issues/?filter=36425

Open Downports Oracle -> OpenJDK:
8u212: https://bugs.openjdk.java.net/issues/?filter=36394
8u222: https://bugs.openjdk.java.net/issues/?filter=36456
11.0.3: https://bugs.openjdk.java.net/issues/?filter=36366
11.0.4: https://bugs.openjdk.java.net/issues/?filter=36409

Additional commits in OpenJDK vs. the equivalent Oracle release
8u212: https://bugs.openjdk.java.net/issues/?filter=36458
8u222: https://bugs.openjdk.java.net/issues/?filter=36459
11.0.3: https://bugs.openjdk.java.net/issues/?filter=36414
11.0.4: https://bugs.openjdk.java.net/issues/?filter=36457

To sort out some issues that are not relevant to OpenJDK, I introduced a new label ?openjdk-na?. If you flag a bug with this, it?ll fall out of my views.
If you want to check whether I flagged something wrongly (where?s my bug?), you can check here: https://bugs.openjdk.java.net/issues/?jql=labels+%3D+openjdk-na

For jdk8u I filter issues which have originally been fixed in openjfx12 or openjfx13 as those probably don?t affect OpenJDK. Maybe we should check the list of openjdkfx bugs for an 8u release at some time during the cycle manually to check that nothing slipped through.

Have fun backporting ??
Christoph


From rob.mckenna at oracle.com  Wed Feb 27 14:46:06 2019
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Wed, 27 Feb 2019 14:46:06 +0000
Subject: How to run tests before pushing a backport changeset?
In-Reply-To: <4d61b5a1-c16d-8842-66d5-ed8e17267338@redhat.com>
References: <CA+w6Hxbe+Ye7tqjGxzB8LDHRWZdDLQyT20pWZk_VTDqbc4z4uQ@mail.gmail.com>
 <f2a642ff-ff81-f52e-ea50-13b845d52d15@redhat.com>
 <CA+kOe0-7S+2LZEg+ieb0pbQwb=Jd2XTNqjkPfYQTmN4YS_Jnug@mail.gmail.com>
 <7a3048c2-b493-d3d0-970d-394b5e033aa6@redhat.com>
 <3371d68c-d6ea-7e03-85d2-0b6cfa09b54d@redhat.com>
 <CAP7YuASoLMowQL3a-+UXKzZ_pnsUbD8bocadG-CkrHo0rw420w@mail.gmail.com>
 <CA+kOe0_0JnoZQ3wQNigx_YG_ZhFSdVzL2yDY4Noox04w4FtF+g@mail.gmail.com>
 <CA+w6HxZq9omdmcRPEonzTN37nYkLxqN++Jr76+cGru=QhFcTRg@mail.gmail.com>
 <4d61b5a1-c16d-8842-66d5-ed8e17267338@redhat.com>
Message-ID: <20190227144606.GA4981@vimes>

This is not quite correct:

On 27/02/19 10:43, Aleksey Shipilev wrote:
> Hi,
> 
> I see actual 12u maintainers have not replied yet, so I am willing to share my understanding.
> 
> On 2/26/19 8:04 PM, Man Cao wrote:
> > We have a follow-up question: is there any difference on the testing policy
> > for JDK12u? Should we seek sponsorship from one of the maintainers from
> > Oracle to run tests before pushing a backport changeset to JDK12u? Or could
> > we just run tier1 tests for fastdebug|release locally and then push?
> 
> It seems that jdk12u-fix-yes is only set when jdk12u-fix-SQE-ok is set. jdk12u-fix-SQE-ok is
> apparently done by Oracle-internal QA department, which probably indicates the patch went through
> the internal QA process? Anyway, jdk12u-fix-yes and local testing should be enough to push.

The SQE-ok keyword indicates that the fix can be accommodated by the
test plan.

> 
> > Also, any changeset that goes into jdk-updates/jdk12u should NOT affect the
> > soon-to-be-released JDK12 that is currently in Release Candidate phase,
> > right?
> 
> Yes, that is correct. JDK 12 Release Candidate is in jdk/jdk12, not in jdk-updates/jdk12u. Whatever
> you push to jdk-updates/jdk12u now would be in 12.0.2.

Correct.

I would like to see potential fixes pass tiers 1 & 2 of the affected area
(e.g. hs or jdk) but tier1 is *must* pass.

(http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-June/002325.html)

    -Rob

> 
> -Aleksey
> 
> 

From shade at redhat.com  Wed Feb 27 15:21:37 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 27 Feb 2019 16:21:37 +0100
Subject: JBS Filters for JDK update work
In-Reply-To: <3fa6de91b4c44736a6570256851c52d3@sap.com>
References: <3fa6de91b4c44736a6570256851c52d3@sap.com>
Message-ID: <53101fe3-08f5-5728-dc74-6853e52fd32f@redhat.com>

On 2/27/19 3:34 PM, Langer, Christoph wrote:
> Hi all,
> 
> after putting some more efforts into my issue filters for jdk-updates projects, here is a current list of the available ones. It might be of value to some folks? As always: You need to be logged in to JBS, otherwise these won?t work. If you find bugs, please report to me.
> 
> Unapproved requests (for the maintainers/approvers):
> 8u: https://bugs.openjdk.java.net/issues/?filter=36415
> 11u: https://bugs.openjdk.java.net/issues/?filter=36358
> 12u: https://bugs.openjdk.java.net/issues/?filter=36359
> 
> Approved requests without push (?orphans?):
> 8u: https://bugs.openjdk.java.net/issues/?filter=36427
> 11u: https://bugs.openjdk.java.net/issues/?filter=36412
> 12u: https://bugs.openjdk.java.net/issues/?filter=36425
> 
> Open Downports Oracle -> OpenJDK:
> 8u212: https://bugs.openjdk.java.net/issues/?filter=36394
> 8u222: https://bugs.openjdk.java.net/issues/?filter=36456
> 11.0.3: https://bugs.openjdk.java.net/issues/?filter=36366
> 11.0.4: https://bugs.openjdk.java.net/issues/?filter=36409
> 
> Additional commits in OpenJDK vs. the equivalent Oracle release
> 8u212: https://bugs.openjdk.java.net/issues/?filter=36458
> 8u222: https://bugs.openjdk.java.net/issues/?filter=36459
> 11.0.3: https://bugs.openjdk.java.net/issues/?filter=36414
> 11.0.4: https://bugs.openjdk.java.net/issues/?filter=36457

These are excellent. We need to put them on Wiki.

-Aleksey


From martijnverburg at gmail.com  Wed Feb 27 15:30:13 2019
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Wed, 27 Feb 2019 15:30:13 +0000
Subject: 'Official' 11.0.3 Release?
Message-ID: <CAP7YuAT8Qk3-76X0CNTsXg5mNxEL=pH-Kr-evzzHH1762jmZYg@mail.gmail.com>

Hi all,

I'm not sure if I missed this in the last month's traffic, but I don't
think it's been stated yet.

Do we have a formal notification/tagging process on when we deem a release
to have gone out (in this case 11.0.3+?)

Cheers,
Martijn

From christoph.langer at sap.com  Wed Feb 27 15:52:32 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 27 Feb 2019 15:52:32 +0000
Subject: 'Official' 11.0.3 Release?
In-Reply-To: <CAP7YuAT8Qk3-76X0CNTsXg5mNxEL=pH-Kr-evzzHH1762jmZYg@mail.gmail.com>
References: <CAP7YuAT8Qk3-76X0CNTsXg5mNxEL=pH-Kr-evzzHH1762jmZYg@mail.gmail.com>
Message-ID: <8f598ed4bd304ad2a9ec5607ce936588@sap.com>

Hi Martijn, 

the tag shall be "jdk-11.0.3-ga" as per https://bugs.openjdk.java.net/browse/JDK-8180946 

Best regards
Christoph

> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> Behalf Of Martijn Verburg
> Sent: Mittwoch, 27. Februar 2019 16:30
> To: jdk-updates-dev at openjdk.java.net
> Subject: 'Official' 11.0.3 Release?
> 
> Hi all,
> 
> I'm not sure if I missed this in the last month's traffic, but I don't
> think it's been stated yet.
> 
> Do we have a formal notification/tagging process on when we deem a
> release
> to have gone out (in this case 11.0.3+?)
> 
> Cheers,
> Martijn

From martijnverburg at gmail.com  Wed Feb 27 16:44:46 2019
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Wed, 27 Feb 2019 16:44:46 +0000
Subject: 'Official' 11.0.3 Release?
In-Reply-To: <8f598ed4bd304ad2a9ec5607ce936588@sap.com>
References: <CAP7YuAT8Qk3-76X0CNTsXg5mNxEL=pH-Kr-evzzHH1762jmZYg@mail.gmail.com>
 <8f598ed4bd304ad2a9ec5607ce936588@sap.com>
Message-ID: <CAP7YuAS_vTWPP9TJ0SWaqzj8YLEeemtFqG-Mqjfn7vOn9HB+vg@mail.gmail.com>

Awesome! The very tag I requested ages ago and of course, stupidly forgot
about.  I"ll go crawl back under my rock now :-).

Cheers,
Martijn


On Wed, 27 Feb 2019 at 15:52, Langer, Christoph <christoph.langer at sap.com>
wrote:

> Hi Martijn,
>
> the tag shall be "jdk-11.0.3-ga" as per
> https://bugs.openjdk.java.net/browse/JDK-8180946
>
> Best regards
> Christoph
>
> > -----Original Message-----
> > From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> > Behalf Of Martijn Verburg
> > Sent: Mittwoch, 27. Februar 2019 16:30
> > To: jdk-updates-dev at openjdk.java.net
> > Subject: 'Official' 11.0.3 Release?
> >
> > Hi all,
> >
> > I'm not sure if I missed this in the last month's traffic, but I don't
> > think it's been stated yet.
> >
> > Do we have a formal notification/tagging process on when we deem a
> > release
> > to have gone out (in this case 11.0.3+?)
> >
> > Cheers,
> > Martijn
>

From shade at redhat.com  Wed Feb 27 19:01:14 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 27 Feb 2019 20:01:14 +0100
Subject: [11u] RFR (S) 8209055:
 c.s.t.javac.code.DeferredCompletionFailureHandler seems to use WeakHashMap
 incorrectly
Message-ID: <24567d61-dbdb-5504-6f56-17e063508dab@redhat.com>

Please review this backport to 11u.

Original bug:
  https://bugs.openjdk.java.net/browse/JDK-8209055

Original fix:
  http://hg.openjdk.java.net/jdk/jdk/rev/1a6aeca4a8c9

The patch does apply cleanly to 11u, but test needs fixups to compile and run. I needed to add this
line to @modules:
 + *   jdk.compiler/com.sun.tools.javac.main:+open

Testing: langtools:tier1, regression test (fails without the patch, passes with),

Thanks,
-Aleksey


From igor.ignatyev at oracle.com  Wed Feb 27 19:11:30 2019
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Wed, 27 Feb 2019 11:11:30 -0800
Subject: [11u] RFR (S) 8209055:
 c.s.t.javac.code.DeferredCompletionFailureHandler seems to use WeakHashMap
 incorrectly
In-Reply-To: <24567d61-dbdb-5504-6f56-17e063508dab@redhat.com>
References: <24567d61-dbdb-5504-6f56-17e063508dab@redhat.com>
Message-ID: <B2035B10-06FE-4BC8-BC51-7E0EC94C2D96@oracle.com>

Hi Aleksey,

I don't see why 'jdk.compiler/com.sun.tools.javac.main:+open' is needed, could you please explain?

-- Igor

> On Feb 27, 2019, at 11:01 AM, Aleksey Shipilev <shade at redhat.com> wrote:
> 
> Please review this backport to 11u.
> 
> Original bug:
>  https://bugs.openjdk.java.net/browse/JDK-8209055
> 
> Original fix:
>  http://hg.openjdk.java.net/jdk/jdk/rev/1a6aeca4a8c9
> 
> The patch does apply cleanly to 11u, but test needs fixups to compile and run. I needed to add this
> line to @modules:
> + *   jdk.compiler/com.sun.tools.javac.main:+open
> 
> Testing: langtools:tier1, regression test (fails without the patch, passes with),
> 
> Thanks,
> -Aleksey
> 


From shade at redhat.com  Wed Feb 27 20:07:24 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 27 Feb 2019 21:07:24 +0100
Subject: [11u] RFR (S) 8209055:
 c.s.t.javac.code.DeferredCompletionFailureHandler seems to use WeakHashMap
 incorrectly
In-Reply-To: <B2035B10-06FE-4BC8-BC51-7E0EC94C2D96@oracle.com>
References: <24567d61-dbdb-5504-6f56-17e063508dab@redhat.com>
 <B2035B10-06FE-4BC8-BC51-7E0EC94C2D96@oracle.com>
Message-ID: <e506d17a-0324-3201-f7c5-45833cabebc4@redhat.com>

Hi Igor,

On 2/27/19 8:11 PM, Igor Ignatyev wrote:
> I don't see why 'jdk.compiler/com.sun.tools.javac.main:+open' is needed, could you please explain?

Otherwise the test would fail to build with:

/home/shade/trunks/jdk-updates-jdk11u-dev/test/langtools/tools/lib/toolbox/JavacTask.java:365:
error: Result.exitCode in package com.sun.tools.javac.main is not accessible
            return taskImpl.doCall().exitCode;
                                    ^
The original tests does "jdk.compiler/com.sun.tools.javac.code:+open", which is not enough. I
thought we can change "code" -> "main", but it would then fail to build with:

/home/shade/trunks/jdk-updates-jdk11u-dev/test/langtools/tools/javac/processing/model/completionfailure/SymbolsDontCumulate.java:44:
error: package com.sun.tools.javac.code is not visible
import com.sun.tools.javac.code.DeferredCompletionFailureHandler;
                          ^
  (package com.sun.tools.javac.code is declared in module jdk.compiler, which does not export it to
the unnamed module)

Therefore all this is needed:
  * @modules jdk.compiler/com.sun.tools.javac.api
  *          jdk.compiler/com.sun.tools.javac.code:+open
  *          jdk.compiler/com.sun.tools.javac.main:+open

Does that make sense?

-Aleksey


From manc at google.com  Wed Feb 27 21:30:36 2019
From: manc at google.com (Man Cao)
Date: Wed, 27 Feb 2019 13:30:36 -0800
Subject: How to run tests before pushing a backport changeset?
In-Reply-To: <20190227144606.GA4981@vimes>
References: <CA+w6Hxbe+Ye7tqjGxzB8LDHRWZdDLQyT20pWZk_VTDqbc4z4uQ@mail.gmail.com>
 <f2a642ff-ff81-f52e-ea50-13b845d52d15@redhat.com>
 <CA+kOe0-7S+2LZEg+ieb0pbQwb=Jd2XTNqjkPfYQTmN4YS_Jnug@mail.gmail.com>
 <7a3048c2-b493-d3d0-970d-394b5e033aa6@redhat.com>
 <3371d68c-d6ea-7e03-85d2-0b6cfa09b54d@redhat.com>
 <CAP7YuASoLMowQL3a-+UXKzZ_pnsUbD8bocadG-CkrHo0rw420w@mail.gmail.com>
 <CA+kOe0_0JnoZQ3wQNigx_YG_ZhFSdVzL2yDY4Noox04w4FtF+g@mail.gmail.com>
 <CA+w6HxZq9omdmcRPEonzTN37nYkLxqN++Jr76+cGru=QhFcTRg@mail.gmail.com>
 <4d61b5a1-c16d-8842-66d5-ed8e17267338@redhat.com>
 <20190227144606.GA4981@vimes>
Message-ID: <CA+w6Hxb1W0tyN2yyWOtqPdpo3pVA2E1bPJSykPT+6qeL7PHwMQ@mail.gmail.com>

Thanks for the clarifications!


> I would like to see potential fixes pass tiers 1 & 2 of the affected area
> (e.g. hs or jdk) but tier1 is *must* pass.
> (http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-June/002325.html)


We are somewhat concerned about breaking tests on non-Linux and non-x86_64
systems. We don't have the infrastructure to build and test them.
It seems that there is no easy way to test these before pushing,
unfortunately.

-Man

From igor.ignatyev at oracle.com  Wed Feb 27 21:53:32 2019
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Wed, 27 Feb 2019 13:53:32 -0800
Subject: [11u] RFR (S) 8209055:
 c.s.t.javac.code.DeferredCompletionFailureHandler seems to use WeakHashMap
 incorrectly
In-Reply-To: <e506d17a-0324-3201-f7c5-45833cabebc4@redhat.com>
References: <24567d61-dbdb-5504-6f56-17e063508dab@redhat.com>
 <B2035B10-06FE-4BC8-BC51-7E0EC94C2D96@oracle.com>
 <e506d17a-0324-3201-f7c5-45833cabebc4@redhat.com>
Message-ID: <C97F5116-A3EC-4AD6-A666-0E1DDA7F4FD1@oracle.com>

Hi Aleksey,

I tried to find the difference b/w jdk11u and jdk repos, and still don't see why it works w/o 'jdk.compiler/<...>main' in jdk/jdk, but not in jdk11u. anyhow, the fix looks good to me.

Thanks,
-- Igor 

> On Feb 27, 2019, at 12:07 PM, Aleksey Shipilev <shade at redhat.com> wrote:
> 
> Hi Igor,
> 
> On 2/27/19 8:11 PM, Igor Ignatyev wrote:
>> I don't see why 'jdk.compiler/com.sun.tools.javac.main:+open' is needed, could you please explain?
> 
> Otherwise the test would fail to build with:
> 
> /home/shade/trunks/jdk-updates-jdk11u-dev/test/langtools/tools/lib/toolbox/JavacTask.java:365:
> error: Result.exitCode in package com.sun.tools.javac.main is not accessible
>            return taskImpl.doCall().exitCode;
>                                    ^
> The original tests does "jdk.compiler/com.sun.tools.javac.code:+open", which is not enough. I
> thought we can change "code" -> "main", but it would then fail to build with:
> 
> /home/shade/trunks/jdk-updates-jdk11u-dev/test/langtools/tools/javac/processing/model/completionfailure/SymbolsDontCumulate.java:44:
> error: package com.sun.tools.javac.code is not visible
> import com.sun.tools.javac.code.DeferredCompletionFailureHandler;
>                          ^
>  (package com.sun.tools.javac.code is declared in module jdk.compiler, which does not export it to
> the unnamed module)
> 
> Therefore all this is needed:
>  * @modules jdk.compiler/com.sun.tools.javac.api
>  *          jdk.compiler/com.sun.tools.javac.code:+open
>  *          jdk.compiler/com.sun.tools.javac.main:+open
> 
> Does that make sense?
> 
> -Aleksey
> 


From shade at redhat.com  Wed Feb 27 22:46:13 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 27 Feb 2019 23:46:13 +0100
Subject: JBS Filters for JDK update work
In-Reply-To: <3fa6de91b4c44736a6570256851c52d3@sap.com>
References: <3fa6de91b4c44736a6570256851c52d3@sap.com>
Message-ID: <88c187ec-0884-9e49-9d81-64be8f356254@redhat.com>

On 2/27/19 3:34 PM, Langer, Christoph wrote:
> 11.0.3: https://bugs.openjdk.java.net/issues/?filter=36414
> 11.0.4: https://bugs.openjdk.java.net/issues/?filter=36457

I think these filters are showing issues that are in 11.0.2 -- those are likely in the base for
11.0.3-oracle? See for example this one: https://bugs.openjdk.java.net/browse/JDK-8208350

-Aleksey



From christoph.langer at sap.com  Wed Feb 27 22:57:41 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 27 Feb 2019 22:57:41 +0000
Subject: JBS Filters for JDK update work
In-Reply-To: <88c187ec-0884-9e49-9d81-64be8f356254@redhat.com>
References: <3fa6de91b4c44736a6570256851c52d3@sap.com>
 <88c187ec-0884-9e49-9d81-64be8f356254@redhat.com>
Message-ID: <b34bdbab58c54f68ad47e8dce67a7ef4@sap.com>

> On 2/27/19 3:34 PM, Langer, Christoph wrote:
> > 11.0.3: https://bugs.openjdk.java.net/issues/?filter=36414
> > 11.0.4: https://bugs.openjdk.java.net/issues/?filter=36457
> 
> I think these filters are showing issues that are in 11.0.2 -- those are likely in
> the base for
> 11.0.3-oracle? See for example this one:
> https://bugs.openjdk.java.net/browse/JDK-8208350

Good catch. Fixed ??

/Christoph

From shade at redhat.com  Wed Feb 27 23:12:38 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 28 Feb 2019 00:12:38 +0100
Subject: Encryption fix in HotSpot
In-Reply-To: <2cb2c58f-1345-9bc3-b665-750abe3e4c7a@redhat.com>
References: <OFADE95772.64B449E3-ONC22583AD.004B8E66-C22583AD.004C8913@notes.na.collabserv.com>
 <2cb2c58f-1345-9bc3-b665-750abe3e4c7a@redhat.com>
Message-ID: <6e2233c4-c7c4-013a-7f57-5082a5a02728@redhat.com>

On 2/26/19 2:59 PM, Aleksey Shipilev wrote:
> On 2/26/19 2:55 PM, Gidon Gershinsky wrote:
>> Can it also be backported to OpenJDK Java 11? This is a very significant 
>> performance problem, that needs to be fixed in order for AES-GCM (one of 
>> the main encryption modes today) to be really workable in Java 11.
> 
> It is on the list to backport to 11.0.4:
>   https://bugs.openjdk.java.net/issues/?filter=36409
> 
> Once 11.0.4 opens, we can start backporting these. You are welcome to do it :)

Ah, that requires some benchmarking.

FYI, Fix Request that currently targets 11.0.4 is away:
  https://bugs.openjdk.java.net/browse/JDK-8201633

-Aleksey


From christoph.langer at sap.com  Thu Feb 28 10:23:29 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 28 Feb 2019 10:23:29 +0000
Subject: [11u] RFR (S) 8209055:
 c.s.t.javac.code.DeferredCompletionFailureHandler seems to use WeakHashMap
 incorrectly
In-Reply-To: <C97F5116-A3EC-4AD6-A666-0E1DDA7F4FD1@oracle.com>
References: <24567d61-dbdb-5504-6f56-17e063508dab@redhat.com>
 <B2035B10-06FE-4BC8-BC51-7E0EC94C2D96@oracle.com>
 <e506d17a-0324-3201-f7c5-45833cabebc4@redhat.com>
 <C97F5116-A3EC-4AD6-A666-0E1DDA7F4FD1@oracle.com>
Message-ID: <3fa63200bd784bf89335ed21ff43baea@sap.com>

Hi,

> I tried to find the difference b/w jdk11u and jdk repos, and still don't see why
> it works w/o 'jdk.compiler/<...>main' in jdk/jdk, but not in jdk11u. anyhow,
> the fix looks good to me.

I think when you run the full suite, the langtools toolbox library is built in another test that probably had this directive set and the build runs through. But when you run the test standalone on an empty jtreg directory, you run into this issue. I Will try this out on jdk/jdk.

> > Therefore all this is needed:
> >  * @modules jdk.compiler/com.sun.tools.javac.api
> >  *          jdk.compiler/com.sun.tools.javac.code:+open
> >  *          jdk.compiler/com.sun.tools.javac.main:+open
> >
> > Does that make sense?

Can you try run the test with only jdk.compiler/com.sun.tools.javac.main (e.g. without +open)?

Other than that, it's fine for me.

Best regards
Christoph


From shade at redhat.com  Thu Feb 28 10:30:10 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 28 Feb 2019 11:30:10 +0100
Subject: [11u] RFR (S) 8209055:
 c.s.t.javac.code.DeferredCompletionFailureHandler seems to use WeakHashMap
 incorrectly
In-Reply-To: <3fa63200bd784bf89335ed21ff43baea@sap.com>
References: <24567d61-dbdb-5504-6f56-17e063508dab@redhat.com>
 <B2035B10-06FE-4BC8-BC51-7E0EC94C2D96@oracle.com>
 <e506d17a-0324-3201-f7c5-45833cabebc4@redhat.com>
 <C97F5116-A3EC-4AD6-A666-0E1DDA7F4FD1@oracle.com>
 <3fa63200bd784bf89335ed21ff43baea@sap.com>
Message-ID: <f606840f-caab-6aff-717e-ae8314a4cb00@redhat.com>

On 2/28/19 11:23 AM, Langer, Christoph wrote:
>>> Therefore all this is needed:
>>>  * @modules jdk.compiler/com.sun.tools.javac.api
>>>  *          jdk.compiler/com.sun.tools.javac.code:+open
>>>  *          jdk.compiler/com.sun.tools.javac.main:+open
>>>
>>> Does that make sense?
> 
> Can you try run the test with only jdk.compiler/com.sun.tools.javac.main (e.g. without +open)?

Just did, it passes with:

 * @modules jdk.compiler/com.sun.tools.javac.api
 *          jdk.compiler/com.sun.tools.javac.main
 *          jdk.compiler/com.sun.tools.javac.code:+open

Should probably go with that!

-Aleksey


From christoph.langer at sap.com  Thu Feb 28 10:45:41 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 28 Feb 2019 10:45:41 +0000
Subject: [11u] RFR (S) 8209055:
 c.s.t.javac.code.DeferredCompletionFailureHandler seems to use WeakHashMap
 incorrectly
In-Reply-To: <f606840f-caab-6aff-717e-ae8314a4cb00@redhat.com>
References: <24567d61-dbdb-5504-6f56-17e063508dab@redhat.com>
 <B2035B10-06FE-4BC8-BC51-7E0EC94C2D96@oracle.com>
 <e506d17a-0324-3201-f7c5-45833cabebc4@redhat.com>
 <C97F5116-A3EC-4AD6-A666-0E1DDA7F4FD1@oracle.com>
 <3fa63200bd784bf89335ed21ff43baea@sap.com>
 <f606840f-caab-6aff-717e-ae8314a4cb00@redhat.com>
Message-ID: <3b49b309112047228162c370854bd561@sap.com>

> > Can you try run the test with only jdk.compiler/com.sun.tools.javac.main
> (e.g. without +open)?
> 
> Just did, it passes with:
> 
>  * @modules jdk.compiler/com.sun.tools.javac.api
>  *          jdk.compiler/com.sun.tools.javac.main
>  *          jdk.compiler/com.sun.tools.javac.code:+open
> 
> Should probably go with that!

Yep, I also verified that the test standalone fails without jdk.compiler/com.sun.tools.javac.main in jdk/jdk. Will file a bug/fix for that.

/Christoph


From shade at redhat.com  Thu Feb 28 10:56:23 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 28 Feb 2019 11:56:23 +0100
Subject: [11u] RFR (S) 8209055:
 c.s.t.javac.code.DeferredCompletionFailureHandler seems to use WeakHashMap
 incorrectly
In-Reply-To: <3b49b309112047228162c370854bd561@sap.com>
References: <24567d61-dbdb-5504-6f56-17e063508dab@redhat.com>
 <B2035B10-06FE-4BC8-BC51-7E0EC94C2D96@oracle.com>
 <e506d17a-0324-3201-f7c5-45833cabebc4@redhat.com>
 <C97F5116-A3EC-4AD6-A666-0E1DDA7F4FD1@oracle.com>
 <3fa63200bd784bf89335ed21ff43baea@sap.com>
 <f606840f-caab-6aff-717e-ae8314a4cb00@redhat.com>
 <3b49b309112047228162c370854bd561@sap.com>
Message-ID: <db903c3c-7408-7c75-ae20-73b3a1dd88f9@redhat.com>

On 2/28/19 11:45 AM, Langer, Christoph wrote:
>>> Can you try run the test with only jdk.compiler/com.sun.tools.javac.main
>> (e.g. without +open)?
>>
>> Just did, it passes with:
>>
>>  * @modules jdk.compiler/com.sun.tools.javac.api
>>  *          jdk.compiler/com.sun.tools.javac.main
>>  *          jdk.compiler/com.sun.tools.javac.code:+open
>>
>> Should probably go with that!
> 
> Yep, I also verified that the test standalone fails without jdk.compiler/com.sun.tools.javac.main in jdk/jdk. Will file a bug/fix for that.

Okay, thanks! Maybe I just backport the patch as is, and we apply the testbug backport right away.

-Aleksey


From christoph.langer at sap.com  Thu Feb 28 11:05:50 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 28 Feb 2019 11:05:50 +0000
Subject: [11u] RFR (S) 8209055:
 c.s.t.javac.code.DeferredCompletionFailureHandler seems to use WeakHashMap
 incorrectly
In-Reply-To: <db903c3c-7408-7c75-ae20-73b3a1dd88f9@redhat.com>
References: <24567d61-dbdb-5504-6f56-17e063508dab@redhat.com>
 <B2035B10-06FE-4BC8-BC51-7E0EC94C2D96@oracle.com>
 <e506d17a-0324-3201-f7c5-45833cabebc4@redhat.com>
 <C97F5116-A3EC-4AD6-A666-0E1DDA7F4FD1@oracle.com>
 <3fa63200bd784bf89335ed21ff43baea@sap.com>
 <f606840f-caab-6aff-717e-ae8314a4cb00@redhat.com>
 <3b49b309112047228162c370854bd561@sap.com>
 <db903c3c-7408-7c75-ae20-73b3a1dd88f9@redhat.com>
Message-ID: <532bb538e46647c1881d303b13117e44@sap.com>

> Okay, thanks! Maybe I just backport the patch as is, and we apply the
> testbug backport right away.

Good idea, I've put you on copy in my mail to compiler-dev.

/Christoph



From aph at redhat.com  Thu Feb 28 11:36:02 2019
From: aph at redhat.com (Andrew Haley)
Date: Thu, 28 Feb 2019 11:36:02 +0000
Subject: Encryption fix in HotSpot
In-Reply-To: <6e2233c4-c7c4-013a-7f57-5082a5a02728@redhat.com>
References: <OFADE95772.64B449E3-ONC22583AD.004B8E66-C22583AD.004C8913@notes.na.collabserv.com>
 <2cb2c58f-1345-9bc3-b665-750abe3e4c7a@redhat.com>
 <6e2233c4-c7c4-013a-7f57-5082a5a02728@redhat.com>
Message-ID: <029a99bd-6768-803f-37fa-2a49c63bc6d5@redhat.com>

On 2/27/19 11:12 PM, Aleksey Shipilev wrote:
> On 2/26/19 2:59 PM, Aleksey Shipilev wrote:
>> On 2/26/19 2:55 PM, Gidon Gershinsky wrote:
>>> Can it also be backported to OpenJDK Java 11? This is a very significant 
>>> performance problem, that needs to be fixed in order for AES-GCM (one of 
>>> the main encryption modes today) to be really workable in Java 11.
>>
>> It is on the list to backport to 11.0.4:
>>   https://bugs.openjdk.java.net/issues/?filter=36409
>>
>> Once 11.0.4 opens, we can start backporting these. You are welcome to do it :)
> 
> Ah, that requires some benchmarking.

Um, why? The benchmarking, if it were necessary, should have been done
on the upstream fix.

If you really think that special benchmarking for 11u is needed,
please be specific about the form you believe it should
take. Newcomers shouldn't have to guess.

-- 
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 takiguc at linux.vnet.ibm.com  Thu Feb 28 12:13:25 2019
From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi)
Date: Thu, 28 Feb 2019 21:13:25 +0900
Subject: Confirmation about jdk11u approval process
Message-ID: <634770840670d2ee3a21f7c531da3b0b@linux.vnet.ibm.com>

Hello.

I'm confused about jdk11u approval process.

According to "JDK Updates: Requesting push approval for fixes" [1].
We need to follow Rule 0 and Rule 1.
I searched bug db [2], it seems 20+ entries are waiting approval 
process.
Could you explain how approval process works ?

11.0.4 was created, but I'd like to backport some changesets into 
11.0.3.
Is it possible ?

[1] https://openjdk.java.net/projects/jdk-updates/approval.html
[2] 
https://bugs.openjdk.java.net/issues?jql=labels%20in%20(jdk11u-fix-request)%20and%20labels%20not%20in%20(jdk11u-fix-no%2C%20jdk11u-fix-yes)

Thanks,
Ichiroh Takiguchi
IBM Japan, Ltd.


From aph at redhat.com  Thu Feb 28 12:47:25 2019
From: aph at redhat.com (Andrew Haley)
Date: Thu, 28 Feb 2019 12:47:25 +0000
Subject: Confirmation about jdk11u approval process
In-Reply-To: <634770840670d2ee3a21f7c531da3b0b@linux.vnet.ibm.com>
References: <634770840670d2ee3a21f7c531da3b0b@linux.vnet.ibm.com>
Message-ID: <fadd1e5f-2634-89ab-30c2-1a06da7ee32b@redhat.com>

On 2/28/19 12:13 PM, Ichiroh Takiguchi wrote:
> Hello.
> 
> I'm confused about jdk11u approval process.
> 
> According to "JDK Updates: Requesting push approval for fixes" [1].
> We need to follow Rule 0 and Rule 1.
> I searched bug db [2], it seems 20+ entries are waiting approval 
> process.

Yes. There has been a frantic flurry of requests. All of these seem to have
been changed in the last 24 shours.

> Could you explain how approval process works ?

It's in the page at https://openjdk.java.net/projects/jdk-updates/approval.html
What part is a problem?

> 11.0.4 was created, but I'd like to backport some changesets into 
> 11.0.3.
> Is it possible ?

How critical are these changesets?

-- 
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 takiguc at linux.vnet.ibm.com  Thu Feb 28 13:22:19 2019
From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi)
Date: Thu, 28 Feb 2019 22:22:19 +0900
Subject: Confirmation about jdk11u approval process
In-Reply-To: <fadd1e5f-2634-89ab-30c2-1a06da7ee32b@redhat.com>
References: <634770840670d2ee3a21f7c531da3b0b@linux.vnet.ibm.com>
 <fadd1e5f-2634-89ab-30c2-1a06da7ee32b@redhat.com>
Message-ID: <2e7d6ad873235c18aaa3226bbc829556@linux.vnet.ibm.com>

Hello Andrew.

Thank you for help.

I did not know about milestones for jdk11u.
So I was late...

Critical one may be JDK-8211393 [1] for Unix platform.

These are for OpenJDK for AIX.
On jdk11, Java did not start with AIX's 3 locales.
It was restriction on jdk11.
On the latest build on jdk13, AIX's all locales are supported by 
OpenJDK.

JDK-8208634 [2], JDK-8213618 [3], JDK-8212794 [4], JDK-8214533 [5], 
JDK-8217880 [6]

[1] https://bugs.openjdk.java.net/browse/JDK-8211393
[2] https://bugs.openjdk.java.net/browse/JDK-8208634
[3] https://bugs.openjdk.java.net/browse/JDK-8213618
[4] https://bugs.openjdk.java.net/browse/JDK-8212794
[5] https://bugs.openjdk.java.net/browse/JDK-8214533
[6] https://bugs.openjdk.java.net/browse/JDK-8217880

Thanks,
Ichiroh Takiguchi

On 2019-02-28 21:47, Andrew Haley wrote:
> On 2/28/19 12:13 PM, Ichiroh Takiguchi wrote:
>> Hello.
>> 
>> I'm confused about jdk11u approval process.
>> 
>> According to "JDK Updates: Requesting push approval for fixes" [1].
>> We need to follow Rule 0 and Rule 1.
>> I searched bug db [2], it seems 20+ entries are waiting approval
>> process.
> 
> Yes. There has been a frantic flurry of requests. All of these seem to 
> have
> been changed in the last 24 shours.
> 
>> Could you explain how approval process works ?
> 
> It's in the page at 
> https://openjdk.java.net/projects/jdk-updates/approval.html
> What part is a problem?
> 
>> 11.0.4 was created, but I'd like to backport some changesets into
>> 11.0.3.
>> Is it possible ?
> 
> How critical are these changesets?


From aph at redhat.com  Thu Feb 28 13:51:59 2019
From: aph at redhat.com (Andrew Haley)
Date: Thu, 28 Feb 2019 13:51:59 +0000
Subject: Confirmation about jdk11u approval process
In-Reply-To: <2e7d6ad873235c18aaa3226bbc829556@linux.vnet.ibm.com>
References: <634770840670d2ee3a21f7c531da3b0b@linux.vnet.ibm.com>
 <fadd1e5f-2634-89ab-30c2-1a06da7ee32b@redhat.com>
 <2e7d6ad873235c18aaa3226bbc829556@linux.vnet.ibm.com>
Message-ID: <76e25246-9c59-958f-e810-22e589394fb8@redhat.com>

Hi,

On 2/28/19 1:22 PM, Ichiroh Takiguchi wrote:
> I did not know about milestones for jdk11u.
> So I was late...
> 
> Critical one may be JDK-8211393 [1] for Unix platform.

What makes this critical? It looks like a minor memory leak. How long would it
take interacting with an application before a user noticed a problem?

-- 
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 shade at redhat.com  Thu Feb 28 15:43:11 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 28 Feb 2019 16:43:11 +0100
Subject: Encryption fix in HotSpot
In-Reply-To: <029a99bd-6768-803f-37fa-2a49c63bc6d5@redhat.com>
References: <OFADE95772.64B449E3-ONC22583AD.004B8E66-C22583AD.004C8913@notes.na.collabserv.com>
 <2cb2c58f-1345-9bc3-b665-750abe3e4c7a@redhat.com>
 <6e2233c4-c7c4-013a-7f57-5082a5a02728@redhat.com>
 <029a99bd-6768-803f-37fa-2a49c63bc6d5@redhat.com>
Message-ID: <8513319f-ed28-8522-a41b-e3c3f6b6624f@redhat.com>

On 2/28/19 12:36 PM, Andrew Haley wrote:
> On 2/27/19 11:12 PM, Aleksey Shipilev wrote:
>> On 2/26/19 2:59 PM, Aleksey Shipilev wrote:
>>> Once 11.0.4 opens, we can start backporting these. You are welcome to do it :)
>>
>> Ah, that requires some benchmarking.
> 
> Um, why? The benchmarking, if it were necessary, should have been done
> on the upstream fix.

I'd like performance bugs to be verified during backports, if possible. Especially for
compiler/intrinsic bugs that have a high chance to interact with something else and turn out to be
the pessimization. This is not a requirement for those who do Fix Requests, but the more we know
about things we are backporting, the better. Saves time fixing the post-integration regressions.

> If you really think that special benchmarking for 11u is needed, please be specific about the
> form you believe it should take. Newcomers shouldn't have to guess.

I have already did it in my Fix Request, there is a link with performance results:
  https://bugs.openjdk.java.net/browse/JDK-8201633

-Aleksey


From daniel.daugherty at oracle.com  Thu Feb 28 15:59:36 2019
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Thu, 28 Feb 2019 10:59:36 -0500
Subject: Encryption fix in HotSpot
In-Reply-To: <8513319f-ed28-8522-a41b-e3c3f6b6624f@redhat.com>
References: <OFADE95772.64B449E3-ONC22583AD.004B8E66-C22583AD.004C8913@notes.na.collabserv.com>
 <2cb2c58f-1345-9bc3-b665-750abe3e4c7a@redhat.com>
 <6e2233c4-c7c4-013a-7f57-5082a5a02728@redhat.com>
 <029a99bd-6768-803f-37fa-2a49c63bc6d5@redhat.com>
 <8513319f-ed28-8522-a41b-e3c3f6b6624f@redhat.com>
Message-ID: <d88c1abf-6c42-9568-c3a2-25e2a65e50e5@oracle.com>

Not related to this particular fix...

Can folks please start using '[8u]', '[11u]' or '[12u]' in the subject
lines of their JDK Update Project emails? That would make life so much
easier for folks...

Dan


On 2/28/19 10:43 AM, Aleksey Shipilev wrote:
> On 2/28/19 12:36 PM, Andrew Haley wrote:
>> On 2/27/19 11:12 PM, Aleksey Shipilev wrote:
>>> On 2/26/19 2:59 PM, Aleksey Shipilev wrote:
>>>> Once 11.0.4 opens, we can start backporting these. You are welcome to do it :)
>>> Ah, that requires some benchmarking.
>> Um, why? The benchmarking, if it were necessary, should have been done
>> on the upstream fix.
> I'd like performance bugs to be verified during backports, if possible. Especially for
> compiler/intrinsic bugs that have a high chance to interact with something else and turn out to be
> the pessimization. This is not a requirement for those who do Fix Requests, but the more we know
> about things we are backporting, the better. Saves time fixing the post-integration regressions.
>
>> If you really think that special benchmarking for 11u is needed, please be specific about the
>> form you believe it should take. Newcomers shouldn't have to guess.
> I have already did it in my Fix Request, there is a link with performance results:
>    https://bugs.openjdk.java.net/browse/JDK-8201633
>
> -Aleksey
>


From shade at redhat.com  Thu Feb 28 16:34:26 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 28 Feb 2019 17:34:26 +0100
Subject: [11u] RFR (S) 8209055:
 c.s.t.javac.code.DeferredCompletionFailureHandler seems to use WeakHashMap
 incorrectly
In-Reply-To: <532bb538e46647c1881d303b13117e44@sap.com>
References: <24567d61-dbdb-5504-6f56-17e063508dab@redhat.com>
 <B2035B10-06FE-4BC8-BC51-7E0EC94C2D96@oracle.com>
 <e506d17a-0324-3201-f7c5-45833cabebc4@redhat.com>
 <C97F5116-A3EC-4AD6-A666-0E1DDA7F4FD1@oracle.com>
 <3fa63200bd784bf89335ed21ff43baea@sap.com>
 <f606840f-caab-6aff-717e-ae8314a4cb00@redhat.com>
 <3b49b309112047228162c370854bd561@sap.com>
 <db903c3c-7408-7c75-ae20-73b3a1dd88f9@redhat.com>
 <532bb538e46647c1881d303b13117e44@sap.com>
Message-ID: <575fb024-5819-dbef-62ab-b0d3ee4e38aa@redhat.com>

On 2/28/19 12:05 PM, Langer, Christoph wrote:
>> Okay, thanks! Maybe I just backport the patch as is, and we apply the
>> testbug backport right away.
> 
> Good idea, I've put you on copy in my mail to compiler-dev.

Reverted the patch to its original form, and langtools:tier1 indeed passes. Let's backport the
testbug fix after it soaks in head jdk a little bit.

-Aleksey


From takiguc at linux.vnet.ibm.com  Thu Feb 28 18:35:02 2019
From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi)
Date: Fri, 01 Mar 2019 03:35:02 +0900
Subject: Confirmation about jdk11u approval process
In-Reply-To: <76e25246-9c59-958f-e810-22e589394fb8@redhat.com>
References: <634770840670d2ee3a21f7c531da3b0b@linux.vnet.ibm.com>
 <fadd1e5f-2634-89ab-30c2-1a06da7ee32b@redhat.com>
 <2e7d6ad873235c18aaa3226bbc829556@linux.vnet.ibm.com>
 <76e25246-9c59-958f-e810-22e589394fb8@redhat.com>
Message-ID: <709b444897ff7f16718ca52952e7e0cc@linux.vnet.ibm.com>

Hello Andrew.

> What makes this critical? It looks like a minor memory leak. How long 
> would it
> take interacting with an application before a user noticed a problem?
It depends on how many characters user typed.
I assume memory leak size is less than 1KB for each input method 
handling event.
I did not check the impact for this issue...

Thanks,
Ichiroh Takiguchi

On 2019-02-28 22:51, Andrew Haley wrote:
> Hi,
> 
> On 2/28/19 1:22 PM, Ichiroh Takiguchi wrote:
>> I did not know about milestones for jdk11u.
>> So I was late...
>> 
>> Critical one may be JDK-8211393 [1] for Unix platform.
> 
> What makes this critical? It looks like a minor memory leak. How long 
> would it
> take interacting with an application before a user noticed a problem?


From aph at redhat.com  Thu Feb 28 19:02:07 2019
From: aph at redhat.com (Andrew Haley)
Date: Thu, 28 Feb 2019 19:02:07 +0000
Subject: Encryption fix in HotSpot
In-Reply-To: <8513319f-ed28-8522-a41b-e3c3f6b6624f@redhat.com>
References: <OFADE95772.64B449E3-ONC22583AD.004B8E66-C22583AD.004C8913@notes.na.collabserv.com>
 <2cb2c58f-1345-9bc3-b665-750abe3e4c7a@redhat.com>
 <6e2233c4-c7c4-013a-7f57-5082a5a02728@redhat.com>
 <029a99bd-6768-803f-37fa-2a49c63bc6d5@redhat.com>
 <8513319f-ed28-8522-a41b-e3c3f6b6624f@redhat.com>
Message-ID: <20c8effd-736e-0577-e85b-f794e39426a0@redhat.com>

On 2/28/19 3:43 PM, Aleksey Shipilev wrote:
> On 2/28/19 12:36 PM, Andrew Haley wrote:
>> On 2/27/19 11:12 PM, Aleksey Shipilev wrote:
>>> On 2/26/19 2:59 PM, Aleksey Shipilev wrote:
>>>> Once 11.0.4 opens, we can start backporting these. You are welcome to do it :)
>>>
>>> Ah, that requires some benchmarking.
>>
>> Um, why? The benchmarking, if it were necessary, should have been done
>> on the upstream fix.
> 
> I'd like performance bugs to be verified during backports, if
> possible. Especially for compiler/intrinsic bugs that have a high
> chance to interact with something else and turn out to be the
> pessimization. This is not a requirement for those who do Fix
> Requests, but the more we know about things we are backporting, the
> better. Saves time fixing the post-integration regressions.
> 
>> If you really think that special benchmarking for 11u is needed,
>> please be specific about the form you believe it should
>> take. Newcomers shouldn't have to guess.
> 
> I have already did it in my Fix Request, there is a link with
> performance results:
> https://bugs.openjdk.java.net/browse/JDK-8201633

Fair enough. So we're done, and Gidon doesn't have to do anything. That
wasn't clear to him.

-- 
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 aph at redhat.com  Thu Feb 28 19:03:42 2019
From: aph at redhat.com (Andrew Haley)
Date: Thu, 28 Feb 2019 19:03:42 +0000
Subject: Encryption fix in HotSpot
In-Reply-To: <d88c1abf-6c42-9568-c3a2-25e2a65e50e5@oracle.com>
References: <OFADE95772.64B449E3-ONC22583AD.004B8E66-C22583AD.004C8913@notes.na.collabserv.com>
 <2cb2c58f-1345-9bc3-b665-750abe3e4c7a@redhat.com>
 <6e2233c4-c7c4-013a-7f57-5082a5a02728@redhat.com>
 <029a99bd-6768-803f-37fa-2a49c63bc6d5@redhat.com>
 <8513319f-ed28-8522-a41b-e3c3f6b6624f@redhat.com>
 <d88c1abf-6c42-9568-c3a2-25e2a65e50e5@oracle.com>
Message-ID: <18f048bb-a8f1-b51b-5925-a3fb5c5254eb@redhat.com>

On 2/28/19 3:59 PM, Daniel D. Daugherty wrote:
> Can folks please start using '[8u]', '[11u]' or '[12u]' in the subject
> lines of their JDK Update Project emails? That would make life so much
> easier for folks...

Good point. We are, though, following a post from a newbie, who isn't necessarily
going to know that.

I'll try to remember, but I am sure to fail sometimes. So is everyone
else.

-- 
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 shade at redhat.com  Thu Feb 28 19:15:10 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 28 Feb 2019 20:15:10 +0100
Subject: Encryption fix in HotSpot
In-Reply-To: <20c8effd-736e-0577-e85b-f794e39426a0@redhat.com>
References: <OFADE95772.64B449E3-ONC22583AD.004B8E66-C22583AD.004C8913@notes.na.collabserv.com>
 <2cb2c58f-1345-9bc3-b665-750abe3e4c7a@redhat.com>
 <6e2233c4-c7c4-013a-7f57-5082a5a02728@redhat.com>
 <029a99bd-6768-803f-37fa-2a49c63bc6d5@redhat.com>
 <8513319f-ed28-8522-a41b-e3c3f6b6624f@redhat.com>
 <20c8effd-736e-0577-e85b-f794e39426a0@redhat.com>
Message-ID: <23eb3d2c-9d34-46bf-334c-16a33bb16abe@redhat.com>

On 2/28/19 8:02 PM, Andrew Haley wrote:
> On 2/28/19 3:43 PM, Aleksey Shipilev wrote:
>> I have already did it in my Fix Request, there is a link with
>> performance results:
>> https://bugs.openjdk.java.net/browse/JDK-8201633
> 
> Fair enough. So we're done, and Gidon doesn't have to do anything. That
> wasn't clear to him.

That is correct, no more work is needed on Gidon's part, it's all mine now.

-Aleksey


From shade at redhat.com  Thu Feb 28 20:05:48 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 28 Feb 2019 21:05:48 +0100
Subject: JBS Filters for JDK update work
In-Reply-To: <3fa6de91b4c44736a6570256851c52d3@sap.com>
References: <3fa6de91b4c44736a6570256851c52d3@sap.com>
Message-ID: <6b11c0da-d7ce-51fc-46d0-5ec3d0a78529@redhat.com>

On 2/27/19 3:34 PM, Langer, Christoph wrote:
> after putting some more efforts into my issue filters for jdk-updates projects, here is a current
> list of the available ones. It might be of value to some folks? As always: You need to be logged
> in to JBS, otherwise these won?t work.
Yes, so people complain (at least to Christoph and me) about the need to have a login to execute
complex JIRA queries. It is minor nuisance for OpenJDK Authors/Committers/Reviewers, but outsiders
are completely deprived of looking at those reports.

What can we do about that? We can dump the filter outputs regularly. For example, see filter-* here:
  https://builds.shipilev.net/backports-monitor/

-Aleksey


From goetz.lindenmaier at sap.com  Thu Feb 28 20:43:48 2019
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Thu, 28 Feb 2019 20:43:48 +0000
Subject: JBS Filters for JDK update work
In-Reply-To: <6b11c0da-d7ce-51fc-46d0-5ec3d0a78529@redhat.com>
References: <3fa6de91b4c44736a6570256851c52d3@sap.com>
 <6b11c0da-d7ce-51fc-46d0-5ec3d0a78529@redhat.com>
Message-ID: <VI1PR02MB5183F4CC92D712B0636D6B56EC750@VI1PR02MB5183.eurprd02.prod.outlook.com>

Hi Aleksey, 

This is really cool ?? !

Cheers,
  Goetz.

(I'm second after you in 11.0.3 pushes ??)

> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> Behalf Of Aleksey Shipilev
> Sent: Thursday, February 28, 2019 9:06 PM
> To: Langer, Christoph <christoph.langer at sap.com>; jdk-updates-
> dev at openjdk.java.net; jdk8u-dev at openjdk.java.net
> Subject: Re: JBS Filters for JDK update work
> 
> On 2/27/19 3:34 PM, Langer, Christoph wrote:
> > after putting some more efforts into my issue filters for jdk-updates
> projects, here is a current
> > list of the available ones. It might be of value to some folks? As always: You
> need to be logged
> > in to JBS, otherwise these won?t work.
> Yes, so people complain (at least to Christoph and me) about the need to
> have a login to execute
> complex JIRA queries. It is minor nuisance for OpenJDK
> Authors/Committers/Reviewers, but outsiders
> are completely deprived of looking at those reports.
> 
> What can we do about that? We can dump the filter outputs regularly. For
> example, see filter-* here:
>   https://builds.shipilev.net/backports-monitor/
> 
> -Aleksey


From philip.m.jones at siemens.com  Thu Feb 28 21:01:15 2019
From: philip.m.jones at siemens.com (Jones, Philip)
Date: Thu, 28 Feb 2019 21:01:15 +0000
Subject: JBS Filters for JDK update work
In-Reply-To: <VI1PR02MB5183F4CC92D712B0636D6B56EC750@VI1PR02MB5183.eurprd02.prod.outlook.com>
References: <3fa6de91b4c44736a6570256851c52d3@sap.com>
 <6b11c0da-d7ce-51fc-46d0-5ec3d0a78529@redhat.com>
 <VI1PR02MB5183F4CC92D712B0636D6B56EC750@VI1PR02MB5183.eurprd02.prod.outlook.com>
Message-ID: <3C3FEEEFE127B940BB0F5FADB28060412850DF93@DEKOMMBX001.net.plm.eds.com>

Thanks to all for the effort in this. I was one of the complainers and that is very useful output.

Philip

-----Original Message-----
From: jdk-updates-dev [mailto:jdk-updates-dev-bounces at openjdk.java.net] On Behalf Of Lindenmaier, Goetz
Sent: 28 February 2019 20:44
To: 'Aleksey Shipilev' <shade at redhat.com>; Langer, Christoph <christoph.langer at sap.com>; jdk-updates-dev at openjdk.java.net; jdk8u-dev at openjdk.java.net
Subject: RE: JBS Filters for JDK update work

Hi Aleksey,

This is really cool ?? !

Cheers,
  Goetz.

(I'm second after you in 11.0.3 pushes ??)

> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> Behalf Of Aleksey Shipilev
> Sent: Thursday, February 28, 2019 9:06 PM
> To: Langer, Christoph <christoph.langer at sap.com>; jdk-updates-
> dev at openjdk.java.net; jdk8u-dev at openjdk.java.net
> Subject: Re: JBS Filters for JDK update work
>
> On 2/27/19 3:34 PM, Langer, Christoph wrote:
> > after putting some more efforts into my issue filters for
> > jdk-updates
> projects, here is a current
> > list of the available ones. It might be of value to some folks? As
> > always: You
> need to be logged
> > in to JBS, otherwise these won?t work.
> Yes, so people complain (at least to Christoph and me) about the need
> to have a login to execute complex JIRA queries. It is minor nuisance
> for OpenJDK Authors/Committers/Reviewers, but outsiders are completely
> deprived of looking at those reports.
>
> What can we do about that? We can dump the filter outputs regularly.
> For example, see filter-* here:
>   https://builds.shipilev.net/backports-monitor/
>
> -Aleksey

-----------------
Siemens Industry Software Limited is a limited company registered in England and Wales.
Registered number: 3476850.
Registered office: Faraday House, Sir William Siemens Square, Frimley, Surrey, GU16 8QD.