RFR: 8u: 8076475: Misuses of strncpy/strncat

[Andrew Hughes]

On 27/05/2020 10:22, Andrew Haley wrote:
> On 26/05/2020 22:25, Andrew Hughes wrote:
>>
>> Completely agree. My aim was to balance what aph said, rather than
>> suggest that we go to the other extreme.
> 
>> I also think we need to be very aware of the growing expertise
>> needed to maintain 8u. Thank you for expanding on this in more
>> detail.
> 
> I'm very grateful for Andrew Dinn's reply. In particular I was
> startled by the idea that backporting dependent changes might in some
> way deskill the process, such that the knowledge and experience needed
> for someone to work on backports is reduced.

I'd be startled too. I'm not aware of anyone suggesting such a thing.

My point was that each bespoke 8u solution increases the amount of
8u-specific knowledge someone needs when approaching a backport.
Specifically, if a fix was implemented differently in 8u, and their
backport builds on top of this using assumptions that are true in later
OpenJDK versions, they need to be aware of this and adjust the backport
accordingly.

It does not imply that backporting dependent changes somehow decreases
the required baseline knowledge, simply that it doesn't increase it to
the same extent.

> 
>> When I look a a proposed backport, I like to see that potential
>> dependencies have been considered, even if it is then decided to
>> work around them.
> 
> Fair enough, consider them, but I will repeat a crucial part of what
> Andrew Dinn wrote:
> 
>>> Downstream fixes should normally only presume the presence of such
>>> a dependency if there is a compelling need to have that dependency
>>> /in its own right/. If not then the default assumption has to be
>>> that a downstream fix should be sought without relying on that
>>> upstream dependency.
> 
> A direct consequence of this is that backporting a dependency has to
> be justified in a strong way: it should be needed.

As I said, I don't disagree with this. You can't make such a judgement
without considering what the potential backports are first.

> 
>> My experience of working on backports for 6u & 7u over the last
>> decade or so suggests that no situation is ever the same as
>> another. In one case, you may need to completely rewrite the fix
>> (common with HotSpot, where there are often significant refactorings
>> and major reworkings). In another, it may make sense to backport a
>> dependent change, because it's low risk and very likely to be a
>> dependency of other future changes (common with testing
>> infrastructure)
> 
> It is not appropriate to import dependent patches simply because they
> might be needed by future patches or in order to reduce the divergence
> between 8u and trunk. I'm happy enough with this for test code, but
> not for changes to the runtime code.

Testing was exactly the example of this I gave above.

> 
> I'm aware that this constitutes a change to the way that maintenance of
> JDK updates has been done for some time. However, as JDK 8u matures
> it is a necessary change.
> 

Not that I'm aware of. I've certainly refused approval to backports
before that I've felt are unnecessary and potentially disruptive.

I'm struggling to see where we disagree here.
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222