[Development] QScroller behavior with QAbstractItemView subclasses

[Adam Treat]

Hi,

In working on https://bugreports.qt.io/browse/QTBUG-64543 I've seen that 
the QAbstractItemView::autoScroll property interferes with QScroller 
managing the flick/scroll. The problematic behavior goes away if users 
of the API manually set this property to false on the instance of 
QAbstractItemView subclass, but ideally when using a QScroller we should 
have a way to turn this autoscroll behavior off automatically. Since 
QScroller does not know anything of the target that it is using... what 
is the best way to do this?

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

Re: [Development] CMake && QtCreator cross-compilation for ARM fails

[Adam Treat]

FWIW, Denis: I feel your pain and agree that the Qt Company and Qt Project have 
a responsibility to make cross compilation with CMake just work out of the box 
when you have the necessary kits installed in QtCreator.

There is absolutley no excuse for us not doing this. We as a company should be 
very careful to make this work as developers who *use* Qt won’t care at all if 
CMake causes them to lose time resetting up their tool chains for cross 
compilation.

I have also noticed that CMake does not work out of the box with many of our 
Boot2Qt kits. Needs fixing ASAP.



From: Development  on behalf of Denis 
Shienkov 
Sent: Thursday, December 13, 2018 4:59 AM
To: chg...@gmail.com
Cc: development@qt-project.org; kevin.kof...@chello.at
Subject: Re: [Development] CMake && QtCreator cross-compilation for ARM fails

> And it would be much worse for QBS, which requires much more from Qt than
> QMake. It requires QML, JavaScript, etc.

So what? A GCC too compiles with GCC... For me, as a developer it is not a
big problem and not a my. A worse problem is in CMake's ideology.

QBS just work immediatelly! Unlike of CMake! And a fact that the QBS's
just work cover all CMake's bootstrap crap. CMake has no one agvantage for 
developers!



чт, 13 дек. 2018 г. в 15:02, Denis Shienkov 
mailto:denis.shien...@gmail.com>>:
> Once you have the cross toolchain configured properly, which is a one-time
> setup effort, CMake will just work, too.

Will just work? What??! HAHA. Are you kidding?

Why I need to configure something? Why I need to create an additional
CMake's scripts, config files, toolchains and etc?

I already have added all required cross-compilation stuff (toolchain && rootfs) 
to
QtCreator. With QBS && QMake it works immediatelly! But for CMake I need in
additional unknown things.

And is it user friendly?

The Qt's PR peoples (especially the CMake maintainers) are praised that they
have added a lot of CMake && QtCreator integration improvements. But, I don't
see any results related event to a simple cross-compilation issues! It is 
nonsense!

How much the users need to wait for improvements for this (and other) issues 
with
CMake? It completelly gets stuck for a working process.

Where is CMake advantages? I see only regressions! And it is reality!

чт, 13 дек. 2018 г. в 13:48, Christian Gagneraud 
mailto:chg...@gmail.com>>:
On Thu, 13 Dec 2018 at 12:27, Kevin Kofler 
mailto:kevin.kof...@chello.at>> wrote:
Hi Kevin,
> > PS: WTF? Why the Qt's management choosed the CMake's instead of QBS?
>
> Because CMake is a widespread tool written in C++/STL

Some people are scared of the wolf, i'm scared of the sheepple.

> (so, unlike QBS, it
> does not depend on Qt, which would mean a circular dependency when building
> Qt),

qmake has this problem, yet it's been packaged for 10+ years without a problem.

> widely packaged for GNU/Linux distributions, and with binaries for
> Windows and macOS shipped by CMake upstream (Kitware) themselves. It has a
> live upstream at Kitware, so Qt does not have to maintain it. And it is
> already widely used in the Qt and KDE community.

What a bunch of cheap free statements, w/o proper comparison.

>
> QBS, on the other hand, is a custom tool, in practice only used by Qt and a
> few Qt-using projects (I know the aim is to support also non-Qt projects,
> but this is not really used in the wild), which requires constant
> maintenance effort from the Qt project.

Can you point me to something that shows the Qt "project" contributing
to the Qt "company" on that very particular topic?
The Qt Company has been looking for "employees" to work on Qbs for
month before dropping it, apparently nobody responded, or something...

> >  From my point of view, the CMake it is a crap...
>
> CMake is not a "crap", it is a powerful tool, almost as easy to use as
> QMake, but a lot more flexible and powerful.

Cmake is crap, it is a macro based language, like it's good to be back
in the 80's.
It has no semantic, and no concept apart form 'macro', the syntax
sucks, big time, every thing is just 'expression', read that one:
https://cmake.org/cmake/help/latest/manual/cmake-generator-expressions.7.html#output-expressions
And read that again and again, until you brain says: 'Actually, CMake
is "crap"!'

>
> > I know, that I'm not a CMake expert, but Why I need to spent a lot time
> > to make the CMake working wich an unknown result,
> > instead of just using QBS? Cross-compilation with QBS works
> > immediatelly, but with CMake sucks!
>
> Once you have the cross toolchain configured properly, which is a one-time
> setup effort, CMake will just work, too.

Oh yeah! Unless you hit some bugs, like, CMake-based cross-compilation
doesn't actually exists (yet) on Windows:
https://github.com/Kitware/CMake/commit/5f0f84c7e0630d7b8190c18badd5a68e2dd08ff7

I'm telling you: with CMake, it's 1988 Christmas, right now!

Chris.
___
Development 

Re: [Development] Build system for Qt 6

[Adam Treat]

See: “deprecated”


From: Development  on 
behalf of Uwe Rathmann 
Sent: Wednesday, October 31, 2018 2:35:50 AM
To: development@qt-project.org
Subject: Re: [Development] Build system for Qt 6

On Tue, 30 Oct 2018 19:24:26 +, Adam Treat wrote:

> Lars gave a keynote saying pretty much the same. Simply is not true that
> we are planning major source compatible breakage for Qt6 so let's stop
> saying that.

When will the already deprecated QQuickControls 1 module going to be
finally removed - isn't it Qt6 ?

QC1 user interfaces for embedded have to be migrated to QC 2, while user
interfaces for the desktop have to be reimplemented from scratch with Qt/
Widgets in C++.

To me this absolutely justifies to insist on the term "major".

Uwe

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

Re: [Development] Build system for Qt 6

