[Releasing] [Development] HEADS-UP: Qt 5.15 Feature Freeze is in effect now

[Volker Hilsheimer]

> On 5 Feb 2020, at 11:50, Edward Welbourne <edward.welbourne at qt.io> wrote:
> 
> On 4 Feb 2020, at 16:56, Volker Hilsheimer <volker.hilsheimer at qt.io> wrote:
>>>> I’ve been struggling a bit more than expected with getting the
>>>> implementation of "move a file or directory to the trash" pass
>>>> CI. It’s a popular feature request:
>>>> 
>>>> https://bugreports.qt.io/browse/QTBUG-47703
>>>> 
>>>> The basic implementation and private APIs have been in for a bit,
>>>> but required a bit of follow-up, which delayed the merging of the
>>>> commit that adds the public API in:
>>>> 
>>>> https://codereview.qt-project.org/c/qt/qtbase/+/287373
> 
> Lars Knoll (Tuesday, February 4, 2020 8:41 PM)
>>> +1 from my side. It doesn’t have dependencies on any other code, so
>>> it can’t break anything else neither.
> 
> Jani Heikkinen (5 February 2020 06:42)
>> Why this is so important that we should get the exception & go in after FF?
> 
> Do we allow changes approved before feature freeze to get past the Coin
> hurdle, even if that happens after FF ?  How much fixing of the change
> (if it turns out to have problems integrating) is acceptable, before we
> declare that it's no longer the change that was approved in time ?
> 
> In the present instance (modulo: I may have misunderstood some of what's
> going on), we have a change that's integrated in 5.15 but won't merge up
> to dev because dev has a platform 5.15 lacks, on which the change
> doesn't compile.  This is blocking 5.15 -> dev merges in qtbase at
> present.  Volker is trying to fix that in 5.15, so that the merge-up can
> go ahead.  Either we revert the commit that introduced move-to-trash, to
> unblock merging, or we need to fix in 5.15 the build that's only done in
> dev.  A revert means backing out of the feature, even though (IIUC) it
> works just fine in 5.15.


The change was indeed approved before FF, and the implementation is in thanks to that; the public API with the unit test is not because it turned out to be a surprisingly annoying feature to test in such a way that it passes our CI :(

The world certainly doesn’t end if we don’t get this in, but OTOH it’s silly to have to wait with this until Qt 6. But this particular feature shouldn’t block the Alpha either; the testing of the release machinery, and the feedback we get through Alpha to the new modules and the more significant additions in Qt 5.15 isn’t invalidated by this being added after Alpha.

But your call, Jani. If we don’t get it in, then I will revert the already merged changes since those internal implementations don’t have a public API.

That the change that passed CI for 5.15 blocks the merge to dev is not related to FF, but because we are testing different platforms in CI for dev than we do for 5.15. The follow-up that fixes the build for that merge is already in 5.15, and the merge needs to be updated to include those changes. Liang knows about that.


Cheers,
Volker