RFR: Section about the release process [v2]

[Stuart Marks]

On Thu, 8 Jul 2021 23:23:29 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

>> Answering some common questions around the release process.
>
> Jesper Wilhelmsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed typos

Changes requested by smarks (Author).

src/index.md line 1719:

> 1717: 
> 1718: [**The start of a release**]{#release-start}
> 1719: :    Since development is always ongoing in the mainline repository ([openjdk/jdk](https://github.com/openjdk/jdk)), the start of a new release can be said to begin when the former release is forked of from mainline. After the start of the release follows six months of development to implement and integrate all the cool stuff that will go into the next release. After these six months rampdown begins.

wording: probably "forked from the mainline" at the end of the first sentence.

src/index.md line 1725:

> 1723: 
> 1724: [**Ramp Down Phase 1 (RDP1)**]{#rdp1}
> 1725: :    At RDS we enter RDP1. During this phase you may continue to fix P1-P3 product bugs. P4 and P5 product bugs should be deferred at this point. Test bugs (labeled `noreg-self`) and documentation bugs (labeled `noreg-doc`) can still be fixed in RDP1 regardless of their priority. To fix an enhancement an approval is required. See the [Late-Enhancement Request Process](https://openjdk.java.net/jeps/3#Late-Enhancement-Request-Process) for details on how to do that. If you want to defer a P1 or P2 bug during RDP1 you will also need an approval. See the [Bug-Deferral Process](https://openjdk.java.net/jeps/3#Bug-Deferral-Process) for more details.

It would be good to avoid duplication with JEP 3. Some of the text here seems to do that, such as late enhancements and bug deferrals. By contrast, the discussion in the previous section about when to put features into a release is indeed suitable for the Guide.

I'm not familiar with "RDS". It's not mentioned anywhere in JEP 3, nor have I heard it much in our discussions. Can't we just say that the mainline repository is forked at the beginning of RDP1, and the new rules apply to the stabilization repo?

src/index.md line 1728:

> 1726: 
> 1727: [**Feature Complete (FC)**]{#fc}
> 1728: :    Feature Complete is declared when all features that are supposed to be in the release have been integrated into the release. With the six-month release cadence, FC is defined as a date rather than a set of features, so the features that are integrated by FC are the features that should be in the release. FC is normally the same day as RDS.

I'm not sure talking about "Feature Complete" is helpful. In projects that are feature-driven, "feature complete" means "we've completed all the features that have been committed for this release". That clearly doesn't apply here. So then you have to explain that it means something different. It doesn't seem to be a separate phase or milestone. The feature set is frozen at the beginning of RDP1 (with some exceptions permitted, namely, the late-enhancement requests). Put another way, the deadline for integrating JEPs and enhancements is the beginning of RDP1.

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?

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.

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

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