Hi Laszlo,
Can I inject an alternative interpretation? (feel free to shoot it down)
On Wed, Nov 07, 2018 at 04:14:01PM +0100, Laszlo Ersek wrote:
Hi,
On 11/07/18 02:12, Gao, Liming wrote:
Hi, all
https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Release-Planning
lists edk2-stable201811 tag planning. Now, we enter into Soft Feature
Freeze phase. In this phase, the feature under review will not be
allowed to be pushed. The patch review can continue without break.
Here is edk2-stable201811 tag planning.
2018-08-15 Beginning of development
2018-11-01 Soft Feature Freeze
2018-11-08 Hard Feature Freeze
2018-11-15 Release
I don't think an announcement should be made like this, one week after
the fact. (If I missed the exact dates on yesterday's stewards' call,
then I apologize.)
If we are making the announcement about the Soft Feature Freeze on
2018-Nov-07, then the Soft Feature Freeze should start no earlier than
2018-Nov-08 or so. Certainly not retro-actively.
Perhaps we should push the schedule by one week.
Do we need to send an announcement for the soft feature freeze?
I would be quite happy with that one being set in stone(ish) from the
planning page, and the hard freeze date being the one that needs to be
announced.
I understand that will prevent the stable tag from being dropped
*exactly* three months after start of development (2018-Aug-15). I think
that should be fine. Nobody forces us to work in cycles of *exactly*
three months. (Even if we slipped over to December, that shouldn't be a
huge problem; we'd just call the tag "edk2-stable201812".) The workflow
itself is work-in-progress.
Of course, I'm heavily biased since I'm hoping to make a Linaro
release this month based on the stable tag...
I realize that
<https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Release-Planning>
has had the dates available all this time. But, the reason we make the
announcements in the first place is precisely that people don't keep
staring at that page.
(
For example, I reviewed and pushed 4 patches yesterday (on 2018-Nov-06):
1 e038bde2679b Revert "OvmfPkg/QemuVideoDxe: list "UnalignedIoInternal.h" in the
INF file"
2 98856a724c2a Revert "OvmfPkg/QemuVideoDxe: VMWare SVGA device support"
3 438ada5aa5a1 Revert "OvmfPkg/QemuVideoDxe: Helper functions for unaligned port
I/O."
4 328409ce8de7 Revert "OvmfPkg: VMWare SVGA display device register
definitions"
which are the first four patches (out of five) from the following
series:
[edk2] [PATCH v2 0/5] OvmfPkg: simply use the Bochs interface for vmsvga
These reverts are arguably not bugfixes; they are preparation for
re-implementing a feature from scratch (the last patch in that series).
Thus, had I known we were already in the Soft Feature Freeze, I wouldn't
have pushed them, because the review was not complete before the soft
freeze start.
But I had just returned from a week (or more) of PTO, there was no
announcement on the list yet, and I didn't remember the wiki page.
(In the technical sense, the reverts are not disruptive, luckily; they
remove code that is dead anyway.)
)
This is my opinion at least -- I'm ready to be overruled, but I wanted
to voice it.
I don't disagree with anything you say, but my feeling is that we're
still learning to work with the new process, and we have seen other
mistakes during this cycle.
So, I'm happy to consider this post the announcement of the
hard-freeze with the soft-freeze date being included for context.
I agree that for the next cycle, separate announcements of soft-freeze
and hard-freeze would be preferable.
I too am OK with being overruled :)
