Re: [Development] Platform / compiler support

On Tuesday 8. November 2011 14.20.35 ext Atlant Schmidt wrote: Thiago: Configure-time tests are very hard to write for Qt. Just compile something that is dependent upon the compiler features. If TestForVariadcMacros.cpp fails to compile, the user will probably figure it out! ;-)

[Development] [API review] QMetaType::TypeFlags

Hi, We are about to introduce a new function and an enum in QMetaType class: class QMetatype { ... enum TypeFlag { NeedsConstruction = 0x1, NeedsDestruction = 0x2, MovableType = 0x4 }; Q_DECLARE_FLAGS(TypeFlags, TypeFlag) ... static TypeFlags

Re: [Development] Use make before you push and stage

On Wednesday 25. January 2012 09.32.38 ext bradley.hug...@nokia.com wrote: Yesterday was a bit of a frustrating day. I had to stage a simple .pro-file change of mine 8, eight, times before it finally went in. All of the breakages throughout the day where build breakages. Many of them were in

Re: [Development] Use make before you push and stage

On Wednesday 25. January 2012 20.14.41 ext marius.storm-ol...@nokia.com wrote: On 1/25/12 11:32 AM, ext morten.sor...@nokia.commailto:morten.sor...@nokia.com morten.sor...@nokia.commailto:morten.sor...@nokia.com wrote: On Jan 25, 2012, at 10:47 AM, ext

Re: [Development] Tests, Shadow-Build and Cross-Compilation

On Sunday 29. January 2012 21.21.12 ext Olivier Goffart wrote: On Sunday 29 January 2012 21:13:25 Holger Hans Peter Freyther wrote: Hi all, I finally got around to play with my personal jenkins[1] setup again, specially to learn (and be kind of an example on how a non Tier1 platform

Re: [Development] Status of ActiveQt module?

On Wednesday 1. February 2012 10.36.35 ext Kent Hansen wrote: Den 01. feb. 2012 09:47, skrev ext Olivier Goffart: Facts: 1) QMetaObjectBuilder is private, its API may still change from minor version to minor version That's fine. It's still better (lower maintenance) than having

Re: [Development] Status of ActiveQt module?

On Wednesday 1. February 2012 12.48.07 ext Robin Burchell wrote: 2012/2/1 Jedrzej Nowacki jedrzej.nowa...@nokia.com: Yes, and by updating QMetaObjectBuilder we will update data generated by ActiveQt. ActiveQt would use the newest meta object version (faster tested). As (I think

Re: [Development] kdelibs partially ported to Qt5

On Tuesday 7. February 2012 23.53.32 ext Stephen Kelly wrote: Hi, These issues didn't get any attention, so I'm bumping them: On Thursday, February 02, 2012 22:30:52 Stephen Kelly wrote: One is the ctor of QTabletEvent, which has been changed. A backward compatible deprecated ctor might

[Development] QMetaTypeId and QMetaTypeId2

Hi, Does anybody know why we have separation between QMetaTypeId and QMetaTypeId2 classes? QMetaTypeId2 delegates all operations to QMetaTypeId by default and qMetaTypeId() function is calling QMetaTypeId2. To make it more complex Q_DECLARE_METATYPE is specializing QMetaTypeId but

Re: [Development] Meaning of Q_PRIMITIVE_TYPE?

On Wednesday 28. March 2012 15.37.46 ext Marc Mutz wrote: Hi, Over at http://codereview.qt-project.org/21518, we're discussing whether QUuid is Q_PRIMITIVE_TYPE or only Q_MOVABLE_TYPE. The documentation of Q_DECLARE_TYPEINFO says Q_PRIMITIVE_TYPE means the type is a POD, without

Re: [Development] Meaning of Q_PRIMITIVE_TYPE?

On Friday 30. March 2012 13.54.06 ext Marc Mutz wrote: On Friday March 30 2012, Jedrzej Nowacki wrote: On Wednesday 28. March 2012 15.37.46 ext Marc Mutz wrote: Hi, Over at http://codereview.qt-project.org/21518, we're discussing whether QUuid is Q_PRIMITIVE_TYPE or only

Re: [Development] Nominating Peter Varga for approver status

On Wednesday 23. May 2012 09.02.00 ext Simon Hausmann wrote: Hi, I would like to nominate Peter for approver status. As part of the team in the University of Szeged he has completed the past few rebases of V8 in the qtjsbackend module, a task that is anything but easy, with a fast moving

Re: [Development] QtScript vs Qml/QJsEngine ?

On Wednesday 30. May 2012 15.23.49 ext Diego Iastrubni wrote: On Wed, May 30, 2012 at 4:11 PM, Olivier Goffart oliv...@woboq.com wrote: On Saturday 26 May 2012 12:51:23 Stephen Kelly wrote: Hi, There is a discussion on a kde list touching on whether there is a replacement for

Re: [Development] About pcre in qt5

On Wednesday 6. June 2012 20.02.16 ext Brett Stottlemyer wrote: I'm hitting the same issue the QT_NO_CURSOR. If I don't compile with this flag, apps crash because the cursor isn't built onto the device. QCursor has no constructor when compiled with QT_NO_CURSOR, but the QMetatype seems to

[Development] Possible binary compatibility problem in a future Qt version

Hi, Qt meta-type system is assuming that type information is constant and consistent. It make sense because in C++ a type trait can not be changed during execution of an application. We agreed that unregistering of a type is a bad idea and that updating a type data can cause malfunction in

Re: [Development] Possible binary compatibility problem in a future Qt version

On Friday 8. June 2012 12.31.50 ext Thiago Macieira wrote: On sexta-feira, 8 de junho de 2012 10.31.31, Jedrzej Nowacki wrote: Qt meta-type system is assuming that type information is constant and consistent. It make sense because in C++ a type trait can not be changed during execution

Re: [Development] Container refactor update

On Wednesday 20. June 2012 11.25.28 ext Peter Kümmel wrote: On 20.06.2012 11:09, Olivier Goffart wrote: static const char qt_meta_stringdata_Fooint[] = { Fooint\0\0t\0asignal(int)\0 }; That's because you are looking at Qt4. In Qt5 it is could be something more like

Re: [Development] QtCS: Javascript backend session

That was a nice chat, but a bit unrelated to a JavaScript backend :-) Cheers, Jędrek On Saturday 30. June 2012 15.04.27 ext Dan Leinir Turthra Jensen wrote: Two people did - myself and another guy whose name i unfortunately have forgotten. So, we sat and had a chat about Gluon's use of

Re: [Development] Q_DECLARE_TYPEINFO and namespaced Qt

On Wednesday 11. July 2012 02.10.28 ext Olivier Goffart wrote: On Tuesday 10 July 2012 18:37:20 Marc Mutz wrote: Hi, as seen on IRC: [18:18:43] ossi|tt thiago: how about we make Q_DECLARE_TYPEINFO automatically use the qt namespace, like Q_DECLARE_METATYPE does? it is massively SIC,

Re: [Development] Nominating Marc Mutz for approver status

On Tuesday 14. August 2012 16.18.53 ext Thiago Macieira wrote: Hello I'd like to nominate Marc Mutz for approver status. He's been around Qt and C++ for a long time, having worked for KDAB for a long time. I actually don't know much of his background, I just remember him being there as an

Re: [Development] Possible binary compatibility problem in a future Qt version

On Wednesday 29. August 2012 14.46.17 ext Olivier Goffart wrote: Reviving old thread because it was discussed on IRC: On Friday 08 June 2012 10:31:31 Jedrzej Nowacki wrote: Hi, What can go wrong then? From nothing to crash, it depends on the flag. For example if the flag

Re: [Development] Proposing reversal of the Math3D qreal-float change

On Wednesday 12. September 2012 09.10.52 ext lars.kn...@nokia.com wrote: On Sep 12, 2012, at 12:27 AM, ext André Pönitz andre.poen...@mathematik.tu- chemnitz.de wrote: On Tue, Sep 11, 2012 at 10:34:50PM +0100, Sean Harmer wrote: On 11/09/2012 13:34, Thiago Macieira wrote: I propose we

Re: [Development] Code coverage statistics online

On Wednesday 26. September 2012 20.06.21 Harri Porten wrote: Feedback of any kind is welcome. Nice! Jędrek ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Updating Serializing Qt Data Types documentation

On Tuesday 23. October 2012 19.34.46 Harri Porten wrote: On Tue, 23 Oct 2012, Mitch Curtis wrote: After https://codereview.qt-project.org/#change,37988, the Serializing Qt Data Types page lists the QDataStream version as 13. I thought it'd be a good idea to ask everyone who is interested to

Re: [Development] The final mile

On Monday 19. November 2012 21.09.35 Knoll Lars wrote: The package creation time is currently being addressed, and hopefully we'll soon be able to get that time down to around 2-3 hours (from 7-8 currently). In addition, I'd like to ask anybody to be careful with changes that might affect

Re: [Development] Comparing two reals in Qt code

On Friday 30. November 2012 09.23.32 Samuel Rødal wrote: Yep, having something similar to AlmostEqualUlpsAndAbs() would be great. I've had some ideas of making qFuzzyCompare work that way in the past, but gave them up due to not wanting to risk subtly breaking a lot of existing code.

[Development] Nominating Mitch Curtis for approver

I would like to propose Mitch Curtis for approver status. https://codereview.qt-project.org/#q,owner:+mitch,n,z https://codereview.qt-project.org/#dashboard,1001967 Mitch is working in the Digia Oslo office. In last few months he contributed more then 100 patches in different areas; mainly in

Re: [Development] Nominating Mitch Curtis for approver

On Friday 14. December 2012 11.17.14 Jedrzej Nowacki wrote: 14 days passed and there was no objections. Congratulations Mitch! Oops it seems that It should be 15 working days. So not yet, I will have set an alarm clock again... Sorry for the noise. http://qt-project.org/wiki

Re: [Development] Nominating Mitch Curtis for approver

On Friday 14. December 2012 12.05.43 Jedrzej Nowacki wrote: On Friday 14. December 2012 11.17.14 Jedrzej Nowacki wrote: 14 days passed and there was no objections. Congratulations Mitch! Oops it seems that It should be 15 working days. So not yet, I will have set an alarm clock again

Re: [Development] [Interest] qRegisterMetaTypeQListQSslError and type flags

On Wednesday 2. January 2013 17.15.11 Thiago Macieira wrote: On quarta-feira, 2 de janeiro de 2013 16.43.27, Jan Kundrát wrote: QMetaType::registerType: Binary compatibility break -- Type flags for type 'QListQSslError' [1062] don't match. Previously registered TypeFlags(0x7), now

Re: [Development] [Interest] Re: qRegisterMetaTypeQListQSslError and type flags

On Thursday 3. January 2013 10.22.15 Jan Kundrát wrote: On Thursday, 3 January 2013 08:48:58 CEST, Jedrzej Nowacki wrote: It is an ODR violation detection: https://codereview.qt-project.org/#change,43812 Well, the commit message says that without that change, it's possible to get

Re: [Development] ChangeLogs

On Thursday 17. January 2013 18.25.29 Oswald Buddenhagen wrote: On Thu, Jan 17, 2013 at 04:05:40PM +0100, Oswald Buddenhagen wrote: two more approaches have been previously proposed: hjk suggested yet another approach: use gerrit itself to collect the changelog entries. after some thinking, i

Re: [Development] Nominating Iikka Eklund as approver

On Thursday 24. January 2013 14.49.33 Oswald Buddenhagen wrote: I think it's reasonable to expect that people exercise their approver rights with care, and only use it were appropriate. one would think so. but we did already see things go wrong because approvers made assumptions about

Re: [Development] abandoning stale changes on gerrit

On Tuesday 29. January 2013 13.05.52 Oswald Buddenhagen wrote: moin *, 5.0 is out and the 5.1 feature freeze isn't that far off any more. seems like the best time for some serious house cleaning. therefore i'd like to urge everyone to give their pending changes which haven't seen activity

Re: [Development] abandoning stale changes on gerrit

On Wednesday 30. January 2013 12.20.18 Oswald Buddenhagen wrote: On Wed, Jan 30, 2013 at 08:58:32AM +0100, Jedrzej Nowacki wrote: Please don't do it. My dashboard contains patches, that I'm interested in. It is a kind of knowledge storage, with already signed CLA. I understand that a big

Re: [Development] abandoning stale changes on gerrit

On Friday 1. February 2013 14.34.26 Oswald Buddenhagen wrote: But if we automate this the timeout period needs to be long enough. 2-3 months is certainly too short, we need to be conservative with these kinds of automatisms. A year sounds more reasonable. i don't think this makes

Re: [Development] Interesting CI failure: Fwd: Change in qt/qt3d[5.7]: Entity: add simple method to check for components

As far I remember it is our QTestlib trying hard to disconnect from attached debugger session on OSX. You got it because something crashed. Not related to CI :-) Cheers, Jędrek From: Development on