[Adam Treat]

Lars gave a keynote saying pretty much the same. Simply is not true that 
we are planning major source compatible breakage for Qt6 so let's stop 
saying that.

On 10/30/2018 03:19 PM, Thiago Macieira wrote:
> On Tuesday, 30 October 2018 12:11:38 PDT NIkolai Marchenko wrote:
>>   >  That's not going to happen any more than our breaking source
>>
>> compatibility in
>> a major way.
>>
>> You are breaking source compatibility in a major way with Qt6 ... ;)
> No, we will break source compatibility in a minor way.
>

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

Re: [Development] Repository request: HTTP server

[Adam Treat]

What came of this?

On 10/06/2017 07:10 AM, Fredrik de Vibe wrote:

Hi all,

We have recently been working on a research project looking into the 
possibilities for creating a lightweight server component that can easily 
enable Qt applications to serve over HTTP. We would like to make this work 
public and therefore request a repository.

This work is intended to continue as a research project, to explore 
alternatives and reveal areas that need work, so it should be under qt-labs.


Name of the project: Qt HTTP Server
Responsible person: Fredrik de Vibe
Gerrit user/email: fredrik.dev...@qt.io
Desired repository name: qthttpserver




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

Re: [Development] About our CI update notifications

[Adam Treat]

NM, I figured out how to cancel it :P

On 03/15/2018 11:57 AM, Adam Treat wrote:

Speaking of...

https://codereview.qt-project.org/#/c/223224/

That integration is stuck and I don't know how to stop it and restage 
it. Apparently, the Windows 7 (mingw53-x86) VM crashed and COIN is not 
aware of that due to these:


 1. https://bugreports.qt.io/browse/QTQAINFRA-1750
 2. https://bugreports.qt.io/browse/QTQAINFRA-1748

Anyone know how to stop the integration so I can restage?

Cheers,

Adam


On 03/15/2018 09:35 AM, Adam Treat wrote:
I would not regard this as excess spam at all. It is important to 
know when the CI is not available and what the status is. If a 
restart or scheduled update of any kind requires to restage commits 
for COIN, please include that info.


On 03/15/2018 04:26 AM, Tony Sarajärvi wrote:


Hi

We’re trying to improve our communication toward you regarding our 
CI and what’s going on with it. So our suggestion comes as follows:


·- In case of a scheduled update, we send an e-mail to the public 
developer mailing list the day before


·- In case of emergency update or pure restart, no notifications are 
needed


·- If Coin is unavailable for more than 30 min, we send an e-mail to 
the public developer mail list and inform about it followed by an 
e-mail when it’s back up again.


·- Keep community updated in case of prolonged downtime

·- We mention a contact address where e-mails should be sent if 
abnormalities are seen after the update/restart, usually qt.ci 
<http://qt.ci/>@qt.io <http://qt.io/>


How does this sound to you recipients of these e-mails? Enough or 
would this be excess spam to some degree?


-Tony





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




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


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

Re: [Development] About our CI update notifications

[Adam Treat]

Speaking of...

https://codereview.qt-project.org/#/c/223224/

That integration is stuck and I don't know how to stop it and restage 
it. Apparently, the Windows 7 (mingw53-x86) VM crashed and COIN is not 
aware of that due to these:


1. https://bugreports.qt.io/browse/QTQAINFRA-1750
2. https://bugreports.qt.io/browse/QTQAINFRA-1748

Anyone know how to stop the integration so I can restage?

Cheers,

Adam


On 03/15/2018 09:35 AM, Adam Treat wrote:
I would not regard this as excess spam at all. It is important to know 
when the CI is not available and what the status is. If a restart or 
scheduled update of any kind requires to restage commits for COIN, 
please include that info.


On 03/15/2018 04:26 AM, Tony Sarajärvi wrote:


Hi

We’re trying to improve our communication toward you regarding our CI 
and what’s going on with it. So our suggestion comes as follows:


·- In case of a scheduled update, we send an e-mail to the public 
developer mailing list the day before


·- In case of emergency update or pure restart, no notifications are 
needed


·- If Coin is unavailable for more than 30 min, we send an e-mail to 
the public developer mail list and inform about it followed by an 
e-mail when it’s back up again.


·- Keep community updated in case of prolonged downtime

·- We mention a contact address where e-mails should be sent if 
abnormalities are seen after the update/restart, usually qt.ci 
<http://qt.ci/>@qt.io <http://qt.io/>


How does this sound to you recipients of these e-mails? Enough or 
would this be excess spam to some degree?


-Tony





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


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

Re: [Development] About our CI update notifications

[Adam Treat]

I would not regard this as excess spam at all. It is important to know 
when the CI is not available and what the status is. If a restart or 
scheduled update of any kind requires to restage commits for COIN, 
please include that info.


On 03/15/2018 04:26 AM, Tony Sarajärvi wrote:


Hi

We’re trying to improve our communication toward you regarding our CI 
and what’s going on with it. So our suggestion comes as follows:


·- In case of a scheduled update, we send an e-mail to the public 
developer mailing list the day before


·- In case of emergency update or pure restart, no notifications are 
needed


·- If Coin is unavailable for more than 30 min, we send an e-mail to 
the public developer mail list and inform about it followed by an 
e-mail when it’s back up again.


·- Keep community updated in case of prolonged downtime

·- We mention a contact address where e-mails should be sent if 
abnormalities are seen after the update/restart, usually qt.ci 
@qt.io 


How does this sound to you recipients of these e-mails? Enough or 
would this be excess spam to some degree?


-Tony



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

Re: [Development] [Qt-creator] Requesting repository for telemetry plugin in Qt Creator

[Adam Treat]

"If many users spend much time doing a "thing", does that mean that this
is most important to them? Or that it is most fun to do?"

Personally, I think we can table the discussion of how to interpret 
non-existent data for a plug-in that does not exist in a thread about whether 
to open a repo.


From: Development  on 
behalf of Robert Löhning 
Sent: Friday, February 23, 2018 9:59:01 AM
To: Edward Welbourne; André Pönitz
Cc: development@qt-project.org; qt-crea...@qt-project.org; Ryein Goddard
Subject: Re: [Development] [Qt-creator] Requesting repository for telemetry 
plugin in Qt Creator

