[edk2-devel] Soft Feature Freeze start date delays to 2020-08-24 for edk2-stable202008

Laszlo Ersek

Hi Jiewen,

On 08/26/20 03:19, Yao, Jiewen wrote:
To clarify below:
I just notice this one week delay. It impacts us.

[PATCH v4 0/8] Need add a FSP binary measurement
The SecurityPkg patches have not been approved yet, and Bret and
Jiewen are still testing / discussing (as far as I understand):
<https://edk2.groups.io/g/devel/message/64526>. Material for the next

[Jiewen] I think the security pkg is already approved by me and Jian
(SecurityPkg maintainer) Bret also provides feedback that it looks
The series in question has three SecurityPkg patches:

[PATCH v4 1/8] SecurityPkg/TcgEventLogRecordLib: add new lib for firmware measurement
[PATCH v4 5/8] SecurityPkg/dsc: add FvEventLogRecordLib
[PATCH v4 7/8] SecurityPkg/Tcg2: handle PRE HASH and LOG ONLY

As I'm writing this, *none* of the listed patches have any kind of
Reviewed-by or Acked-by, either included in the patches themselves, or
posted in response to them.

I request to check in to stable202008, if possible.
We can do that only if (a) we extend the SFF deadline again, and (b)
each of the SecurityPkg patches receives at least an Acked-by from one
of the SecurityPkg maintainers, until the new deadline.

I'm certainly not against the idea. I don't mind if the release slips
some more; it's OK to say that we're not ready to release yet. The point
is, as long as we're doing more work for completing the release, we
should prolong the stabilization period as well (opportunity for people
to test).


Laszlo Ersek

On 08/26/20 12:16, Yao, Jiewen wrote:
HI Laszlo
I checked the history.

Jiewen replied " [PATCH v3 0/8] Need add a FSP binary measurement" with review-by on V3 patch series in August 15, with comment to rename FvEventLogRecordLib to TcgEventLogRecordLib.
You are correct:


I have two comments on this.

First, because you authored the IntelFsp2WrapperPkg patches in the
series, you cannot R-b them (you cannot R-b your own patches, even if
they are resent by someone else). However, that's not necessary: the
IntelFsp2WrapperPkg is maintained by Chasel Chiu, and Chasel did review
those patches, under v4, in the end.

Second, the v4 submitter, Qi Zhang, should have picked up your R-b from
under v3, and included them in the v4 posting. (Assuming the v3->v4
changes were exactly as you requested, under v3.)

Qi sent v4 series in August 17, with only naming change from FvEventLogRecordLib to TcgEventLogRecordLib.
OK. In this case, Qi should have posted the v4 SecurityPkg patches with
your R-b *already* present.

Jian replied "[PATCH v3 0/8] Need add a FSP binary measurement" with reviewed-by on V3 patch series in August 18.
That's correct too:


This means that Qi should have sent v4 with Jian's R-b on *every* patch.

So I treat this patch series is qualified to check in (since V4 adopted my comment). But please let me know if there is any misunderstanding.
No, you are entirely correct. I was misled because v4 was not posted
correctly, with regard to the feedback tags given under v3.

So, what remains to do now is this: until the HFF (2020-08-28) we can,
and should, merge v4 of the series. As follows:

- apply Jian's R-b from under v3 to every patch in the series

- apply your R-b from under v3 to the patches you did *not* author (that
is, apply the tag to the SecurityPkg patches, plus to
"IntelFsp2WrapperPkg/dsc: add HashLib, Tpm2CommandLib and Tpm2DeviceLib")

- apply Chasel Chiu's R-b from under v4 to the IntelFsp2WrapperPkg patches.

This will make the series fully reviewed, and mergeable.

Note that Chasel requested a copyright year update when pushing, here:
<https://edk2.groups.io/g/devel/message/64382>. Given that Chasel
(maintainer/reviewer), Jiewen (original author) and Qi (poster) all work
for Intel, and the (C) notice in question is Intel's, I think that *any*
maintainer can satisfy Chasel's request, when merging the series.

So, I think I'll go ahead and merge v4. Thank you for the v3 pointers.

When I am about to merge, I am told that we are in SFF and I cannot check in.
According to the plan, I will check in after August 28, which is end of August. It is still OK for me.
2020-08-14 Soft Feature Freeze
2020-08-21 Hard Feature Freeze
2020-08-28 Release

But now, if we need delay one week, then the final release data will be September. If I cannot check in now, I will have to check in at September.
That is why I said, it impacts me, because of this one week delay.
I'm going to merge the series for you, given the amount of work needed
for collecting the feedback tags.