RFR: Section on backporting

[Jesper Wilhelmsson]

On Thu, 2 Dec 2021 04:12:12 GMT, David Holmes <david.holmes at oracle.com> wrote:

> Note there is a distinction, in this context, between "backing out" a change and later reversing it, or changing it. "backouts" are when a change is pushed and quickly demonstrates it has issues and needs to be undone promptly. But sometimes a change is available for a while and we only later discover it is the source of an unexpected consequence (functional or performance) and so it needs to be modified or sometimes completely reversed. Generally speaking the former should never be backported because a backport should only happen after a change has had some bake time.

In the particular case mentioned here, JDK-8274338, the issue itself was not backed out from mainline, but only the 11.0.14 backport was backed out from 11u. This is a rare case (I hope) but clearly motivates some guidance on how to handle it as the standard model for backports is not sufficient here.

> I would think we should follow what is done for the primary issue in such a case - the backport issue should be Resolved as "Fix failed", and link to the backout issue of course.

I have done that for this backport but this is not enough. The main issue still have the backported-by-link to JDK-8276785 (11.0.14) so in the main issue it still looks like this fix was backported to 11.0.14. A minimum action here would be to also remove the backported-by-link and add a relates-to-link instead.

-------------

PR: https://git.openjdk.java.net/guide/pull/66