Am 23.02.2018 um 11:54 schrieb Edward Welbourne:
> André Pönitz (22 February 2018 20:05)
>> Any number for a "measured" value for rate of crashes or memory leaks
>> is uninteresting for me when I run into the problem myself reqularly.
>> And trust me, I do.
>
> I trust you.
> It is, however, possible your usage patterns of the UI are not typical;
> consequently, you'll prioritise the bugs you see most often; which might
> not be the bugs most often encountered by other users.  Analytics may
> give you the data to know the pain points everyone else is as acutely
> aware of as you are of the pain points you meet most often.
>
>> As someone who has been working on Qt Creator for more than a decade I
>> *do* know about issues in the IDE by my own use of it, by the
>> significant backlog of bug reports in JIRA, and by interacting with
>> (sometimes referred to as "talking to") actual users.
>>
>> The currently 399 open issues assigned to me personally would already
>> be enough to keep me busy for approximately a $WHILE, full time, not
>> including time spent in review processes etc.
>>
>> I certainly do not need another input channel that makes me spent time
>> on guessing how the information that "user A spent at time B an amount
>> of C minutes working on project named D" will translate into making my
>> work more efficient
>
> The proposed system provides anonymised and presumably aggregated data;
> so you won't be given, much less asked to evaluate, information about a
> specific user A doing things at a specific time B; your objection is a
> straw man.  You'd be getting data on what proportion of users spend what
> proportions of their time doing which things.  In particular, knowing
> which bugs bite most users most often might not be entirely useless when
> it comes to prioritising which bug to fix first.

If many users spend much time doing a "thing", does that mean that this
is most important to them? Or that it is most fun to do? Or does it just
mean that the design is so bad that they lose lots of time there and
can't use it efficiently?

> This won't enable you to write new features any faster or fix bugs any
> faster; but it may enable you to prioritise the things that are causing
> most pain to most users, and the things that would give the most win to
> the most users.  *That* is what analytics is good for.  The fact that it
> doesn't do a bunch of other things is beside the point, and no reason to
> reject it out of hand.
>
> Now, fortunately for you, most of the folk who use the product you work
> on are in fact software developers, so may well have similar habits to
> yours; so if the scope of this project is only Qt Creator, it may well
> be a waste of time; and, if it's intended to be a more general tool,
> this may also be a reason to *not* focus on Qt Creator as initial
> test-bed, as seems to be the present plan - that's apt to skew what we
> develop to be something that only works when the user-base thinks like
> the developers, which is not where (honest, open, ethical) analytics is
> at its best - where it reveals things to the developer that users see
> all the time, but the developer never encounters.
>
>Eddy.
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>

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

Re: [Development] [Qt-creator] Requesting repository for telemetry plugin in Qt Creator

[Adam Treat]

+1 to playground

This is open source... by all means experiment! As long as no laws are being 
broken and no licenses violated, then if their is an itch... scratch it!

The person who codes decides. We can all judge the results by looking at the 
code. Useless to have stop energy about a plug-in that does not yet exist. It 
could be great or it could be a lousy failure, but opening up a playgrounds 
repo costs no one anything.


From: Development  on 
behalf of Simon Hausmann 
Sent: Friday, February 23, 2018 3:00:33 AM
To: Pasi Keränen; Tino Pyssysalo; Tuukka Turunen; qt-crea...@qt-project.org; 
development@qt-project.org
Subject: Re: [Development] [Qt-creator] Requesting repository for telemetry 
plugin in Qt Creator


Hi,


Given that no plan has been presented about how this is intended to work in 
terms of backend or API scope, I stand with my -1 for a qt/ or qt-creator/ 
repo. If there exists no plan yet but the desire to experiment, then I'm with 
Pasi here and would suggest a repository in the playground scope. I think 
either analytics or telemetry make sense to have in the name. Firebase for 
example uses the term analytics in their API and Mozilla uses the term 
telemetry for the service of collecting performance and usage info for Firefox.



Simon


From: Pasi Keränen
Sent: Friday, February 23, 2018 8:53:33 AM
To: Maurice Kalinowski; Tino Pyssysalo; Simon Hausmann; Tuukka Turunen; 
qt-crea...@qt-project.org; development@qt-project.org
Subject: Re: [Development] [Qt-creator] Requesting repository for telemetry 
plugin in Qt Creator


Hi,



Repos can be relocated to new homes if really needed, but I think it’s fair to 
say more generic location is definitely preferred from Qt 3D Studio point of 
view.



To make this even easier I’d even start with a playground repo if nothing else 
can be found. Qt has always been (despite our vocal and sometimes a bit harsh 
dialogue) inclusive, so it should be fine to go and experiment with all things 
UI related. Just to see if something is worth the effort or not.



Regards,

Pasi



From: Development  on 
behalf of Maurice Kalinowski 
Date: Friday, 23 February 2018 at 9.33
To: Tino Pyssysalo , Simon Hausmann 
, Tuukka Turunen , 
"qt-crea...@qt-project.org" , 
"development@qt-project.org" 
Subject: Re: [Development] [Qt-creator] Requesting repository for telemetry 
plugin in Qt Creator



“The idea is to develop a generic library/plugin, which anyone could use for 
analytics”



If that is the case, then qt-creator/telemetry is the wrong repository to ask 
for. If you are aiming at something generic, then it should be qt/



Maurice



Von: Qt-creator 
[mailto:qt-creator-bounces+maurice.kalinowski=qt...@qt-project.org] Im Auftrag 
von Tino Pyssysalo
Gesendet: Thursday, February 22, 2018 2:59 PM
An: Simon Hausmann ; Tuukka Turunen 
; qt-crea...@qt-project.org; development@qt-project.org
Betreff: Re: [Qt-creator] [Development] Requesting repository for telemetry 
plugin in Qt Creator



Hi,



The idea is to develop a generic library/plugin, which anyone could use for 
analytics. The backend can be any storage and The Qt Company does not provide 
that.



We plan to use the same backend, which we already use in online installers to 
collect statistics about installations. At least in case of Qt Creator, the 
plan is to make some analysis results available for the community. Obviously, 
we do not do that for our commercial tooling.



Analytics is opt-in and disabled by default in Qt Creator. We plan to ask user 
in the installer, if the user wish to participate in Qt UX improvement. If the 
answers is no, the analytics plugin is never installed.  When the creator is 
started for the first time, it will show a dialog, consisting a list of 
collected data items and an option to enable/disable the plugin. There will be 
a new output pane, which shows collected data, conversions methods, if any 
used, and transmitted data to the user.

