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

[Andrew Haley]

On 3/13/20 10:24 AM, Langer, Christoph wrote:
>
>> -----Original Message-----
>> From: Andrew Haley <aph at redhat.com>
>> Sent: Freitag, 13. März 2020 11:02
>> To: Langer, Christoph <christoph.langer at sap.com>; Reingruber, Richard
>> <richard.reingruber at sap.com>; jdk-updates-dev at openjdk.java.net
>> Subject: Re: [11u] RFR 8235183: Remove the "HACK CODE" in comment
>>
>> How do you know? Presumably because you have access to Oracle's closed
>> source code.
>
> No, we just know that this backport exists:
> https://bugs.openjdk.java.net/browse/JDK-8238957.

OK, I see.

>> That policy exists because we don't want to have bugs in OpenJDK which
>> are fixed in Oracle's releases. There never has been any policy which
>> says that the source code should be identical, and that's impossible
>> anyway. It never occurred to me that anyone would interpret the policy
>> in such a way.
>
> Sure, the main motivation for that policy is to have all bugs fixed
> in OpenJDK that Oracle chose to fix.
> For 11u, though, we have so far effectively backported everything we
> saw backported to Oracle, no matter if it were comment changes,
> license header changes etc.

That seems a little bit extreme, almost like we're making extra work
for ourselves because Oracle has done so. But thank you for that
explanation.

> I personally would rather continue with this. But if we chose to
> stop with that and be more picky about changes that don't affect the
> binary results, I have no strong emotions. We should just not reject
> this backport and later on approve others that fall into the same
> category.

Sure.

> You are the lead maintainer, you can set the rules ��

Yes, I understand that.

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.

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.

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