[prev in list] [next in list] [prev in thread] [next in thread]
List: openjdk-compiler-dev
Subject: Re: Backporting JDK-8210483 to Java 11
From: Vitaly Davidovich <vitalyd () gmail ! com>
Date: 2019-02-06 16:53:38
Message-ID: CAHjP37GuvxytNKDZo9np1oJALwd+pL+mfOYYdrmvykJ39r-zMQ () mail ! gmail ! com
[Download RAW message or body]
Hey Andrew,
On Wed, Feb 6, 2019 at 4:19 PM Andrew Dinn <adinn@redhat.com> wrote:
> Hi Vitaly,
>
> On 06/02/2019 15:27, Vitaly Davidovich wrote:
> > Yes, I'd assume the difficulty and perceived (in)stability of a backport
> > request would be weighed in the decision to backport or not. But, this
> > is a bug fix - javac fails on fairly pedestrian code.
>
> It may seem counter-intuitive but Brian is 100% correct in stating that
> decisions over backports require balancing of pros and cons -- even in
> cases where the proposed backport is a bug fix. Changes may have
> unintended consequences. Risk aversion sometimes trumps corrective
> action, especially when correcting a rare error case.
>
Hmm, I don't think there's anything counter-intuitive - I understand
Brian's (and your) point in general, but I was interested in this specific
bug only, not a more general backport policy.
>
> > Again, I'd imagine a javac bug of the sort here would be deemed critical
> > to backport to an LTS release. But ok, if the answer is "refer to your
> > LTS provider", then so be it.
> What Brian specifically recommended was that you negotiated this request
> with the maintainer of a specific LTS release. When the maintainer has a
> private, proprietary tree (like, say, Oracle) the utility of such a
> request may depend on you being in a commercial, contractual
> relationship. An alternative route is to approach those maintaining the
> tree for the continuing open source project. Fixes applied to that tree
> should appear in subsequent open source LTS releases which you will be
> able to obtain without the requirement to be in a commercial,
> contractual relationship.
>
> Neither path guarantees a patch will be provided. Neither rules it out.
>
Sure. Perhaps my impression of this bug's severity differs from reality,
but I'm having a hard time seeing a case where it doesn't require a fix in
11. There're the unanswered questions around who'll do the backport work,
which I understand now.
>
> At this point I would normally route you straight to the jdk11u project
> maintainer -- except that the jdk11u project is in the process of being
> handed over from Oracle to an as yet unconfirmed project lead. That
> situation ought to change very soon and, when it does, I suggest you
> post to the jdk updates list (jdk-updates-dev@openjdk.java.net) asking
> whether a backport is possible.
>
Thanks, I wasn't aware of this mailing list - I'll keep that in mind going
forward.
>
> Bonus points would definitely be awarded if your request included a
> jdk11-ready version of the upstream patch in that request, preferably
> accompanied with reports of tests confirming its validity. And, as Brian
> hinted: What do points mean? a healthy open source eco-system!
>
> 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
>
[Attachment #3 (text/html)]
<div dir="ltr"><div dir="ltr">Hey Andrew,</div><br><div class="gmail_quote"><div \
dir="ltr" class="gmail_attr">On Wed, Feb 6, 2019 at 4:19 PM Andrew Dinn <<a \
href="mailto:adinn@redhat.com">adinn@redhat.com</a>> wrote:<br></div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex">Hi Vitaly,<br> <br>
On 06/02/2019 15:27, Vitaly Davidovich wrote:<br>
> Yes, I'd assume the difficulty and perceived (in)stability of a backport<br>
> request would be weighed in the decision to backport or not. But, this<br>
> is a bug fix - javac fails on fairly pedestrian code.<br>
<br>
It may seem counter-intuitive but Brian is 100% correct in stating that<br>
decisions over backports require balancing of pros and cons -- even in<br>
cases where the proposed backport is a bug fix. Changes may have<br>
unintended consequences. Risk aversion sometimes trumps corrective<br>
action, especially when correcting a rare error case.<br></blockquote><div>Hmm, I \
don't think there's anything counter-intuitive - I understand Brian's \
(and your) point in general, but I was interested in this specific bug only, not a \
more general backport policy.</div><blockquote class="gmail_quote" style="margin:0px \
0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br>
> Again, I'd imagine a javac bug of the sort here would be deemed critical<br>
> to backport to an LTS release. But ok, if the answer is "refer to \
your<br> > LTS provider", then so be it. <br>
What Brian specifically recommended was that you negotiated this request<br>
with the maintainer of a specific LTS release. When the maintainer has a<br>
private, proprietary tree (like, say, Oracle) the utility of such a<br>
request may depend on you being in a commercial, contractual<br>
relationship. An alternative route is to approach those maintaining the<br>
tree for the continuing open source project. Fixes applied to that tree<br>
should appear in subsequent open source LTS releases which you will be<br>
able to obtain without the requirement to be in a commercial,<br>
contractual relationship.<br>
<br>
Neither path guarantees a patch will be provided. Neither rules it \
out.<br></blockquote><div>Sure. Perhaps my impression of this bug's severity \
differs from reality, but I'm having a hard time seeing a case where it \
doesn't require a fix in 11. There're the unanswered questions around \
who'll do the backport work, which I understand now. </div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"> <br>
At this point I would normally route you straight to the jdk11u project<br>
maintainer -- except that the jdk11u project is in the process of being<br>
handed over from Oracle to an as yet unconfirmed project lead. That<br>
situation ought to change very soon and, when it does, I suggest you<br>
post to the jdk updates list (<a href="mailto:jdk-updates-dev@openjdk.java.net" \
target="_blank">jdk-updates-dev@openjdk.java.net</a>) asking<br> whether a backport \
is possible.<br></blockquote><div>Thanks, I wasn't aware of this mailing list - \
I'll keep that in mind going forward. </div><blockquote class="gmail_quote" \
style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"> <br>
Bonus points would definitely be awarded if your request included a<br>
jdk11-ready version of the upstream patch in that request, preferably<br>
accompanied with reports of tests confirming its validity. And, as Brian<br>
hinted: What do points mean? a healthy open source eco-system!<br>
<br>
regards,<br>
<br>
<br>
Andrew Dinn<br>
-----------<br>
Senior Principal Software Engineer<br>
Red Hat UK Ltd<br>
Registered in England and Wales under Company Registration No. 03798903<br>
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric \
Shander<br> </blockquote></div></div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic