Re: [Development] Changes to Qt offering

[d3fault]

Both the "removal of LTS" and "removal of offline installers" serve as
evidence that Tuukka Turunen doesn't care about the Free
Software/Culture movement. In both cases he is actively hurting the
open source side of Qt in order to promote the business side. The work
is already being done to create the LTS and Offline Installers; openly
publishing that work requires very little (negligible) additional
effort.

It's not the end of Qt by any means, but it's a step in the wrong direction.


d3fault
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Alexander Akulich]

Do we want to sort out all overloads of error() signal/getter in all
(essential?) modules for Qt 6?

For example, Qt Multimedia still has more than a dozen public classes
with such overloads (of a signal and a getter) in 5.15 and dev.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Volker Hilsheimer]

This merged just now 🤓 Will update wiki tomorrow.

Apologies for not getting this finished earlier, and thanks for the flexibility 
🙏

Cheers,
Volker



From: Jani Heikkinen 
Sent: Wednesday, February 5, 2020 12:29:27 PM
To: Volker Hilsheimer ; Edward Welbourne 

Cc: Lars Knoll ; development@qt-project.org 
; releas...@qt-project.org 

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

> -Original Message-
> From: Volker Hilsheimer 
> Sent: keskiviikko 5. helmikuuta 2020 13.10
> To: Edward Welbourne 
> Cc: Jani Heikkinen ; Lars Knoll ;
> development@qt-project.org; releas...@qt-project.org
> Subject: Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is
> in effect now
>
> > On 5 Feb 2020, at 11:50, Edward Welbourne 
> wrote:
> >
> > On 4 Feb 2020, at 16:56, Volker Hilsheimer 
> 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.

Ok, fair enough. Let's take this in Qt 5.15; it seems this shouldn't cause too 
much harm or delays.

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,
Jani
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Timur Pocheptsov]

https://codereview.qt-project.org/c/qt/qtbase/+/285791

> But ok otherwise. So +1-1=0.

Interesting.

Best regards,
Timur.

From: Development  on behalf of Thiago 
Macieira 
Sent: Wednesday, February 5, 2020 7:43 PM
To: development@qt-project.org 
Subject: Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is in 
effect now

On Wednesday, 5 February 2020 09:41:58 PST Alexander Akulich wrote:
> On Wed, Feb 5, 2020 at 6:58 PM Thiago Macieira
>
>  wrote:
> > The correct signal for an error situation is errorOccurred, like in
> > QLocalSocket and QProcess.
>
> Actually both QLocalSocket and QAbstractSocket renamed the "error()"
> getter to keep using "error()" signal as opposed to many other Qt
> modules "errorOccurred()" signals.

Which is the opposite of QProcess and violates the naming convention. Signals
are named after verbs in the past tense and properties & property getters are
simple nouns. So "error" is the getter, "errorOccurred" is the signal.

qprocess.h:

#if QT_DEPRECATED_SINCE(5, 6)
QT_DEPRECATED_X("Use QProcess::errorOccurred(QProcess::ProcessError)
instead")
void error(QProcess::ProcessError error);
#endif
void errorOccurred(QProcess::ProcessError error);


--
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Thiago Macieira]

On Wednesday, 5 February 2020 08:03:45 PST Shawn Rutledge wrote:
> It defeats the purpose of deprecation to do that before you are ready.  It’s
> something to be done later, to verify that you really have gotten rid of
> all uses of the old API.  “Later” should not be as long a time as it has
> been in the past (as in deprecating something only in documentation in 5.0,
> and then waiting until 5.14 to deal with the consequences); but it also IMO
> should not be treated as a P0 blocker issue hanging over our heads the
> instant after deprecating something, to go and rewrite all uses in all
> modules.  It’s technical debt though.

Deprecation should be done preferably at least one release after the 
replacement API became available. If that's not possible, in the same release.

Deprecating without a replacement should only be done if there will be no 
replacement or if the API is actually harmful.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Thiago Macieira]

On Wednesday, 5 February 2020 09:41:58 PST Alexander Akulich wrote:
> On Wed, Feb 5, 2020 at 6:58 PM Thiago Macieira
> 
>  wrote:
> > The correct signal for an error situation is errorOccurred, like in
> > QLocalSocket and QProcess.
> 
> Actually both QLocalSocket and QAbstractSocket renamed the "error()"
> getter to keep using "error()" signal as opposed to many other Qt
> modules "errorOccurred()" signals.

Which is the opposite of QProcess and violates the naming convention. Signals 
are named after verbs in the past tense and properties & property getters are 
simple nouns. So "error" is the getter, "errorOccurred" is the signal.

qprocess.h:

#if QT_DEPRECATED_SINCE(5, 6)
QT_DEPRECATED_X("Use QProcess::errorOccurred(QProcess::ProcessError) 
instead")
void error(QProcess::ProcessError error);
#endif
void errorOccurred(QProcess::ProcessError error);


-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Timur Pocheptsov]

Correct, to avoid breaking old connection syntax silently (with warnings not 
noticed in code).
Now, please enumerate those many modules you are talking about? There are 4 
classes in
QtNetwork doing similar changes  (not touching a tricky signal, but a getter) 
and I, as the
maintainer of QtNetwork, prefer it this way.

Best.



