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

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

[Gao, Liming]

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

Thanks
Liming

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

[Laszlo Ersek]

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.

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.

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.

Thanks
Laszlo

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

[Leif Lindholm]

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 :)

/
    Leif

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

[Laszlo Ersek]

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

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

[Zeng, Star]

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
> 

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

[Gao, Liming]

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
>>

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

[Laszlo Ersek]

On 11/08/18 06:39, Gao, Liming wrote:

> 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.

I'm happy to update these wiki pages. Whom should I identify in the
articles as the expected sender(s) of the announcements?

Thanks!
Laszlo

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

[Gao, Liming]

Laszlo:
  Please list my name (Liming Gao <liming.gao@intel.com>) as the sender. 

Thanks
Liming
> -----Original Message-----
> From: Laszlo Ersek [mailto:lersek@redhat.com]
> Sent: Thursday, November 8, 2018 9:10 PM
> To: Gao, Liming <liming.gao@intel.com>; Zeng, Star <star.zeng@intel.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>; Kinney,
> Michael D <michael.d.kinney@intel.com>
> Subject: Re: [edk2] Soft Feature Freeze has started since Nov.1 for dk2-stable201811
> 
> On 11/08/18 06:39, Gao, Liming wrote:
> 
> > 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.
> 
> I'm happy to update these wiki pages. Whom should I identify in the
> articles as the expected sender(s) of the announcements?
> 
> Thanks!
> Laszlo

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

[Laszlo Ersek]

On 11/08/18 14:57, Gao, Liming wrote:
> Laszlo:
>   Please list my name (Liming Gao <liming.gao@intel.com>) as the sender. 

Thanks. In the first version, I'm going to add a link to your github
user page instead; I don't think we should directly expose your email
address in a wiki article.

Thanks!
Laszlo


>> -----Original Message-----
>> From: Laszlo Ersek [mailto:lersek@redhat.com]
>> Sent: Thursday, November 8, 2018 9:10 PM
>> To: Gao, Liming <liming.gao@intel.com>; Zeng, Star <star.zeng@intel.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>; Kinney,
>> Michael D <michael.d.kinney@intel.com>
>> Subject: Re: [edk2] Soft Feature Freeze has started since Nov.1 for dk2-stable201811
>>
>> On 11/08/18 06:39, Gao, Liming wrote:
>>
>>> 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.
>>
>> I'm happy to update these wiki pages. Whom should I identify in the
>> articles as the expected sender(s) of the announcements?
>>
>> Thanks!
>> Laszlo

[urgent] Soft Feature Freeze has started since Nov.1 for dk2-stable201811

[Laszlo Ersek]

+ Yuchenlin, + Gerd, + both Phils

On 11/07/18 20:13, Laszlo Ersek wrote:

>>> 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.)

I've given this more thought.

The reverts indeed remove dead code, but the code in question is dead
*only* on QEMU v2.10+. On QEMU v2.9 and earlier, the code is not dead.

