[11u] RFR 8235183: Remove the "HACK CODE" in comment

[Andrew Haley]

Hi,

On 3/16/20 8:46 AM, Langer, Christoph wrote:

>> I can't guess why Oracle chose to backport this comment-only change,
>> but I believe that 11u is about fixing *significant* bugs, by which I
>> mean significant to *users*. Last year Aleksey Shipilev made the point
>> (rather forcefully!) that maintainers should still be able to reject
>> patches even if Oracle approved them. I suspect that the reason for
>> his reasoning was if Oracle decide to jump off a cliff, we shouldn't
>> jump with them. That isn't the case here, though: this patch is
>> harmless.
>
> Just in case you hadn't been aware of it, we do reject/ignore some
> things that Oracle did. If you query for the label "openjdk-na" in
> JBS you'll find quite a bunch of items that don't apply to OpenJDK
> and won't show up in our stats. At the moment the count of this list
> is 64.
>
> There are also changes like
> https://bugs.openjdk.java.net/browse/JDK-8232569 (Use test image
> from different jib profile for testing), where the change could
> apply to OpenJDK source code but we chose not to take it since the
> file that was edited there is only used in Oracle infrastructure.

Yes, I get that.

>> As has been pointed out, this is almost a zero-risk patch in that it
>> does nothing, but it's also a zero-gain patch in that it does nothing.
>> On the other hand it might mess up our statistics because there will
>> appear to be a patch Oracle backported but we didn't, and I can see
>> that will be misleading. It might even cause people to distrust us
>> because we're not fixing some bugs.
>>
>> So I'm no longer sure. If you think it makes life easier for you to
>> apply patches which only affect source code, and they have equivalent
>> Oracle backports, go ahead. But let's not do so otherwise.
>
> OK, so, given that it's
>
> a) harmless though effectless
> b) we've always backported these kind of patches so far
> and
> c) backport work is done & reviewed,
>
> I'll admit that backport.

OK, fine. But b) is *not* a reason for anything. We're not bound to
tradition in that way, but obviously it does not help anyone working
on backports not to know what the ground rules are. So we need to try
to be consistent, but it's easy to fall into habits which become rules
by accident.

All of this email still applies, modulo the controversial (and
subsequently reverted) paragraph about "backports which have already
been approved by Oracle..."

  https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-August/001578.html

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