From: Development  on behalf of Alexander 
Akulich 
Sent: Wednesday, February 5, 2020 6:41 PM
To: Thiago Macieira 
Cc: Qt development mailing list 
Subject: Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is in 
effect now

On Wed, Feb 5, 2020 at 6:58 PM Thiago Macieira
 wrote:
>
> The correct signal for an error situation is errorOccurred, like in
> QLocalSocket and QProcess.

Actually both QLocalSocket and QAbstractSocket renamed the "error()"
getter to keep using "error()" signal as opposed to many other Qt
modules "errorOccurred()" signals.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Mailing List

[Eloise Downey]

Please remove me from this mailing list as it is clogging up my inbox. 

Many thanks. 

Sent from my iPad

-- 
CONFIDENTIALITY NOTICE:  
The contents of this email message and any 
attachments are intended solely for the addressee(s) and may contain 
confidential and/or privileged information and may be legally protected 
from disclosure. If you are not the intended recipient of this message or 
their agent, or if this message has been addressed to you in error, please 
immediately alert the sender by reply email and then delete this message 
and any attachments. If you are not the intended recipient, you are hereby 
notified that any use, dissemination, copying, or storage of this message 
or its attachments is 
strictly prohibited. 
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Alexander Akulich]

On Wed, Feb 5, 2020 at 6:58 PM Thiago Macieira
 wrote:
>
> The correct signal for an error situation is errorOccurred, like in
> QLocalSocket and QProcess.

Actually both QLocalSocket and QAbstractSocket renamed the "error()"
getter to keep using "error()" signal as opposed to many other Qt
modules "errorOccurred()" signals.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Alexander Akulich]

On Wed, Feb 5, 2020 at 7:29 PM Alexander Akulich
 wrote:
>
> On Wed, Feb 5, 2020 at 1:11 PM Ville Voutilainen
>  wrote:
> >
> > Isn't that an ABI break?
>
> Yep; this is what we're doing here (we're deprecating and sorting out
> the API to break the ABI in Qt 6).

(I thought that it is obvious, but it seems to be not the case, so:)
I mean that we want to prepare and improve the API for Qt 6, so we
need to add some signals and mark some others as deprecated. This is a
well-known procedure and it is not an ABI breakage for a regular (e.g.
not "no-deprecated") build. What I'm proposing to do is basically to
apply for QAbstractSocket the same API changes as done in [1] for
QProcess.

[1] 
https://code.qt.io/cgit/qt/qtbase.git/commit/?id=4672e319e6dd0fbaa986e056e52dbb06d78fcfa5
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Alexander Akulich]

On Wed, Feb 5, 2020 at 1:11 PM Ville Voutilainen
 wrote:
>
> Isn't that an ABI break?

Yep; this is what we're doing here (we're deprecating and sorting out
the API to break the ABI in Qt 6).
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Alexander Akulich]

It seems "feature freeze" != "API freeze" and the API review for 5.15
is still "to be done", so we still can raise the objection at the
right time for Qt 5.15.

The API consistency is one of the biggest advantages of Qt and I
really hope that we won't stop caring about it.


On Wed, Feb 5, 2020 at 6:58 PM Thiago Macieira
 wrote:
>
> On Wednesday, 5 February 2020 02:12:06 PST Alexander Akulich wrote:
> > Oh, I'm sorry for the spam! You already renamed error() getter to
> > sockerError() [1], so the issue is not relevant now.
> > It's a bit unfortunate to see such diversity in the API. error()
> > getter seems to be a convention in Qt. I thought that the same
> > convention is to use '-ed' verbs in signal names.
>
> It is. The correct signal for an error situation is errorOccurred, like in
> QLocalSocket and QProcess.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel System Software Products
>
>
>
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Shawn Rutledge]

> On 5 Feb 2020, at 16:31, Edward Welbourne  wrote:
> 
> Shawn Rutledge (5 February 2020 14:14)
>> So I’m strongly in favor of continuing to do deprecations as long as
>> possible.  A deprecation is not something that can break existing
>> functionality, so it’s no real risk as long as we’re sure we really
>> want to deprecate it.
> 
> A deprecation can break existing builds, for those who enable
> warnings-are-errors.  

It defeats the purpose of deprecation to do that before you are ready.  It’s 
something to be done later, to verify that you really have gotten rid of all 
uses of the old API.  “Later” should not be as long a time as it has been in 
the past (as in deprecating something only in documentation in 5.0, and then 
waiting until 5.14 to deal with the consequences); but it also IMO should not 
be treated as a P0 blocker issue hanging over our heads the instant after 
deprecating something, to go and rewrite all uses in all modules.  It’s 
technical debt though.

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Thiago Macieira]

On Wednesday, 5 February 2020 02:12:06 PST Alexander Akulich wrote:
> Oh, I'm sorry for the spam! You already renamed error() getter to
> sockerError() [1], so the issue is not relevant now.
> It's a bit unfortunate to see such diversity in the API. error()
> getter seems to be a convention in Qt. I thought that the same
> convention is to use '-ed' verbs in signal names.

It is. The correct signal for an error situation is errorOccurred, like in 
QLocalSocket and QProcess.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Edward Welbourne]

Shawn Rutledge (5 February 2020 14:14)
> So I’m strongly in favor of continuing to do deprecations as long as
> possible.  A deprecation is not something that can break existing
> functionality, so it’s no real risk as long as we’re sure we really
> want to deprecate it.