--

Tino





On 22/02/2018, 15.26, "Simon Hausmann" 
> wrote:



Hi,



Can you provide a bit more information about how this plugin / frontend fits 
into the Qt project? Where is the collected data sent to and how is it 
accessible to the community?



(-1 from me, as I think this needs to be clarified)



Simon



From: Development 
>
 on behalf of Tuukka Turunen >
Sent: Thursday, February 22, 2018 

Re: [Development] Qt branches & proposal how to continue with those

[Adam Treat]

“stop doing patch releases for minor releases that are not LTS.”

+1

_
From: Simon Hausmann 
Sent: Monday, January 29, 2018 3:16 AM
Subject: Re: [Development] Qt branches & proposal how to continue with those
To: Jani Heikkinen , 



Hi,


I feel that we are generally guiding our users towards the LTS releases. The 
minor releases appear to address in particular users who need a particular 
feature before it hits the next LTS release.


In the light of that, I think it would be better to keep the LTS branches open 
longer and stop doing patch releases for minor releases that are not LTS.



Simon


From: Development  on 
behalf of Jani Heikkinen 
Sent: Monday, January 29, 2018 7:59:06 AM
To: development@qt-project.org
Subject: [Development] Qt branches & proposal how to continue with those

Hi,

We have currently really many branches open:
- 5.6
- 5.9
- 5.10
- 5.10.1
- 5.11
- dev

In my opinion this is too much to handle effectively, especially because there 
is many branches in stable mode 
(seehttp://code.qt.io/cgit/meta/quips.git/tree/quip-0005.rst). Currently '5.6' 
is in 'strict' mode and  '5.9', 5.10' & '5.11' are in stable... I think we need 
to change that to be able to work efficiently & get releases out.

So I am proposing following changes starting from 1st Feb 2018:

- '5.6' will move in 'very strict' mode
- '5.9' will move in 'strict' mode. So no direct submissions anymore, just 
cherry picks from stable
- '5.10' will be closed and Qt 5.10.1 will be the final release from Qt 5.10 
series (5.6 and 5.9 are LTS branches so we shouldn't keep Qt 5.10 active too 
long)
- '5.11' will be to one and only stable branch

br,

Jani
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


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

Re: [Development] Setters: Clarifying the ownership

[Adam Treat]

How about "transfer"

On 01/19/2018 11:57 AM, Thiago Macieira wrote:

On sexta-feira, 19 de janeiro de 2018 08:26:21 PST Philippe wrote:

+20 years ago, the (good) Taligent crossplatform project, in its guideline,
proposed:

adopt() aka "take ownership"

orphan() aka "release ownership"

Given that we already have "take"  methods that release ownership in the Qt
containers, that won't work. See QList / QVector::takeAt.



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

Re: [Development] atomic commits across submodules

[Adam Treat]

On 12/18/2017 05:24 AM, Jędrzej Nowacki wrote:

On czwartek, 7 grudnia 2017 12:17:16 CET Adam Treat wrote:

Hi,

I think it is high time that we fix the underlying problem: supporting
atomic commits across submodules.

As I'm not against the idea, I'm not really fan of it either. The problem with
atomic commits across submodules is that they encourage API breakages. Without
supporting both code paths even for a little while, one is not aware of the
pain that our users needs to go through every time we break API.


So your position is we shouldn't need atomic commits across submodules 
because the changes that are leading to breakage are themselves the 
problem. Let's examine types of changes:


1) Build system changes that require cross-module modifications
2) New public API in base module where dependent module takes advantage 
of it

3) Private API being changed out from under
4) Merges of the above 3 types from release branches to dev

Of these, only #2 should be solvable without atomic commits. In that 
case, we can introduce API first and when it is integrated, only then 
update dependent modules. This is still a problem for #4 though, but 
more about that later.


For the other types, atomic commits are at least sometimes going to be 
required. Right now, we are experiencing breakage. And it *is* painful. 
But I have not seen a postmortem of said breakages that shows the 
current processes are up to preventing such breakage. Maybe the answer 
is to move away from private API and a build system that does not need 
to be bootstrapped from Qt...


Now, back to #4, I do know that those responsible for merging from 
release branches into dev face a mind field of cross-module 
modifications. Consider #2 again and say such a change across modules 
has made it into release branches. It is my understanding that it is 
*just such a set of changes* that led to Liang Qi's request to add 
labels to API changes because the ordering info gets lost.  Merges from 
release to dev are going to be problematic until we have some way of 
ensuring cross-module dependencies are handled.


Which is why I propose that we stop merging from release to dev and 
require all changes to hit dev first. But, more on that in another email 
thread later. Maybe after the holidays ;)



Once this is done we should revert our CI to test changes against latest
version of all modules.

No. First, how these two are connected, that is a big jump to a solution,
without providing reasoning. I know that you didn't know about the fact that
we pin submodules in qt5 and you got burned by this. That __is__ an argument,
but an alternative solution would be a better documentation or UI.  Second,
the most important, that doesn't scale. By compiling against latest Qt5 we
reduced CI load by ~80%.


Fair enough, let's table this. I have more to say about this, but it 
really is related to my suggestion above. Again, more about that later.

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

Re: [Development] COIN failures on dev

[Adam Treat]

This was apparently the result of a miscommunication and no force 
pushing is contemplated.


On 12/12/2017 01:24 PM, Tuukka Turunen wrote:


Hi,

Force pushing of what? Of course in a situation where nothing else is 
possible, we need to have a way to unblock CI by forced push. But we 
are not pushing other than really mandatory fixes in bypassing the CI.


It is very unfortunate that dev has been broken for a while, but work 
is ongoing to unblock it.


Yours,

    Tuukka

*From: *Development 
<development-bounces+tuukka.turunen=qt...@qt-project.org> on behalf of 
Adam Treat <adam.tr...@qt.io>

*Date: *Tuesday, 12 December 2017 at 13.10
*To: *Simon Hausmann <simon.hausm...@qt.io>, 
"development@qt-project.org" <development@qt-project.org>

*Subject: *Re: [Development] COIN failures on dev

