RFR: Section about the release process [v2]

[Jesper Wilhelmsson]

On Tue, 10 Aug 2021 23:36:22 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 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.

Fixed

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

I removed RDS and reworked RDP1. Now referring to JEP 3 instead of repeating all the details.

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

I removed FC.

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

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