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

["Gao, Liming" <liming.gao@intel.com>]

Star:
  There is no special process for Hard Feature Freeze. If the people has the comments or rejection for the bug fix in this phase, they can give their comments in review mail. 
  Yes. I will send the mail today to announce Hard Feature Freeze. 

Laszlo:
  Thanks for your feedback. We will send the separate announce mail ahead of the feature freeze date for next release cycle. And, I suggest to update SoftFeatureFreeze and HardFeatureFreeze wiki page with the announce mail requirement. For this release, I would like to dry run this process. So, I will send another  announcement for Hard Feature Freeze today. 

Thanks
Liming
>-----Original Message-----
>From: Zeng, Star
>Sent: Thursday, November 08, 2018 10:02 AM
>To: Laszlo Ersek <lersek@redhat.com>; Leif Lindholm
><leif.lindholm@linaro.org>
>Cc: edk2-devel@lists.01.org; Cetola, Stephano <stephano.cetola@intel.com>;
>Richardson, Brian <brian.richardson@intel.com>; Gao, Liming
><liming.gao@intel.com>; Kinney, Michael D <michael.d.kinney@intel.com>;
>Zeng, Star <star.zeng@intel.com>
>Subject: Re: [edk2] Soft Feature Freeze has started since Nov.1 for dk2-
>stable201811
>
>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
>>