Ah, so last successful integration on qt5 super module was nearly a 
month ago?? 11/172017


Now, what I was really after was last generally unsuccessful 
integration to see how all the brokenness went through.  I guess the 
git repo is not the source of truth for that. The integrations 
yesterday were failing seemingly unrelated to the patch. Folks seemed 
generally unsurprised this was happening and attributed it to 
flakiness that is generally known and that force pushes are the way to 
deal with that.


Is this customary? Force pushing because the CI results are too flaky 
to be trusted?




*From:*Simon Hausmann
*Sent:* Tuesday, December 12, 2017 3:09:03 AM
*To:* Adam Treat; development@qt-project.org
*Subject:* Re: [Development] COIN failures on dev

Hi,

I find the easiest way to find the last successful integration for 
example for qt5.git dev is this:


    (1) Go to http://code.qt.io/cgit/qt/qt5.git/ and pick the dev branch

    (2) Click on the last commit in the branch

    (3) Click on the "Change-Id" link or paste the commit sha1 into 
the Gerrit search field


    (4) At the bottom of the change in Gerrit you can find a link to 
https://testresults.qt.io/ with more details about the actual 
integration and what other changes it was tested together with 
(https://testresults.qt.io/coin/integration/qt/qt5/tasks/1510549095 in 
this case).


The git repo is our source of truth, and from there it's easy to get 
back to gerrit and then the CI. All of the above steps can also be 
done entirely in a CLI way by using Gerrit's ssh query interface.


Simon



*From:*Development 
<development-bounces+simon.hausmann=qt...@qt-project.org> on behalf of 
Adam Treat <adam.tr...@qt.io>

*Sent:* Monday, December 11, 2017 5:47:41 PM
*To:* development@qt-project.org
*Subject:* Re: [Development] COIN failures on dev

Whenever I discover something seemingly broken in an area of code I'm
unfamiliar with I first suspect I don't understand something...

Right now I'm looking for the last successful dev branch integration on
qt5 supermodule and I can not find it. I've gone back to before
Thanksgiving.

Can this possibly be correct??

Where is the dashboard showing the last successful integration for a
given branch?

On 12/11/2017 11:24 AM, Adam Treat wrote:
> Hi,
>
> For the past few business days we've all witnessed failures on dev
> branch like this: https://codereview.qt-project.org/#/c/213309/
>
> Seems that something broke with provisioning on macOS or something. I
> see this https://codereview.qt-project.org/#/c/214045/ attempt to fix,
> but that is also failing to integrate due to seemingly unrelated 
reasons.

>
> I'm disturbed that I haven't seen any widely shared communication
> about this, how it broke, what is being done to fix, or what can be
> done to stop it in the future.
>
> Things seem really broken with our CI system in general. I wonder that
> this isn't the normalization of deviance. Has the project just given
> up and regards this as standard operating procedure?
>
> - Adam
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

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



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

Re: [Development] COIN failures on dev

[Adam Treat]

Ah, so last successful integration on qt5 super module was nearly a month ago?? 
11/172017

Now, what I was really after was last generally unsuccessful integration to see 
how all the brokenness went through.  I guess the git repo is not the source of 
truth for that. The integrations yesterday were failing seemingly unrelated to 
the patch. Folks seemed generally unsurprised this was happening and attributed 
it to flakiness that is generally known and that force pushes are the way to 
deal with that.

Is this customary? Force pushing because the CI results are too flaky to be 
trusted?




From: Simon Hausmann
Sent: Tuesday, December 12, 2017 3:09:03 AM
To: Adam Treat; development@qt-project.org
Subject: Re: [Development] COIN failures on dev


Hi,


I find the easiest way to find the last successful integration for example for 
qt5.git dev is this:


(1) Go to http://code.qt.io/cgit/qt/qt5.git/ and pick the dev branch

(2) Click on the last commit in the branch

(3) Click on the "Change-Id" link or paste the commit sha1 into the Gerrit 
search field

(4) At the bottom of the change in Gerrit you can find a link to 
https://testresults.qt.io/ with more details about the actual integration and 
what other changes it was tested together with 
(https://testresults.qt.io/coin/integration/qt/qt5/tasks/1510549095 in this 
case).



The git repo is our source of truth, and from there it's easy to get back to 
gerrit and then the CI. All of the above steps can also be done entirely in a 
CLI way by using Gerrit's ssh query interface.



Simon


From: Development <development-bounces+simon.hausmann=qt...@qt-project.org> on 
behalf of Adam Treat <adam.tr...@qt.io>
Sent: Monday, December 11, 2017 5:47:41 PM
To: development@qt-project.org
Subject: Re: [Development] COIN failures on dev

Whenever I discover something seemingly broken in an area of code I'm
unfamiliar with I first suspect I don't understand something...

Right now I'm looking for the last successful dev branch integration on
qt5 supermodule and I can not find it. I've gone back to before
Thanksgiving.

Can this possibly be correct??

Where is the dashboard showing the last successful integration for a
given branch?

On 12/11/2017 11:24 AM, Adam Treat wrote:
> Hi,
>
> For the past few business days we've all witnessed failures on dev
> branch like this: https://codereview.qt-project.org/#/c/213309/
>
> Seems that something broke with provisioning on macOS or something. I
> see this https://codereview.qt-project.org/#/c/214045/ attempt to fix,
> but that is also failing to integrate due to seemingly unrelated reasons.
>
> I'm disturbed that I haven't seen any widely shared communication
> about this, how it broke, what is being done to fix, or what can be
> done to stop it in the future.
>
> Things seem really broken with our CI system in general. I wonder that
> this isn't the normalization of deviance. Has the project just given
> up and regards this as standard operating procedure?
>
> - Adam
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

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

Re: [Development] COIN failures on dev

[Adam Treat]

Whenever I discover something seemingly broken in an area of code I'm 
unfamiliar with I first suspect I don't understand something...


Right now I'm looking for the last successful dev branch integration on 
qt5 supermodule and I can not find it. I've gone back to before 
Thanksgiving.


Can this possibly be correct??

Where is the dashboard showing the last successful integration for a 
given branch?


On 12/11/2017 11:24 AM, Adam Treat wrote:

Hi,

For the past few business days we've all witnessed failures on dev 
branch like this: https://codereview.qt-project.org/#/c/213309/