Re: [Development] Should qMetaTypeId() == qMetaTypeId()?

I love to be proven wrong, but this time I would not call it easy [?] Try this: struct F{}; Q_DECLARE_METATYPE(F*); Q_DECLARE_METATYPE(const F*); Q_DECLARE_METATYPE(F); // Q_DECLARE_METATYPE(const F); doesn't compile, that is a bug! class O : public QObject { Q_OBJECT signals: void

Re: [Development] Module maintainers: action required (Coin migrates from sync.profile to .gitmodules on 28.09.2016)

Good news everyone! The deployment was success and we can wait for fireworks. I'm sure there will be some. So if something doesn't compile now, because of an invalid dependency look to .gitmodules in the right qt5 branch and fix it. Integrations may fail also because of invalid intermodule

Re: [Development] Removal of some of the blacklisted (non-working) autotests?

ard Welbourne Sent: Wednesday, November 9, 2016 11:05:24 AM To: Jedrzej Nowacki Cc: development@qt-project.org Subject: Re: [Development] Removal of some of the blacklisted (non-working) autotests? Jedrzej Nowacki said: > As you wrote, in the first iteration of the functionality I would go > fo

Re: [Development] Removal of some of the blacklisted (non-working) autotests?

be a make target. So everyone could just type: make stress-test in a test folder and after 10 min get the result. Cheers, Jędrek From: Edward Welbourne Sent: Friday, November 4, 2016 9:36 AM To: Jedrzej Nowacki Cc: development@qt-project.org Subject: Re