(See the original discussion in the thread "[edk2] [PATCH] OvmfPkg:
initialize bochs when initializing vmsvga".)

This means that, with only the first four patches applied from the
series (= the reverts), and with the fifth patch (= the clean
re-implementation of the feature) postponed, people running
edk2-stable201811 on *old* -- v2.9 or older -- QEMU, with VMW SVGA, will
suffer a regression.

So that leaves me with a question. Should I revert the first four
patches now, for edk2-stable201811? (I.e., revert the reverts -->
re-instate the incorrect VMW SVGA driver impl, that happens to work on
v2.9 and earlier.)

... Note that upstream QEMU no longer supports (= maintains stable
branches) for v2.9 and earlier releases. The QEMU homepage
<https://www.qemu.org/> currently advertizes:
- 3.1.0-rc0
- 3.0.0
- 2.12.1
- 2.11.2

Personally I'm leaning towards keeping the reverts for
edk2-stable201811. (v2.9 is really old, and the VMW SVGA device model is
virtually unused.) For my professional integrity though, I must ask this
question publicly.

Thanks
Laszlo

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

[Leif Lindholm]

Hi Laszlo,

On Fri, Nov 09, 2018 at 05:46:47PM +0100, Laszlo Ersek wrote:
> + Yuchenlin, + Gerd, + both Phils
> 
> On 11/07/18 20:13, Laszlo Ersek wrote:
> 
> >>> 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.)
> 
> I've given this more thought.
> 
> The reverts indeed remove dead code, but the code in question is dead
> *only* on QEMU v2.10+. On QEMU v2.9 and earlier, the code is not dead.
> 
> (See the original discussion in the thread "[edk2] [PATCH] OvmfPkg:
> initialize bochs when initializing vmsvga".)
> 
> This means that, with only the first four patches applied from the
> series (= the reverts), and with the fifth patch (= the clean
> re-implementation of the feature) postponed, people running
> edk2-stable201811 on *old* -- v2.9 or older -- QEMU, with VMW SVGA, will
> suffer a regression.
> 
> So that leaves me with a question. Should I revert the first four
> patches now, for edk2-stable201811? (I.e., revert the reverts -->
> re-instate the incorrect VMW SVGA driver impl, that happens to work on
> v2.9 and earlier.)
> 
> ... Note that upstream QEMU no longer supports (= maintains stable
> branches) for v2.9 and earlier releases. The QEMU homepage
> <https://www.qemu.org/> currently advertizes:
> - 3.1.0-rc0
> - 3.0.0
> - 2.12.1
> - 2.11.2
> 
> Personally I'm leaning towards keeping the reverts for
> edk2-stable201811. (v2.9 is really old, and the VMW SVGA device model is
> virtually unused.) For my professional integrity though, I must ask this
> question publicly.

Well, I don't really have a horse in this race, but since you've
directed the email at me (at least that's what mailman makes it look
like :) I'll state my opinion:

My leaning would be towards reverting the reverts.
My workstation runs Debian Stretch, and the QEMU included there is
2.8.1. So a current "stable" distribution would be affected ...

... for people who run bleeding edge EDK2 on stable-distro-provided
QEMU. Which is why it's only leaning.

There is no such thing as too many reverts.

/
    Leif

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

[Phil Dennis-Jordan]

Hi Laszlo,

On Fri, Nov 9, 2018 at 5:47 PM Laszlo Ersek <lersek@redhat.com> wrote:
>
> + Yuchenlin, + Gerd, + both Phils
>
> On 11/07/18 20:13, Laszlo Ersek wrote:
>
> >>> 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.)
>
> I've given this more thought.
>
> The reverts indeed remove dead code, but the code in question is dead
> *only* on QEMU v2.10+. On QEMU v2.9 and earlier, the code is not dead.
>
> (See the original discussion in the thread "[edk2] [PATCH] OvmfPkg:
> initialize bochs when initializing vmsvga".)
>
> This means that, with only the first four patches applied from the
> series (= the reverts), and with the fifth patch (= the clean
> re-implementation of the feature) postponed, people running
> edk2-stable201811 on *old* -- v2.9 or older -- QEMU, with VMW SVGA, will
> suffer a regression.
>
> So that leaves me with a question. Should I revert the first four
> patches now, for edk2-stable201811? (I.e., revert the reverts -->
> re-instate the incorrect VMW SVGA driver impl, that happens to work on
> v2.9 and earlier.)
>
> ... Note that upstream QEMU no longer supports (= maintains stable
> branches) for v2.9 and earlier releases. The QEMU homepage
> <https://www.qemu.org/> currently advertizes:
> - 3.1.0-rc0
> - 3.0.0
> - 2.12.1
> - 2.11.2
>
> Personally I'm leaning towards keeping the reverts for
> edk2-stable201811. (v2.9 is really old, and the VMW SVGA device model is
> virtually unused.) For my professional integrity though, I must ask this
> question publicly.

I suspect the number of users relying on this feature is small, and I
have my doubts that this group are running an unpatched snapshot of
the master branch, let alone a stable OVMF release. But I don't have
data for this, only anecdotal evidence. I personally won't be losing
much sleep over it assuming we fix it for ~all versions of Qemu soon
after.

Phil

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

[Laszlo Ersek]

On 11/09/18 20:08, Phil Dennis-Jordan wrote:
> Hi Laszlo,
> 
> On Fri, Nov 9, 2018 at 5:47 PM Laszlo Ersek <lersek@redhat.com> wrote:
>>
>> + Yuchenlin, + Gerd, + both Phils
>>
>> On 11/07/18 20:13, Laszlo Ersek wrote:
>>
>>>>> 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.)
>>
>> I've given this more thought.
>>
>> The reverts indeed remove dead code, but the code in question is dead
>> *only* on QEMU v2.10+. On QEMU v2.9 and earlier, the code is not dead.
>>
>> (See the original discussion in the thread "[edk2] [PATCH] OvmfPkg:
>> initialize bochs when initializing vmsvga".)
>>
>> This means that, with only the first four patches applied from the
>> series (= the reverts), and with the fifth patch (= the clean
>> re-implementation of the feature) postponed, people running
>> edk2-stable201811 on *old* -- v2.9 or older -- QEMU, with VMW SVGA, will
>> suffer a regression.
>>
>> So that leaves me with a question. Should I revert the first four
>> patches now, for edk2-stable201811? (I.e., revert the reverts -->
>> re-instate the incorrect VMW SVGA driver impl, that happens to work on
>> v2.9 and earlier.)
>>
>> ... Note that upstream QEMU no longer supports (= maintains stable
>> branches) for v2.9 and earlier releases. The QEMU homepage
>> <https://www.qemu.org/> currently advertizes:
>> - 3.1.0-rc0
>> - 3.0.0
>> - 2.12.1
>> - 2.11.2
>>
>> Personally I'm leaning towards keeping the reverts for
>> edk2-stable201811. (v2.9 is really old, and the VMW SVGA device model is
>> virtually unused.) For my professional integrity though, I must ask this
>> question publicly.
> 
> I suspect the number of users relying on this feature is small, and I
> have my doubts that this group are running an unpatched snapshot of
> the master branch, let alone a stable OVMF release. But I don't have
> data for this, only anecdotal evidence. I personally won't be losing
> much sleep over it assuming we fix it for ~all versions of Qemu soon
> after.

Thanks Phil -- that sounds justified and (for me) convenient too. But, I
want to be precise and correct about this. I didn't push the patches out
of carelessness (I had returned from a stretch of PTO, and there hadn't
been a timely announcement on edk2-devel about the soft freeze -- and I
don't think I could be expected to remember the schedule wiki page from
a distance of multiple months).

But, *why* I messed up doesn't matter; only the fact that I did, does.
So, I've filed <https://bugzilla.tianocore.org/show_bug.cgi?id=1319>
now, and I'll soon post the revert-revert series.

Thanks!
Laszlo