On Fri, Feb 28, 2020 at 04:13:09 +0000, Gao, Liming wrote:
> > > I agree it needs to catch the stable tag. If it affects only VS builds
> > > then I am not going to insist on extending the hard freeze, but I
> > > (technically on holiday today/tomorrow) don't have time to dig much
> > > deeper into it.
> > >
> [Liming] This fix is to restore the original behavior before the commit
> 818283de3f6d
> for !INCLUDE style in Makefile generation. It does update GNUmakefile and VS
> makefile
> generation. Because it just restores original behavior, its quality risk is
> low. So, I suggest
> to catch it in this stable tag on current release planning.
If it is *just* a revert, then the risk is often low enough to not
slip the date. But I think, as you say, this is something that
restores original behaviour - but leaving the code different from
the original.
> > > However, I think the process is pretty clear that this *should* extend
> > > the hard freeze.
>
> [Liming] I am not aware of the process to extend the hard freeze. But, you
> think more time is
> required for the review and test on the critical bug fix. I am OK.
>
> > > I will note that from the trail (commitdate of 818283de3f6d until
> > > BZ2563 was raised) it appears that detecting this bug itself, which
> > > went in two days before the soft freeze, took 15 days.
>
> [Liming] Yes. It takes 15 days to expose this issue.
>
> > I agree with Liming's analysis on the patches (i.e., what goes in and
> > what gets postponed), and I agree with Leif that we should extend the
> > hard freeze by at least a couple of days.
>
> [Liming] If you both agree to extend the hard freeze, I have no objection.
> I request to extend few days instead of few weeks if no other critical issues
> are reported.
> Then, the impact of the community can be reduced.
>
> > This is not unusual. Originally I thought that edk2 freeze and release
> > dates were set in stone, but then Mike explained to me that that had
> > never been the intent. And other open source projects do several
> > pre-releases (rc0, rc1, .... pre-releases with "release critical" (rc)
> > bug fixes), before a final release. For example, QEMU regularly plans
> > rc0..rc2 or even rc3, and then *optionally* adds an rc4 if even rc3
> > receives significant bugfixes. The idea is that the final release / tag
> > should be preceded by a silent / calm period, where we've waited a few
> > days and become reasonably convinced that "OK, there's nothing else we
> > should obviously fix right now".
> >
> > I wouldn't immediately suggest a full week extension, but maybe until
> > March 4th (middle of next week)?
> [Liming] March 4th is one good choice to reserve few days for the different
> time zone people.
> If no more feedback, I will send announcement to delay this stable tag on Feb
> 28th (00:00:00 UTC-8).
I am OK with March 4th.
Thanks!
/
Leif
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#55092): https://edk2.groups.io/g/devel/message/55092
Mute This Topic: https://groups.io/mt/71371549/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
