Re: Soft Feature Freeze has started since Nov.1 for dk2-stable201811

["Zeng, Star" <star.zeng@intel.com>]

Has been the time to announce Hard Feature Freeze?

During Hard Feature Freeze, every checkin needs to be approved by 
stewards, right?


Thanks,
Star

On 2018/11/8 3:13, Laszlo Ersek wrote:
> On 11/07/18 16:38, Leif Lindholm wrote:
>> 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 :)
> 
> OK, let's stick with the current dates as they are.
> 
> I do think we should send separate announcements about soft & hard
> freezes. The soft freeze is the first time in a cycle when maintainers
> have to stop and think about non-technical reasons before they push. I'd
> really like to be poked about that.
> 
> Thanks
> Laszlo
>