A deprecation can break existing builds, for those who enable
warnings-are-errors.  Consequently, in the API change review, reviewers
need to be able to see all deprecations, in order to be able to raise
objections to any that are going to cause pain.

I am well aware of how being kept from Qt 6 work makes it hard to
discover the deprecations that'll be needed in 5.15 to support that Qt 6
work, once we get to it - I spent much of the last fortnight frantically
getting those deprecations (and some API consolidations I noticed in the
process) sorted out, precisely because I understood feature freeze as a
hard cut-off.  Dealing with it as such gives everyone a clearer view of
what we're doing.

I accept that the final Qt 5 release is special - and agree that the
usual "we do time-based, so your change that missed FF only has to wait
half a year" isn't as true as it would be at other times - but we do
need to have visibility for changes to the API - including deprecations
- so that our API change reviews can do their job properly.  That
includes clients of an API getting a chance to object to a deprecation.

So please be sure to comment on API change reviews if you even suspect
you may be about to decide to deprecate things that haven't yet been
sorted out before feature freeze.  API change reviewers need to know
about them.


We seem to have some diversity of opinion on how hard a cut-off the
feature freeze is meant to be: that's a topic we need to discuss and
answer, if we're to have release processes we can trust.  On the one
hand, the need for predictability in our release process means we need
to have deadlines and stick to them.  On the other hand, various
practicalities make it necessary to have some flexibility.  I think we
need to revisit the incomplete QUIP 11 and actually document which
things cut off when.

https://codereview.qt-project.org/c/meta/quips/+/228450

Eddy.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Make a decision for asynchronous APIs

[Sona Kurazyan]

It seems like everyone agrees that we need to keep and improve the asynchronous 
APIs in Qt 6.
Since there are already tasks for each of proposed changes, let’s move more 
detailed discussions about each item to the relevant task. They are all linked 
to https://bugreports.qt.io/browse/QTBUG-80908.
Feel free to make comments if you are interested.

Best regards,
Sona


From: Development  On Behalf Of Sona 
Kurazyan
Sent: Friday, 31 January 2020 17:24
To: development@qt-project.org
Subject: Re: [Development] Make a decision for asynchronous APIs

Hi everyone,

It's been a while since we've started discussions on this topic. I would like 
to summarize the outcome of these discussions and propose improvements to our 
asynchronous APIs based on the feedback we've received so far.

First of all, there was a question weather we should keep QtConcurrent and 
QFuture (and related classes) at all, and the answer seems to be "yes", because 
the corresponding STL alternatives are still lacking a lot of features: 
std::future still doesn't support continuations, its API is not finalized yet, 
no executors are supported for parallel algorithms in C++17, etc. Additionally, 
Qt's asynchronous APIs have extensions like cancelling, pausing, resuming and 
progress reporting (although not everyone agrees that these extensions fit with 
a typical future, but they can be useful in Qt-specific use-cases, for example 
GUI applications).

On the other hand, there are couple of improvements to be applied to 
QtConcurrent and QFuture* , to make them more useful and keep them in Qt 6. 
Here's the list of suggestions I've collected:

QFuture (and related classes)

  1.  Officially document QFutureInterface and rename it to QPromise 