Seems that something broke with provisioning on macOS or something. I 
see this https://codereview.qt-project.org/#/c/214045/ attempt to fix, 
but that is also failing to integrate due to seemingly unrelated reasons.


I'm disturbed that I haven't seen any widely shared communication 
about this, how it broke, what is being done to fix, or what can be 
done to stop it in the future.


Things seem really broken with our CI system in general. I wonder that 
this isn't the normalization of deviance. Has the project just given 
up and regards this as standard operating procedure?


- Adam

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


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

[Development] COIN failures on dev

[Adam Treat]

Hi,

For the past few business days we've all witnessed failures on dev 
branch like this: https://codereview.qt-project.org/#/c/213309/


Seems that something broke with provisioning on macOS or something. I 
see this https://codereview.qt-project.org/#/c/214045/ attempt to fix, 
but that is also failing to integrate due to seemingly unrelated reasons.


I'm disturbed that I haven't seen any widely shared communication about 
this, how it broke, what is being done to fix, or what can be done to 
stop it in the future.


Things seem really broken with our CI system in general. I wonder that 
this isn't the normalization of deviance. Has the project just given up 
and regards this as standard operating procedure?


- Adam

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

Re: [Development] Suggestion to add labels when changing API

[Adam Treat]

On 12/08/2017 12:47 PM, Sergio Ahumada wrote:

On 08.12.2017 16:50, Oswald Buddenhagen wrote:

On Fri, Dec 08, 2017 at 04:15:10PM +0100, Sergio Ahumada wrote:

On 08.12.2017 15:42, Adam Treat wrote:
Relying upon qt5 submodule pins is the problem. The underlying 
issue is

atomicity of commits. Oswald is right.

We need to have a way to provide atomic commits across modules at 
least

the CI should see these as atomic and integrate accordingly.



what about trying to enable gerrit topic's feature again for cross-repo
changes?


from the ci perspective, that's both pointless (because the grouping can
be achieved temporally by just staging the changes at the same time) and
insufficient (because the system currently just won't do atomic
integrations).


I meant provided the system is able to do atomic integrations, as Adam 
suggested. But that would probably require quite a lot of more 
computer power.


Why?


actually, Adam's initial proposal sounds quite good to me

> * Adopt something like Google's repo tool: 
https://code.google.com/archive/p/git-repo/

> * Stop using submodules and use a monolithic repo

for both these proposals see https://bugreports.qt.io/browse/QTBUG-19580

> * Implement atomic commit across submodules not in Git, but in the 
gerrit/COIN layer so that COIN effectively locks integrations until 
commits that span submodules are finished


Use the topic feature to merge changes across repos once they are all 
passed their CIs. Merge normal changes as usual after their CIs are 
passed.


Move the old dependencies from 
sync.profile+http://code.qt.io/cgit/qt/qt5.git/tree/.gitmodules to the 
demo-default.xml file proposed in QTBUG-19580 .. get the list of repos 
to be cloned (or already built tgz) + needed sha1 to git-reset and 
then git-cherry-pick the changes under test on top ..


does that make any sense?


As another alternative I'm trying to figure out if Gitlab's CI system 
has a way to deal with this:


https://forum.gitlab.com/t/trigger-ci-build-if-any-dependent-git-repo-is-updated/9725

They do have ways to kick off integration jobs based on git triggers 
and/or other logic: https://docs.gitlab.com/ee/ci/yaml/#jobs


I think we could design atomic integrations across submodules with 
something like that.


In general, has anyone looked into Gitlab's CI system and 
compared/contrasted with COIN?



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

Re: [Development] Suggestion to add labels when changing API

[Adam Treat]

On 12/08/2017 09:20 AM, Konstantin Tokarev wrote:


08.12.2017, 17:14, "Tor Arne Vestbø" :

On 08/12/2017 14:54, Sergio Ahumada wrote:

  an old concept that used to pin the sha1 of repo/module's dependency, eg

  
http://code.qt.io/cgit/qt/qtdeclarative.git/commit/sync.profile?id=ab6b6b7c7ab544d347d59b7eefad403837d94012

  that was replaced in, eg,
  
http://code.qt.io/cgit/qt/qtdeclarative.git/commit/sync.profile?id=9bfe3324f7fa94e1f272c35bcb943daa2669edba

  for

  http://code.qt.io/cgit/qt/qt5.git/tree/.gitmodules

Ouch, what was the rationale for making this change?

IIRC, it was done to have all things in one place. Integration is strongly 
affected by used qt5 commit, which determines provisioning configuration and 
platform configs, so it's logical to use its submodule references as well.


Again, this all boils down to the commits across submodules are not 
atomic. The very least that needs to be done is to make it atomic from 
the CI perspective if not atomic to all those doing git fetch and rebuild.

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

Re: [Development] Suggestion to add labels when changing API

[Adam Treat]

Relying upon qt5 submodule pins is the problem. The underlying issue is 
atomicity of commits. Oswald is right.


We need to have a way to provide atomic commits across modules at least 
the CI should see these as atomic and integrate accordingly.


On 12/08/2017 09:20 AM, Konstantin Tokarev wrote:


08.12.2017, 17:14, "Tor Arne Vestbø" :

On 08/12/2017 14:54, Sergio Ahumada wrote:

  an old concept that used to pin the sha1 of repo/module's dependency, eg

  
http://code.qt.io/cgit/qt/qtdeclarative.git/commit/sync.profile?id=ab6b6b7c7ab544d347d59b7eefad403837d94012

  that was replaced in, eg,
  
http://code.qt.io/cgit/qt/qtdeclarative.git/commit/sync.profile?id=9bfe3324f7fa94e1f272c35bcb943daa2669edba

  for

  http://code.qt.io/cgit/qt/qt5.git/tree/.gitmodules

Ouch, what was the rationale for making this change?

IIRC, it was done to have all things in one place. Integration is strongly 
affected by used qt5 commit, which determines provisioning configuration and 
platform configs, so it's logical to use its submodule references as well.


tor arne

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


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

Re: [Development] Suggestion to add labels when changing API

[Adam Treat]

Hi,

I think it is high time that we fix the underlying problem: supporting 
atomic commits across submodules.


Once this is done we should revert our CI to test changes against latest 
version of all modules. As for how this could be done:


* Adopt something like Google's repo tool: 
https://code.google.com/archive/p/git-repo/

