RFR: Section about the release process [v2]

[Stuart Marks]

On Wed, 11 Aug 2021 23:54:21 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

>> src/index.md line 1759:
>> 
>>> 1757: During the rampdown of a release there are two repositories in play, the stabilization fork for the outgoing release, and the mainline repository where the next release is being developed. Any bugfix going into the stabilization fork is likely to be desired in mainline as well. As a developer you should push your fix to the stabilization fork **only**, even if you intend for it to go to both repositories. Your fix will be forward ported to mainline.
>>> 1758: 
>>> 1759: All fixes that are pushed to the stabilization fork are forward ported to mainline. If you have a fix that is only intended for the stabilization fork you will have to manually back it out from mainline once it has been forward ported.
>> 
>> Is this the way it really works? Certainly every commit is pulled from the stabilization fork into the mainline, since we want the mainline to include all the commits from the previous release. But are all those commits necessarily merged onto the master branch? Offhand I can't think of a better way, but maybe this deserves more discussion. At the very least, maybe there needs to be some workflow. For example, if you want to fix JDK-xxx in the stabilization fork but not in the mainline, you need to file JDK-yyy to back out the fix after it's merged into the mainline, and then link the bugs together in a particular way, or something.
>
> This is the way it works. I forward port all changes from JDK 17 to mainline, and if a change is not for mainline it must be backed out. I added a paragraph with your example to clarify the JBS part.

OK. If this is the way it really works, then clearly that reality needs to be documented. I'm a bit surprised about this; on the other hand, I thought of several alternatives, but they're either unworkable or more complicated and don't offer any advantages. This is probably a pretty rare case, so maybe the workflow is fine as it stands.

The filing-two-bugs material looks reasonable. I might strengthen it to say something like the following.

« As soon as you know that there is a fix that needs to go into the stabilization fork but not the mainline, you should do the following: file a bug JDK-yyy to cover the backout work, link it to JDK-xxx, set its Fix Version to the next release, add a comment describing the situation, and set the priority to be relatively high (e.g., P3). Then, you have to wait until the JDK-xxx fix is forward ported to the mainline before actually fixing JDK-yyy. Making these settings in JDK-yyy will help ensure that it won't be missed. »

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

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