Re: EDK II Stable Tag release edk2-stable201808 and quiet period starting today

[Laszlo Ersek <lersek@redhat.com>]

On 08/15/18 04:05, Zhang, Chao B wrote:
> Hi Laszlo
>    8  667abfaf8a16 UefiCpuPkg: Removing ipf which is no longer supported from edk2.
>    9  df49a85dbcc6 CorebootModulePkg: Removing ipf from edk2.
>   10  04c7f9023ffe CorebootPayloadPkg: Removing ipf from edk2.
>   11  4fcb0d54584f NetworkPkg: Removing ipf which is no longer supported from edk2.
>   12  87f9867f5536 QuarkPlatformPkg: Removing ipf which is no longer supported from edk2.
>   13  fda6abd64f02 QuarkSocPkg: Removing ipf which is no longer supported from edk2.
>   14  22ec06c8aaa1 Vlv2TbltDevicePkg: Removing ipf which from edk2.
>
> These patches are in a patch series to remove IPF. The community
> review has been started a very long time before silent period.  And
> part of patch series was already in EDK2.
> There is no source code change but only removes some useless sections
> in INF & DSC. And from feature complete perspective, I think it is OK
> to check-in.
> Anyway, We will learn from this process and be more careful.

We should distinguish two things here.

- The first is the scope of the quiet period. That is, what kinds of
commits are permitted, for what packages.

- The second is whether (and how) we honor the quiet period.

My email was about the 2nd point; that is, that we should respect the
quiet period, with whatever scope that had been set.

The scope was set by Mike's earlier announcement (1st point), and it
said "critical issues only" and "bugzillas required".

I'm fine with updating the scope, even during the quiet period, but it
should be a discussion. Most other open source projects do something
similar; for example they tag release candidates (RCs) before an actual
release, and they keep iterating release candidates until all known
regressions or critical bugs are fixed. Sometimes they might even
postpone a release (and then the tag name could be necessary to update)
-- such projects say, "it's done when it's done, and not when a specific
date arrives".


In the QEMU project there are two kinds of "freezes", for entering the
quiet period.

https://wiki.qemu.org/Planning/SoftFeatureFreeze
https://wiki.qemu.org/Planning/HardFeatureFreeze

* Using that terminology, and considering the quiet period announcement
from 8 Aug a "soft freeze", merging the remaining IPF removal patches
would have been fine, between the soft freeze and the hard freeze,
because the patches had been posted and reviewed before the soft freeze.

On the other hand, Mike's series "[edk2] [Patch 0/4] Vlv2TbltDevicePkg:
Add FmpDevicePkg support" wouldn't qualify, because it was posted on 10
Aug (the quiet period, now interpreted as "soft freeze", was announced
on 8 Aug).

* Alternatively, considering the quiet period announcement from 8 Aug a
"hard freeze", neither patch set should have been pushed, because none
of them are bug fixes.


Personally I took the announcement as a "hard freeze", because it said
"critical bug fixes only".

Again, if we'd really like to complete some pending features before
tagging a commit as "stable", I'm fine if we move out the tag a few
weeks. The point is, once we determine a scope, we should stick to it;
and if modifications are necessary, discuss them on the list (or in
BZs). Otherwise different maintainers will gate commits against
different criteria.


Another thing I believe QEMU does well is a "planning" wiki page, for
the next release. This helps developers keep the scope up-to-date, and
compare feature / bugfix status (e.g. list of BZs) against the most
recently set release date.

https://wiki.qemu.org/Planning/3.0

Thanks
Laszlo