<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<div>
<div>
<div style="direction: ltr;">This merged just now đ¤ Will update wiki tomorrow.</div>
<div><br>
</div>
<div style="direction: ltr;">Apologies for not getting this finished earlier, and thanks for the flexibility đ</div>
<div><br>
</div>
<div style="direction: ltr;">Cheers,</div>
<div style="direction: ltr;">Volker</div>
<div><br>
</div>
</div>
<div><br>
</div>
<div class="ms-outlook-ios-signature"></div>
</div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> Jani Heikkinen <jani.heikkinen@qt.io><br>
<b>Sent:</b> Wednesday, February 5, 2020 12:29:27 PM<br>
<b>To:</b> Volker Hilsheimer <volker.hilsheimer@qt.io>; Edward Welbourne <edward.welbourne@qt.io><br>
<b>Cc:</b> Lars Knoll <lars.knoll@qt.io>; development@qt-project.org <development@qt-project.org>; releasing@qt-project.org <releasing@qt-project.org><br>
<b>Subject:</b> RE: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is in effect now</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt;">
<div class="PlainText">> -----Original Message-----<br>
> From: Volker Hilsheimer <volker.hilsheimer@qt.io><br>
> Sent: keskiviikko 5. helmikuuta 2020 13.10<br>
> To: Edward Welbourne <edward.welbourne@qt.io><br>
> Cc: Jani Heikkinen <jani.heikkinen@qt.io>; Lars Knoll <lars.knoll@qt.io>;<br>
> development@qt-project.org; releasing@qt-project.org<br>
> Subject: Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is<br>
> in effect now<br>
> <br>
> > On 5 Feb 2020, at 11:50, Edward Welbourne <edward.welbourne@qt.io><br>
> wrote:<br>
> ><br>
> > On 4 Feb 2020, at 16:56, Volker Hilsheimer <volker.hilsheimer@qt.io><br>
> wrote:<br>
> >>>> Iâve been struggling a bit more than expected with getting the<br>
> >>>> implementation of "move a file or directory to the trash" pass CI.<br>
> >>>> Itâs a popular feature request:<br>
> >>>><br>
> >>>> <a href="https://bugreports.qt.io/browse/QTBUG-47703">https://bugreports.qt.io/browse/QTBUG-47703</a><br>
> >>>><br>
> >>>> The basic implementation and private APIs have been in for a bit,<br>
> >>>> but required a bit of follow-up, which delayed the merging of the<br>
> >>>> commit that adds the public API in:<br>
> >>>><br>
> >>>> <a href="https://codereview.qt-project.org/c/qt/qtbase/+/287373">https://codereview.qt-project.org/c/qt/qtbase/+/287373</a><br>
> ><br>
> > Lars Knoll (Tuesday, February 4, 2020 8:41 PM)<br>
> >>> +1 from my side. It doesnât have dependencies on any other code, so<br>
> >>> it canât break anything else neither.<br>
> ><br>
> > Jani Heikkinen (5 February 2020 06:42)<br>
> >> Why this is so important that we should get the exception & go in after<br>
> FF?<br>
> ><br>
> > Do we allow changes approved before feature freeze to get past the<br>
> > Coin hurdle, even if that happens after FF ? How much fixing of the<br>
> > change (if it turns out to have problems integrating) is acceptable,<br>
> > before we declare that it's no longer the change that was approved in time<br>
> ?<br>
> ><br>
> > In the present instance (modulo: I may have misunderstood some of<br>
> > what's going on), we have a change that's integrated in 5.15 but won't<br>
> > merge up to dev because dev has a platform 5.15 lacks, on which the<br>
> > change doesn't compile. This is blocking 5.15 -> dev merges in qtbase<br>
> > at present. Volker is trying to fix that in 5.15, so that the<br>
> > merge-up can go ahead. Either we revert the commit that introduced<br>
> > move-to-trash, to unblock merging, or we need to fix in 5.15 the build<br>
> > that's only done in dev. A revert means backing out of the feature,<br>
> > even though (IIUC) it works just fine in 5.15.<br>
> <br>
> <br>
> The change was indeed approved before FF, and the implementation is in<br>
> thanks to that; the public API with the unit test is not because it turned out to<br>
> be a surprisingly annoying feature to test in such a way that it passes our CI :(<br>
> <br>
> The world certainly doesnât end if we donât get this in, but OTOH itâs silly to<br>
> have to wait with this until Qt 6. But this particular feature shouldnât block the<br>
> Alpha either; the testing of the release machinery, and the feedback we get<br>
> through Alpha to the new modules and the more significant additions in Qt<br>
> 5.15 isnât invalidated by this being added after Alpha.<br>
> <br>
> But your call, Jani. If we donât get it in, then I will revert the already merged<br>
> changes since those internal implementations donât have a public API.<br>
<br>
Ok, fair enough. Let's take this in Qt 5.15; it seems this shouldn't cause too much harm or delays.
<br>
<br>
And let's not delay Alpha because of this even I do think we should have all new features & APIs in Alpha already. But I know public API will be changed after Alpha because of API review findings so it doesn't matter that much if simple API methods are added
after the Alpha release as well đ<br>
<br>
br,<br>
Jani<br>
</div>
</span></font></div>
</body>
</html>