(https://bugreports.qt.io/browse/QTBUG-81586)
  2.  Add support for continuations​ to QFuture 
(https://bugreports.qt.io/browse/QTBUG-81587)
  3.  Provide a way of integrating QFuture with signals 
(https://bugreports.qt.io/browse/QTBUG-81589)
  4.  Improve the error reporting of QFuture 
(https://bugreports.qt.io/browse/QTBUG-81588)

QtConcurrent

  1.  Rename QtConcurrent::run to qAsync() and modernize it 
(https://bugreports.qt.io/browse/QTBUG-81590)
  2.  Allow passing a QThreadPool* as a parameter to QtConcurrent algorithms to 
avoid exhausting all system threads.
  3.  Fix the algorithms which do not work with lambdas 
(https://bugreports.qt.io/browse/QTBUG-33735)
  4.  Add initial values to map/filter reduce 
(https://bugreports.qt.io/browse/QTBUG-73240)

It would be nice to hear some opinions, to see whether this is a right 
direction to go, and if it makes sense to put our effort on these improvements. 
Is there anything important I’m missing in the list? Or maybe some of these 
items do not add much value?

Additionally, there are some discussions about QFuture being a mix between a 
“Task” and a “Future”. One of the options of improving this situation is to 
make a QTask (or QJob) out of the current QFuture. But then the question is: 
should we also support a “classic” QFuture? Is there a value in having it, when 
there are already some very advanced implementations of a future?

Please share your thoughts!

Thanks,
Sona


From: Development 
mailto:development-boun...@qt-project.org>> 
on behalf of Karsten Heimrich 
mailto:karsten.heimr...@qt.io>>
Sent: Thursday, December 19, 2019 2:12 PM
To: development@qt-project.org 
mailto:development@qt-project.org>>
Subject: [Development] Make a decision for asynchronous APIs


Hi,

we are planning to continue some work on the QFuture, QtConcurrent APIs, either 
improve up on the existing implementation or deprecate and remove them 
completely for Qt6. We’ve created a user story in Jira and  like to gather some 
feedback here. So if this topic is of interest for you, I would like to point 
you to https://bugreports.qt.io/browse/QTBUG-80908 to place some comments there.



BR, Karsten


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Mitch Curtis]

> -Original Message-
> From: Releasing  On Behalf Of Jani
> Heikkinen
> Sent: Wednesday, 5 February 2020 6:37 AM
> To: Lars Knoll ; Yulong Bai 
> Cc: Volker Hilsheimer ; Qt development mailing list
> ; releas...@qt-project.org
> Subject: Re: [Releasing] [Development] HEADS-UP: Qt 5.15 Feature Freeze is
> in effect now
> 
> Hi!
> 
> Yeah, for me this seems to be quite low risky addition as well. Only concern 
> is
> that we need to delay the Alpha release because of this late addition. We
> have Alpha content in place already now and at least in theory we should
> delay it until all new features are in... So adding 2 weeks delay to there
> doesn't sound that nice to me at this point.; delays are usually causing
> problems & unnecessary hassle later phases of releasing :( And taking this in
> between Alpha and beta doesn't sound that well to me either; what is the
> purpose of Alpha if there isn't all known features in...
> 
> Why this is so important that we should get the exception & go in after FF?

Hi Jani.

- It's a vital part of creating a table in Qt Quick, and something that is 
non-trivial for a good chunk of users to implement themselves.
- I think you and Lars have already said it's low risk, which is true.
- I don't think this counts as justification, but.. it's been in the works for 
a while, and we really shouldn't delay it any longer.
- I'm also confident we will be ready to merge it today.

Cheers.
 
> br,
> Jani
> 
> 
> From: Lars Knoll 
> Sent: Tuesday, February 4, 2020 3:50 PM
> To: Yulong Bai
> Cc: Jani Heikkinen; Qt development mailing list; releas...@qt-project.org;
> Volker Hilsheimer
> Subject: Re: [Development] HEADS-UP: Qt 5.15 Feature Freeze is in effect
> now
> 
> I’d be ok with extending the deadline for this one item until end of next
> week. It shouldn’t be able to break other things as far as I can tell.
> 
> But would like to hear Jani’s opinion as well. If he’s also ok go ahead, but 
> it
> really needs to get approved and merged quickly.
> 
> Cheers,
> Lars
> 
> On 4 Feb 2020, at 14:39, Yulong Bai
> mailto:yulong@qt.io>> wrote:
> 
> Hello,
> 
> HeaderView is almost done but I just missed the feature-freeze. I will have it
> ready by this Friday.
> 
> So, is it OK for everybody that I merge it after the 5.15 feature freeze. It's
> here https://codereview.qt-project.org/c/qt/qtquickcontrols2/+/270170
> 
> br,
> Yulong
> Software Engineer
> 
> From: Jani Heikkinen mailto:jani.heikki...@qt.io>>
> Sent: 03 February 2020 06:35
> To: development@qt-project.org
> mailto:development@qt-project.org>>;
> releas...@qt-project.org  project.org>
> Subject: [Development] HEADS-UP: Qt 5.15 Feature Freeze is in effect now
> 
> Hi all,
> 
> Qt 5.15 Feature Freeze is in effect now. So no new features in '5.15'
> anymore. Please update Qt 5.15 new features page
> (https://wiki.qt.io/New_Features_in_Qt_5.15) now; it seems to be quite
> empty still...
> 
> Target is to publish Qt 5.15 Alpha as soon as possible; Let's see if we can 
> get it
> out already during this week.
> 
> API review for Qt 5.15 will start soon as well. Please do reviews immediately
> when available.
> 
> br,
> Jani Heikkinen
> Release Manager
> 
> ___
> Releasing mailing list
> releas...@qt-project.org
> https://lists.qt-project.org/listinfo/releasing
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Shawn Rutledge]

On 5 Feb 2020, at 13:04, Jani Heikkinen 
mailto:jani.heikki...@qt.io>> wrote:

We are doing time based releases so if new feature misses the deadline there 
will be next one coming after few months. It might be quite long time for 
unique feature but on the other hand it isn't really that long…

It’s the end of the Qt 5 series, so time to the next Qt 5 release after this 
one is infinite (it won't happen at all).  Users won’t switch to Qt 6 anytime 
soon.  Missing functionality will hurt them more than usual.  I’m not talking 
about pie-in-the-sky ideas, but features that are close to done and were 
promised for a long time already; and even more so, missing features that are 
blocking imminent releases of other modules that were promised, or already paid 
for.

Failing to get all the deprecations in place for things we want to remove in Qt 
6 will also hurt users a lot.  So I think we need to be more flexible than 
usual about getting those in.  And those of us who had real work to add 
features in 5.15 have not yet had time to work on the sort of Qt 6 things that 
could result in the need to add deprecations in 5.15.  (And that will probably 
go on for a few more weeks, too.)

If you argue against getting more deprecations in place in 5.15, then you are 
also implicitly arguing in favor of having more SC breaks in Qt 6.

So I’m strongly in favor of continuing to do deprecations as long as possible.  
A deprecation is not something that can break existing functionality, so it’s 
no real risk as long as we’re sure we really want to deprecate it.

The exact timing of the 5.15 release could even slip more than usual; what will 
it really matter?  For once I think we should be concerned more about quality 
than timing.  As long as we get 5.15.0 out within the first half of the year, 
we will satisfy our duty to the almighty #%#$% schedule.

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Jani Heikkinen]

> -Original Message-
> From: Eskil Abrahamsen Blomfeldt 
> Sent: keskiviikko 5. helmikuuta 2020 13.06
> To: Edward Welbourne ; Jani Heikkinen
> ; Lars Knoll ; Volker Hilsheimer
> 
> Cc: Qt development mailing list ;
> releas...@qt-project.org
> Subject: Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is
> in effect now
> 
> 
> On 05.02.2020 11:50, Edward Welbourne wrote:
> > 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
> ?
> 
> 
> If the change is ready and approved by the time of feature freeze and only
> delayed by CI problems, failures from other changes in a batch, or the
> awkwardness of our dependency structure, I think it has to be acceptable to
> merge after the freeze. Otherwise feature freeze becomes a lottery where
> the features in a given release is based mostly on chance.

By default we shouldn't put any new features in after FF, not even those which 
were approved early enough. Not respecting the freeze date was one of biggest 
reasons why we failed to keep the release schedule with earlier releases. And 
after we started to be much tighter with the freeze we have been much better to 
keep the schedules as well...

> The slack to accommodate these intrinsic delays need to be in the release
> plan in my opinion, and not in each developer's individual plan for merging
> their changes.

I have to disagree. Everyone knows that there is flakiness/problems in 
integrations and so on changes has to be ready early enough so that there is 
still time to pass the CI. That's why FF date is agreed & informed quite early 
& there is several heads-up telling it is coming closer...

We are doing time based releases so if new feature misses the deadline there 
will be next one coming after few months. It might be quite long time for 
unique feature but on the other hand it isn't really that long... Our goal is 
to cut the schedule between FF and final release, not reserving more time 
there. Ok, currently there is of course some buffer in; Release plans are based 
on previous releases and realized schedules there. But we should be able to 
develop our ways of working & our release systems so that we can make that time 
much shorter. That way we could get more time to develop new features. 

br,
Jani
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Jani Heikkinen]

> -Original Message-
> From: Volker Hilsheimer 
> Sent: keskiviikko 5. helmikuuta 2020 13.10
> To: Edward Welbourne 
> Cc: Jani Heikkinen ; Lars Knoll ;
> development@qt-project.org; releas...@qt-project.org
> Subject: Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is
> in effect now
> 
> > On 5 Feb 2020, at 11:50, Edward Welbourne 
> wrote:
> >
> > On 4 Feb 2020, at 16:56, Volker Hilsheimer 
> 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.

Ok, fair enough. Let's take this in Qt 5.15; it seems this shouldn't cause too 
much harm or delays. 

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,
Jani
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Volker Hilsheimer]

> On 5 Feb 2020, at 11:50, Edward Welbourne  wrote:
> 
> On 4 Feb 2020, at 16:56, Volker Hilsheimer  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

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Eskil Abrahamsen Blomfeldt]

On 05.02.2020 11:50, Edward Welbourne wrote:
> 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 ?


If the change is ready and approved by the time of feature freeze and 
only delayed by CI problems, failures from other changes in a batch, or 
the awkwardness of our dependency structure, I think it has to be 
acceptable to merge after the freeze. Otherwise feature freeze becomes a 
lottery where the features in a given release is based mostly on chance. 
The slack to accommodate these intrinsic delays need to be in the 
release plan in my opinion, and not in each developer's individual plan 
for merging their changes.

If it turns out the change cannot be merged as-is and needs additional 
fixing, I think it should be addressed as any other change that doesn't 
match the conditions above: on a case-by-case basis, considering value 
vs. risk in each case.

In the particular case you mention, I think we should fix the issues 
with the feature in 5.15 rather than revert it. The reason we have 
several months between freeze and release is so that we have time for 
stabilization work such as this.

-- 
Eskil Abrahamsen Blomfeldt
Senior Manager, Graphics

The Qt Company
Sandakerveien 116
0484, Oslo, Norway
eskil.abrahamsen-blomfe...@qt.io
+47 938 85 836
http://qt.io
https://twitter.com/eskilblomfeldt

The Future is Written with Qt

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Edward Welbourne]

On 4 Feb 2020, at 16:56, Volker Hilsheimer  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.

Eddy.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Mårten Nordheim]

There was already a patch which did this, for the getter:

https://codereview.qt-project.org/c/qt/qtbase/+/286089


Fra: Development  på vegne av Alexander 
Akulich 
Sendt: Wednesday, February 5, 2020 11:04:35 AM
Til: Jani Heikkinen 
Kopi: Qt development mailing list 
Emne: Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is in 
effect now

What I'm talking about is to repeat [1] for QAbstractSocket [2] as a
last-minute change for Qt 5.15.
If such a patch is not acceptable for 5.15, is it still acceptable for
Qt 6 (in terms of Qt 5.15/6.0 compatibility policy)?

I'm going to prepare the patch right now, whether it 'll be accepted
or not. (I hope and expect it to be a small change that is not sad to
drop)

[1] 
https://code.qt.io/cgit/qt/qtbase.git/commit/?id=4672e319e6dd0fbaa986e056e52dbb06d78fcfa5
[2] https://doc.qt.io/qt-5/qabstractsocket.html#error-1

On Wed, Feb 5, 2020 at 12:42 PM Alexander Akulich
 wrote:
>
> Hi all,
>
> does the 5.15 feature freeze mean that we can not adjust signal names
> anymore? IIRC it was said that "deprecated-free" code for Qt 5.15
> will/should be compatible with Qt 6.
>
> IIRC there was an intention to rename
> QAbstractSocket::error(SocketError) signal to errorOccured() to align
> it with the other signals and to remove the overload of
> QAbstractSocket::error() getter, so the API becomes a bit more
> developer-friendly.
> I thought that it was done, but it seems to be not the case. I can
> prepare and submit a patch in a few hours if it is still applicable
> for 5.15.
>
> On Wed, Feb 5, 2020 at 8:43 AM Jani Heikkinen  wrote:
> >
> > Hi!
> >
> > For this one my reply is similar  :D
> >
> > Why this is so important that we should get the exception & go in after FF? 
> > We need to delay the Alpha release because of this late addition if we 
> > agree to take this in. It seems this shouldn't cause that big delay but you 
> > never know... And taking this in between Alpha and beta doesn't sound that 
> > well to me either; as written before all known features should be in 
> > Alpha...
> >
> > br,
> > Jani
> >
> >
> > 
> > From: Lars Knoll 
> > Sent: Tuesday, February 4, 2020 8:41 PM
> > To: Volker Hilsheimer
> > Cc: Jani Heikkinen; Qt development mailing list; releas...@qt-project.org
> > Subject: Re: [Releasing] [Development] HEADS-UP: Qt 5.15 Feature Freeze is  
> > in effect now
> >
> > > On 4 Feb 2020, at 16:56, Volker Hilsheimer  
> > > wrote:
> > >
> > >> On 3 Feb 2020, at 06:35, Jani Heikkinen  wrote:
> > >>
> > >> Hi all,
> > >>
> > >> Qt 5.15 Feature Freeze is in effect now. So no new features in '5.15' 
> > >> anymore. Please update Qt 5.15 new features page 
> > >> (https://wiki.qt.io/New_Features_in_Qt_5.15) now; it seems to be quite 
> > >> empty still...
> > >>
> > >> Target is to publish Qt 5.15 Alpha as soon as possible; Let's see if we 
> > >> can get it out already during this week.
> > >>
> > >> API review for Qt 5.15 will start soon as well. Please do reviews 
> > >> immediately when available.
> > >>
> > >> br,
> > >> Jani Heikkinen
> > >
> > >
> > > 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
> >
> > +1 from my side. It doesn’t have dependencies on any other code, so it 
> > can’t break anything else neither.
> >
> > Cheers,
> > Lars
> >
> > ___
> > Development mailing list
> > Development@qt-project.org
> > https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
From: Alexander Akulich
Sent: onsdag 5. februar 2020 11:07
Subject: Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is in 
effect now

What I'm talking about is to repeat [1] for QAbstractSocket [2] as a
last-minute change for Qt 5.15.
If such a patch is not acceptable for 5.15, is it still acceptable for
Qt 6 (in terms of Qt 5.15/6.0 compatibility policy)?

I'm going to prepare the patch right now, whether it 'll be accepted
or not. (I hope and expect it to be a small change that is not sad to
drop)

[1] 
https://code.qt.io/cgit/qt/qtbase.git/commit/?id=4672e319e6dd0fbaa986e056e52dbb06d78fcfa5
[2] https://doc.qt.io/qt-5/qabstractsocket.html#error-1

On Wed, Feb 5, 2020 at 12:42 PM Alexander Akulich
 wrote:
>
> Hi all,
>
> does the 5.15 feature freeze mean that we can not adjust signal names
> anymore? IIRC it was said that "deprecated-free" code for Qt 5.15
> wil

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

[Alexander Akulich]

Oh, I'm sorry for the spam! You already renamed error() getter to
sockerError() [1], so the issue is not relevant now.
It's a bit unfortunate to see such diversity in the API. error()
getter seems to be a convention in Qt. I thought that the same
convention is to use '-ed' verbs in signal names.

[1] 
https://code.qt.io/cgit/qt/qtbase.git/commit/?h=5.15&id=94b3dd77f29a00ebbd1efdc66d75f57e1c75b152

On Wed, Feb 5, 2020 at 1:04 PM Alexander Akulich
 wrote:
>
> What I'm talking about is to repeat [1] for QAbstractSocket [2] as a
> last-minute change for Qt 5.15.
> If such a patch is not acceptable for 5.15, is it still acceptable for
> Qt 6 (in terms of Qt 5.15/6.0 compatibility policy)?
>
> I'm going to prepare the patch right now, whether it 'll be accepted
> or not. (I hope and expect it to be a small change that is not sad to
> drop)
>
> [1] 
> https://code.qt.io/cgit/qt/qtbase.git/commit/?id=4672e319e6dd0fbaa986e056e52dbb06d78fcfa5
> [2] https://doc.qt.io/qt-5/qabstractsocket.html#error-1
>
> On Wed, Feb 5, 2020 at 12:42 PM Alexander Akulich
>  wrote:
> >
> > Hi all,
> >
> > does the 5.15 feature freeze mean that we can not adjust signal names
> > anymore? IIRC it was said that "deprecated-free" code for Qt 5.15
> > will/should be compatible with Qt 6.
> >
> > IIRC there was an intention to rename
> > QAbstractSocket::error(SocketError) signal to errorOccured() to align
> > it with the other signals and to remove the overload of
> > QAbstractSocket::error() getter, so the API becomes a bit more
> > developer-friendly.
> > I thought that it was done, but it seems to be not the case. I can
> > prepare and submit a patch in a few hours if it is still applicable
> > for 5.15.
> >
> > On Wed, Feb 5, 2020 at 8:43 AM Jani Heikkinen  wrote:
> > >
> > > Hi!
> > >
> > > For this one my reply is similar  :D
> > >
> > > Why this is so important that we should get the exception & go in after 
> > > FF? We need to delay the Alpha release because of this late addition if 
> > > we agree to take this in. It seems this shouldn't cause that big delay 
> > > but you never know... And taking this in between Alpha and beta doesn't 
> > > sound that well to me either; as written before all known features should 
> > > be in Alpha...
> > >
> > > br,
> > > Jani
> > >
> > >
> > > 
> > > From: Lars Knoll 
> > > Sent: Tuesday, February 4, 2020 8:41 PM
> > > To: Volker Hilsheimer
> > > Cc: Jani Heikkinen; Qt development mailing list; releas...@qt-project.org
> > > Subject: Re: [Releasing] [Development] HEADS-UP: Qt 5.15 Feature Freeze 
> > > is  in effect now
> > >
> > > > On 4 Feb 2020, at 16:56, Volker Hilsheimer  
> > > > wrote:
> > > >
> > > >> On 3 Feb 2020, at 06:35, Jani Heikkinen  wrote:
> > > >>
> > > >> Hi all,
> > > >>
> > > >> Qt 5.15 Feature Freeze is in effect now. So no new features in '5.15' 
> > > >> anymore. Please update Qt 5.15 new features page 
> > > >> (https://wiki.qt.io/New_Features_in_Qt_5.15) now; it seems to be quite 
> > > >> empty still...
> > > >>
> > > >> Target is to publish Qt 5.15 Alpha as soon as possible; Let's see if 
> > > >> we can get it out already during this week.
> > > >>
> > > >> API review for Qt 5.15 will start soon as well. Please do reviews 
> > > >> immediately when available.
> > > >>
> > > >> br,
> > > >> Jani Heikkinen
> > > >
> > > >
> > > > 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
> > >
> > > +1 from my side. It doesn’t have dependencies on any other code, so it 
> > > can’t break anything else neither.
> > >
> > > Cheers,
> > > Lars
> > >
> > > ___
> > > Development mailing list
> > > Development@qt-project.org
> > > https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Ville Voutilainen]

On Wed, 5 Feb 2020 at 11:44, Alexander Akulich
 wrote:
>
> Hi all,
>
> does the 5.15 feature freeze mean that we can not adjust signal names
> anymore? IIRC it was said that "deprecated-free" code for Qt 5.15
> will/should be compatible with Qt 6.
>
> IIRC there was an intention to rename
> QAbstractSocket::error(SocketError) signal to errorOccured() to align
> it with the other signals and to remove the overload of
> QAbstractSocket::error() getter, so the API becomes a bit more
> developer-friendly.
> I thought that it was done, but it seems to be not the case. I can
> prepare and submit a patch in a few hours if it is still applicable
> for 5.15.

Isn't that an ABI break?
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Alexander Akulich]

What I'm talking about is to repeat [1] for QAbstractSocket [2] as a
last-minute change for Qt 5.15.
If such a patch is not acceptable for 5.15, is it still acceptable for
Qt 6 (in terms of Qt 5.15/6.0 compatibility policy)?

I'm going to prepare the patch right now, whether it 'll be accepted
or not. (I hope and expect it to be a small change that is not sad to
drop)

[1] 
https://code.qt.io/cgit/qt/qtbase.git/commit/?id=4672e319e6dd0fbaa986e056e52dbb06d78fcfa5
[2] https://doc.qt.io/qt-5/qabstractsocket.html#error-1

On Wed, Feb 5, 2020 at 12:42 PM Alexander Akulich
 wrote:
>
> Hi all,
>
> does the 5.15 feature freeze mean that we can not adjust signal names
> anymore? IIRC it was said that "deprecated-free" code for Qt 5.15
> will/should be compatible with Qt 6.
>
> IIRC there was an intention to rename
> QAbstractSocket::error(SocketError) signal to errorOccured() to align
> it with the other signals and to remove the overload of
> QAbstractSocket::error() getter, so the API becomes a bit more
> developer-friendly.
> I thought that it was done, but it seems to be not the case. I can
> prepare and submit a patch in a few hours if it is still applicable
> for 5.15.
>
> On Wed, Feb 5, 2020 at 8:43 AM Jani Heikkinen  wrote:
> >
> > Hi!
> >
> > For this one my reply is similar  :D
> >
> > Why this is so important that we should get the exception & go in after FF? 
> > We need to delay the Alpha release because of this late addition if we 
> > agree to take this in. It seems this shouldn't cause that big delay but you 
> > never know... And taking this in between Alpha and beta doesn't sound that 
> > well to me either; as written before all known features should be in 
> > Alpha...
> >
> > br,
> > Jani
> >
> >
> > 
> > From: Lars Knoll 
> > Sent: Tuesday, February 4, 2020 8:41 PM
> > To: Volker Hilsheimer
> > Cc: Jani Heikkinen; Qt development mailing list; releas...@qt-project.org
> > Subject: Re: [Releasing] [Development] HEADS-UP: Qt 5.15 Feature Freeze is  
> > in effect now
> >
> > > On 4 Feb 2020, at 16:56, Volker Hilsheimer  
> > > wrote:
> > >
> > >> On 3 Feb 2020, at 06:35, Jani Heikkinen  wrote:
> > >>
> > >> Hi all,
> > >>
> > >> Qt 5.15 Feature Freeze is in effect now. So no new features in '5.15' 
> > >> anymore. Please update Qt 5.15 new features page 
> > >> (https://wiki.qt.io/New_Features_in_Qt_5.15) now; it seems to be quite 
> > >> empty still...
> > >>
> > >> Target is to publish Qt 5.15 Alpha as soon as possible; Let's see if we 
> > >> can get it out already during this week.
> > >>
> > >> API review for Qt 5.15 will start soon as well. Please do reviews 
> > >> immediately when available.
> > >>
> > >> br,
> > >> Jani Heikkinen
> > >
> > >
> > > 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
> >
> > +1 from my side. It doesn’t have dependencies on any other code, so it 
> > can’t break anything else neither.
> >
> > Cheers,
> > Lars
> >
> > ___
> > Development mailing list
> > Development@qt-project.org
> > https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Alexander Akulich]

Hi all,

does the 5.15 feature freeze mean that we can not adjust signal names
anymore? IIRC it was said that "deprecated-free" code for Qt 5.15
will/should be compatible with Qt 6.

IIRC there was an intention to rename
QAbstractSocket::error(SocketError) signal to errorOccured() to align
it with the other signals and to remove the overload of
QAbstractSocket::error() getter, so the API becomes a bit more
developer-friendly.
I thought that it was done, but it seems to be not the case. I can
prepare and submit a patch in a few hours if it is still applicable
for 5.15.

On Wed, Feb 5, 2020 at 8:43 AM Jani Heikkinen  wrote:
>
> Hi!
>
> For this one my reply is similar  :D
>
> Why this is so important that we should get the exception & go in after FF? 
> We need to delay the Alpha release because of this late addition if we agree 
> to take this in. It seems this shouldn't cause that big delay but you never 
> know... And taking this in between Alpha and beta doesn't sound that well to 
> me either; as written before all known features should be in Alpha...
>
> br,
> Jani
>
>
> 
> From: Lars Knoll 
> Sent: Tuesday, February 4, 2020 8:41 PM
> To: Volker Hilsheimer
> Cc: Jani Heikkinen; Qt development mailing list; releas...@qt-project.org
> Subject: Re: [Releasing] [Development] HEADS-UP: Qt 5.15 Feature Freeze is
>   in effect now
>
> > On 4 Feb 2020, at 16:56, Volker Hilsheimer  wrote:
> >
> >> On 3 Feb 2020, at 06:35, Jani Heikkinen  wrote:
> >>
> >> Hi all,
> >>
> >> Qt 5.15 Feature Freeze is in effect now. So no new features in '5.15' 
> >> anymore. Please update Qt 5.15 new features page 
> >> (https://wiki.qt.io/New_Features_in_Qt_5.15) now; it seems to be quite 
> >> empty still...
> >>
> >> Target is to publish Qt 5.15 Alpha as soon as possible; Let's see if we 
> >> can get it out already during this week.
> >>
> >> API review for Qt 5.15 will start soon as well. Please do reviews 
> >> immediately when available.
> >>
> >> br,
> >> Jani Heikkinen
> >
> >
> > 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
>
> +1 from my side. It doesn’t have dependencies on any other code, so it can’t 
> break anything else neither.
>
> Cheers,
> Lars
>
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] The future of smart pointers in Qt API

[Ulf Hermann]

> A "Qt style" "RAII handle" is a QObject parent at creation time.
> There is no double deletion in this context, *only* when you start
> to sprinkle in other ownership models, i.e. deviate from "Qt style".

No.

There are many places in our API that expect or return plain QObject 
pointers and you just have to know whether those are or should be 
pre-owned by something and whether ownership is transferred by calling 
the method. In quite many places it's advisable to store a QObject 
pointer in a QScopedPointer or std::unique_ptr in order not to leak it 
under adverse conditions.

In some places you're expected to pass an unowned object to a method, 
for example when adding a widget to a layout. Most getters on widgets 
and similar, just return pre-owned objects you should _not_ put into a 
smart pointer (which would indeed risk double-deletion) or re-parent. 
But then, there are also factory methods that create an unowned object 
you should definitely re-parent or put into a smart pointer, and there 
are methods like the whole QVariant/QObject interaction that expect you 
to _keep_ ownership of the objects you pass and that return objects 
supposedly owned by something else, that you should _not_ put into a 
smart pointer or reparent.

A prime example of problems arising from the ambiguity of plain pointers 
are all the qtdeclarative tests that currently leak the result of 
QQmlComponent::create(). Those are quite a headache when I'm trying to 
get meaningful results from ASAN.

I would very much appreciate a way to denote the ownership conditions 
when transferring a pointer on a language level. That is basically what 
smart pointers are.

Ulf
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development