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

[Leif Lindholm <leif.lindholm@linaro.org>]

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