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

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

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.

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.

BTW what about reverting the OpenSBI change? You could still call
sbi_strncmp() -- rather than strncmp() -- in the "helper" lib.

Thanks
Laszlo