From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-1.mimecast.com (us-smtp-1.mimecast.com [205.139.110.120]) by mx.groups.io with SMTP id smtpd.web10.13927.1598453355581368465 for ; Wed, 26 Aug 2020 07:49:15 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=BxePuPrZ; spf=pass (domain: redhat.com, ip: 205.139.110.120, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1598453354; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=hgE5JZ5zsn7YFFHi/0CdO+S3DV8k4Eob0R5GWM1gs44=; b=BxePuPrZLo62GLGF90QIlY4TtWQ9RSlgUPyfzNS9T4j1VQpwMO0VUqsZ4ee/2UFR2l8H61 9608i4jyLNSsvAkkIgsTIS4wxqIxdCkyQOwU761aO5goZKSKQBwDj4Bz1vm3CR0GBHp4Cg QF6h5UulutL6Z8aN1YbdQYkSKZnbUsU= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-346-lFDoIFV7M_igfLivTQPrbg-1; Wed, 26 Aug 2020 10:49:00 -0400 X-MC-Unique: lFDoIFV7M_igfLivTQPrbg-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 8BD01425D0; Wed, 26 Aug 2020 14:48:58 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-114-182.ams2.redhat.com [10.36.114.182]) by smtp.corp.redhat.com (Postfix) with ESMTP id B34F97D4F9; Wed, 26 Aug 2020 14:48:53 +0000 (UTC) Subject: Re: [edk2-devel] Soft Feature Freeze start date delays to 2020-08-24 for edk2-stable202008 To: "Yao, Jiewen" , "devel@edk2.groups.io" , gaoliming , 'Leif Lindholm' , "afish@apple.com" , "Kinney, Michael D" , "Guptha, Soumya K" Cc: "announce@edk2.groups.io" , "'Chang, Abner (HPS SW/FW Technologist)'" , "Zhang, Qi1" , "marcello.bauer@9elements.com" References: <001501d679b8$bdb3aa20$391afe60$@byosoft.com.cn> <5140ca34-9534-8873-8fbb-e07a9132d53d@redhat.com> From: "Laszlo Ersek" Message-ID: <75d83546-1b22-ab44-5370-33ac95194a39@redhat.com> Date: Wed, 26 Aug 2020 16:48:52 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=lersek@redhat.com X-Mimecast-Spam-Score: 0.003 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit 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: https://edk2.groups.io/g/devel/message/64299 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: https://edk2.groups.io/g/devel/message/64342 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: . 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. Thanks! Laszlo