[11u] RFR(S): 8241234: Unify monitor enter/exit runtime entries.
Andrew Dinn
adinn at redhat.com
Wed Sep 9 09:38:29 UTC 2020
On 09/09/2020 09:23, Andrew Haley wrote:
> Thinking about this some more: it really should be a reviewer's job to
> object if a patch is likely to fail a risk-vs-reward test. Every patch
> should be considered carefully in this way. It's hard for
> inexperienced contributors to be able to make such judgements, so they
> should ask on the list if it isn't clear.
I agree. Indeed, I have already been doing that for some of the more
complex patches.
Another couple of things that should really be agreed between the
backporter and a reviewer when a patch is complex or has wider-reaching
side-effects than jst fixing the bug itself is whether 1) to limit the
backport to some subset of the upstream change or even 2) to come up
with a custom change that fixes the problem in a different way. That may
involve the backporter asking for an early review of a preliminary
patch. There's /nothing wrong/ with doing that.
> But we can say this much: crashes and Java language specification
> failures will always qualify for fixes; performance improvements,
> especially small performance improvements, not so much. Compatibility
> bugs which break communications protocols must be fixed. Updates for
> new versions of communication protocols and new ciphers, probably.
>
> There's a wide grey area in between, it's true.
Yes, and that is where reviewers can and should be brought in to help
clarify things.
regards,
Andrew Dinn
-----------
Red Hat Distinguished Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill
More information about the jdk-updates-dev
mailing list