* Stop using submodules and use a monolithic repo
* Git subtree
* Implement atomic commit across submodules not in Git, but in the 
gerrit/COIN layer so that COIN effectively locks integrations until 
commits that span submodules are finished

* Something else?

Cheers,
Adam

On 12/07/2017 11:22 AM, Liang Qi wrote:

Since 
http://lists.qt-project.org/pipermail/development/2016-October/027542.html , 
Coin tests all changes against Qt5 instead of the latest version of all modules.

The situation is sth like, some new APIs were added to qtbase in 5.10, and 
other modules were adapted. But around beta or sometime(before release), some 
refactoring work happened on those APIs. We adjusted them in qtbase, and other 
modules. We have several steps to make sure those thing to be approved in 
CI/COIN. But the order of things gets lost easily when merging the changes up, 
for example to the dev branch.

Here are some suggestions to make those steps more clearer to the people who 
maintain merge and integration.

The changes that are important to be merged up before other changes should have 
a special tag, such as API_CHANGE in the commit message. Then the script used 
to do the merges could stop and/or warn about commits with this tag in the 
message, which would make the merge easier. We can also apply this check into 
the submodule update script.

The situation is also valid for some private API changes(which were used cross 
qt submodules).

About which labels are better to be used for this purpose, please give your 
suggestion and votes. Thanks.

Best Regards,
Liang

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


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

Re: [Development] Nominating Maintainers of qt3dstudio/qt3dstudio

[Adam Treat]

+1

On 11/02/2017 08:11 AM, Lars Knoll wrote:

Hi Pasi,

I fully support this. Qt 3D Studio is a big piece that TQtC just open 
sourced earlier and it’s good to get a defined maintainer structure 
for that project.


Cheers,
Lars

On 2 Nov 2017, at 12:48, Pasi Keränen > wrote:


Hi all,
Those of you who have been following our blog posts or who went to 
QtCon this year know about the new 3D UI design tool and runtime 
combination we received as contribution from NVIDIA earlier this 
year. The tool is now known as Qt 3D Studio and the repositories were 
opened before Qt WS 2017. For more info check 
out:http://blog.qt.io/blog/2017/10/11/qt-3d-studio-source-code-pre-release-snapshots-available/
I’d like to name myself (Pasi Keränen) as the maintainer of Qt 3D 
Studio. I’ve been involved in the project since the early 
negotiations with NVIDIA and handling the receiving of the 
contribution from them. All the way to leading the Qt integration 
work that is still ongoing towards 1.0 release later this month.
As Qt 3D Studio is a large piece of work I’d like to also suggest the 
following persons as maintainers of sub-areas of Qt 3D Studio:
*Soili Väinämö*– Maintainer of UX, ensuring the user experience of 
the tool and runtime develop going onwards. Soili has been doing 
excellent work in both converting the look’n’feel of the application 
to leading UX studies on how to improve the usability of the product 
from end user point of view.
*Tomi Korpipää*– Maintainer of Editor Application code. Tomi has done 
great work in handling the bug flow and converting the look’n’feel to 
more Qt like together with Soili.
*Antti Määttä*– Maintainer of Runtime 1.0 and runtime integration. 
Antti has long history of working with 3D engine code and has done 
excellent work in for example prototyping OpenGL ES 2 support in the 
runtime component of Qt 3D Studio.
*Laszlo Agocs*– Maintainer of Qt 3D based Runtime 2.0. Laszlo has 
been working on the prototype runtime for some time now and is 
already looking in to productizing it.
*Miikka Heikkinen*– Maintainer of installer and viewer application. 
Miikka has been instrumental in getting the installer creation 
implemented and also has been adding new experimental features to the 
viewer like image sequence generation.

Regards,
Pasi Keränen
Team lead of TQtC 3D Team, Oulu
___
Development mailing list
Development@qt-project.org 
http://lists.qt-project.org/mailman/listinfo/development




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


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

Re: [Development] Future of QBS

[Adam Treat]

A few points:

* Unless you are worried about building software with possibly infinite 
dependencies, infinite build products, then a non-Turing complete 
language that just lacks general recursion will be sufficiently 
expressive to meet your needs. In particular, this means those vaguely 
worrying about "sufficiently complex" build systems can rest assured. If 
a strongly normalizing language can suffice as the internal language to 
build a new foundation for ZFC set theory, then I think it'd be 
sufficient to express a deterministic build system.


* Of course you can work around the halting problem so that Qt Creator 
(or some other IDE) doesn't hang should a build never halt. The point of 
non-Turing complete language is that you could ensure this by design.


That said, I think the Turing-completeness question and halting problem 
should be low on the list of priorities for qbs.


Cheers,
Adam

On 10/17/2017 01:16 PM, André Somers wrote:

Exactly. The halting problem can be worked around pragmatically.

... at the price of getting different build results based on CPU speed ...

Your fast desktop CPU crunches through the JS and you get a working
built, while my sucky laptop CPU does not and the build fails for me.

A simple timeout may be a bit too pragmatic, but you could count the
JS instructions executed.


you guys are discussing the locks of a house without walls. when any
type of reasonable limiter needs to kick in, the your build system is
*broken*. that's a fatal error, not just a "different result", and you
need to rethink what you're doing.

Could you clear up what you mean *exactly* here?
Do you mean 1) that any system that provides some kind of timeout (in
terms of wall time or another measure) for evaluation is broken, or that
2) a build setup that runs into such a timeout is broken? That's a big
difference.

_I_ think that doing 1) is reasonable to keep a IDE like Creator
responsive. And of course, you report an error and fail the build when
that happens. A message stating where the issue occured would of course
be very helpfull.

André

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


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

Re: [Development] Future of QBS

[Adam Treat]

Prolog is turing-complete and hence can be used to construct programs 
which do not terminate.


On 10/16/2017 09:42 AM, Konstantin Tokarev wrote:


16.10.2017, 16:17, "Adam Treat" <adam.tr...@qt.io>:

You'll need a strongly normalizing language for that which does not
allow general recursion. Something built on the simply typed lambda
calculus, but with added syntactic sugar would do.

Maybe Prolog would do it too.


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

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


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

Re: [Development] Future of QBS

[Adam Treat]

You'll need a strongly normalizing language for that which does not 
allow general recursion. Something built on the simply typed lambda 
calculus, but with added syntactic sugar would do.