[Development] Coin update

Hi, We need to update the Coin server, so the service will be interrupted for a while today. Sorry for the short notice. Cheers, Jędrek ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development

[Development] Coin news

Good news everyone! Changing Coin to test changes against Qt5 instead of the latest version of all modules reduced load on the CI significantly and now the build queue is sane even in rush hours (reaching around ~250 items instead of ~1700). I hope every one feels that integrations are

Re: [Development] Coin update

). It can take 2-3 hours. Sorry for the inconvenience. Cheers, Jędrek From: Development <development-bounces+jedrzej.nowacki=qt...@qt-project.org> on behalf of Jedrzej Nowacki <jedrzej.nowa...@qt.io> Sent: Tuesday, October 25, 2016 9:26:02 AM To:

Re: [Development] macOS CI node segfault

As Thiago said. Moc is crashing on OSX for an unknown reason. It is unlikely to be RAM problem, because we would see much wider distribution of crashes (related bug report: https://bugreports.qt.io/browse/QTQAINFRA-990). Regarding overwriting logs, it is Coin bug. For some reason we naively

Re: [Development] macOS CI node segfault

Yes, it is possible, but that would be a manual work. From that perspective I would prefer to focus on automatic uploading core dumps. Fredrik volunteered to look into that (thanks!) Cheers, Jędrek From: Development

Re: [Development] macOS CI node segfault

Bug report for it doesn't exist it is something hanging in back of our heads for months, but feel free to fill the form. Cheers, Jędrek From: Sean Harmer <s...@theharmers.co.uk> Sent: Monday, October 10, 2016 9:11 PM To: Jedrzej Nowacki; developm

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

On piątek, 13 października 2017 13:04:46 CEST Viktor Engelmann wrote: > On the [Interest] mailing list there was a discussion about the > review-process taking to long and we also had multiple discussions about > that at the world summit. I have complained about this myself, so I > would like to

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

If you do like that then you are doing it wrong. Review process is _not_ based on a name / company / sun activity. It is based on the change content. Even best people do mistakes. Cheers, Jędrek On piątek, 13 października 2017 15:48:51 CEST Viktor Engelmann wrote: > I am thinking about the

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

Please, do not jump immediately to a conclusion. It was Viktor's proposal which does not represent "TQC administration" whatever it is. Qt-project has own rules and it is self-governmented. Just to be fair, you could also notice my answer to the proposal: > I do not agree. An employer name does

Re: [Development] Adding Qt CoAP

On Monday, September 4, 2017 11:58:13 AM CEST Thiago Macieira wrote: > > True, but we can re-evaluate if it is not working, modularization is > > harder > > in general as it requires some code changes. Regarding the "two weeks" > > delay, it is mostly a social problem, as we can not agree on how

Re: [Development] Adding Qt CoAP

On Monday, September 4, 2017 9:14:37 AM CEST Thiago Macieira wrote: > On Saturday, 2 September 2017 16:54:03 -03 Jędrzej Nowacki wrote: > > On piątek, 1 września 2017 08:38:19 CEST Thiago Macieira wrote: > > > I'm also wondering if we shouldn't have a bigger repo for IoT-related > > > things,

[Development] Qt with sanitizers

Hi, I made an experiment to see if we should enable sanitizers in CI, by default. Essentially, how much we would slow down integrations and what would be the tests pass rate. Short answer is that, currently, it is not an option, but I produced some data, if someone is interested, please keep

Re: [Development] QtCS 2017 QtCore sessions

On wtorek, 17 października 2017 17:28:54 CEST Marc Mutz wrote: > > (...) > > Discussion not finished > > I certainly hope so, because the above does not make any sense. See my > talk at QtWS. Returning QStringView is not different from c.begin() or > str.data(). You need to document the lifetime

Re: [Development] Continuous Integration issues - Coin temporarily down

On Wednesday, November 1, 2017 8:50:06 AM CET Jedrzej Nowacki wrote: > On Tuesday, October 31, 2017 10:11:22 PM CET Frederik Gladhorn wrote: > > Hi all, > > > > we've had a bunch of unfortunate small things piling up, so sadly Coin is > > down right now. I expe

Re: [Development] Continuous Integration issues - Coin temporarily down

On Wednesday, November 1, 2017 10:16:53 AM CET Jedrzej Nowacki wrote: > On Wednesday, November 1, 2017 8:50:06 AM CET Jedrzej Nowacki wrote: > > On Tuesday, October 31, 2017 10:11:22 PM CET Frederik Gladhorn wrote: > > > Hi all, > > > > > > we've had a bunch o

Re: [Development] Continuous Integration issues - Coin temporarily down

On Tuesday, October 31, 2017 10:11:22 PM CET Frederik Gladhorn wrote: > Hi all, > > we've had a bunch of unfortunate small things piling up, so sadly Coin is > down right now. I expect it to be up tomorrow (so in roughly 10 hours from > now) assuming everything now goes smooth. > Small update.

Re: [Development] Continuous Integration issues - Coin temporarily down

conditions it is not easy. Cheers, Jędrek From: Development <development-bounces+jedrzej.nowacki=qt...@qt-project.org> on behalf of Jedrzej Nowacki <jedrzej.nowa...@qt.io> Sent: Wednesday, November 1, 2017 11:19 AM To: development@qt-project.org

Re: [Development] Continuous Integration issues - Coin temporarily down

On Wednesday, November 1, 2017 2:59:22 PM CET Jedrzej Nowacki wrote: > Hi, > > Yet another update. We narrowed down the IO issue. The network update from > 1G to 10G, mentioned before, brought compellent into the picture and that > one didn't want to cooperate nicely with our btr

Re: [Development] Dropping of MSVC 2013

Hi, We really should think about some more or less automatic policy about supported platforms. Discussing that on each release is not great nor for us, nor for our users. It takes time, to discuss it. I guess that from outside it is looking as a complete chaos, especially in context of

Re: [Development] Continuous Integration issues - Coin temporarily down

On Thursday, November 2, 2017 9:32:10 AM CET Jedrzej Nowacki wrote: > Everything should be functional today. Have fun. > > Cheers, > Jędrek Well, almost, 5.9 is blocked because of a bug in provisioning script (https:// codereview.qt-project.org/#/c/209874/). Let's hope tha

Re: [Development] Continuous Integration issues - Coin temporarily down

On Thursday, November 2, 2017 11:28:22 AM CET Jedrzej Nowacki wrote: > Well, almost, 5.9 is blocked because of a bug in provisioning script > (https:// codereview.qt-project.org/#/c/209874/). Let's hope that is the > end of the series of failures that we had for the last days. &g

Re: [Development] QTBUG-43096 - QML instantiation performance decadence

On Saturday, May 26, 2018 2:05:38 PM CEST Simon Hausmann wrote: > Jędrzej had a beautiful proof of concept at some point for QObject to > combine the object and d-pointer allocation into one. Old times :-) For completeness: https://codereview.qt-project.org/#/q/status:deferred

Re: [Development] Qt 6 buildsystem support requirements

On Tuesday, July 31, 2018 8:15:50 PM CEST Ville Voutilainen wrote: > On 31 July 2018 at 20:49, Thiago Macieira wrote: > > I know CMake meets these requirements, but it has other problems and the > > fact that it currently does not build Qt. On that front, qbs is ahead. > > But qbs has a shorter

Re: [Development] Metatype system in Qt6

Dnia poniedziałek, 29 października 2018 18:46:18 CET Olivier Goffart pisze: > On 10/29/18 5:39 PM, Jedrzej Nowacki wrote: > > Hi everyone! > > > >While main heat on the mailing list is taken by topic how to encode > >that we > > > > are nice, f

Re: [Development] Another integer typedef OR how to prepare for 64-bit in Qt 5

On Friday, November 2, 2018 4:42:52 AM CET Thiago Macieira wrote: > We have a lot of API that, for Qt 6, we've already decided to extend to > 64-bit on 64-bit platforms, but keep as decently-sized 32-bit on 32-bit > ones. Smells like qreal, with all problems that it causes... We could reconsider

[Development] Metatype system in Qt6

Hi everyone! While main heat on the mailing list is taken by topic how to encode that we are nice, friendly and respectful to each other, I would like to show some side project that I had. It is a proposal for base of metatype system for Qt6. You can look and comment at it here:

Re: [Development] Another integer typedef OR how to prepare for 64-bit in Qt 5

Dnia piątek, 2 listopada 2018 16:02:55 CET Thiago Macieira pisze: > On Friday, 2 November 2018 06:50:50 PDT Jedrzej Nowacki wrote: > > On Friday, November 2, 2018 4:42:52 AM CET Thiago Macieira wrote: > > > We have a lot of API that, for Qt 6, we've already decided to extend to

Re: [Development] Closing issues automatically with new keyword

On Friday, September 21, 2018 9:07:14 AM CEST Sami Nurmenniemi wrote: > I committed this to 5.11 branch: > https://codereview.qt-project.org/#/c/240566/ > > Now Gerrit Bot marked this as fixed in 5.11.0, which is not correct: > https://bugreports.qt.io/browse/QTBUG-70493 > > I'm not sure if it

Re: [Development] Closing issues automatically with new keyword

On Friday, September 21, 2018 1:02:10 PM CEST Tor Arne Vestbø wrote: > > On 21 Sep 2018, at 12:47, Jedrzej Nowacki wrote: > > > > On Friday, September 21, 2018 9:07:14 AM CEST Sami Nurmenniemi wrote: > > > >> I committed this to 5.11 branch: > >> ht

Re: [Development] Qt6: Adding UTF-8 storage support to QString

Dnia środa, 16 stycznia 2019 21:12:55 CET André Pönitz pisze: > On Tue, Jan 15, 2019 at 10:44:45PM +0100, Allan Sandfeld Jensen wrote: > > On Dienstag, 15. Januar 2019 19:43:57 CET Cristian Adam wrote: > > > Hi, > > > > > > With every Qt release we see how the new release improved over previous >

[Development] Proposal: New branch model

Hi, It is time to rethink our branch model. We are approaching Qt6 development and I'm worried that what we have now, will simply not scale. As you know, our branch model is mainly(*) based on merging from stable up to development branches. In general, it is a very good model, which make

Re: [Development] Use QMetaEnum::keyCount() to initialise array

On Monday, December 31, 2018 2:56:29 PM CET Marco Bubke wrote: > Is it because the meta type information could be created later? What about adding > a constexpr version like: QMetaEnum::compileTimeFromType? Or do we wait for > static reflections? Yes, sometimes, but the fact that the output

Re: [Development] Running AVX2 code in the CI

On Thursday, January 10, 2019 6:32:02 PM CET Thiago Macieira wrote: > Hello > > Commit c8c5ff19de1c34a99b8315e59015d115957b3584[1] was allowed to pass the > CI despite failing tests in a non-blacklisted test. It's fixed in [2] which > is integrating now. > > The reason this was allowed is

Re: [Development] Proposal: New branch model

On Friday, January 25, 2019 11:08:52 AM CET Lars Knoll wrote: > This adds a very small risk that two parallel changes don’t conflict during > the merge/cherry-pick process, but cause a test regression together. To > help with that, we can simply run a regular status check on the repo. If > this

Re: [Development] Proposal: New branch model

On Friday, January 25, 2019 9:25:16 AM CET Simon Hausmann wrote: > I'm somewhat attracted to the proposed model, in conjunction with automation > and by treating Qt6 differently. > > However Allan's last point is what sticks to me most, the load on the CI and > the resulting impact on

Re: [Development] Proposal: New branch model

On Thursday, January 24, 2019 7:46:35 PM CET Sergio Ahumada wrote: > On 24.01.19 14:10, Edward Welbourne wrote: > > Automated cherry-picking implies various complications that we haven't > > fully explored; whereas merges have some well-established reliable > > properties that avoid many of those

Re: [Development] Proposal: New branch model

On Thursday, January 24, 2019 10:29:13 PM CET Ville Voutilainen wrote: > On Thu, 24 Jan 2019 at 20:26, Simon Hausmann wrote: > > I would see the biggest long term impact with the massive amount of cherry > > picks from dev to qt6 over a long period of time. > > > > Git rerere works locally, so

Re: [Development] Proposal: New branch model

On Monday, January 28, 2019 2:38:44 PM CET Robert Loehning wrote: > Am 28.01.2019 um 14:09 schrieb Jedrzej Nowacki: > > > On Friday, January 25, 2019 3:23:36 PM CET Robert Loehning wrote: > > > >>> Testing whether the bug that I’m fixing exists in dev or not is par

Re: [Development] Proposal: New branch model

On Friday, January 25, 2019 2:17:15 PM CET Edward Welbourne wrote: > On 25 Jan 2019, at 10:10, Simon Hausmann mailto:simon.hausm...@qt.io>> wrote: > >> I think it's worthwhile to develop the tooling to automate > >> cherry-picking. That tooling is something that is perhaps best tried > >> on a

Re: [Development] Proposal: New branch model

On Friday, January 25, 2019 3:23:36 PM CET Robert Loehning wrote: > > Testing whether the bug that I’m fixing exists in dev or not is part of > > the drill of fixing bug, isn’t it? Why would you spend time on fixing > > something in 5.12 without checking whether the issue is still present in > >

Re: [Development] Proposal: New branch model

On Thursday, January 24, 2019 3:18:59 PM CET Kari Oikarinen wrote: > On 24.1.2019 16.15, Edward Welbourne wrote: > > > Kari Oikarinen (24 January 2019 15:02) > > > >> The rest of the paragraph talks about a situation where we will have two > >> stable branches alive at the same time. Typically

Re: [Development] Proposal: New branch model

On Friday, January 25, 2019 11:50:55 AM CET Eike Ziller wrote: > Note that this risk exists partially even if fixes are first pushed into dev > and then from dev directly to multiple “stable” branches. > > Fix goes into dev. > Fix is cherry-picked into 5.9 without issues. > Fix is cherry-picked

Re: [Development] Proposal: New branch model

On Thursday, January 24, 2019 2:35:51 PM CET Allan Sandfeld Jensen wrote: > We can't integrate multiple changes to the same branch in parellel. So you > can't start using more resources to speed things up. (9 women to have a > child in 1 month) The only way to speed up CI integration is to be

Re: [Development] Proposal: New branch model

On Friday, January 25, 2019 1:30:52 PM CET Shawn Rutledge wrote: > > On 25 Jan 2019, at 09:43, Martin Smith wrote: > > > > > >> It is the absolute exception that a change goes into qtbase on first > >> attempt. > > > > > But many rejections have nothing to do with any change at all. I often >

Re: [Development] QVariant container API

On Monday, April 1, 2019 11:09:27 AM CEST Vasily Pupkin wrote: > Hi. > > I would like to submit a patch. Since it is probably going to break binary > compatibility and is mostly about coding conventions, I would like to have > some feedback before investing time. Great! > The general idea is to

Re: [Development] CMake Workshop Summary

On Friday, February 22, 2019 7:18:36 AM CET Thiago Macieira wrote: > But do note that our parallelism isn't that bad right now. It is not bad, but it is not great either :-). For example one needs to _link_ QtCore before compilation on other things can be started, it is quite visible on an

Re: [Development] On deprecating functions

On Tuesday, March 5, 2019 8:14:00 AM CET Lars Knoll wrote: > One solution I thought about is to replace the QT_DEPRECATED(_X) macros with > something that also contains the version (similar to QT_DEPRECATED_SINCE). > Then the user could define how current he wants to be, and we could set a >

Re: [Development] Continuous Integration for 3rd party projects using Qt

On Tuesday, March 19, 2019 7:55:53 AM CET Uwe Rathmann wrote: > Hi all, > > in the end all advice goes into the direction of using one of the > standard services in combination with using my own brain when working on > the code. > > Unfortunately nobody pointed out a realistic way how a 3rd

Re: [Development] CMake branch

On Friday, March 22, 2019 9:58:33 AM CET Simon Hausmann wrote: > Am 21.03.19 um 15:54 schrieb Tobias Hunger: > > > My idea was to ask for merging wip/cmake after > > https://bugreports.qt.io/browse/QTBUG-73925 (aka. "milestone 1"). At that > > point the branch would be in a state where people

[Development] Allow to do parallel integration (was: Proposal: New branch model)

On Friday, January 25, 2019 11:08:52 AM CET Lars Knoll wrote: > To me this means we need to seriously rethink that part of our CI system, > and ideally test changes (or patch series) individually and in parallel. So > maybe we should adjust our CI system that way: > > * test changes (or patch

Re: [Development] Allow to do parallel integration (was: Proposal: New branch model)

On Wednesday, January 30, 2019 10:41:02 AM CET Jedrzej Nowacki wrote: > Cheap (a.k.a reasonably fast to implement) proposal: > - Stage button would create a stage branch as currently (through cherry-pick > on top of target branch) > - 3-5 minutes old stage branch would changed t

Re: [Development] Allow to do parallel integration (was: Proposal: New branch model)

On Wednesday, January 30, 2019 11:19:07 AM CET Edward Welbourne wrote: > > Mårten pointed out that we can check for conflicts up front. Not only > > against HEAD of the target branch, but also against all build branches. > > That is even nicer as there is no need to start a job that would likely >

Re: [Development] Allow to do parallel integration (was: Proposal: New branch model)

On Wednesday, January 30, 2019 11:48:40 AM CET Allan Jensen wrote: > On Wednesday, 30 January 2019 11:19:07 CET Edward Welbourne wrote: > > Jedrzej Nowacki (30 January 2019 11:08) > > > > > Mårten pointed out that we can check for conflicts up front. Not only > >

Re: [Development] Allow to do parallel integration (was: Proposal: New branch model)

On Wednesday, January 30, 2019 1:55:41 PM CET Allan Jensen wrote: > On Wednesday, 30 January 2019 13:38:46 CET Jedrzej Nowacki wrote: > > On Wednesday, January 30, 2019 11:48:40 AM CET Allan Jensen wrote: > > > On Wednesday, 30 January 2019 11:19:07 CET Edward Welbourne wrot

Re: [Development] Proposal: New branch model

Dnia czwartek, 24 stycznia 2019 09:08:29 CET Liang Qi pisze: > My concern is about "cherry-pick" a series of changes for a big > feature, especially during the period to have "dev" branches for both > 5 and 6. I don't have solution for this issue yet. My assumption is that bot would cherry-pick

Re: [Development] Proposal: New branch model

Dnia środa, 23 stycznia 2019 17:37:57 CET Konstantin Tokarev pisze: > Note that backporting changes from dev should also be a full-time job for > someone, otherwise amount of fixes going to stable branches will likely > drop Yes, depending who you ask it is good or bad. It means that only fixes

Re: [Development] Proposal: New branch model

Dnia czwartek, 24 stycznia 2019 11:24:41 CET Vitaly Fanaskov pisze: > > Why not X instead? > > -- > > > > - GitFlow, GitHub <= both are based on feature branches, that doesn't work > > well with gerrit. > > So, the only problem here is gerrit (aside from personal preferences and

Re: [Development] Proposal: New branch model

Dnia środa, 23 stycznia 2019 22:04:16 CET Allan Sandfeld Jensen pisze: > On Mittwoch, 23. Januar 2019 16:51:10 CET Jedrzej Nowacki wrote: > > Proposal in short: let's use cherry-pick mode everywhere. > > > > All(**) changes would go to dev. From which they w

Re: [Development] Proposal: New branch model

Dnia środa, 23 stycznia 2019 18:49:46 CET Thiago Macieira pisze: > On Wednesday, 23 January 2019 08:37:57 PST Konstantin Tokarev wrote: > > > Disadvantages: > > > - git history would be a bit wilder, "git branch --contains" would not > > > work > > > - commit messages in some branches

  1   2   >