Re: [edk2-announce] Re: Soft Feature Freeze starts now for edk2-stable202008

["Laszlo Ersek" <lersek@redhat.com>]

On 08/19/20 18:20, Gao, Liming wrote:
> 
>> -----Original Message-----
>> From: Chang, Abner (HPS SW/FW Technologist) <abner.chang@hpe.com>
>> Sent: Wednesday, August 19, 2020 10:59 PM
>> To: Laszlo Ersek <lersek@redhat.com>; Leif Lindholm <leif@nuviainc.com>
>> Cc: devel@edk2.groups.io; Gao, Liming <liming.gao@intel.com>; announce@edk2.groups.io; afish@apple.com; Kinney, Michael D
>> <michael.d.kinney@intel.com>
>> Subject: RE: [edk2-announce] Re: Soft Feature Freeze starts now for edk2-stable202008
>>
>>
>>
>>> -----Original Message-----
>>> From: Laszlo Ersek [mailto:lersek@redhat.com]
>>> Sent: Wednesday, August 19, 2020 10:30 PM
>>> To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@hpe.com>; Leif
>>> Lindholm <leif@nuviainc.com>
>>> Cc: devel@edk2.groups.io; liming.gao <liming.gao@intel.com>;
>>> announce@edk2.groups.io; afish@apple.com; Kinney, Michael D
>>> <michael.d.kinney@intel.com>
>>> Subject: Re: [edk2-announce] Re: Soft Feature Freeze starts now for edk2-
>>> stable202008
>>>
>>> On 08/19/20 15:34, Chang, Abner (HPS SW/FW Technologist) wrote:
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: Laszlo Ersek [mailto:lersek@redhat.com]
>>>>> Sent: Wednesday, August 19, 2020 9:19 PM
>>>>> To: Leif Lindholm <leif@nuviainc.com>; Chang, Abner (HPS SW/FW
>>>>> Technologist) <abner.chang@hpe.com>
>>>>> Cc: devel@edk2.groups.io; liming.gao <liming.gao@intel.com>;
>>>>> announce@edk2.groups.io; afish@apple.com; Kinney, Michael D
>>>>> <michael.d.kinney@intel.com>
>>>>> Subject: Re: [edk2-announce] Re: Soft Feature Freeze starts now for
>>>>> edk2-
>>>>> stable202008
>>>>>
>>>>> On 08/19/20 13:48, Leif Lindholm wrote:
>>>>>> (Slightly trimmed recipient list due to different patch being
>>>>>> discussed.)
>>>>>>
>>>>>> So, I can't make this call, because I'm the one who messed up.
>>>>>>
>>>>>> This patch does exactly what I had requested Abner to do some time
>>>>>> back (off-list, unfortunately), and I was *convinced* I gave it an
>>>>>> R-b as soon as it hit my inbox - until Abner nudged me about it yesterday.
>>>>>>
>>>>>> The patch in question is
>>>>>> https://edk2.groups.io/g/devel/topic/76021725
>>>>>
>>>>> My understanding is:
>>>>>
>>>>> (1) there is an external project that consumes the FDT library in
>>>>> EmbeddedPkg, meaning the lib class header
>>>>> "EmbeddedPkg/Include/libfdt.h"
>>>>> and the lib instance "EmbeddedPkg/Library/FdtLib/FdtLib.inf",
>>>> [Chang, Abner] Yes
>>>>>
>>>>> (2) the lib class header pulls in "fdt.h" and "libfdt_env.h",
>>>> [Chang, Abner] yes
>>>>>
>>>>> (3) the external project is not edk2-platforms,
>>>> [Chang, Abner] yes
>>>>>
>>>>> (4) the external project wants -- for some strange reason -- edk2's
>>>>> "libfdt_env.h" to provide an strncmp() function (or function-like
>>>>> macro), with that particular stncmp() implementation not being needed
>>>>> in either edk2- platforms or edk2 itself,
>>>> [Chang, Abner] yes, at least so far
>>>>>
>>>>> (5) the patch for adding said strncmp() was posted on Aug 6th (at
>>>>> least when viewed from my time zone), i.e., before the SFF,
>>>> [Chang, Abner] Yes
>>>>>
>>>>> (6) it was reviewed 12 days later (within the SFF)
>>>> [Chang, Abner] yes.
>>>>>
>>>>> If my understanding is correct, then I don't see how this patch could
>>>>> be considered a bugfix -- even as a feature addition, it seems hardly
>>>>> justified to me --, and there would have been ~8 days before the SFF to
>>> review it.
>>>>>
>>>>> I think we should postpone the patch until after the stable tag.
>>>> This patch is important because the edk2-stable202008 would be the stable
>>> tag (if this patch is accepted) for booting RISC-V platform to Linux kernel with
>>> EFI Runtime service on either real platform and QEMU. We can publish this
>>> information in RISC-V community which is considered as a valuable milestone
>>> for RISC-V edk2 port.
>>>
>>> Let's move out the dates for the stable tag then, by one week:
>>>
>>> - let the SFF start on 2020-08-21
>>> - let the HFF start on 2020-08-28
>>> - let's release edk2-stable202008 on 2020-09-04
>>>
>>> Release slips are permitted and there have been examples.
>> Appreciate for this.
> 
> Previous stable tags (202005/202002/201905) extended SFF or HFF period to let the critical bug fix catch the stable tag. 
> Today case is like a new feature. According to Abner comment, it is important to RISC-V community.
> If SFF start time is changed, more features may catch this stable, such as VariableLock feature.

Yes, exactly.

We must apply the same deadline to all features. If one feature is
important enough for delaying the SFF, then patch review for other
pending features is resumed as well.

>>
>>>
>>> What doesn't make sense is making rules and then breaking them
>>> opportunistically, whenever they're uncomfortable. If that's a frequent
>>> occurrence, we should pick different rules, or -- again -- if this is a very
>>> important patch, we should delay the release for it.
> 
> I suggest to define the process on delay the release. The initial process is specified here.
> The requestor provides the justification why his patch needs to catch the stable tag after SFF phase. 
> All stewards make the decision whether delay the stable tag to include his patch.  
> If stewards agree to delay the stable tag, and there is no objection from the community, 
> the release maintainer will update edk2 release planning with new date. 
> If stewards rejects to this request, there is no change in stable tag release. 

I'm OK with delaying the release by one or two weeks, for any feature(s)
currently pending review on the list. (If we go for two weeks, we should
likely change the name of the upcoming stable tag.)

(Some projects don't even propose cut-off dates, they say "we'll make a
release when we have enough stuff to release, and when all of those
things are complete". That's another approach to consider.)

Thanks
Laszlo

>>> BTW what about reverting the OpenSBI change? You could still call
>>> sbi_strncmp() -- rather than strncmp() -- in the "helper" lib.
>> I replied this in another thread.
>>>
>>> Thanks
>>> Laszlo
>>
>