On 10/16/2017 09:08 AM, Ulf Hermann wrote:

I have no real experience with Meson, but at least it has following advantages:

* Its language is typed(!), has native support for arrays(!), and 
functions/methods have
first-class return values(!)
* Its language has native support for properties, with syntax that really looks 
like
properties in another languages
* It is target-oriented from the start and is not so burdened by legacy ways of 
doing
things wrong, which plague old CMake projects and confuse newcomers
* It is written in scripting language, so it's easier to add (and possibly 
distribute) new
functionality without getting it through upstream hands first.

That said, I totally dislike the idea of inventing restricted DSL language for 
build system
instead of using general purpose language (like e.g. in QBS or Premake).

You could also argue that build systems should not use turing complete 
languages, so that other tools can get an idea of what they're doing without 
exercising the halting problem. However, apparently Meson fails at that, like 
so many others.

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


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

Re: [Development] Speeding up the review process (was: PostgreSQL cross compile for Pi)

[Adam Treat]

+1

I also really appreciate when a reviewer is up front about the steps 
necessary to get the patch over the finish line. And if you are just 
doing a drive-by review pointing out all the mistakes, but not willing 
to +2 in the end then please state that up front as well. To be clear, 
I'm not against drive-by reviews where the reviewers never intend to +2 
in the end (as they can still help me improve my code!!), but I just 
would like them to be up front about this.


Cheers,
Adam

On 10/13/2017 10:56 AM, Thiago Macieira wrote:

On Friday, 13 October 2017 04:04:46 PDT Viktor Engelmann wrote:

  5. Set a deadline for criticism on the general approach to a change.
 Too often I have had the situation that I uploaded a patch, then we
 debated the qdoc entries, variable names, method names, etc FOR
 MONTHS - and when I thought we were finally wrapping up and I could
 soon submit it, someone else chimes in and says "this should be done
 completely differently". Even if the person is right - they should
 have said that months earlier - before I wasted all that valuable
 time on variable names, compliance with qdoc guidelines, etc.
 In earlier discussions I have been told that such a deadline would
 have to be long, because someone who might have an opinion might be
 on vacation. IMHO, this doesn't count, because a) you can still make
 an exception to the rule in such a situation and b) by that logic
 you should never approve anything, because we also might hire a new
 employee in 10 years who might have an opinion.

I urge all reviewers to adopt the three-phase review process outlined in Sarah
Sharp's blog:

http://sarah.thesharps.us/2014/09/01/the-gentle-art-of-patch-review/

The only problem with this process is that different reviewers will reach
different stages at different times. So some of them may already have finished
the review of the concept and may be already providing criticism on the
implementation, while others are still not convinced of the concept.

Therefore, I add this extra advice on top of the blog:

When you're a reviewer in a change with multiple other reviewers, try to keep
pace with the other reviewers and not race ahead. If it's not evident where
the other reviewers are, communication is good. Post something like

"Thank you for your change, I like the idea and I think you implemented it
properly. I have some comments on your coding style, but we'll discuss that
when other reviewers have had a chance to review your implementation too."



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

Re: [Development] Should QFileSystemWatcher be thread-safe? (Qt 5.8.0)

[Adam Treat]

Simon just gave a talk about signals and slots on different threads and 
the internals of how Qt handles this at CppCon in Seattle yesterday. I 
would suggest you have a look at the video of his presentation when it 
comes out. You could also look at the documentation: 
http://doc.qt.io/qt-5/threads-qobject.html with particular attention to 
"Signals and Slots Across Threads"


On 09/30/2017 10:24 AM, René J. V. Bertin wrote:

Konrad Rosenbaum wrote:


Apart from this I'd suspect you will still get the SEGV if you do not block
- even if the frequency changes.

As in when emitting the signal too frequently from multiple threads?

For my personal education, what happens behind the scenes when a signal is sent
from one thread to a slot in a different thread? Can I assume there's some kind
of fifo that ensures signals are delivered in order of being sent and such that
producer and consumer don't try to modify (access) the queue concurrently?

R.

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


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

Re: [Development] Let's please drop MSVC 2013 for 5.10

[Adam Treat]

On 06/23/2017 03:23 PM, Marc Mutz wrote:

[forgot to CC list]

On 2017-06-23 19:50, Thiago Macieira wrote:

On Friday, 23 June 2017 09:17:55 PDT Marc Mutz wrote:

The above argument makes no sense to me. What value does quoting
download numbers for 5.9, an LTS, have, to argue about dropping the
compiler from 5.10. Ever since we provide LTSs (yes, once), we drop
compilers in the version _after_ the LTS, which is kind of the natural
point to drop stuff.


The point is that in June 2017, 30% of the Windows downloads were for 
MSVC

2013. it doesn't matter that this is an LTS release or not: way too many
people are using that compiler. We need to "wean" them off 2013, so I'm
starting a note in the 5.9.1 changelog that it will be gone in 5.11 
(one year

advance notice):


We didn't "wean people off" 2012, either. And how can we decide to 
drop 2013 in 5.11 if we don't know what the download numbers will be, 
then, yet? Who's crystal ball makes such decisions possible?


Now you favor using retrospective downloads as sole criterion? You only 
want to drop support when downloads go below a certain threshold?


Or is this your attempt at a reductio ad absurdum argument that using 
downloads to inform is only legit when used retrospectively as sole 
criterion?

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

Re: [Development] syncqt.pl in C++

[Adam Treat]

On 03/07/2017 03:54 PM, Thiago Macieira wrote:

Same here, though I have also to concede that breaking the status quo (to
quote Jake's tweet) is sometimes a good idea. Teambuilder -- to name another
Trolltech project that had nothing to do with qt -- was a couple of orders of
magnitude better than the tools that existed at the time (distcc). Icecream/
icecc came about only because TB wasn't open source, but every now and then I
miss TB2 features that icecc doesn't have. TB3 would have been even better.

Maybe qbs will be another such leapfrog. I can't fault TQtC for trying.


Speaking of distributed compilers... if QBS had built-in 
icecream/TeamBuilder like functionality I would *love* this. It could 
even bundle the tarball itself since it has the complete recipe for all 
the tools necessary, the translation unit and everything in addition to 
create the object file.


That'd be one compelling feature for me.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development