RFR: Section on backporting [v6]

[David Holmes]

On 2/12/2021 12:06 am, Goetz Lindenmaier wrote:
> On Thu, 25 Nov 2021 18:17:46 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:
> 
>>> Guidance on backporting.
>>> Also moved "Backing out a change" to the testing section where I believe it fits better. This section is unchanged.
>>
>> Jesper Wilhelmsson has updated the pull request incrementally with one additional commit since the last revision:
>>
>>    Update src/index.md
>>    
>>    Co-authored-by: Andrew Haley <aph-open at littlepinkcloud.com>
> 
> A general remark wrt. backouts:
> One thing I have always been wondering about:
> What to do if a backported issue is backed out?

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.

> For an example see JDK-8274338. It was backported
> to 11.0.14 but then backed out again as JDK-8276943.
> Nevertheless in JBS the original issue is marked as backported
> to 11.0.14.
> Should we advise to remove this link, and change
> the backport issue and the backout issue to
> bugs?
> I think this would make obvious that the issue is NOT
> fixed in the older release (here 11.0.14).

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.

Cheers,
David
-----

> src/index.md line 1501:
> 
>> 1499:
>> 1500: In order to be allowed to push a change to one of the OpenJDK Update Release repositories, an approval is required. The [official process for how to request push approval for a backport](https://openjdk.java.net/projects/jdk-updates/approval.html) describes in detail how to work with JBS when requesting approvals. In short, there's a label `jdk<release>u-fix-request` that should be added to the main JBS issue. Also put a motivation as to why the issue needs to be backported as a comment in the main issue. Once the label and motivation has been added, wait for the maintainers of the release to approve your request. The approval will be indicated with a label, `jdk<release>u-fix-yes`, added to the main issue.
>> 1501:
> 
> Hi,
> I would propose to differ the development and release
> repositories most update projects use (like jdk11u-dev and jdk11u).
> 
> In this case, in the first sentence, it should say
> "... OpenJDK Update **Development** repositories ..."
> 
> and at the end you could add
>    If an update is in rampdown in the Release repository,
>    urgent fixes need to be approved with
>    `jdk<release>u-critical-request` / `jdk<release>u-critical-yes`.
> 
> If you want to keep it short, omitting this is ok.  But this is
> also missing on the "JDK Updates: Requesting push approval for fixes"
> wiki page referred to from here.
> 
> -------------
> 
> Changes requested by goetz (no project role).
> 
> PR: https://git.openjdk.java.net/guide/pull/66
>