RFR: Section about the release process [v2]

[Jesper Wilhelmsson]

On Tue, 10 Aug 2021 23:43:28 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> Jesper Wilhelmsson has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed typos
>
> src/index.md line 1753:
> 
>> 1751: | RDP1      | Fix or Defer with approval | Fix or Defer with approval | Fix or Defer | Defer | Fix or Defer | Fix with approval or Defer |
>> 1752: | RDP2      | Fix with approval or Defer with approval | Fix with approval or Defer with approval | Defer | Defer | Fix or Defer | Defer |
>> 1753: | RC        | Fix with approval or Defer with approval | Defer | Defer | Defer | Defer    | Defer    |
> 
> Is this table the same as in JEP 3?

I was never happy with the table. I think the table in JEP 3 is difficult to read but this wasn't any better. I removed the table. I think some other (graphical) picture is needed to clarify what can be pushed and deferred when.

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

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

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