Laszlo:
I understand this release requirement. Now, we have Feature Planning Freeze (1WW), Soft Feature Freeze (1WW) and Hard Feature Freeze (5 days). I would propose to remove Feature Planning Freeze, keep Soft Feature Freeze (1WW), and extend Hard Feature Freeze (1week and 5 days). For Q3 stable tag, new planning will be like the below.

Date (00:00:00 UTC-8) Description
2021-05-28 Beginning of development
2021-08-09 Soft Feature Freeze
2021-08-16 Hard Feature Freeze
2021-08-27 Release

Thanks
Liming

On 06/25/21 04:11, gaoliming wrote:

Laszlo:
I understand this release requirement. Now, we have Feature Planning Freeze (1WW), Soft Feature Freeze (1WW) and Hard Feature Freeze (5 days). I would propose to remove Feature Planning Freeze, keep Soft Feature Freeze (1WW), and extend Hard Feature Freeze (1week and 5 days). For Q3 stable tag, new planning will be like the below.

Date (00:00:00 UTC-8) Description
2021-05-28 Beginning of development
2021-08-09 Soft Feature Freeze
2021-08-16 Hard Feature Freeze
2021-08-27 Release

I haven't even been aware of the "planning freeze". I think we can
remove it.

Regarding the HFF, I'd really suggest / request 14 calendar days.

Thanks
Laszlo

Thanks
Liming

-----邮件原件-----
发件人: rfc@edk2.groups.io <rfc@edk2.groups.io> 代表 Laszlo Ersek
发送时间: 2021年6月22日 18:24
收件人: rfc@edk2.groups.io
抄送: Liming Gao (Byosoft address) <gaoliming@...>
主题: [edk2-rfc] release candidate tags

Hi,

(1) I'm proposing an extension to the soft feature freeze and hard
feature freeze announcements:


https://github.com/tianocore/tianocore.github.io/wiki/SoftFeatureFreeze#an
nouncing-the-soft-feature-freeze

https://github.com/tianocore/tianocore.github.io/wiki/HardFeatureFreeze#a
nnouncing-the-hard-feature-freeze

as follows:

When the SFF is announced, the Release Manager should please tag the
then-HEAD commit of the "master" branch with a Release Candidate tag of
the form

edk2-stableYYYYMM-rc0

When the HFF is announced, the Release Manager should please tag the
then-HEAD commit of the "master" branch with a Release Candidate tag of
the form

edk2-stableYYYYMM-rc1

Note that a single commit may bear multiple tags in the end; for
example, if there are no fixes merged between the HFF announcement and
the actual release, then the final commit would bear both tags

edk2-stableYYYYMM-rc1
edk2-stableYYYYMM


The purpose of the Release Candidate tags is to coordinate pre-release
testing between consumers (downstreams) of edk2. Concentrated
pre-release testing is useful because it helps downstreams (a) identify
issues against a common base and (b) contribute upstream bugfixes still
in time for the actual release.


(2) Relatedly, I'm proposing that the Hard Feature Freeze never be
shorter than 2 calendar weeks.

Background: if I recall correctly, the Hard Feature Freeze for
edk2-stable202105 was 4 days. That's not enough for the above-described,
downstream, pre-release testing. In my opinion, two calendar weeks are
sensible for the "finishing touches" on the release.

I'm not asking for an extended Soft Feature Freeze. I reckon that most
downstreams will want to start their pre-release integration and testing
at the rc1 tag. Between the rc0 and rc1 tags (that is, during the Soft
Feature Freeze), features reviewed previously may still be merged, and
those have a higher chance to invalidate downstream testing performed
earlier. So the "real" testing will likely commence at rc1, and so the
period we'd extend to 2 calendar weeks should be the Hard Feature
Freeze.

(I'm not expressing the new period length in "business days", as the
definition of those varies around the world, and over time.)

Thanks,
Laszlo