From h4nn35.work at gmail.com Thu Feb 1 09:57:56 2018 From: h4nn35.work at gmail.com (Johannes Pointner) Date: Thu, 1 Feb 2018 09:57:56 +0100 Subject: [Development] libinput: Export the number of touches Message-ID: Hello, after a discussion on the wayland maillinglist this bug was created: https://bugs.freedesktop.org/show_bug.cgi?id=104867 Maybe it is of some interest for Qt too. Regards, Hannes From jani.heikkinen at qt.io Thu Feb 1 11:21:54 2018 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Thu, 1 Feb 2018 10:21:54 +0000 Subject: [Development] Qt branches & proposal how to continue with those In-Reply-To: <45E55A9F-D3E3-4FC4-B239-74E2BBBA7AFC@qt.io> References: <4137226.H1Wp0KbUjd@tjmaciei-mobl1> <3586F83C-F715-4B4E-BFA1-A24EF62946FA@qt.io> <833e801049d7d35ed1dab558afafd7fb.squirrel@squirrel.six.silmor.de> <45E55A9F-D3E3-4FC4-B239-74E2BBBA7AFC@qt.io> Message-ID: > -----Original Message----- > From: Development [mailto:development-bounces+jani.heikkinen=qt.io at qt- > project.org] On Behalf Of Tuukka Turunen > Sent: tiistai 30. tammikuuta 2018 23.38 > To: Konrad Rosenbaum ; development at qt-project.org > Subject: Re: [Development] Qt branches & proposal how to continue with those > > The item that has received comments both in favor and against is what to do > with 5.10 now. I think that instead of closing 5.10, we could move it to cherry > pick mode, just like Qt 5.9 is. That allows putting the necessary fixes there, but > reduces the amount of needed merges a lot. It also allows to faster get all the > fixes merged up to dev, which is something we have struggled in the past. > > With this approach we have full capability to make Qt 5.10.2 release, if one is > needed. We also continue to make Qt 5.9.x patch releases. We would have two > branches open for direct submission: 5.11 and dev, and for each commit the > lowest applicable branch can be chosen. For all such important fixes that need > to be in Qt 5.9.x LTS releases or in the 5.10 branch, we use cherry picking. > This is OK for me as well so +1 from my side - Jani From sean.harmer at kdab.com Thu Feb 1 11:44:14 2018 From: sean.harmer at kdab.com (Sean Harmer) Date: Thu, 1 Feb 2018 10:44:14 +0000 Subject: [Development] Qt branches & proposal how to continue with those In-Reply-To: References: <4137226.H1Wp0KbUjd@tjmaciei-mobl1> <3586F83C-F715-4B4E-BFA1-A24EF62946FA@qt.io> <833e801049d7d35ed1dab558afafd7fb.squirrel@squirrel.six.silmor.de> <45E55A9F-D3E3-4FC4-B239-74E2BBBA7AFC@qt.io> Message-ID: -1 from me. How is this any less work than merging, especially with git rerere? Can we please keep 5.9 open until we have at least released 5.11.0? I really don't want to get into a situation where we have bug fixes on 5.9 and 5.11 but not 5.10.2 say. Once 5.10 is properly closed then fine, move to a cherry pick approach for 5.9 but right now, especially for Qt 3D we have some important bug fixes landing on 5.9 than can be merged forward (with the help of git rerere) but for which cherry picking would be more awkward and also risk missing 5.10.2 if there is one. Cheers, Sean On 01/02/2018 10:21, Jani Heikkinen wrote: >> -----Original Message----- >> From: Development [mailto:development-bounces+jani.heikkinen=qt.io at qt- >> project.org] On Behalf Of Tuukka Turunen >> Sent: tiistai 30. tammikuuta 2018 23.38 >> To: Konrad Rosenbaum ; development at qt-project.org >> Subject: Re: [Development] Qt branches & proposal how to continue with those >> >> The item that has received comments both in favor and against is what to do >> with 5.10 now. I think that instead of closing 5.10, we could move it to cherry >> pick mode, just like Qt 5.9 is. That allows putting the necessary fixes there, but >> reduces the amount of needed merges a lot. It also allows to faster get all the >> fixes merged up to dev, which is something we have struggled in the past. >> >> With this approach we have full capability to make Qt 5.10.2 release, if one is >> needed. We also continue to make Qt 5.9.x patch releases. We would have two >> branches open for direct submission: 5.11 and dev, and for each commit the >> lowest applicable branch can be chosen. For all such important fixes that need >> to be in Qt 5.9.x LTS releases or in the 5.10 branch, we use cherry picking. >> > > This is OK for me as well so +1 from my side > > - Jani > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -- Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK KDAB (UK) Ltd, a KDAB Group company Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090 Mobile: +44 (0)7545 140604 KDAB - Qt Experts From oswald.buddenhagen at qt.io Thu Feb 1 12:19:13 2018 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Thu, 1 Feb 2018 12:19:13 +0100 Subject: [Development] Qt branches & proposal how to continue with those In-Reply-To: <45E55A9F-D3E3-4FC4-B239-74E2BBBA7AFC@qt.io> References: <4137226.H1Wp0KbUjd@tjmaciei-mobl1> <3586F83C-F715-4B4E-BFA1-A24EF62946FA@qt.io> <833e801049d7d35ed1dab558afafd7fb.squirrel@squirrel.six.silmor.de> <45E55A9F-D3E3-4FC4-B239-74E2BBBA7AFC@qt.io> Message-ID: <20180201111913.GC14103@troll08> On Tue, Jan 30, 2018 at 09:38:29PM +0000, Tuukka Turunen wrote: > The item that has received comments both in favor and against is what > to do with 5.10 now. I think that instead of closing 5.10, we could > move it to cherry pick mode, just like Qt 5.9 is. That allows putting > the necessary fixes there, but reduces the amount of needed merges a > lot. It also allows to faster get all the fixes merged up to dev, > which is something we have struggled in the past. > that makes no sense at all. firstly, 5.9 is NOT in cherry-pick mode - your own update to quip 5 codifies this status quo. i see no reason to revise that decision *again*. secondly, *nobody* is going to cherry-pick to a branch which *could* _hypothetically_ have another patch release, because that would be an epic waste of resources. thirdly, let me point out that cherry-picking *delays* patch releases, because it implies that a commit must have already integrated into a more current branch before it can hit the release branch (deviating from that principle is just plain stupid), which in the context of our infrastructure makes it a poor choice for recent/active branches. so no, this just isn't an option. From annulen at yandex.ru Thu Feb 1 12:36:16 2018 From: annulen at yandex.ru (Konstantin Tokarev) Date: Thu, 01 Feb 2018 14:36:16 +0300 Subject: [Development] Qt branches & proposal how to continue with those In-Reply-To: <20180201111913.GC14103@troll08> References: <4137226.H1Wp0KbUjd@tjmaciei-mobl1> <3586F83C-F715-4B4E-BFA1-A24EF62946FA@qt.io> <833e801049d7d35ed1dab558afafd7fb.squirrel@squirrel.six.silmor.de> <45E55A9F-D3E3-4FC4-B239-74E2BBBA7AFC@qt.io> <20180201111913.GC14103@troll08> Message-ID: <475241517484976@web4j.yandex.ru> 01.02.2018, 14:19, "Oswald Buddenhagen" : > On Tue, Jan 30, 2018 at 09:38:29PM +0000, Tuukka Turunen wrote: >>  The item that has received comments both in favor and against is what >>  to do with 5.10 now. I think that instead of closing 5.10, we could >>  move it to cherry pick mode, just like Qt 5.9 is. That allows putting >>  the necessary fixes there, but reduces the amount of needed merges a >>  lot. It also allows to faster get all the fixes merged up to dev, >>  which is something we have struggled in the past. > > that makes no sense at all. > firstly, 5.9 is NOT in cherry-pick mode - your own update to quip 5 > codifies this status quo. i see no reason to revise that decision > *again*. > secondly, *nobody* is going to cherry-pick to a branch which *could* > _hypothetically_ have another patch release, because that would be an > epic waste of resources. > thirdly, let me point out that cherry-picking *delays* patch releases, > because it implies that a commit must have already integrated into a > more current branch before it can hit the release branch (deviating from > that principle is just plain stupid), which in the context of our > infrastructure makes it a poor choice for recent/active branches. Only in case when cherry-picked patches are release blockers, otherwise they just don't go in if they miss schedule. I guess the idea behind this proposal is that we improve quality of dev and 5.11 by sacrificing comprehensiveness of 5.6, 5.9, and 5.10. Multi-level merges combined with overall CI instability lead to huge delays for patches to reach dev, as a result people work on stable branches or maintain their own, which in turn leaves us with worse baseline when next releases' branch is started from dev. > > so no, this just isn't an option. > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From tuukka.turunen at qt.io Thu Feb 1 14:35:58 2018 From: tuukka.turunen at qt.io (Tuukka Turunen) Date: Thu, 1 Feb 2018 13:35:58 +0000 Subject: [Development] Qt branches & proposal how to continue with those In-Reply-To: <475241517484976@web4j.yandex.ru> References: <4137226.H1Wp0KbUjd@tjmaciei-mobl1> <3586F83C-F715-4B4E-BFA1-A24EF62946FA@qt.io> <833e801049d7d35ed1dab558afafd7fb.squirrel@squirrel.six.silmor.de> <45E55A9F-D3E3-4FC4-B239-74E2BBBA7AFC@qt.io> <20180201111913.GC14103@troll08> <475241517484976@web4j.yandex.ru> Message-ID: <9ABE2AC4-87A1-4F9F-8543-5DCA73D8B79F@qt.io> Hi, To be clear, the updated QUIP5 (http://code.qt.io/cgit/meta/quips.git/tree/quip-0005.rst) says: "*strict* This period starts when the one after next stable branch is created (for the 5.9 LTS, the one after next is 5.11). Submitting to the LTS branch directly is then no longer possible; changes must be submitted to the stable branch and undergo some testing first before being cherry-picked into the LTS branch." So based on this Qt 5.9 should be in cherry pick mode next week. With previous wording it should have been in cherry pick mode from 2.9.2017 onwards, which was way too soon (hence the change to QUIP5). I think that it is not possible to wait until Qt 5.11.0 is released before going to cherry pick mode for Qt 5.9 LTS and closing (or moving to cherry pick mode) for Qt 5.10. We just do not have enough people and computers to manage all the needed merges in time. I do understand the opinions that it would be nice to have these open longer, but it is not seen feasible by the persons who actually do the work needed for it. Related to LTS releases in general, I believe that strict mode is a good thing. By only cherry picking the important fixes, we reduce the risk of accidentally causing some undesired regressions (in functionality or performance). We do want to continue making more Qt 5.9.x patch level releases, but with slightly reduced pace after Qt 5.9.5 (planned for March). I believe that we can achieve two important items by reducing the amount of merges (Jani's original proposal): 1. Release Qt 5.11 in schedule without a huge stress for the release team at the end 2. Keep dev in good working shape during H1/18, thus paving the way of having a rock solid Qt 5.12 (LTS) in November What about Qt 5.10.2? This of course needs to be addressed after we see how Qt 5.10.1 turns out to be. But provided Qt 5.10.1 is a good release, I would like to put full focus into getting Qt 5.11.0 out quickly and try to release Qt 5.11.1 in June already. Yours, Tuukka On 01/02/2018, 13.36, "Development on behalf of Konstantin Tokarev" wrote: 01.02.2018, 14:19, "Oswald Buddenhagen" : > On Tue, Jan 30, 2018 at 09:38:29PM +0000, Tuukka Turunen wrote: >> The item that has received comments both in favor and against is what >> to do with 5.10 now. I think that instead of closing 5.10, we could >> move it to cherry pick mode, just like Qt 5.9 is. That allows putting >> the necessary fixes there, but reduces the amount of needed merges a >> lot. It also allows to faster get all the fixes merged up to dev, >> which is something we have struggled in the past. > > that makes no sense at all. > firstly, 5.9 is NOT in cherry-pick mode - your own update to quip 5 > codifies this status quo. i see no reason to revise that decision > *again*. > secondly, *nobody* is going to cherry-pick to a branch which *could* > _hypothetically_ have another patch release, because that would be an > epic waste of resources. > thirdly, let me point out that cherry-picking *delays* patch releases, > because it implies that a commit must have already integrated into a > more current branch before it can hit the release branch (deviating from > that principle is just plain stupid), which in the context of our > infrastructure makes it a poor choice for recent/active branches. Only in case when cherry-picked patches are release blockers, otherwise they just don't go in if they miss schedule. I guess the idea behind this proposal is that we improve quality of dev and 5.11 by sacrificing comprehensiveness of 5.6, 5.9, and 5.10. Multi-level merges combined with overall CI instability lead to huge delays for patches to reach dev, as a result people work on stable branches or maintain their own, which in turn leaves us with worse baseline when next releases' branch is started from dev. > > so no, this just isn't an option. > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From oswald.buddenhagen at qt.io Thu Feb 1 15:53:07 2018 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Thu, 1 Feb 2018 15:53:07 +0100 Subject: [Development] Qt branches & proposal how to continue with those In-Reply-To: <9ABE2AC4-87A1-4F9F-8543-5DCA73D8B79F@qt.io> References: <4137226.H1Wp0KbUjd@tjmaciei-mobl1> <3586F83C-F715-4B4E-BFA1-A24EF62946FA@qt.io> <833e801049d7d35ed1dab558afafd7fb.squirrel@squirrel.six.silmor.de> <45E55A9F-D3E3-4FC4-B239-74E2BBBA7AFC@qt.io> <20180201111913.GC14103@troll08> <475241517484976@web4j.yandex.ru> <9ABE2AC4-87A1-4F9F-8543-5DCA73D8B79F@qt.io> Message-ID: <20180201145307.GE14103@troll08> On Thu, Feb 01, 2018 at 02:35:58PM +0100, Tuukka Turunen wrote: > So based on this Qt 5.9 should be in cherry pick mode next week. With > previous wording it should have been in cherry pick mode from 2.9.2017 > onwards, which was way too soon (hence the change to QUIP5). > right. > What about Qt 5.10.2? This of course needs to be addressed after we > see how Qt 5.10.1 turns out to be. But provided Qt 5.10.1 is a good > release, I would like to put full focus into getting Qt 5.11.0 out > quickly and try to release Qt 5.11.1 in June already. > yes, but the point is that we can't change the policy retroactively. if 5.10.2 is an option, then 5.10 needs to stay open as the default target for fixes, and be forward-merged. this leaves us at two merges for a fix to reach dev. the same delay would occurr if we closed 5.10 and continued to merge from 5.9, which is why the discussion which one is more important emerged. this leaves us with three options: 1) - 5.9 goes to cherry-pick mode, essentially now. - 5.10 stays open until 5.11.0 is released. - we should create 5.10.2 before the 5.11.0 release even if we don't intent to actually make a release, just so we have a mergable target branch (to avoid "illegal" 5.10 => 5.11.0 merges or cherry-picks). 2) - we just declare that there won't be 5.10.2 and close 5.10 after 5.10.1. potentially not user-friendly, but we've done it in the past, and while releasing capacity isn't the limiting factor now, forward-merging apparently is. 2a) we continue to forward-merge from 5.9. 2b) 5.9 goes to cherry-pick mode, which cuts out another merge step. note that 5.10 going to cherry-pick mode is specifically not an option, as stated previously. 1) seems most natural to me. From tuukka.turunen at qt.io Thu Feb 1 16:22:01 2018 From: tuukka.turunen at qt.io (Tuukka Turunen) Date: Thu, 1 Feb 2018 15:22:01 +0000 Subject: [Development] Qt branches & proposal how to continue with those In-Reply-To: <20180201145307.GE14103@troll08> References: <4137226.H1Wp0KbUjd@tjmaciei-mobl1> <3586F83C-F715-4B4E-BFA1-A24EF62946FA@qt.io> <833e801049d7d35ed1dab558afafd7fb.squirrel@squirrel.six.silmor.de> <45E55A9F-D3E3-4FC4-B239-74E2BBBA7AFC@qt.io> <20180201111913.GC14103@troll08> <475241517484976@web4j.yandex.ru> <9ABE2AC4-87A1-4F9F-8543-5DCA73D8B79F@qt.io> <20180201145307.GE14103@troll08> Message-ID: Hi, Of those 2a and 2b sound the best to me, however we should be able to make 5.10.2 at least in case needed on top of 5.10.1 with a critical security fix (or similar). I think keeping 5.9 open a bit longer has benefit due to it being an LTS. It adds a bit merge effort, but should be manageable if 5.10 is out of the picture. We should aim to increase stability, as is the target of strict mode. Perhaps we could simple agree to now on push only items that match strict mode criteria to 5.9, rest goes to 5.11 or dev? Move to cherry pick mode for 5.9 a few months later then. Yours, Tuukka On 01/02/2018, 16.53, "Development on behalf of Oswald Buddenhagen" wrote: On Thu, Feb 01, 2018 at 02:35:58PM +0100, Tuukka Turunen wrote: > So based on this Qt 5.9 should be in cherry pick mode next week. With > previous wording it should have been in cherry pick mode from 2.9.2017 > onwards, which was way too soon (hence the change to QUIP5). > right. > What about Qt 5.10.2? This of course needs to be addressed after we > see how Qt 5.10.1 turns out to be. But provided Qt 5.10.1 is a good > release, I would like to put full focus into getting Qt 5.11.0 out > quickly and try to release Qt 5.11.1 in June already. > yes, but the point is that we can't change the policy retroactively. if 5.10.2 is an option, then 5.10 needs to stay open as the default target for fixes, and be forward-merged. this leaves us at two merges for a fix to reach dev. the same delay would occurr if we closed 5.10 and continued to merge from 5.9, which is why the discussion which one is more important emerged. this leaves us with three options: 1) - 5.9 goes to cherry-pick mode, essentially now. - 5.10 stays open until 5.11.0 is released. - we should create 5.10.2 before the 5.11.0 release even if we don't intent to actually make a release, just so we have a mergable target branch (to avoid "illegal" 5.10 => 5.11.0 merges or cherry-picks). 2) - we just declare that there won't be 5.10.2 and close 5.10 after 5.10.1. potentially not user-friendly, but we've done it in the past, and while releasing capacity isn't the limiting factor now, forward-merging apparently is. 2a) we continue to forward-merge from 5.9. 2b) 5.9 goes to cherry-pick mode, which cuts out another merge step. note that 5.10 going to cherry-pick mode is specifically not an option, as stated previously. 1) seems most natural to me. _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From kevin.kofler at chello.at Thu Feb 1 21:21:34 2018 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 01 Feb 2018 21:21:34 +0100 Subject: [Development] Qt branches & proposal how to continue with those References: <4137226.H1Wp0KbUjd@tjmaciei-mobl1> <3586F83C-F715-4B4E-BFA1-A24EF62946FA@qt.io> <833e801049d7d35ed1dab558afafd7fb.squirrel@squirrel.six.silmor.de> <45E55A9F-D3E3-4FC4-B239-74E2BBBA7AFC@qt.io> <20180201111913.GC14103@troll08> <475241517484976@web4j.yandex.ru> <9ABE2AC4-87A1-4F9F-8543-5DCA73D8B79F@qt.io> <20180201145307.GE14103@troll08> Message-ID: Tuukka Turunen wrote: > Of those 2a and 2b sound the best to me, however we should be able to make > 5.10.2 at least in case needed on top of 5.10.1 with a critical security > fix (or similar). You are talking about needing maybe one security fix. I can tell you that it is practically certain that there will be several security fixes needed for QtWebEngine approx. every 6 weeks (at every Chromium release). Kevin Kofler From edward.welbourne at qt.io Fri Feb 2 12:35:11 2018 From: edward.welbourne at qt.io (Edward Welbourne) Date: Fri, 2 Feb 2018 11:35:11 +0000 Subject: [Development] Qt branches & proposal how to continue with those In-Reply-To: References: <4137226.H1Wp0KbUjd@tjmaciei-mobl1> <3586F83C-F715-4B4E-BFA1-A24EF62946FA@qt.io> <833e801049d7d35ed1dab558afafd7fb.squirrel@squirrel.six.silmor.de> <45E55A9F-D3E3-4FC4-B239-74E2BBBA7AFC@qt.io> <20180201111913.GC14103@troll08> <475241517484976@web4j.yandex.ru> <9ABE2AC4-87A1-4F9F-8543-5DCA73D8B79F@qt.io> <20180201145307.GE14103@troll08>, Message-ID: Tuukka Turunen (1 February 2018 16:22) > I think keeping 5.9 open a bit longer has benefit due to it being an > LTS. The benefit looks small, to me. If I have to cherry-pick back to LTS, it's for an important issue; I've just done that for QTBUG-66076 because it got reported against 5.9.4, after I'd fixed it on dev (it made it into 5.10.0). Maybe it's because I can see bugs in code without needing a bug report to lead me to them, but I'm used to this happening - I don't always know, when I'm fixing an issue, whether it's important enough to warrant starting out in 5.9; and I'm conservative enough to not put fixes into LTS unless I positively see a definite need for them (e.g. an actual bug report). Furthermore, a fix cherry-picked back to LTS has the virtue of having seen relatively thorough testing in other branches, reducing the risk of "surprises". Having 5.9 at the start of the merge-chain incurs some hassle for anyone who does end up needing to cherry-pick back to it, and may incur conflicts during merge-up when that's happened; which encourages folk to put changes into 5.9, just to be on the "safe" side (i.e. avoid that hassle), when the fix might not actually be critical enough to belong there - which isn't so good for the "safety" of LTS; every fix incurs a risk of breakage; if that fix wasn't really needed in LTS, then this is needless risk. Furthermore, fixes introduced in 5.9, for merging up to other branches, haven't been as rigorously tested as fixes that have been round the grind in a later branch - which can discover unexpected side-effects, that a fix developed on 5.9 will have introduced in LTS. So you get a little convenience out of keeping 5.9 in the merge chain, which I can see the virtue of up until about the point where 5.10.0 got released, but that convenience comes at the price of added hassle for those whose fixes on other branches turn out to be needed in LTS, plus a bunch of added risk to the stability of LTS. > It adds a bit merge effort, but should be manageable if 5.10 is out of > the picture. We should aim to increase stability, as is the target of > strict mode. Perhaps we could simple agree to now on push only items > that match strict mode criteria to 5.9, rest goes to 5.11 or dev? Move > to cherry pick mode for 5.9 a few months later then. I get twitchy about the merge pattern being 5.9 -> 5.11 -> dev, without passing through 5.10 on the way. It'll lead to folk expecting things to be in 5.10 when they aren't. Once 5.10 is no longer part of the merge chain, 5.9 should be in cherry-pick mode. That change will make folk more aware that their changes to 5.9 aren't getting into a putative 5.10.2, if it ever is needed, so there's a better chance they'll evaluate whether it's needed there and, if it is, cherry-pick it to 5.10 ready for that (or fix it on 5.10 in the first place, if it stays in the merge chain). If we're going to stop merging up from 5.10, after 5.10.1 branches, then we should switch 5.9 to cherry-picking mode at the same time; and allow cherry-picks back to 5.10 for critical issues, targeting a 5.10.2 that we hope we won't need but should be ready to produce if we do. However, see Kevin's point: we *know* we'll have security fixes for qtwebengine; our plan *should* take account of that. Shall 5.11 and 5.11.1 be close enough to 5.10 that those on 5.10 can sensibly be expected to upgrade to them - in which case, why aren't they called 5.10.2 and so on ? - or do we need to plan a 5.10.2 simply for qtwebengine's sake ? Or is it time we genuinely separated qtwebengine's release schedule from the rest of Qt ? Would that even work ? We've upped the tempo of releases: this is, of course, good - but it comes with costs. When I'm fixing a bug, I fix it on dev and wait for it to be reviewed before worrying about which branch it belongs on - because, all too often, the branch I *would* have put it on at the start has been released before anyone reviews what I've changed. So I leave that decision until I know which branch is appropriate *when the fix gets past review* - but that tends to bias me towards putting it on a later branch than it might have belonged on. Pause to consider another model: we close 5.10 transiently, during the life-time of 5.10.1, so that 5.10.1 takes 5.10's place in the merge chain; we re-open 5.10 after 5.10.1 releases, only for critical fixes that would be needed for a 5.10.2 release, if we can't avoid one. When 5.10.1 closes, we'd do a merge from it to 5.10, which would then re-open; then we merge up from there. We would seldom need to merge up from 5.10, reducing its contribution to the merge chain; and taking it out of the chain during 5.10.1's stabilisation period makes sense. As long as we put 5.9 into cherry-pick mode during that, we'll have a merge chain that looks like: 5.10.1 -> 5.11.0 -> 5.11 -> dev and changes to 5.10 -> 5.11.0 -> 5.11 -> dev before reducing to 5.10 -> 5.11 -> dev with the 5.10 -> steps always being low-bandwidth. The problem right now is that we're adding stabilisation branches to 5.9 -> 5.10 -> 5.11 -> dev A three-step flow is only really tolerable transiently (e.g. during the lifetimes of stabilisation branches); we need to cut 5.9 loose to keep the merge chain manageable. If we also lock x.y during the stabilisation of x.y.z for any z > 0, to take x.y out of the merge chain, we can keep the chain short aside from transiently during releases. We then have a normal two-step chain (5.10 -> 5.11 -> dev) , to which we sometimes add a third step for a first release (5.10 -> 5.11.0 -> 5.11 -> dev) and in which we sometimes replace a released major-version branch with a stabilisation branch off it for its next release (x.y.z for z > 0 replacing x.y in the chain). It's only every three-step during a first release stabilisation phase; it's never more; and the first step is usually low-bandwidth. Both 5.10.1 and 5.11.0 are transient, so should only force a few merges; each needs merge after it release, each may need merges due to critical things that break development on later branches, so need to be merged up promptly - although we *should* have few of those, precisely because these are meant to be stabilisation branches. Killing 5.10 just because these transients make the chain too long looks like the wrong answer, to me, Eddy. From jani.heikkinen at qt.io Fri Feb 2 13:42:47 2018 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Fri, 2 Feb 2018 12:42:47 +0000 Subject: [Development] Branching from '5.10' to '5.10.1' (almost) ready In-Reply-To: References: Message-ID: Hi all, Final downmerge from '5.10' -> '5.10.1' is now (almost) done; only webengine downmerge is still missing and will be done later today. So from now on '5.10' is for Qt 5.10.2 and all changes targeted to Qt 5.10.1 must be done in '5.10.1'. And please remember: Target is to get Qt 5.10.1 as soon as possible so no any nice to haves in '5.10.1' from now on: we will accept only fixes for release blockers. br, Jani ________________________________________ From: Jani Heikkinen Sent: Monday, January 29, 2018 7:54 AM To: development at qt-project.org Cc: releasing at qt-project.org Subject: Branching from '5.10' to '5.10.1' started Hi all, We have soft branched '5.10.1' from '5.10' on Friday. Target is to do final downmerge from '5.10' -> '5.10.1' Friday 2.2.2018. Please finalize ongoing changes in '5.10' and start using '5.10.1' for new changes. First Qt 5.10.1 snapshot is already under testing and we are targeting to get Qt 5.10.1 out as soon as possible after final downmerge. So please minimize changes for Qt 5.10.1 from now on to get it out quickly! br, Jani From kde at carewolf.com Fri Feb 2 18:43:40 2018 From: kde at carewolf.com (Allan Sandfeld Jensen) Date: Fri, 02 Feb 2018 18:43:40 +0100 Subject: [Development] Qt branches & proposal how to continue with those In-Reply-To: References: <8f399bb9-a01e-7fd2-4f36-38e08bcebfff@kdab.com> Message-ID: <2052902.2PR9bkAb7P@twilight> On Montag, 29. Januar 2018 14:40:20 CET Kevin Kofler wrote: > Giuseppe D'Angelo wrote: > > I don't agree, 5.10 releases should be done on a regular basis until > > 5.11.1 is out (Yes, .1, many users don't upgrade to .0 versions...) > > +1, I also agree with you and therefore disagree with the original proposal. > > Especially security warrants always having one current release branch > active. There is one Qt component (QtWebEngine) for which it is essentially > GUARANTEED that there will be security concerns to address. In addition, > security issues can hit any Qt component at any time. Those MUST be > addressed in a timely manner for Qt to be usable. > > While offering security fixes as patches attached to security advisories can > work for some components, this is not always workable. In particular, > QtWebEngine just cannot be handled that way. > > And of course, there can also be other bugs that users will want fixed > sooner rather than later. > I also agree. We should have a patch release at least every two months. As far as can tell that should mean a 5.10.2. 'Allan From thiago.macieira at intel.com Sat Feb 3 03:32:39 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 02 Feb 2018 18:32:39 -0800 Subject: [Development] Final downmerge from dev to '5.11' delayed In-Reply-To: References: Message-ID: <2613119.HASPqMZLpT@tjmaciei-mobl1> On Wednesday, 31 January 2018 02:57:21 PST Jani Heikkinen wrote: > Hi all, > > Most probably there is changes in 'dev' which should be in Qt 5.11 but which > aren't yet integrated because of CI issues recently. That's why let's > postpone final downmerge (and Qt 5.11 FF) to the end of this week. New plan > is to have final downmerge from 'dev' to '5.11' (and Qt 5.11 FF) Monday > 5.2.2018 (morning). > > Hoping CI will behave now and you have enough time to get needed changes in > before final downmerge. And remember: This delay is just to get changes in, > not for getting extra time for new implementation! So.... are we frozen? The CI integrated three times since your email for qtbase, all of them today (Friday). I just want to know if I change my \since 5.11 to 5.12. The changes are ready and do not need other modification. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From jani.heikkinen at qt.io Sat Feb 3 10:00:15 2018 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Sat, 3 Feb 2018 09:00:15 +0000 Subject: [Development] Final downmerge from dev to '5.11' delayed In-Reply-To: <2613119.HASPqMZLpT@tjmaciei-mobl1> References: <2613119.HASPqMZLpT@tjmaciei-mobl1> Message-ID: > -----Original Message----- > From: Development [mailto:development-bounces+jani.heikkinen=qt.io at qt- > project.org] On Behalf Of Thiago Macieira > Sent: lauantai 3. helmikuuta 2018 4.33 > To: development at qt-project.org > Subject: Re: [Development] Final downmerge from dev to '5.11' delayed > > On Wednesday, 31 January 2018 02:57:21 PST Jani Heikkinen wrote: > > Hi all, > > > > Most probably there is changes in 'dev' which should be in Qt 5.11 but > > which aren't yet integrated because of CI issues recently. That's why > > let's postpone final downmerge (and Qt 5.11 FF) to the end of this > > week. New plan is to have final downmerge from 'dev' to '5.11' (and Qt > > 5.11 FF) Monday > > 5.2.2018 (morning). > > > > Hoping CI will behave now and you have enough time to get needed > > changes in before final downmerge. And remember: This delay is just to > > get changes in, not for getting extra time for new implementation! > > So.... are we frozen? We are kind of semi frozen :) I meant to say that please don't use that extra time to push some new things in anymore. If those were ready (but not in because of ci issues) at original FF date then it is of course OK to integrate those in dev now. But if not then just postpone those in Qt 5.12 instead. Final downmerge from dev to 5.11 will happen on Monday morning so all changes in dev before that will end up in Qt 5.11 br, jani From thiago.macieira at intel.com Sat Feb 3 22:00:10 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sat, 03 Feb 2018 13:00:10 -0800 Subject: [Development] Final downmerge from dev to '5.11' delayed In-Reply-To: References: <2613119.HASPqMZLpT@tjmaciei-mobl1> Message-ID: <5503009.yEltaWgQyX@tjmaciei-mobl1> On Saturday, 3 February 2018 01:00:15 PST Jani Heikkinen wrote: > We are kind of semi frozen I meant to say that please don't use that extra > time to push some new things in anymore. If those were ready (but not in > because of ci issues) at original FF date then it is of course OK to > integrate those in dev now. But if not then just postpone those in Qt 5.12 > instead. Ok, since there are still changes unreviewed, despite being up for review for over a week and emails posted here, I'll consider non-ready. Updating everything to 5.12 and figuring out what are bugfixes that should be in 5.11. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Sat Feb 3 22:16:51 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sat, 03 Feb 2018 13:16:51 -0800 Subject: [Development] Final downmerge from dev to '5.11' delayed In-Reply-To: <5503009.yEltaWgQyX@tjmaciei-mobl1> References: <5503009.yEltaWgQyX@tjmaciei-mobl1> Message-ID: <10172068.PljLCaiAAJ@tjmaciei-mobl1> On Saturday, 3 February 2018 13:00:10 PST Thiago Macieira wrote: > Ok, since there are still changes unreviewed, despite being up for review > for over a week and emails posted here, I'll consider non-ready. > > Updating everything to 5.12 and figuring out what are bugfixes that should > be in 5.11. Done. The two QJsonValue changes (QUrl and QUuid) are clean and targetted to 5.11. The rest of CBOR is now \since 5.12. Will someone now please review them? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From jani.heikkinen at qt.io Mon Feb 5 06:37:07 2018 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Mon, 5 Feb 2018 05:37:07 +0000 Subject: [Development] Qt 5.10.1 changes files: MAINTAINERS, your action needed! Message-ID: Hi, Most of Qt 5.10.1 changes files are still under work, see https://codereview.qt-project.org/#/q/message:%22Add+changes+file+for+Qt+5.10.1%22,n,z Please make sure those will be finalized & approved today; we need to get Qt 5.10.1 final content in place now Also please start updating known issues page for Qt 5.10.1 here: https://wiki.qt.io/Qt_5.10.1_Known_Issues br, Jani From lars.knoll at qt.io Mon Feb 5 11:35:55 2018 From: lars.knoll at qt.io (Lars Knoll) Date: Mon, 5 Feb 2018 10:35:55 +0000 Subject: [Development] Qt branches & proposal how to continue with those In-Reply-To: <20180201145307.GE14103@troll08> References: <4137226.H1Wp0KbUjd@tjmaciei-mobl1> <3586F83C-F715-4B4E-BFA1-A24EF62946FA@qt.io> <833e801049d7d35ed1dab558afafd7fb.squirrel@squirrel.six.silmor.de> <45E55A9F-D3E3-4FC4-B239-74E2BBBA7AFC@qt.io> <20180201111913.GC14103@troll08> <475241517484976@web4j.yandex.ru> <9ABE2AC4-87A1-4F9F-8543-5DCA73D8B79F@qt.io> <20180201145307.GE14103@troll08> Message-ID: Hi all, Sorry for being a bit late with answering to this thread. Been first traveling and then was down with a flu last week. Unfortunately, none of the options on the table will be 100% satisfying to everybody. This is basically because we have limits on how much work we can or should be doing getting different releases out, and different users have different preferences with regards to our branches. I think that we’ll be long term best off, if we move Qt forward as quickly as we can. Qt 5.11 provides some significant new things over 5.10, so in the end we should prioritise finalising that branch and getting 5.11.0 out as quickly as we can. Less merging will free up people and CI capacity to focus on 5.11 bug fixing and speed up turn around time to getting qt5.git integrations through. This means we’ll go with something close to option 2b that Ossi outlined below: * We put 5.9 in cherry-picking mode in line with QUIP 5. * There is currently no 5.10.2 release planned. The main reason to do one would be to be an urgent security update. This means we also leave 5.10 branch behind and close it. * If we have a larger security issue that deserves a release (and not just a patch) from 5.10, we can still do that from the branch on top of 5.10.1 (maybe doing a one time merge from 5.9 to 5.10 if we want those fixes as well) * Instead we put our focus on getting 5.11 out as quickly as we can. Let’s branch now, create first alpha and then beta packages as quickly as possible. Not having to merge from 5.10 will ease this significantly. Getting 5.11 out quick will hopefully also make Webengine not fall too far/long behind upstream security patches. Of course, we continue having regular releases from 5.9, but with it being in strict mode, the frequency of releases will maybe drop a bit (from every 6 weeks currently to maybe every 8-10 weeks). Let’s also now plan for at least two patch level releases of 5.11 before 5.12 comes out. Cheers, Lars > On 1 Feb 2018, at 15:53, Oswald Buddenhagen wrote: > > On Thu, Feb 01, 2018 at 02:35:58PM +0100, Tuukka Turunen wrote: >> So based on this Qt 5.9 should be in cherry pick mode next week. With >> previous wording it should have been in cherry pick mode from 2.9.2017 >> onwards, which was way too soon (hence the change to QUIP5). >> > right. > >> What about Qt 5.10.2? This of course needs to be addressed after we >> see how Qt 5.10.1 turns out to be. But provided Qt 5.10.1 is a good >> release, I would like to put full focus into getting Qt 5.11.0 out >> quickly and try to release Qt 5.11.1 in June already. >> > yes, but the point is that we can't change the policy retroactively. if > 5.10.2 is an option, then 5.10 needs to stay open as the default target > for fixes, and be forward-merged. this leaves us at two merges for a fix > to reach dev. > the same delay would occurr if we closed 5.10 and continued to merge > from 5.9, which is why the discussion which one is more important > emerged. > > this leaves us with three options: > 1) > - 5.9 goes to cherry-pick mode, essentially now. > - 5.10 stays open until 5.11.0 is released. > - we should create 5.10.2 before the 5.11.0 release even if we don't > intent to actually make a release, just so we have a mergable > target branch (to avoid "illegal" 5.10 => 5.11.0 merges or > cherry-picks). > 2) > - we just declare that there won't be 5.10.2 and close 5.10 after > 5.10.1. potentially not user-friendly, but we've done it in the > past, and while releasing capacity isn't the limiting factor now, > forward-merging apparently is. > 2a) we continue to forward-merge from 5.9. > 2b) 5.9 goes to cherry-pick mode, which cuts out another merge step. > > note that 5.10 going to cherry-pick mode is specifically not an option, > as stated previously. > > 1) seems most natural to me. > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From lars.knoll at qt.io Mon Feb 5 11:35:56 2018 From: lars.knoll at qt.io (Lars Knoll) Date: Mon, 5 Feb 2018 10:35:56 +0000 Subject: [Development] Qt branches & proposal how to continue with those In-Reply-To: <20180201145307.GE14103@troll08> References: <4137226.H1Wp0KbUjd@tjmaciei-mobl1> <3586F83C-F715-4B4E-BFA1-A24EF62946FA@qt.io> <833e801049d7d35ed1dab558afafd7fb.squirrel@squirrel.six.silmor.de> <45E55A9F-D3E3-4FC4-B239-74E2BBBA7AFC@qt.io> <20180201111913.GC14103@troll08> <475241517484976@web4j.yandex.ru> <9ABE2AC4-87A1-4F9F-8543-5DCA73D8B79F@qt.io> <20180201145307.GE14103@troll08> Message-ID: <323715F8-A641-4076-8F01-520FE7D10ECD@qt.io> Hi all, Sorry for being a bit late with answering to this thread. Been first traveling and then was down with a flu last week. Unfortunately, none of the options on the table will be 100% satisfying to everybody. This is basically because we have limits on how much work we can or should be doing getting different releases out, and different users have different preferences with regards to our branches. I think that we’ll be long term best off, if we move Qt forward as quickly as we can. Qt 5.11 provides some significant new things over 5.10, so in the end we should prioritise finalising that branch and getting 5.11.0 out as quickly as we can. Less merging will free up people and CI capacity to focus on 5.11 bug fixing and speed up turn around time to getting qt5.git integrations through. This means we’ll go with something close to option 2b that Ossi outlined below: * We put 5.9 in cherry-picking mode in line with QUIP 5. * There is currently no 5.10.2 release planned. The main reason to do one would be to be an urgent security update. This means we also leave 5.10 branch behind and close it. * If we have a larger security issue that deserves a release (and not just a patch) from 5.10, we can still do that from the branch on top of 5.10.1 (maybe doing a one time merge from 5.9 to 5.10 if we want those fixes as well) * Instead we put our focus on getting 5.11 out as quickly as we can. Let’s branch now, create first alpha and then beta packages as quickly as possible. Not having to merge from 5.10 will ease this significantly. Getting 5.11 out quick will hopefully also make Webengine not fall too far/long behind upstream security patches. Of course, we continue having regular releases from 5.9, but with it being in strict mode, the frequency of releases will maybe drop a bit (from every 6 weeks currently to maybe every 8-10 weeks). Let’s also now plan for at least two patch level releases of 5.11 before 5.12 comes out. Cheers, Lars > On 1 Feb 2018, at 15:53, Oswald Buddenhagen wrote: > > On Thu, Feb 01, 2018 at 02:35:58PM +0100, Tuukka Turunen wrote: >> So based on this Qt 5.9 should be in cherry pick mode next week. With >> previous wording it should have been in cherry pick mode from 2.9.2017 >> onwards, which was way too soon (hence the change to QUIP5). >> > right. > >> What about Qt 5.10.2? This of course needs to be addressed after we >> see how Qt 5.10.1 turns out to be. But provided Qt 5.10.1 is a good >> release, I would like to put full focus into getting Qt 5.11.0 out >> quickly and try to release Qt 5.11.1 in June already. >> > yes, but the point is that we can't change the policy retroactively. if > 5.10.2 is an option, then 5.10 needs to stay open as the default target > for fixes, and be forward-merged. this leaves us at two merges for a fix > to reach dev. > the same delay would occurr if we closed 5.10 and continued to merge > from 5.9, which is why the discussion which one is more important > emerged. > > this leaves us with three options: > 1) > - 5.9 goes to cherry-pick mode, essentially now. > - 5.10 stays open until 5.11.0 is released. > - we should create 5.10.2 before the 5.11.0 release even if we don't > intent to actually make a release, just so we have a mergable > target branch (to avoid "illegal" 5.10 => 5.11.0 merges or > cherry-picks). > 2) > - we just declare that there won't be 5.10.2 and close 5.10 after > 5.10.1. potentially not user-friendly, but we've done it in the > past, and while releasing capacity isn't the limiting factor now, > forward-merging apparently is. > 2a) we continue to forward-merge from 5.9. > 2b) 5.9 goes to cherry-pick mode, which cuts out another merge step. > > note that 5.10 going to cherry-pick mode is specifically not an option, > as stated previously. > > 1) seems most natural to me. > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From jani.heikkinen at qt.io Mon Feb 5 13:39:47 2018 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Mon, 5 Feb 2018 12:39:47 +0000 Subject: [Development] Qt branches & proposal how to continue with those In-Reply-To: <323715F8-A641-4076-8F01-520FE7D10ECD@qt.io> References: <4137226.H1Wp0KbUjd@tjmaciei-mobl1> <3586F83C-F715-4B4E-BFA1-A24EF62946FA@qt.io> <833e801049d7d35ed1dab558afafd7fb.squirrel@squirrel.six.silmor.de> <45E55A9F-D3E3-4FC4-B239-74E2BBBA7AFC@qt.io> <20180201111913.GC14103@troll08> <475241517484976@web4j.yandex.ru> <9ABE2AC4-87A1-4F9F-8543-5DCA73D8B79F@qt.io> <20180201145307.GE14103@troll08>, <323715F8-A641-4076-8F01-520FE7D10ECD@qt.io> Message-ID: Hi, So the decision how to proceed is done. Let's give everyone a while to finalize ongoing tasks and put the decision in effect after a week. So from 12.2.2018 -> - '5.9' will be in cherry-pick mode - '5.10' will be closed We will make sure final merges from '5.9' -> '5.10' -> '5.11' will be done after that and then there will be merges only from '5.11' -> 'dev' br, Jani ________________________________________ From: Development on behalf of Lars Knoll Sent: Monday, February 5, 2018 12:35 PM To: Qt development mailing list Subject: Re: [Development] Qt branches & proposal how to continue with those Hi all, Sorry for being a bit late with answering to this thread. Been first traveling and then was down with a flu last week. Unfortunately, none of the options on the table will be 100% satisfying to everybody. This is basically because we have limits on how much work we can or should be doing getting different releases out, and different users have different preferences with regards to our branches. I think that we’ll be long term best off, if we move Qt forward as quickly as we can. Qt 5.11 provides some significant new things over 5.10, so in the end we should prioritise finalising that branch and getting 5.11.0 out as quickly as we can. Less merging will free up people and CI capacity to focus on 5.11 bug fixing and speed up turn around time to getting qt5.git integrations through. This means we’ll go with something close to option 2b that Ossi outlined below: * We put 5.9 in cherry-picking mode in line with QUIP 5. * There is currently no 5.10.2 release planned. The main reason to do one would be to be an urgent security update. This means we also leave 5.10 branch behind and close it. * If we have a larger security issue that deserves a release (and not just a patch) from 5.10, we can still do that from the branch on top of 5.10.1 (maybe doing a one time merge from 5.9 to 5.10 if we want those fixes as well) * Instead we put our focus on getting 5.11 out as quickly as we can. Let’s branch now, create first alpha and then beta packages as quickly as possible. Not having to merge from 5.10 will ease this significantly. Getting 5.11 out quick will hopefully also make Webengine not fall too far/long behind upstream security patches. Of course, we continue having regular releases from 5.9, but with it being in strict mode, the frequency of releases will maybe drop a bit (from every 6 weeks currently to maybe every 8-10 weeks). Let’s also now plan for at least two patch level releases of 5.11 before 5.12 comes out. Cheers, Lars > On 1 Feb 2018, at 15:53, Oswald Buddenhagen wrote: > > On Thu, Feb 01, 2018 at 02:35:58PM +0100, Tuukka Turunen wrote: >> So based on this Qt 5.9 should be in cherry pick mode next week. With >> previous wording it should have been in cherry pick mode from 2.9.2017 >> onwards, which was way too soon (hence the change to QUIP5). >> > right. > >> What about Qt 5.10.2? This of course needs to be addressed after we >> see how Qt 5.10.1 turns out to be. But provided Qt 5.10.1 is a good >> release, I would like to put full focus into getting Qt 5.11.0 out >> quickly and try to release Qt 5.11.1 in June already. >> > yes, but the point is that we can't change the policy retroactively. if > 5.10.2 is an option, then 5.10 needs to stay open as the default target > for fixes, and be forward-merged. this leaves us at two merges for a fix > to reach dev. > the same delay would occurr if we closed 5.10 and continued to merge > from 5.9, which is why the discussion which one is more important > emerged. > > this leaves us with three options: > 1) > - 5.9 goes to cherry-pick mode, essentially now. > - 5.10 stays open until 5.11.0 is released. > - we should create 5.10.2 before the 5.11.0 release even if we don't > intent to actually make a release, just so we have a mergable > target branch (to avoid "illegal" 5.10 => 5.11.0 merges or > cherry-picks). > 2) > - we just declare that there won't be 5.10.2 and close 5.10 after > 5.10.1. potentially not user-friendly, but we've done it in the > past, and while releasing capacity isn't the limiting factor now, > forward-merging apparently is. > 2a) we continue to forward-merge from 5.9. > 2b) 5.9 goes to cherry-pick mode, which cuts out another merge step. > > note that 5.10 going to cherry-pick mode is specifically not an option, > as stated previously. > > 1) seems most natural to me. > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From jani.heikkinen at qt.io Tue Feb 6 12:45:40 2018 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Tue, 6 Feb 2018 11:45:40 +0000 Subject: [Development] Final downmerge from dev to '5.11' done In-Reply-To: References: Message-ID: Hi! Final downmerge from 'dev' to '5.11' is now done and Qt 5.11 FF is officially in effect. From now on 'dev' is for Qt 5.12 and we will continue finalizing Qt 5.11 in '5.11'. Overall release schedule can be found from release wiki (https://wiki.qt.io/Qt_5.11_Release). Plan is to get alpha out as soon as possible; hoping that will happen earlier than planned. Target is to release it immediately after qt5.git integration succeed in '5.11' and when we have created and RTA tested needed packages. Please update Qt 5.11 new features wiki (https://wiki.qt.io/New_Features_in_Qt_5.11) now. br, Jani ________________________________________ From: Jani Heikkinen Sent: Wednesday, January 31, 2018 12:57 PM To: Jani Heikkinen; development at qt-project.org Cc: releasing at qt-project.org Subject: Final downmerge from dev to '5.11' delayed Hi all, Most probably there is changes in 'dev' which should be in Qt 5.11 but which aren't yet integrated because of CI issues recently. That's why let's postpone final downmerge (and Qt 5.11 FF) to the end of this week. New plan is to have final downmerge from 'dev' to '5.11' (and Qt 5.11 FF) Monday 5.2.2018 (morning). Hoping CI will behave now and you have enough time to get needed changes in before final downmerge. And remember: This delay is just to get changes in, not for getting extra time for new implementation! br, Jani > -----Original Message----- > From: Development [mailto:development-bounces+jani.heikkinen=qt.io at qt- > project.org] On Behalf Of Jani Heikkinen > Sent: torstai 25. tammikuuta 2018 8.58 > To: development at qt-project.org > Cc: releasing at qt-project.org > Subject: [Development] Branching from 'dev' to '5.11' started > > Hi, > > We have now soft branched '5.11' from dev so please start using '5.11' now. Qt > 5.11 feature freeze and final downmerge from 'dev' to '5.11' will happen Wed > 31.1.2018 so there is still enough time to finalize ongoing changes in 'dev'. > > And let's keep the feature freeze now, it is key enabler for us to be able to keep > the release schedule. So it is time to check if new feature can be finalized early > enough for the feature freeze. If not then we should just postpone it to Qt 5.12 > instead of trying to get it in Qt 5.11. > > br, > Jani Heikkinen > Release Manager > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From thiago.macieira at intel.com Tue Feb 6 16:35:22 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 6 Feb 2018 07:35:22 -0800 Subject: [Development] Final downmerge from dev to '5.11' done In-Reply-To: References: Message-ID: <3997465.AZBqgGRL6k@tjmaciei-mobl1> On terça-feira, 6 de fevereiro de 2018 03:45:40 PST Jani Heikkinen wrote: > Final downmerge from 'dev' to '5.11' is now done And by "done", Jani means "in progress", since https://codereview.qt-project.org/219162 is still integrating and therefore could fail. However, we don't expect to update the source commit from dev that it merges (c0948d508e7179e2e23c893ba6152c40400de060). Everything integrated into dev now is 5.12. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Simon.Hausmann at qt.io Wed Feb 7 08:09:59 2018 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Wed, 7 Feb 2018 07:09:59 +0000 Subject: [Development] Final downmerge from dev to '5.11' done In-Reply-To: <3997465.AZBqgGRL6k@tjmaciei-mobl1> References: , <3997465.AZBqgGRL6k@tjmaciei-mobl1> Message-ID: <83F010EB-3877-4847-9CCC-E352D56D863C@qt.io> Hi, And by the look of it we are also going to need another merge from dev to 5.11 for qtdeclarative as the merge from 5.10 was submitted to dev instead of 5.11, along with the blacklisting. Simon > On 6. Feb 2018, at 16:35, Thiago Macieira wrote: > >> On terça-feira, 6 de fevereiro de 2018 03:45:40 PST Jani Heikkinen wrote: >> Final downmerge from 'dev' to '5.11' is now done > > And by "done", Jani means "in progress", since > https://codereview.qt-project.org/219162 is still integrating and therefore > could fail. However, we don't expect to update the source commit from dev that > it merges (c0948d508e7179e2e23c893ba6152c40400de060). Everything integrated > into dev now is 5.12. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From Frederik.Gladhorn at qt.io Wed Feb 7 13:48:21 2018 From: Frederik.Gladhorn at qt.io (Frederik Gladhorn) Date: Wed, 7 Feb 2018 12:48:21 +0000 Subject: [Development] Deprecation of Qt Quick Controls 1 Message-ID: Hi all, It should come as no big surprise that we are not working much on Qt Quick Controls 1. After some discussions inside The Qt Company, we concluded that it would make sense to clarify the situation. We see the value Controls 1 provides - more platform native styling - but it comes at a high price. Performance is very problematic with the module and we now offer more modern styles in Controls 2. In addition customizing the styles in Controls 2 is possible in different ways. There is the image based style that is especially accessible to graphical designers. There is the general styling that has become really cheap now (thanks to the deferred execution patches), so replacing parts of the ready-made controls does come at no cost. Finally writing a completely custom style is entirely possible, using the logic of Controls 2 as building blocks. In fact I see Controls 2 as being part of Qt Quick, the part that has been missing for a long time and that completes the story to make developing applications with Qt Quick easy. With the recent updates to the Qt Quick Designer in Qt Creator and additions to make Controls 2 more desktop friendly for modern applications, I'd recommend everyone to move over. Next to that we have picked up Qt Widgets lately again and fixes are making their way into the module. For applications that need to look and behave like traditional desktop applications, this is an alternative. As you can see, the effort is currently split and we'd like to reduce the attention to the two big areas - Widgets and Quick with Controls 2. This means we will spend even less time on Controls 1, where we'll only fix critical issues in the future. As always, feedback welcome :) Cheers, Frederik -------------- next part -------------- An HTML attachment was scrubbed... URL: From helmut.muelner at gmail.com Wed Feb 7 14:06:59 2018 From: helmut.muelner at gmail.com (=?iso-8859-1?Q?Helmut_M=FClner?=) Date: Wed, 7 Feb 2018 14:06:59 +0100 Subject: [Development] Deprecation of Qt Quick Controls 1 In-Reply-To: References: Message-ID: <008c01d3a014$8a7aa580$9f6ff080$@gmail.com> > It should come as no big surprise that we are not working much on Qt Quick Controls 1. After some discussions inside The Qt Company, we concluded that it would make sense to clarify the situation. We see the value Controls 1 provides - more platform native styling - but it comes at a high price. > [ ] > As you can see, the effort is currently split and we'd like to reduce the attention to the two big areas - Widgets and Quick with Controls 2. This means we will spend even less time on Controls 1, where we'll only fix critical issues in the future. In my application I mostly use Controls 2 but have to add some controls from Qt Quick Controls 1, e.g. TableView, SplitView, Calendar, ScrollView. It would be nice to have these controls available in Controls 2 before you deprecate Controls 1. Regards Helmut -------------- next part -------------- An HTML attachment was scrubbed... URL: From enmarantispam at gmail.com Wed Feb 7 14:10:24 2018 From: enmarantispam at gmail.com (NIkolai Marchenko) Date: Wed, 7 Feb 2018 16:10:24 +0300 Subject: [Development] Deprecation of Qt Quick Controls 1 In-Reply-To: <008c01d3a014$8a7aa580$9f6ff080$@gmail.com> References: <008c01d3a014$8a7aa580$9f6ff080$@gmail.com> Message-ID: I basically can't use Controls 2 in my application because combobox in controls 2 has extremely out of place style for desktop applications, is too bloated and you can't control it enough to make it look more like Controls 1. Admittedly, I almost do not use QML in my apps but I wasn't able to find an easy solution to make combobox tolerable for desktop On Wed, Feb 7, 2018 at 4:06 PM, Helmut Mülner wrote: > > > It should come as no big surprise that we are not working much on Qt > Quick Controls 1. > After some discussions inside The Qt Company, we concluded that it would > make sense to clarify the situation. > We see the value Controls 1 provides - more platform native styling - but > it comes at a high price. > > > […] > > As you can see, the effort is currently split and we'd like to reduce > the attention to the two big areas - Widgets and Quick with Controls 2. This > means we will spend even less time on Controls 1, where we'll only fix > critical issues in the future. > > In my application I mostly use Controls 2 but have to add some controls > from Qt Quick Controls 1, e.g. TableView, SplitView, Calendar, ScrollView. > It would be nice to have these controls available in Controls 2 before you > deprecate Controls 1. > > > > Regards > > Helmut > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From enmarantispam at gmail.com Wed Feb 7 14:12:40 2018 From: enmarantispam at gmail.com (NIkolai Marchenko) Date: Wed, 7 Feb 2018 16:12:40 +0300 Subject: [Development] Deprecation of Qt Quick Controls 1 In-Reply-To: References: <008c01d3a014$8a7aa580$9f6ff080$@gmail.com> Message-ID: And no, widgets is not an alterlative to proper qml controls on desktop when you want custom interface. I have an app that uses qml to draw a custom listview for users, it would be extremely hard to replicate it with widgets and why should I do that when I have qml? On Wed, Feb 7, 2018 at 4:10 PM, NIkolai Marchenko wrote: > I basically can't use Controls 2 in my application because combobox in > controls 2 has extremely out of place style for desktop applications, is > too bloated and you can't control it enough to make it look more like > Controls 1. > Admittedly, I almost do not use QML in my apps but I wasn't able to find > an easy solution to make combobox tolerable for desktop > > On Wed, Feb 7, 2018 at 4:06 PM, Helmut Mülner > wrote: > >> >> > It should come as no big surprise that we are not working much on Qt >> Quick Controls 1. >> After some discussions inside The Qt Company, we concluded that it would >> make sense to clarify the situation. >> We see the value Controls 1 provides - more platform native styling - but >> it comes at a high price. >> >> > […] >> > As you can see, the effort is currently split and we'd like to reduce >> the attention to the two big areas - Widgets and Quick with Controls 2. This >> means we will spend even less time on Controls 1, where we'll only fix >> critical issues in the future. >> >> In my application I mostly use Controls 2 but have to add some controls >> from Qt Quick Controls 1, e.g. TableView, SplitView, Calendar, ScrollView. >> It would be nice to have these controls available in Controls 2 before you >> deprecate Controls 1. >> >> >> >> Regards >> >> Helmut >> >> >> >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeanmichael.celerier at gmail.com Wed Feb 7 14:18:40 2018 From: jeanmichael.celerier at gmail.com (=?UTF-8?Q?Jean=2DMicha=C3=ABl_Celerier?=) Date: Wed, 7 Feb 2018 14:18:40 +0100 Subject: [Development] Deprecation of Qt Quick Controls 1 In-Reply-To: References: <008c01d3a014$8a7aa580$9f6ff080$@gmail.com> Message-ID: KDE has some codes that enables simulation of the "native" style through QtQuickControls 2 if it can be useful : https://github.com/KDE/qqc2-desktop-style However, even though Qt Quick Controls (and Qt Quick in general) are both very nice, I think that a big missing part is CSS-like properties, that is, properties that would apply to whole subtrees of QML components easily. Ableton has graciously provided some code for this : https://github.com/Ableton/aqt-stylesheets but it would be nice to have a syntaxic solution part of Qt proper... Best, ------- Jean-Michaël Celerier http://www.jcelerier.name On Wed, Feb 7, 2018 at 2:12 PM, NIkolai Marchenko wrote: > And no, widgets is not an alterlative to proper qml controls on desktop > when you want custom interface. > I have an app that uses qml to draw a custom listview for users, it would > be extremely hard to replicate it with widgets and why should I do that > when I have qml? > > On Wed, Feb 7, 2018 at 4:10 PM, NIkolai Marchenko > wrote: > >> I basically can't use Controls 2 in my application because combobox in >> controls 2 has extremely out of place style for desktop applications, is >> too bloated and you can't control it enough to make it look more like >> Controls 1. >> Admittedly, I almost do not use QML in my apps but I wasn't able to find >> an easy solution to make combobox tolerable for desktop >> >> On Wed, Feb 7, 2018 at 4:06 PM, Helmut Mülner >> wrote: >> >>> >>> > It should come as no big surprise that we are not working much on Qt >>> Quick Controls 1. >>> After some discussions inside The Qt Company, we concluded that it would >>> make sense to clarify the situation. >>> We see the value Controls 1 provides - more platform native styling - >>> but it comes at a high price. >>> >>> > […] >>> > As you can see, the effort is currently split and we'd like to reduce >>> the attention to the two big areas - Widgets and Quick with Controls 2. This >>> means we will spend even less time on Controls 1, where we'll only fix >>> critical issues in the future. >>> >>> In my application I mostly use Controls 2 but have to add some controls >>> from Qt Quick Controls 1, e.g. TableView, SplitView, Calendar, ScrollView. >>> It would be nice to have these controls available in Controls 2 before you >>> deprecate Controls 1. >>> >>> >>> >>> Regards >>> >>> Helmut >>> >>> >>> >>> _______________________________________________ >>> Development mailing list >>> Development at qt-project.org >>> http://lists.qt-project.org/mailman/listinfo/development >>> >>> >> > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mitch.curtis at qt.io Wed Feb 7 14:22:01 2018 From: mitch.curtis at qt.io (Mitch Curtis) Date: Wed, 7 Feb 2018 13:22:01 +0000 Subject: [Development] Deprecation of Qt Quick Controls 1 In-Reply-To: <008c01d3a014$8a7aa580$9f6ff080$@gmail.com> References: <008c01d3a014$8a7aa580$9f6ff080$@gmail.com> Message-ID: TableView is in the works: https://blog.qt.io/blog/2017/11/23/ready-qt-quick-controls-2-3/ Controls 2 has ScrollView: https://doc.qt.io/qt-5/qml-qtquick-controls2-scrollview.html Qt.labs.calendar has MonthGrid and associated types: https://doc.qt.io/qt-5/qml-qt-labs-calendar-monthgrid.html I'm not sure about SplitView, but I wouldn't imagine that would be too difficult to implement yourself. From: Development [mailto:development-bounces+mitch.curtis=qt.io at qt-project.org] On Behalf Of Helmut Mülner Sent: Wednesday, 7 February 2018 2:07 PM To: Frederik Gladhorn ; development at qt-project.org Subject: Re: [Development] Deprecation of Qt Quick Controls 1 > It should come as no big surprise that we are not working much on Qt Quick Controls 1. After some discussions inside The Qt Company, we concluded that it would make sense to clarify the situation. We see the value Controls 1 provides - more platform native styling - but it comes at a high price. > [...] > As you can see, the effort is currently split and we'd like to reduce the attention to the two big areas - Widgets and Quick with Controls 2. This means we will spend even less time on Controls 1, where we'll only fix critical issues in the future. In my application I mostly use Controls 2 but have to add some controls from Qt Quick Controls 1, e.g. TableView, SplitView, Calendar, ScrollView. It would be nice to have these controls available in Controls 2 before you deprecate Controls 1. Regards Helmut -------------- next part -------------- An HTML attachment was scrubbed... URL: From mitch.curtis at qt.io Wed Feb 7 14:24:26 2018 From: mitch.curtis at qt.io (Mitch Curtis) Date: Wed, 7 Feb 2018 13:24:26 +0000 Subject: [Development] Deprecation of Qt Quick Controls 1 In-Reply-To: References: <008c01d3a014$8a7aa580$9f6ff080$@gmail.com> Message-ID: Have you tried the Fusion style in 5.10? https://doc.qt.io/qt-5/qtquickcontrols2-fusion.html From: Development [mailto:development-bounces+mitch.curtis=qt.io at qt-project.org] On Behalf Of NIkolai Marchenko Sent: Wednesday, 7 February 2018 2:10 PM To: Helmut Mülner Cc: Qt development mailing list Subject: Re: [Development] Deprecation of Qt Quick Controls 1 I basically can't use Controls 2 in my application because combobox in controls 2 has extremely out of place style for desktop applications, is too bloated and you can't control it enough to make it look more like Controls 1. Admittedly, I almost do not use QML in my apps but I wasn't able to find an easy solution to make combobox tolerable for desktop On Wed, Feb 7, 2018 at 4:06 PM, Helmut Mülner > wrote: > It should come as no big surprise that we are not working much on Qt Quick Controls 1. After some discussions inside The Qt Company, we concluded that it would make sense to clarify the situation. We see the value Controls 1 provides - more platform native styling - but it comes at a high price. > […] > As you can see, the effort is currently split and we'd like to reduce the attention to the two big areas - Widgets and Quick with Controls 2. This means we will spend even less time on Controls 1, where we'll only fix critical issues in the future. In my application I mostly use Controls 2 but have to add some controls from Qt Quick Controls 1, e.g. TableView, SplitView, Calendar, ScrollView. It would be nice to have these controls available in Controls 2 before you deprecate Controls 1. Regards Helmut _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From annulen at yandex.ru Wed Feb 7 15:25:21 2018 From: annulen at yandex.ru (Konstantin Tokarev) Date: Wed, 07 Feb 2018 17:25:21 +0300 Subject: [Development] Deprecation of Qt Quick Controls 1 In-Reply-To: References: <008c01d3a014$8a7aa580$9f6ff080$@gmail.com> Message-ID: <193391518013521@web37j.yandex.ru> 07.02.2018, 16:13, "NIkolai Marchenko" : > And no, widgets is not an alterlative to proper qml controls on desktop when you want custom interface. > I have an app that uses qml to draw a custom listview for users, it would be extremely hard to replicate it with widgets and why should I do that when I have qml? FWIW, it's not really hard to implement your own ItemView widgets. --  Regards, Konstantin From enmarantispam at gmail.com Wed Feb 7 15:35:34 2018 From: enmarantispam at gmail.com (NIkolai Marchenko) Date: Wed, 7 Feb 2018 17:35:34 +0300 Subject: [Development] Deprecation of Qt Quick Controls 1 In-Reply-To: <193391518013521@web37j.yandex.ru> References: <008c01d3a014$8a7aa580$9f6ff080$@gmail.com> <193391518013521@web37j.yandex.ru> Message-ID: even stuff like that? https://imgur.com/a/tTFeO I doubt it. I really don't want to delve into manual painter usage and styleoptions when I can just quickly make such stuff with qml listview. And basically the only thing that really hurts me with controls 2 is that combobox becomes quite horrible On Wed, Feb 7, 2018 at 5:25 PM, Konstantin Tokarev wrote: > > > 07.02.2018, 16:13, "NIkolai Marchenko" : > > And no, widgets is not an alterlative to proper qml controls on desktop > when you want custom interface. > > I have an app that uses qml to draw a custom listview for users, it > would be extremely hard to replicate it with widgets and why should I do > that when I have qml? > > FWIW, it's not really hard to implement your own ItemView widgets. > > > -- > Regards, > Konstantin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Wed Feb 7 15:40:13 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 7 Feb 2018 06:40:13 -0800 Subject: [Development] Final downmerge from dev to '5.11' done In-Reply-To: <83F010EB-3877-4847-9CCC-E352D56D863C@qt.io> References: <3997465.AZBqgGRL6k@tjmaciei-mobl1> <83F010EB-3877-4847-9CCC-E352D56D863C@qt.io> Message-ID: <3401658.OlG3efNvJD@tjmaciei-mobl1> On Tuesday, 6 February 2018 23:09:59 PST Simon Hausmann wrote: > And by the look of it we are also going to need another merge from dev to > 5.11 for qtdeclarative as the merge from 5.10 was submitted to dev instead > of 5.11, along with the blacklisting. I notice that happening for qtbase and gave it a -1, so I guess we stopped it in time. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From helmut.muelner at gmail.com Wed Feb 7 15:46:48 2018 From: helmut.muelner at gmail.com (=?UTF-8?Q?Helmut_M=C3=BClner?=) Date: Wed, 7 Feb 2018 15:46:48 +0100 Subject: [Development] Deprecation of Qt Quick Controls 1 In-Reply-To: References: <008c01d3a014$8a7aa580$9f6ff080$@gmail.com> <193391518013521@web37j.yandex.ru> Message-ID: <00e701d3a022$7c0ff870$742fe950$@gmail.com> * And basically the only thing that really hurts me with controls 2 is that combobox becomes quite horrible I use something like this for a decent looking combobox: ComboBox { id: comboBox Layout.fillWidth: true height: 30 Layout.maximumHeight: 30 Layout.minimumHeight: 30 font.pointSize: 10 anchors.verticalCenter: parent.verticalCenter textRole: "name" model: myModel delegate: ItemDelegate { width: comboBox.width height: 30 contentItem: Text { id: itemDelegateText text: name font: comboBox.font elide: Text.ElideRight verticalAlignment: Text.AlignVCenter } highlighted: comboBox.highlightedIndex == index } } Cheers, Helmut -------------- next part -------------- An HTML attachment was scrubbed... URL: From annulen at yandex.ru Wed Feb 7 15:54:05 2018 From: annulen at yandex.ru (Konstantin Tokarev) Date: Wed, 07 Feb 2018 17:54:05 +0300 Subject: [Development] Deprecation of Qt Quick Controls 1 In-Reply-To: References: <008c01d3a014$8a7aa580$9f6ff080$@gmail.com> <193391518013521@web37j.yandex.ru> Message-ID: <611491518015245@web6g.yandex.ru> 07.02.2018, 17:42, "NIkolai Marchenko" : > even stuff like that? > https://imgur.com/a/tTFeO > I doubt it. I really don't want to delve into manual painter usage and styleoptions when I can just quickly make such stuff with qml listview. FWIW, in company where I work we routinely did such UIs for embedded systems with Qt 4 and widgets. However, it required quite a bit of work to implement basic ListView with pluggable renderers. However, we didn't use QStyle and style options, and had no tough controls like combo box there. > And basically the only thing that really hurts me with controls 2 is that combobox becomes quite horrible > > On Wed, Feb 7, 2018 at 5:25 PM, Konstantin Tokarev wrote: > >> 07.02.2018, 16:13, "NIkolai Marchenko" : >>> And no, widgets is not an alterlative to proper qml controls on desktop when you want custom interface. >>> I have an app that uses qml to draw a custom listview for users, it would be extremely hard to replicate it with widgets and why should I do that when I have qml? >> >> FWIW, it's not really hard to implement your own ItemView widgets. >> >> -- >> Regards, >> Konstantin --  Regards, Konstantin From enmarantispam at gmail.com Wed Feb 7 16:02:18 2018 From: enmarantispam at gmail.com (NIkolai Marchenko) Date: Wed, 7 Feb 2018 18:02:18 +0300 Subject: [Development] Deprecation of Qt Quick Controls 1 In-Reply-To: <611491518015245@web6g.yandex.ru> References: <008c01d3a014$8a7aa580$9f6ff080$@gmail.com> <193391518013521@web37j.yandex.ru> <611491518015245@web6g.yandex.ru> Message-ID: I really don't want to go there for a project I am not paid to develop :) On Wed, Feb 7, 2018 at 5:54 PM, Konstantin Tokarev wrote: > > > 07.02.2018, 17:42, "NIkolai Marchenko" : > > even stuff like that? > > https://imgur.com/a/tTFeO > > I doubt it. I really don't want to delve into manual painter usage and > styleoptions when I can just quickly make such stuff with qml listview. > > FWIW, in company where I work we routinely did such UIs for embedded > systems with Qt 4 and widgets. However, it required quite a bit of work to > implement basic ListView with pluggable renderers. However, we didn't use > QStyle and style options, and had no tough controls like combo box there. > > > And basically the only thing that really hurts me with controls 2 is > that combobox becomes quite horrible > > > > On Wed, Feb 7, 2018 at 5:25 PM, Konstantin Tokarev > wrote: > > > >> 07.02.2018, 16:13, "NIkolai Marchenko" : > >>> And no, widgets is not an alterlative to proper qml controls on > desktop when you want custom interface. > >>> I have an app that uses qml to draw a custom listview for users, it > would be extremely hard to replicate it with widgets and why should I do > that when I have qml? > >> > >> FWIW, it's not really hard to implement your own ItemView widgets. > >> > >> -- > >> Regards, > >> Konstantin > > > -- > Regards, > Konstantin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From enmarantispam at gmail.com Wed Feb 7 16:02:44 2018 From: enmarantispam at gmail.com (NIkolai Marchenko) Date: Wed, 7 Feb 2018 18:02:44 +0300 Subject: [Development] Deprecation of Qt Quick Controls 1 In-Reply-To: <00e701d3a022$7c0ff870$742fe950$@gmail.com> References: <008c01d3a014$8a7aa580$9f6ff080$@gmail.com> <193391518013521@web37j.yandex.ru> <00e701d3a022$7c0ff870$742fe950$@gmail.com> Message-ID: Thanks, I will see how it works. Though I will use the model: 10 syntax like this :( On Wed, Feb 7, 2018 at 5:46 PM, Helmut Mülner wrote: > Ø And basically the only thing that really hurts me with controls 2 is > that combobox becomes quite horrible > > > > I use something like this for a decent looking combobox: > > > > ComboBox { > > id: *comboBox* > > Layout.fillWidth: true > > height: 30 > > Layout.maximumHeight: 30 > > Layout.minimumHeight: 30 > > font.pointSize: 10 > > anchors.verticalCenter: *parent*.verticalCenter > > textRole: "name" > > model: myModel > > delegate: ItemDelegate { > > width: *comboBox*.width > > height: 30 > > contentItem: Text { > > id: *itemDelegateText* > > text: name > > font: *comboBox*.font > > elide: Text.ElideRight > > verticalAlignment: Text.AlignVCenter > > } > > highlighted: *comboBox*.highlightedIndex == index > > } > > } > > > > Cheers, > > Helmut > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From enmarantispam at gmail.com Wed Feb 7 16:03:22 2018 From: enmarantispam at gmail.com (NIkolai Marchenko) Date: Wed, 7 Feb 2018 18:03:22 +0300 Subject: [Development] Deprecation of Qt Quick Controls 1 In-Reply-To: References: <008c01d3a014$8a7aa580$9f6ff080$@gmail.com> <193391518013521@web37j.yandex.ru> <00e701d3a022$7c0ff870$742fe950$@gmail.com> Message-ID: I meant, I will *lose* model:10 syntax like this (mailing lists and unfixable wording errors, ugh) On Wed, Feb 7, 2018 at 6:02 PM, NIkolai Marchenko wrote: > Thanks, I will see how it works. Though I will use the model: 10 syntax > like this :( > > On Wed, Feb 7, 2018 at 5:46 PM, Helmut Mülner > wrote: > >> Ø And basically the only thing that really hurts me with controls 2 is >> that combobox becomes quite horrible >> >> >> >> I use something like this for a decent looking combobox: >> >> >> >> ComboBox { >> >> id: *comboBox* >> >> Layout.fillWidth: true >> >> height: 30 >> >> Layout.maximumHeight: 30 >> >> Layout.minimumHeight: 30 >> >> font.pointSize: 10 >> >> anchors.verticalCenter: *parent*.verticalCenter >> >> textRole: "name" >> >> model: myModel >> >> delegate: ItemDelegate { >> >> width: *comboBox*.width >> >> height: 30 >> >> contentItem: Text { >> >> id: *itemDelegateText* >> >> text: name >> >> font: *comboBox*.font >> >> elide: Text.ElideRight >> >> verticalAlignment: Text.AlignVCenter >> >> } >> >> highlighted: *comboBox*.highlightedIndex == index >> >> } >> >> } >> >> >> >> Cheers, >> >> Helmut >> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From olivier at woboq.com Wed Feb 7 16:48:19 2018 From: olivier at woboq.com (Olivier Goffart) Date: Wed, 07 Feb 2018 16:48:19 +0100 Subject: [Development] Deprecation of Qt Quick Controls 1 In-Reply-To: References: <193391518013521@web37j.yandex.ru> Message-ID: <1954736.A9jPoBRzyW@maurice> Am Mittwoch, 7. Februar 2018, 15:35:34 CET schrieb NIkolai Marchenko: > even stuff like that? > https://imgur.com/a/tTFeO > I doubt it. I really don't want to delve into manual painter usage and > styleoptions when I can just quickly make such stuff with qml listview. > And basically the only thing that really hurts me with controls 2 is that > combobox becomes quite horrible That can be done without too much difficulty. For reference, i have been doing the ui for the ownCloud client with a QTreeView: https://imgur.com/a/7ore2 "All you have to do," is create a QAbstractItemDelegate, then you can paint anything with QPainter. It is just a bunch of drawRectangle and drawText, and for the style element, you can use style()->drawComplexControl You have to layout everything by manually computing the position of items. The logic of the embedded combobox might be a bit tricky but perhaps a spinbox would be much easier to draw. Clearly this is not the prettiest code ever https://code.woboq.org/owncloud/client/src/gui/folderstatusdelegate.cpp.html#_ZNK3OCC20FolderStatusDelegate5paintEP8QPainterRK20QStyleOptionViewItemRK11QModelIndex So while it is possible to do this, this is indeed much harder and less maintainable than with QML. Unfortunately, it seems that the story for QML on desktop is less than ideal. There is still much polishing to do to get there. And the fact that Qt Quick Controls 2 does not seem to have the desktop as a first place citizen is worrying. The Qt Company does not seem to be interested in the desktop. The fact that QtCreator went back from using some of QML for example just shows that the situation is regressing rather than improving. -- Olivier Woboq - Qt services and support - https://woboq.com - https://code.woboq.org From enmarantispam at gmail.com Wed Feb 7 17:10:45 2018 From: enmarantispam at gmail.com (NIkolai Marchenko) Date: Wed, 7 Feb 2018 19:10:45 +0300 Subject: [Development] Deprecation of Qt Quick Controls 1 In-Reply-To: <1954736.A9jPoBRzyW@maurice> References: <193391518013521@web37j.yandex.ru> <1954736.A9jPoBRzyW@maurice> Message-ID: Well, thank you for your example, but I would rather code a completely custom combobox in QML than go this route (even with my qml skills noobish at best it seems a more reasonable idea, than coding a "widgets monster" ) And for the time being I will just stick with Controls 1 as I want to be improving the core of my app rather than spend weeks of my weekend time fixing UI problem introduced by controls deprecation. I just wanted to highlight the problem, that it is really, really too early to cycle out V1. And that combobox V2 is completely unacceptable on desktop. I still have to see the "fusion" suggestion though On Wed, Feb 7, 2018 at 6:48 PM, Olivier Goffart wrote: > Am Mittwoch, 7. Februar 2018, 15:35:34 CET schrieb NIkolai Marchenko: > > even stuff like that? > > https://imgur.com/a/tTFeO > > I doubt it. I really don't want to delve into manual painter usage and > > styleoptions when I can just quickly make such stuff with qml listview. > > And basically the only thing that really hurts me with controls 2 is that > > combobox becomes quite horrible > > That can be done without too much difficulty. For reference, i have been > doing the ui for the ownCloud client with a QTreeView: > https://imgur.com/a/7ore2 > > "All you have to do," is create a QAbstractItemDelegate, then you can paint > anything with QPainter. It is just a bunch of drawRectangle and drawText, > and for the style element, you can use style()->drawComplexControl > You have to layout everything by manually computing the position of items. > The logic of the embedded combobox might be a bit tricky but perhaps a > spinbox > would be much easier to draw. > > Clearly this is not the prettiest code ever > https://code.woboq.org/owncloud/client/src/gui/ > folderstatusdelegate.cpp.html#_ZNK3OCC20FolderStatusDelegate5 > paintEP8QPainterRK20QStyleOptionViewItemRK11QModelIndex > > So while it is possible to do this, this is indeed much harder and less > maintainable than with QML. > > Unfortunately, it seems that the story for QML on desktop is less than > ideal. > There is still much polishing to do to get there. And the fact that Qt > Quick > Controls 2 does not seem to have the desktop as a first place citizen is > worrying. > > The Qt Company does not seem to be interested in the desktop. The fact that > QtCreator went back from using some of QML for example just shows that the > situation is regressing rather than improving. > > -- > Olivier > > Woboq - Qt services and support - https://woboq.com - > https://code.woboq.org > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.kofler at chello.at Thu Feb 8 04:27:21 2018 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 08 Feb 2018 04:27:21 +0100 Subject: [Development] Deprecation of Qt Quick Controls 1 References: <008c01d3a014$8a7aa580$9f6ff080$@gmail.com> <193391518013521@web37j.yandex.ru> Message-ID: NIkolai Marchenko wrote: > even stuff like that? > https://imgur.com/a/tTFeO Maybe try using QListWidget::setItemWidget? That should even let you assign some widget layed out in Qt Designer. Also FYI, since QListWidget is a subclass of QListView, you can actually also use a QAbstractItemDelegate with a QListWidget (hint: QListWidget::itemFromIndex does wonders to actually find the QListWidgetItem in the delegate), even though the documentation omits that detail or even tries to imply otherwise. (And the same goes for tree widgets, just s/List/Tree/g in the previous sentence.) Kompare actually declares a subclass of QTreeWidgetItem with a virtual paintCell method, subclass which is the superclass of all the concrete item subclasses, which implement/override the paintCell method, and then sets a (subclassed) QStyledItemDelegate that just calls that virtual paintCell method when the tree widget asks it (the delegate) to paint the item. (For a bit of history: The virtual paintCell method in the item was how things worked in Qt 3 out of the box. It took me just a few lines of item delegate code to emulate that way of working in Qt 4 and 5, and I think this can be a convenient trick even in new code.) Kevin Kofler From kevin.kofler at chello.at Thu Feb 8 04:32:25 2018 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 08 Feb 2018 04:32:25 +0100 Subject: [Development] Qt branches & proposal how to continue with those References: <4137226.H1Wp0KbUjd@tjmaciei-mobl1> <3586F83C-F715-4B4E-BFA1-A24EF62946FA@qt.io> <833e801049d7d35ed1dab558afafd7fb.squirrel@squirrel.six.silmor.de> <45E55A9F-D3E3-4FC4-B239-74E2BBBA7AFC@qt.io> <20180201111913.GC14103@troll08> <475241517484976@web4j.yandex.ru> <9ABE2AC4-87A1-4F9F-8543-5DCA73D8B79F@qt.io> <20180201145307.GE14103@troll08> Message-ID: Lars Knoll wrote: > * Instead we put our focus on getting 5.11 out as quickly as we can. Let’s > branch now, create first alpha and then beta packages as quickly as > possible. Not having to merge from 5.10 will ease this significantly. > Getting 5.11 out quick will hopefully also make Webengine not fall too > far/long behind upstream security patches. We are now in early February. By your schedule, 5.11 will be out on the last day of May. That's a whopping 4 months without a Qt release from the current (non-LTS) branch! In that time, at least 2 batches of Chromium security updates will happen. And that does not even account for the inevitable slips that consistently happen. If this decision is now final, you are really telling your users to get lost! :-( Kevin Kofler From hein at kde.org Thu Feb 8 08:22:24 2018 From: hein at kde.org (Eike Hein) Date: Thu, 8 Feb 2018 16:22:24 +0900 Subject: [Development] Deprecation of Qt Quick Controls 1 In-Reply-To: References: Message-ID: <92412fb9-35b1-f17e-00fb-48f5909d222e@kde.org> Hi, in addition, kde.org ships a qqc2-desktop-style for Controls 2 that implements QStyle theming (it's an improved derivative of the code used in qqc1) and has no other KDE dependencies. It's viable to ship with an app, and available in most distributions as a system package as well as inside KDE's Flatpak runtime. It's not been tested much outside of X11, Wayland and win32, though. We've mostly transitioned to qqc2 even for desktoppy things on the back of this style, modulo some remaining gripes with the qqc2 combobox, IIRC. (We've had a talk about upstreaming this work but it stalled a while back.) Cheers, Eike From hein at kde.org Thu Feb 8 08:30:09 2018 From: hein at kde.org (Eike Hein) Date: Thu, 8 Feb 2018 16:30:09 +0900 Subject: [Development] Deprecation of Qt Quick Controls 1 In-Reply-To: References: <008c01d3a014$8a7aa580$9f6ff080$@gmail.com> <193391518013521@web37j.yandex.ru> Message-ID: <5e13fb7a-e69a-af72-f603-1b26c1dd25ca@kde.org> On 02/08/2018 12:27 PM, Kevin Kofler wrote: > NIkolai Marchenko wrote: >> even stuff like that? >> https://imgur.com/a/tTFeO > > Maybe try using QListWidget::setItemWidget? That should even let you assign > some widget layed out in Qt Designer. The KWidgetItemDelegate class in KDE's KItemViews library (which has no other KDE dependencies) is also quite convenient for things like this and used in KDE apps for complex item views with widget-embedding delegates. Cheers, Eike From thiago.macieira at intel.com Thu Feb 8 08:35:46 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 07 Feb 2018 23:35:46 -0800 Subject: [Development] Qt branches & proposal how to continue with those In-Reply-To: References: Message-ID: <14795953.F2orM6F176@tjmaciei-mobl1> On Wednesday, 7 February 2018 19:32:25 PST Kevin Kofler wrote: > We are now in early February. By your schedule, 5.11 will be out on the last > day of May. That's a whopping 4 months without a Qt release from the > current (non-LTS) branch! In that time, at least 2 batches of Chromium > security updates will happen. And that does not even account for the > inevitable slips that consistently happen. I want to point out that we appeared to have fixed our release problems. The last time we had released a .2, aside from the LTS 5.6.2, was 5.4.2. But we HAD fixed the problem. 5.9.2 was released before 5.10.0. In fact, even 5.9.3 was released before 5.10.0. This means we managed TWO releases between 5.9.1 and 5.10.0. Taking this to the case now, it would allow us to release 5.9.5 and 5.10.2 before 5.11.0 if we wanted to. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From andras.mantia at kdab.com Thu Feb 8 08:45:43 2018 From: andras.mantia at kdab.com (Andras Mantia) Date: Thu, 08 Feb 2018 09:45:43 +0200 Subject: [Development] Deprecation of Qt Quick Controls 1 In-Reply-To: <92412fb9-35b1-f17e-00fb-48f5909d222e@kde.org> References: <92412fb9-35b1-f17e-00fb-48f5909d222e@kde.org> Message-ID: <8690260.zPGxmFUUXI@stein.andtib> Hi, On Thursday, February 8, 2018 9:22:24 AM EET Eike Hein wrote: > Hi, > > in addition, kde.org ships a qqc2-desktop-style for Controls 2 that > implements QStyle theming (it's an improved derivative of the code > used in qqc1) and has no other KDE dependencies. It's viable to ship > with an app, and available in most distributions as a system package > as well as inside KDE's Flatpak runtime. It's not been tested much > outside of X11, Wayland and win32, though. Note, that the style KDE installs can interfere with your own customizations done for QQC2 items. I've seen this with Qt 3D Studio for example. So there is still work to done in this area. Andras -- András Mantia | andras.mantia at kdab.com | Senior Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - The Qt Experts From lars.knoll at qt.io Thu Feb 8 09:17:34 2018 From: lars.knoll at qt.io (Lars Knoll) Date: Thu, 8 Feb 2018 08:17:34 +0000 Subject: [Development] Qt branches & proposal how to continue with those In-Reply-To: <14795953.F2orM6F176@tjmaciei-mobl1> References: <14795953.F2orM6F176@tjmaciei-mobl1> Message-ID: > On 8 Feb 2018, at 08:35, Thiago Macieira wrote: > > On Wednesday, 7 February 2018 19:32:25 PST Kevin Kofler wrote: >> We are now in early February. By your schedule, 5.11 will be out on the last >> day of May. That's a whopping 4 months without a Qt release from the >> current (non-LTS) branch! In that time, at least 2 batches of Chromium >> security updates will happen. And that does not even account for the >> inevitable slips that consistently happen. > > I want to point out that we appeared to have fixed our release problems. The > last time we had released a .2, aside from the LTS 5.6.2, was 5.4.2. Yes, I think we have fixed most of the problems related to getting releases out. What we haven’t yet fixed good enough is how to work with 5 open branches at the same time. The cost of handling those is largely invisible to those not doing the work, but it’s there. The merges from one branch to the next plus updates to qt5.git are the main problem here. Those do cost a lot of time and effort that go away from bug fixing and testing. > > But we HAD fixed the problem. 5.9.2 was released before 5.10.0. In fact, even > 5.9.3 was released before 5.10.0. This means we managed TWO releases between > 5.9.1 and 5.10.0. Taking this to the case now, it would allow us to release > 5.9.5 and 5.10.2 before 5.11.0 if we wanted to. Most of the releases were done form 5.9, where we do not have a problem that we need to merge changes from another branch. But getting 5.10 out was again pretty painful due to the merges from 5.9. We often had very long times between successful qt5.git updates. Having one additional branch with both 5.10 and 5.11 and dev where we need to cascade merges will make that problem quite a bit bigger. So we’re still not in the world I’d like to have where we can handle multiple branches in a good way. This is something we need to try to solve and find ways to handle better. One thing we’re doing currently is adding more capacity to CI. This has been a bottleneck that was slowing down merges and qt5.git updates. Better capacity should be in place in early spring. The other thing I believe we need to do is to find ways to automate merges between branches and do those one a more continuous basis. Currently we often ended up waiting many days until a fix had been merged into all relevant branches, leading to delays in different places. Ideally those merges should happen daily, not once every two weeks. If required, we could probably still do a 5.10.2, but if we do it, I’d like to limit that one to security issues, and avoid the long merge chain from 5.10 to dev until we have figured out how to handle that better. Cheers, Lars From lars.knoll at qt.io Thu Feb 8 09:17:35 2018 From: lars.knoll at qt.io (Lars Knoll) Date: Thu, 8 Feb 2018 08:17:35 +0000 Subject: [Development] Qt branches & proposal how to continue with those In-Reply-To: <14795953.F2orM6F176@tjmaciei-mobl1> References: <14795953.F2orM6F176@tjmaciei-mobl1> Message-ID: <17B4ADFE-8FBC-4899-BFD0-70AB2A68A706@qt.io> > On 8 Feb 2018, at 08:35, Thiago Macieira wrote: > > On Wednesday, 7 February 2018 19:32:25 PST Kevin Kofler wrote: >> We are now in early February. By your schedule, 5.11 will be out on the last >> day of May. That's a whopping 4 months without a Qt release from the >> current (non-LTS) branch! In that time, at least 2 batches of Chromium >> security updates will happen. And that does not even account for the >> inevitable slips that consistently happen. > > I want to point out that we appeared to have fixed our release problems. The > last time we had released a .2, aside from the LTS 5.6.2, was 5.4.2. Yes, I think we have fixed most of the problems related to getting releases out. What we haven’t yet fixed good enough is how to work with 5 open branches at the same time. The cost of handling those is largely invisible to those not doing the work, but it’s there. The merges from one branch to the next plus updates to qt5.git are the main problem here. Those do cost a lot of time and effort that go away from bug fixing and testing. > > But we HAD fixed the problem. 5.9.2 was released before 5.10.0. In fact, even > 5.9.3 was released before 5.10.0. This means we managed TWO releases between > 5.9.1 and 5.10.0. Taking this to the case now, it would allow us to release > 5.9.5 and 5.10.2 before 5.11.0 if we wanted to. Most of the releases were done form 5.9, where we do not have a problem that we need to merge changes from another branch. But getting 5.10 out was again pretty painful due to the merges from 5.9. We often had very long times between successful qt5.git updates. Having one additional branch with both 5.10 and 5.11 and dev where we need to cascade merges will make that problem quite a bit bigger. So we’re still not in the world I’d like to have where we can handle multiple branches in a good way. This is something we need to try to solve and find ways to handle better. One thing we’re doing currently is adding more capacity to CI. This has been a bottleneck that was slowing down merges and qt5.git updates. Better capacity should be in place in early spring. The other thing I believe we need to do is to find ways to automate merges between branches and do those one a more continuous basis. Currently we often ended up waiting many days until a fix had been merged into all relevant branches, leading to delays in different places. Ideally those merges should happen daily, not once every two weeks. If required, we could probably still do a 5.10.2, but if we do it, I’d like to limit that one to security issues, and avoid the long merge chain from 5.10 to dev until we have figured out how to handle that better. Cheers, Lars From christian.gudrian at aucos.de Thu Feb 8 09:54:29 2018 From: christian.gudrian at aucos.de (Christian Gudrian) Date: Thu, 8 Feb 2018 09:54:29 +0100 Subject: [Development] Remote Objects: How to deal with inheritance Message-ID: <70f56dd1-d29d-bdd7-b755-0cc570e442fe@aucos.de> Hello! Currently the (generated) replica always derive from QRemoteObjectReplica. What if the source objects form an inheritance hierarchy? Given two source classes "Base" and "Derived" (which derives from "Base") the generated class "DerivedReplica" does not expose the "Base" API. Can I safely modify the generated source to have "DerivedReplica" derive from "BaseReplica"? Christian -- Christian Gudrian AUCOS AG, Matthiashofstraße 47–49, 52064 Aachen, Germany From annulen at yandex.ru Thu Feb 8 10:07:48 2018 From: annulen at yandex.ru (Konstantin Tokarev) Date: Thu, 08 Feb 2018 12:07:48 +0300 Subject: [Development] Qt branches & proposal how to continue with those In-Reply-To: References: <14795953.F2orM6F176@tjmaciei-mobl1> Message-ID: <234911518080868@web5g.yandex.ru> 08.02.2018, 11:17, "Lars Knoll" : >>  On 8 Feb 2018, at 08:35, Thiago Macieira wrote: >> >>  On Wednesday, 7 February 2018 19:32:25 PST Kevin Kofler wrote: >>>  We are now in early February. By your schedule, 5.11 will be out on the last >>>  day of May. That's a whopping 4 months without a Qt release from the >>>  current (non-LTS) branch! In that time, at least 2 batches of Chromium >>>  security updates will happen. And that does not even account for the >>>  inevitable slips that consistently happen. >> >>  I want to point out that we appeared to have fixed our release problems. The >>  last time we had released a .2, aside from the LTS 5.6.2, was 5.4.2. > > Yes, I think we have fixed most of the problems related to getting releases out. What we haven’t yet fixed good enough is how to work with 5 open branches at the same time. The cost of handling those is largely invisible to those not doing the work, but it’s there. The merges from one branch to the next plus updates to qt5.git are the main problem here. Those do cost a lot of time and effort that go away from bug fixing and testing. > >>  But we HAD fixed the problem. 5.9.2 was released before 5.10.0. In fact, even >>  5.9.3 was released before 5.10.0. This means we managed TWO releases between >>  5.9.1 and 5.10.0. Taking this to the case now, it would allow us to release >>  5.9.5 and 5.10.2 before 5.11.0 if we wanted to. > > Most of the releases were done form 5.9, where we do not have a problem that we need to merge changes from another branch. But getting 5.10 out was again pretty painful due to the merges from 5.9. We often had very long times between successful qt5.git updates. Having one additional branch with both 5.10 and 5.11 and dev where we need to cascade merges will make that problem quite a bit bigger. > > So we’re still not in the world I’d like to have where we can handle multiple branches in a good way. This is something we need to try to solve and find ways to handle better. > > One thing we’re doing currently is adding more capacity to CI. This has been a bottleneck that was slowing down merges and qt5.git updates. Better capacity should be in place in early spring. Have you considered assigning priorities to CI jobs? > > The other thing I believe we need to do is to find ways to automate merges between branches and do those one a more continuous basis. Currently we often ended up waiting many days until a fix had been merged into all relevant branches, leading to delays in different places. Ideally those merges should happen daily, not once every two weeks. > > If required, we could probably still do a 5.10.2, but if we do it, I’d like to limit that one to security issues, and avoid the long merge chain from 5.10 to dev until we have figured out how to handle that better. > > Cheers, > Lars > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From kotov.valery at gmail.com Thu Feb 8 10:39:45 2018 From: kotov.valery at gmail.com (Valery Kotov) Date: Thu, 8 Feb 2018 10:39:45 +0100 Subject: [Development] JavaScript Promise implementation, Promise.all capability-executor-not-callable test case Message-ID: Dear all, I'm working on JS Promise implementation: https://codereview.qt-project.org/#/c/122066/ https://codereview.qt-project.org/#/c/122066/ I also would like the implementation to pass official ECMAScript test suite . Though I faced some difficulty to understand certain test cases. E.g. notion of "IsCallable" seems to be a bit unclear to me. It is stated here: "8. If IsCallable(promiseCapability.[[Resolve]]) is false, throw a TypeError exception." "9. If IsCallable(promiseCapability.[[Reject]]) is false, throw a TypeError exception." Presumably the statement is supposed to be proved by test cases in the file. E.g. var checkPoint = ""; assert.throws(TypeError, function() { Promise.all.call(function(executor) { checkPoint += "a"; executor(undefined, undefined); checkPoint += "b"; }, []); }, "executor called with (undefined, undefined)"); assert.sameValue(checkPoint, "ab", "executor called with (undefined, undefined)"); The conclusion I could make looking at this, both check points should pass and no exception should be raised during "executor(undefined, undefined)" call. But does that mean "IsCallable(undefined) === true"? Which is a bit confusing, sine one could get completely opposite conclusion for example from the test here . To be honest, ECMAScript spec does not seem to be very helpful as well since notion of callable object is a bit vague: https://www.ecma-international.org/ecma-262/8.0/index.html#sec-iscallable https://www.ecma-international.org/ecma-262/8.0/index.html#sec-iscallable Also, unfortunately, I could not find clear answer in official tests for "undefined": https://github.com/tc39/test262/tree/da4f4385fdf88ff2c8acf036efaaa62f8cd6bd58/test/built-ins/undefined It feels a bit like a contradiction. Thus, I'm a bit puzzled how to go about it. Am I missing something? I would appreciate some help or hints! Sincerely yours, Valery Kotov -------------- next part -------------- An HTML attachment was scrubbed... URL: From lars.knoll at qt.io Thu Feb 8 14:01:39 2018 From: lars.knoll at qt.io (Lars Knoll) Date: Thu, 8 Feb 2018 13:01:39 +0000 Subject: [Development] JavaScript Promise implementation, Promise.all capability-executor-not-callable test case In-Reply-To: References: Message-ID: Hi Valery, Great you’re looking into this :) I’ve also recently started working on some more support for ES6. One of the first things from my side will probably be support for Symbol, as that is a basis for quite a bit of the other functionality. On 8 Feb 2018, at 10:39, Valery Kotov > wrote: Dear all, I'm working on JS Promise implementation: https://codereview.qt-project.org/#/c/122066/https://codereview.qt-project.org/#/c/122066/ I also would like the implementation to pass official ECMAScript test suite. Though I faced some difficulty to understand certain test cases. E.g. notion of "IsCallable" seems to be a bit unclear to me. It is stated here: "8. If IsCallable(promiseCapability.[[Resolve]]) is false, throw a TypeError exception." "9. If IsCallable(promiseCapability.[[Reject]]) is false, throw a TypeError exception." Presumably the statement is supposed to be proved by test cases in the file. E.g. var checkPoint = ""; assert.throws(TypeError, function() { Promise.all.call(function(executor) { checkPoint += "a"; executor(undefined, undefined); checkPoint += "b"; }, []); }, "executor called with (undefined, undefined)"); assert.sameValue(checkPoint, "ab", "executor called with (undefined, undefined)"); The conclusion I could make looking at this, both check points should pass and no exception should be raised during "executor(undefined, undefined)" call. But does that mean "IsCallable(undefined) === true”? No, IsCallable(x) basically means that x is a FunctionObject. As far as I understand the test case you quote above, it implies that the code snippet will throw a TypeError, in line with chapter 25.4.1.4 point 8 and 9 of the spec. Which is a bit confusing, sine one could get completely opposite conclusion for example from the test here. To be honest, ECMAScript spec does not seem to be very helpful as well since notion of callable object is a bit vague: https://www.ecma-international.org/ecma-262/8.0/index.html#sec-iscallablehttps://www.ecma-international.org/ecma-262/8.0/index.html#sec-iscallable Also, unfortunately, I could not find clear answer in official tests for "undefined": https://github.com/tc39/test262/tree/da4f4385fdf88ff2c8acf036efaaa62f8cd6bd58/test/built-ins/undefined IsCallable(undefined) is false, simply because it’s not an Object. The argument also needs a [[Call]] internal slot, which is only the case for FunctionObject’s. It feels a bit like a contradiction. Thus, I'm a bit puzzled how to go about it. Am I missing something? I would appreciate some help or hints! With the above, I don’t think there’s a contradiction. Hope this helps you further. Let me know when you want me to have a closer look at your patches and review them. Cheers, Lars Sincerely yours, Valery Kotov _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From frederik.gladhorn at qt.io Thu Feb 8 15:41:02 2018 From: frederik.gladhorn at qt.io (Frederik Gladhorn) Date: Thu, 08 Feb 2018 15:41:02 +0100 Subject: [Development] Deprecation of Qt Quick Controls 1 In-Reply-To: References: Message-ID: <2931282.ZxLgNLDoPa@frederik-thinkcentre-m93p> Thanks for the feedback :) Seems like this was a good point to send the mail and we became aware that many of you are struggling with the ComboBoxes in Controls 2. Improving that makes a lot of sense for us then. Note that we are not going to make the module magically disappear for the moment, it will still be part of Qt releases for the time being. This was to check what we have left to do to allow a happy transition and prepare and nudge everyone else to move to Controls 2. Cheers, Frederik On onsdag 7. februar 2018 13.48.21 CET Frederik Gladhorn wrote: > Hi all, > > It should come as no big surprise that we are not working much on Qt Quick > Controls 1. After some discussions inside The Qt Company, we concluded that > it would make sense to clarify the situation. We see the value Controls 1 > provides - more platform native styling - but it comes at a high price. > > Performance is very problematic with the module and we now offer more modern > styles in Controls 2. In addition customizing the styles in Controls 2 is > possible in different ways. There is the image based style that is > especially accessible to graphical designers. There is the general styling > that has become really cheap now (thanks to the deferred execution > patches), so replacing parts of the ready-made controls does come at no > cost. Finally writing a completely custom style is entirely possible, using > the logic of Controls 2 as building blocks. In fact I see Controls 2 as > being part of Qt Quick, the part that has been missing for a long time and > that completes the story to make developing applications with Qt Quick > easy. With the recent updates to the Qt Quick Designer in Qt Creator and > additions to make Controls 2 more desktop friendly for modern applications, > I'd recommend everyone to move over. > > Next to that we have picked up Qt Widgets lately again and fixes are making > their way into the module. For applications that need to look and behave > like traditional desktop applications, this is an alternative. > > As you can see, the effort is currently split and we'd like to reduce the > attention to the two big areas - Widgets and Quick with Controls 2. This > means we will spend even less time on Controls 1, where we'll only fix > critical issues in the future. > > As always, feedback welcome :) > > Cheers, > Frederik From thiago.macieira at intel.com Thu Feb 8 19:45:54 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 8 Feb 2018 10:45:54 -0800 Subject: [Development] Suggestion: switch binary builds to OpenSSL 1.1 in Qt 5.11 Message-ID: <3028229.9F9WlbBkjx@tjmaciei-mobl1> As $SUBJECT says. Only for 5.11 onward, so shouldn't affect the 5.6 and 5.9 LTS (which don't have OpenSSL 1.1 support anyway) or any 5.10.x releases still to come. As a bonus side-effect, users who hadn't realised they have an old, not-up-to- date OpenSSL will have to fix the issue. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From rich at kde.org Thu Feb 8 21:48:52 2018 From: rich at kde.org (Richard Moore) Date: Thu, 8 Feb 2018 20:48:52 +0000 Subject: [Development] Suggestion: switch binary builds to OpenSSL 1.1 in Qt 5.11 In-Reply-To: <3028229.9F9WlbBkjx@tjmaciei-mobl1> References: <3028229.9F9WlbBkjx@tjmaciei-mobl1> Message-ID: On 8 February 2018 at 18:45, Thiago Macieira wrote: > As $SUBJECT says. > > Only for 5.11 onward, so shouldn't affect the 5.6 and 5.9 LTS (which don't > have OpenSSL 1.1 support anyway) or any 5.10.x releases still to come. > > As a bonus side-effect, users who hadn't realised they have an old, > not-up-to- > date OpenSSL will have to fix the issue. > > ​ +1 those who need to use an older version will still be able to build their own. We really need to start actively pushing people to 1.1. Cheers Rich. -------------- next part -------------- An HTML attachment was scrubbed... URL: From apoenitz at t-online.de Thu Feb 8 23:07:33 2018 From: apoenitz at t-online.de (=?iso-8859-1?Q?Andr=E9_P=F6nitz?=) Date: Thu, 8 Feb 2018 23:07:33 +0100 Subject: [Development] Qt branches & proposal how to continue with those In-Reply-To: References: <3586F83C-F715-4B4E-BFA1-A24EF62946FA@qt.io> <833e801049d7d35ed1dab558afafd7fb.squirrel@squirrel.six.silmor.de> <45E55A9F-D3E3-4FC4-B239-74E2BBBA7AFC@qt.io> <20180201111913.GC14103@troll08> <475241517484976@web4j.yandex.ru> <9ABE2AC4-87A1-4F9F-8543-5DCA73D8B79F@qt.io> <20180201145307.GE14103@troll08> Message-ID: <20180208220733.GB1702@klara.mpi.htwm.de> On Thu, Feb 08, 2018 at 04:32:25AM +0100, Kevin Kofler wrote: > Lars Knoll wrote: > > * Instead we put our focus on getting 5.11 out as quickly as we can. Let’s > > branch now, create first alpha and then beta packages as quickly as > > possible. Not having to merge from 5.10 will ease this significantly. > > Getting 5.11 out quick will hopefully also make Webengine not fall too > > far/long behind upstream security patches. > > We are now in early February. By your schedule, 5.11 will be out on the last > day of May. That's a whopping 4 months without a Qt release from the current > (non-LTS) branch! In that time, at least 2 batches of Chromium security > updates will happen. And that does not even account for the inevitable slips > that consistently happen. > > If this decision is now final, you are really telling your users to get > lost! :-( I think you need to start differentiating between Qt-without-Webengine and QtWebengine. And maybe "we" should do that, too. Andre' From andy.shaw at qt.io Fri Feb 9 07:44:01 2018 From: andy.shaw at qt.io (Andy Shaw) Date: Fri, 9 Feb 2018 06:44:01 +0000 Subject: [Development] Suggestion: switch binary builds to OpenSSL 1.1 in Qt 5.11 In-Reply-To: References: <3028229.9F9WlbBkjx@tjmaciei-mobl1> Message-ID: + 1 from me too. Is it clear enough from the docs for 5.9 and 5.10 that it does not support OpenSSL 1.1? In case someone still uses that and ends up replacing their existing installation of OpenSSL without realizing. Andy Fra: Development på vegne av Moore Richard Dato: torsdag 8. februar 2018 21.48 Til: "development at qt-project.org" Emne: Re: [Development] Suggestion: switch binary builds to OpenSSL 1.1 in Qt 5.11 On 8 February 2018 at 18:45, Thiago Macieira > wrote: As $SUBJECT says. Only for 5.11 onward, so shouldn't affect the 5.6 and 5.9 LTS (which don't have OpenSSL 1.1 support anyway) or any 5.10.x releases still to come. As a bonus side-effect, users who hadn't realised they have an old, not-up-to- date OpenSSL will have to fix the issue. ​ +1 those who need to use an older version will still be able to build their own. We really need to start actively pushing people to 1.1. Cheers Rich. -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Fri Feb 9 07:51:34 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 8 Feb 2018 22:51:34 -0800 Subject: [Development] Suggestion: switch binary builds to OpenSSL 1.1 in Qt 5.11 In-Reply-To: References: <3028229.9F9WlbBkjx@tjmaciei-mobl1> Message-ID: <1729216.nSAhlEB5yn@tjmaciei-mobl1> On Thursday, 8 February 2018 22:44:01 PST Andy Shaw wrote: > + 1 from me too. > > Is it clear enough from the docs for 5.9 and 5.10 that it does not support > OpenSSL 1.1? In case someone still uses that and ends up replacing their > existing installation of OpenSSL without realizing. No, because we never had to tell people that it didn't work with a version that didn't exist at the time the docs were written. When support was added to 5.10, we didn't update the docs. But I have seen more than once in #qt channel that people install OpenSSL 1.1 and then have problems. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From kevin.kofler at chello.at Fri Feb 9 07:52:35 2018 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 09 Feb 2018 07:52:35 +0100 Subject: [Development] Qt branches & proposal how to continue with those References: <3586F83C-F715-4B4E-BFA1-A24EF62946FA@qt.io> <833e801049d7d35ed1dab558afafd7fb.squirrel@squirrel.six.silmor.de> <45E55A9F-D3E3-4FC4-B239-74E2BBBA7AFC@qt.io> <20180201111913.GC14103@troll08> <475241517484976@web4j.yandex.ru> <9ABE2AC4-87A1-4F9F-8543-5DCA73D8B79F@qt.io> <20180201145307.GE14103@troll08> <20180208220733.GB1702@klara.mpi.htwm.de> Message-ID: André Pönitz wrote: > I think you need to start differentiating between Qt-without-Webengine > and QtWebengine. > > And maybe "we" should do that, too. I would be entirely in favor of separate (more frequent and/or more aligned with Chromium security fixes) QtWebEngine releases. I am already updating QtWebEngine in Fedora on a separate schedule from the core Qt updates (with the intent of delivering security updates faster), so it would not be a problem for me if the releases were entirely separate. And it would surely get security fixes delivered in a more timely manner. Kevin Kofler From kevin.kofler at chello.at Fri Feb 9 08:02:36 2018 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 09 Feb 2018 08:02:36 +0100 Subject: [Development] Qt branches & proposal how to continue with those References: <14795953.F2orM6F176@tjmaciei-mobl1> Message-ID: Lars Knoll wrote: > One thing we’re doing currently is adding more capacity to CI. This has > been a bottleneck that was slowing down merges and qt5.git updates. Better > capacity should be in place in early spring. (Disclaimer: The following proposal may sound "insane" to you. I also do not have any kind of decision power here in Qt. Still, I cannot resist the urge to formulate it.) IMHO, you need to rethink your whole CI approach. This is increasingly being the one bottleneck slowing down Qt development and releases. It might make more sense to try a different approach, such as allowing all commits through initially, then making CI runs at regular intervals, and triggering reverts if things broke. Qt is being developed very much as a corporate project. (I write "as" rather than "like" because that's what Qt is, despite Open Governance.) It would help to look at how community Free Software projects do things. They tend to be more efficient. And some company-developed Free Software projects have already adopted such processes. Just my 2 cents as a (mostly) packager and application developer. Kevin Kofler From thiago.macieira at intel.com Fri Feb 9 08:13:01 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 8 Feb 2018 23:13:01 -0800 Subject: [Development] Qt branches & proposal how to continue with those In-Reply-To: References: Message-ID: <14514062.8z7eoau313@tjmaciei-mobl1> On Thursday, 8 February 2018 23:02:36 PST Kevin Kofler wrote: > IMHO, you need to rethink your whole CI approach. This is increasingly being > the one bottleneck slowing down Qt development and releases. It might make > more sense to try a different approach, such as allowing all commits > through initially, then making CI runs at regular intervals, and triggering > reverts if things broke. Which will happen ALL the time. We'll never get back down: when we released Qt 4.2, 4.3 and 4.4, we were happy if only 10 tests failed (that only happened for QWS). For the other platforms, the normal number was a hundred tests failing. Then we spent weeks trying to get the number down. Sorry, I don't want to go back to that. > Qt is being developed very much as a corporate project. (I write "as" rather > than "like" because that's what Qt is, despite Open Governance.) It would > help to look at how community Free Software projects do things. They tend > to be more efficient. And some company-developed Free Software projects > have already adopted such processes. It would not do us well to look at poorer practices than what we have. Just because everyone else is where we were 10 years ago is no reason for us to go back to it. Show us a *better* model, one that still prevents failures from being added, and we'll consider it. The only one I know that fits the bill is the OpenStack model. Like Qt's, staged commits get tested *before* they are added to the mainline. The difference is that they have a massive datacenter, so they can run more quickly. They have even enough spare capacity to bisect the commits being added and figure out which one introduced the failure. We can't do that. > Just my 2 cents as a (mostly) packager and application developer. And my 2 cents as a core developer, maintainer, open source & community expert, and someone who has followed the subject for the past 12 years. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From lars.knoll at qt.io Fri Feb 9 08:51:23 2018 From: lars.knoll at qt.io (Lars Knoll) Date: Fri, 9 Feb 2018 07:51:23 +0000 Subject: [Development] Qt branches & proposal how to continue with those In-Reply-To: <14514062.8z7eoau313@tjmaciei-mobl1> References: <14514062.8z7eoau313@tjmaciei-mobl1> Message-ID: <1FE342CE-2A8F-45E5-95C8-01E1100A8769@qt.io> > On 9 Feb 2018, at 08:13, Thiago Macieira wrote: > > On Thursday, 8 February 2018 23:02:36 PST Kevin Kofler wrote: >> IMHO, you need to rethink your whole CI approach. This is increasingly being >> the one bottleneck slowing down Qt development and releases. It might make >> more sense to try a different approach, such as allowing all commits >> through initially, then making CI runs at regular intervals, and triggering >> reverts if things broke. > > Which will happen ALL the time. We'll never get back down: when we released Qt > 4.2, 4.3 and 4.4, we were happy if only 10 tests failed (that only happened > for QWS). For the other platforms, the normal number was a hundred tests > failing. Then we spent weeks trying to get the number down. > > Sorry, I don't want to go back to that. I 100% agree with Thiago. We’ve been there, tried that and it didn’t work. > >> Qt is being developed very much as a corporate project. (I write "as" rather >> than "like" because that's what Qt is, despite Open Governance.) It would >> help to look at how community Free Software projects do things. They tend >> to be more efficient. And some company-developed Free Software projects >> have already adopted such processes. > > It would not do us well to look at poorer practices than what we have. Just > because everyone else is where we were 10 years ago is no reason for us to go > back to it. Show us a *better* model, one that still prevents failures from > being added, and we'll consider it. > > The only one I know that fits the bill is the OpenStack model. Like Qt's, > staged commits get tested *before* they are added to the mainline. The > difference is that they have a massive datacenter, so they can run more > quickly. They have even enough spare capacity to bisect the commits being > added and figure out which one introduced the failure. We can't do that. This is what we’re trying to fix by improving our CI capacity. I believe there are more things we need to do, but speeding up our turnaround time in CI is one of the most important things here. The rest is stability of the system and flaky tests. Both are things we need to work on. > >> Just my 2 cents as a (mostly) packager and application developer. > > And my 2 cents as a core developer, maintainer, open source & community > expert, and someone who has followed the subject for the past 12 years. Cheers, Lars From lars.knoll at qt.io Fri Feb 9 08:54:02 2018 From: lars.knoll at qt.io (Lars Knoll) Date: Fri, 9 Feb 2018 07:54:02 +0000 Subject: [Development] Qt branches & proposal how to continue with those In-Reply-To: References: <3586F83C-F715-4B4E-BFA1-A24EF62946FA@qt.io> <833e801049d7d35ed1dab558afafd7fb.squirrel@squirrel.six.silmor.de> <45E55A9F-D3E3-4FC4-B239-74E2BBBA7AFC@qt.io> <20180201111913.GC14103@troll08> <475241517484976@web4j.yandex.ru> <9ABE2AC4-87A1-4F9F-8543-5DCA73D8B79F@qt.io> <20180201145307.GE14103@troll08> <20180208220733.GB1702@klara.mpi.htwm.de> Message-ID: > On 9 Feb 2018, at 07:52, Kevin Kofler wrote: > > André Pönitz wrote: >> I think you need to start differentiating between Qt-without-Webengine >> and QtWebengine. >> >> And maybe "we" should do that, too. > > I would be entirely in favor of separate (more frequent and/or more aligned > with Chromium security fixes) QtWebEngine releases. I am already updating > QtWebEngine in Fedora on a separate schedule from the core Qt updates (with > the intent of delivering security updates faster), so it would not be a > problem for me if the releases were entirely separate. And it would surely > get security fixes delivered in a more timely manner. We’ve been discussing this in the past, and most people agreed that releasing QtWebEngine on an independent schedule would be a good thing. But there’s still a couple of things that need sorting out before that can happen, both in the CI and how we create/package our product and SDK as well as in QtWebengine which for example still uses private API of some other parts of Qt. Cheers, Lars From timur.pocheptsov at qt.io Fri Feb 9 09:42:55 2018 From: timur.pocheptsov at qt.io (Timur Pocheptsov) Date: Fri, 9 Feb 2018 08:42:55 +0000 Subject: [Development] Suggestion: switch binary builds to OpenSSL 1.1 in Qt 5.11 In-Reply-To: References: <3028229.9F9WlbBkjx@tjmaciei-mobl1> , Message-ID: Andy, do you have any feedback from our customers about this? My anecdotal evidence so far - I have 0 bug-reports complaining they see a message: "Incompatible version of OpenSSL" (qsslsocket_openssl_symbols.cpp, line 1025), this means for me people using our binaries mostly have OpenSSL version below 1.1. Best regards, Timur. ________________________________ From: Development on behalf of Andy Shaw Sent: Friday, February 9, 2018 7:44:01 AM To: Richard Moore; development at qt-project.org Subject: Re: [Development] Suggestion: switch binary builds to OpenSSL 1.1 in Qt 5.11 + 1 from me too. Is it clear enough from the docs for 5.9 and 5.10 that it does not support OpenSSL 1.1? In case someone still uses that and ends up replacing their existing installation of OpenSSL without realizing. Andy Fra: Development på vegne av Moore Richard Dato: torsdag 8. februar 2018 21.48 Til: "development at qt-project.org" Emne: Re: [Development] Suggestion: switch binary builds to OpenSSL 1.1 in Qt 5.11 On 8 February 2018 at 18:45, Thiago Macieira > wrote: As $SUBJECT says. Only for 5.11 onward, so shouldn't affect the 5.6 and 5.9 LTS (which don't have OpenSSL 1.1 support anyway) or any 5.10.x releases still to come. As a bonus side-effect, users who hadn't realised they have an old, not-up-to- date OpenSSL will have to fix the issue. ​ +1 those who need to use an older version will still be able to build their own. We really need to start actively pushing people to 1.1. Cheers Rich. -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy.shaw at qt.io Fri Feb 9 09:45:38 2018 From: andy.shaw at qt.io (Andy Shaw) Date: Fri, 9 Feb 2018 08:45:38 +0000 Subject: [Development] Suggestion: switch binary builds to OpenSSL 1.1 in Qt 5.11 In-Reply-To: References: <3028229.9F9WlbBkjx@tjmaciei-mobl1> Message-ID: <934F6DB4-2C19-4120-A21B-01EA31A12FAA@qt.io> I have had some people upgrading to 1.1 and asking us why it doesn’t work, so we have told them to downgrade explaining why. I think it is the right thing to do with the upgrade to 1.1, but I just want to try and prevent people overwriting their existing version if they are using older versions of Qt still so it doesn’t get in the way of that. They just need to make sure they install OpenSSL 1.1 to a different location then. Andy Fra: Timur Pocheptsov Dato: fredag 9. februar 2018 09.42 Til: Andy Shaw , Moore Richard , "development at qt-project.org" Emne: Re: [Development] Suggestion: switch binary builds to OpenSSL 1.1 in Qt 5.11 Andy, do you have any feedback from our customers about this? My anecdotal evidence so far - I have 0 bug-reports complaining they see a message: "Incompatible version of OpenSSL" (qsslsocket_openssl_symbols.cpp, line 1025), this means for me people using our binaries mostly have OpenSSL version below 1.1. Best regards, Timur. ________________________________ From: Development on behalf of Andy Shaw Sent: Friday, February 9, 2018 7:44:01 AM To: Richard Moore; development at qt-project.org Subject: Re: [Development] Suggestion: switch binary builds to OpenSSL 1.1 in Qt 5.11 + 1 from me too. Is it clear enough from the docs for 5.9 and 5.10 that it does not support OpenSSL 1.1? In case someone still uses that and ends up replacing their existing installation of OpenSSL without realizing. Andy Fra: Development på vegne av Moore Richard Dato: torsdag 8. februar 2018 21.48 Til: "development at qt-project.org" Emne: Re: [Development] Suggestion: switch binary builds to OpenSSL 1.1 in Qt 5.11 On 8 February 2018 at 18:45, Thiago Macieira > wrote: As $SUBJECT says. Only for 5.11 onward, so shouldn't affect the 5.6 and 5.9 LTS (which don't have OpenSSL 1.1 support anyway) or any 5.10.x releases still to come. As a bonus side-effect, users who hadn't realised they have an old, not-up-to- date OpenSSL will have to fix the issue. ​ +1 those who need to use an older version will still be able to build their own. We really need to start actively pushing people to 1.1. Cheers Rich. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuukka.turunen at qt.io Fri Feb 9 10:11:26 2018 From: tuukka.turunen at qt.io (Tuukka Turunen) Date: Fri, 9 Feb 2018 09:11:26 +0000 Subject: [Development] Qt branches & proposal how to continue with those In-Reply-To: <1FE342CE-2A8F-45E5-95C8-01E1100A8769@qt.io> References: <14514062.8z7eoau313@tjmaciei-mobl1> <1FE342CE-2A8F-45E5-95C8-01E1100A8769@qt.io> Message-ID: <91EDFAFD-2D70-4B62-8506-DB253DCA395E@qt.io> On 09/02/2018, 9.51, "Development on behalf of Lars Knoll" wrote: > On 9 Feb 2018, at 08:13, Thiago Macieira wrote: > > On Thursday, 8 February 2018 23:02:36 PST Kevin Kofler wrote: >> IMHO, you need to rethink your whole CI approach. This is increasingly being >> the one bottleneck slowing down Qt development and releases. It might make >> more sense to try a different approach, such as allowing all commits >> through initially, then making CI runs at regular intervals, and triggering >> reverts if things broke. > > Which will happen ALL the time. We'll never get back down: when we released Qt > 4.2, 4.3 and 4.4, we were happy if only 10 tests failed (that only happened > for QWS). For the other platforms, the normal number was a hundred tests > failing. Then we spent weeks trying to get the number down. > > Sorry, I don't want to go back to that. I 100% agree with Thiago. We’ve been there, tried that and it didn’t work. Tuukka: Same here. We should continue to add automation and test coverage in different platforms, rather than reduce it. We need to get the infrastructure stability into shape and continue improving the test asset continuously. > >> Qt is being developed very much as a corporate project. (I write "as" rather >> than "like" because that's what Qt is, despite Open Governance.) It would >> help to look at how community Free Software projects do things. They tend >> to be more efficient. And some company-developed Free Software projects >> have already adopted such processes. > > It would not do us well to look at poorer practices than what we have. Just > because everyone else is where we were 10 years ago is no reason for us to go > back to it. Show us a *better* model, one that still prevents failures from > being added, and we'll consider it. > > The only one I know that fits the bill is the OpenStack model. Like Qt's, > staged commits get tested *before* they are added to the mainline. The > difference is that they have a massive datacenter, so they can run more > quickly. They have even enough spare capacity to bisect the commits being > added and figure out which one introduced the failure. We can't do that. This is what we’re trying to fix by improving our CI capacity. I believe there are more things we need to do, but speeding up our turnaround time in CI is one of the most important things here. The rest is stability of the system and flaky tests. Both are things we need to work on. Tuukka: Exactly. This is the first step, and it should help already significantly. In addition we need to solve the issues with multiple branches open, as discussed earlier. This probably needs some changes to the current practices, so that we can get the needed fixes faster to all branches. Capacity and stability need to be fixed first, but most likely are not enough. > >> Just my 2 cents as a (mostly) packager and application developer. > > And my 2 cents as a core developer, maintainer, open source & community > expert, and someone who has followed the subject for the past 12 years. Cheers, Lars _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From rjvbertin at gmail.com Fri Feb 9 11:17:19 2018 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Fri, 09 Feb 2018 11:17:19 +0100 Subject: [Development] Mac/Win: Let QIcon::fromTheme() return something appropriate even when no theme is defined? Message-ID: <2207332.JG3kuaNCyN@portia.local> Hi, Freedesktop.org icon themes contain icons with mime-type names that are accessible via QIcon::fromTheme() and widely used to use an appropriate image for document icons. On Mac, using setWindowFilePath() will also show an appropriate icon next to the document filename, and I presume MS Windows must have a similar functionality. Would it be feasible in QIcon::fromTheme() to retrieve and return those icons when the icon name is a mime-type, on Mac and/or MS Windows, when no theme is defined? R. From giuseppe.dangelo at kdab.com Fri Feb 9 11:59:31 2018 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Fri, 9 Feb 2018 11:59:31 +0100 Subject: [Development] Suggestion: switch binary builds to OpenSSL 1.1 in Qt 5.11 In-Reply-To: <3028229.9F9WlbBkjx@tjmaciei-mobl1> References: <3028229.9F9WlbBkjx@tjmaciei-mobl1> Message-ID: On 08/02/18 19:45, Thiago Macieira wrote: > Only for 5.11 onward, so shouldn't affect the 5.6 and 5.9 LTS (which don't > have OpenSSL 1.1 support anyway) or any 5.10.x releases still to come. > > As a bonus side-effect, users who hadn't realised they have an old, not-up-to- > date OpenSSL will have to fix the issue. However there's many users that *do* have realized that but are waiting on a new release of a distribution. I'm specifically looking at Ubuntu 16.04 LTS [1]. Ubuntu 18.04 LTS will have OpenSSL 1.1 [2] (it literally landed a few days ago [3]) but the first recommended upgrade for LTS users is 18.04.1 [4], which will came in Q3 with any luck (no data available yet, basing the estimate on 16.04.1 [5]). Centos 7 / RHEL 7 also have 1.0.2 [6]. OpenSUSE Leap 42.3 also has 1.0.2 [7]. Which made me think, are we even testing OpenSSL 1.1 in our CI? So I took this run on dev from a few days ago: > https://testresults.qt.io/coin/integration/qt/qtbase/tasks/1518126028 According to the logs, not a single configuration is building and testing the OpenSSL 1.1 support. In the light of everything above, I'm against this change for 5.11. The earliest acceptable would be 5.12, after announcing it in 5.11, and after adding significant coverage for it to the CI. My 2 cents, > [1] https://packages.ubuntu.com/xenial/openssl > [2] https://packages.ubuntu.com/bionic/openssl > [3] http://changelogs.ubuntu.com/changelogs/pool/main/o/openssl/openssl_1.1.0g-2ubuntu1/changelog > [4] https://help.ubuntu.com/lts/serverguide/installing-upgrading.html > [5] https://wiki.ubuntu.com/XenialXerus/ReleaseSchedule > [6] https://git.centos.org/summary/?r=rpms/openssl.git > [7] https://software.opensuse.org/package/openssl -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4007 bytes Desc: S/MIME Cryptographic Signature URL: From olivier at woboq.com Fri Feb 9 12:07:08 2018 From: olivier at woboq.com (Olivier Goffart) Date: Fri, 09 Feb 2018 12:07:08 +0100 Subject: [Development] Qt branches & proposal how to continue with those In-Reply-To: <14514062.8z7eoau313@tjmaciei-mobl1> References: <14514062.8z7eoau313@tjmaciei-mobl1> Message-ID: <1612485.zHsb0QH5hg@maurice> Am Freitag, 9. Februar 2018, 08:13:01 CET schrieb Thiago Macieira: > On Thursday, 8 February 2018 23:02:36 PST Kevin Kofler wrote: > > IMHO, you need to rethink your whole CI approach. This is increasingly > > being the one bottleneck slowing down Qt development and releases. It > > might make more sense to try a different approach, such as allowing all > > commits through initially, then making CI runs at regular intervals, and > > triggering reverts if things broke. > > Which will happen ALL the time. We'll never get back down: when we released > Qt 4.2, 4.3 and 4.4, we were happy if only 10 tests failed (that only > happened for QWS). For the other platforms, the normal number was a hundred > tests failing. Then we spent weeks trying to get the number down. > > Sorry, I don't want to go back to that. That's not exactly how I remember it from the Qt 4.6 and 4.7 times where there was no CI yet, but we were actively fixing tests. There were always a few red tests on testr.troll.no, but they were mostly flacky tests. What is it compared to now with about 100 BLACKLIST files in qtbase alone? (there was no blacklist at the time) That said, I agree we should not go back to that. > > > Qt is being developed very much as a corporate project. (I write "as" > > rather than "like" because that's what Qt is, despite Open Governance.) > > It would help to look at how community Free Software projects do things. > > They tend to be more efficient. And some company-developed Free Software > > projects have already adopted such processes. > > It would not do us well to look at poorer practices than what we have. Just > because everyone else is where we were 10 years ago is no reason for us to > go back to it. Show us a *better* model, one that still prevents failures > from being added, and we'll consider it. How pretentious are you, thinking that everybody else has poorer practice? Other projects still manage to release product with passing test. And might not get ludicrous release delay "because of the CI system" that was supposed to help, but gets in the way instead. Anyway, here is some example of models which works: In LLVM, devs commit directly. buildbots build the trunk continuously. In case of failure, the buildbot maintainer quickly find out which commit likely broke the test and reverts the commit imediatly (or commit a fix if the fix is trivial) This works because there are buildbot maintainers taking care of the build status, and they are not afraid to revert. Also the build and test time is reasonable (while still being big), and individual developer can easily run all the tests on their machine before submitting patches. (Very few platform specific tests). On other projects I've seen on github with travis and co.: the tests are run for every pull request individually, before it is integrated. The reviewer sees the result of the tests and decide whether to merge on not based on the result. If one sees that the failures is obviously unrelated to the patch, the reviewer will override and merge anyway. I think this model could be easily applied to Qt. In particular, there should be an option to merge a patch directly without going through CI. (If you are scared of abuse, limit it to admin or maintainers). This could be used (exceptionally) for urgent patches such as patches that fixes the CI and that are not being integrated quickly enough because of other unrelated failures, continuing to block the CI for days. That way, the CI would not get in the way. In Summary: The CI should be a tool helping the development, and not slowing it down. And having a way to override the CI for important patches should be an easy and quick way to improve things a bit. -- Olivier Woboq - Qt services and support - https://woboq.com - https://code.woboq.org From annulen at yandex.ru Fri Feb 9 12:12:19 2018 From: annulen at yandex.ru (Konstantin Tokarev) Date: Fri, 09 Feb 2018 14:12:19 +0300 Subject: [Development] Qt branches & proposal how to continue with those In-Reply-To: <1612485.zHsb0QH5hg@maurice> References: <14514062.8z7eoau313@tjmaciei-mobl1> <1612485.zHsb0QH5hg@maurice> Message-ID: <6511518174739@web53o.yandex.ru> 09.02.2018, 14:07, "Olivier Goffart" : > Am Freitag, 9. Februar 2018, 08:13:01 CET schrieb Thiago Macieira: >>  On Thursday, 8 February 2018 23:02:36 PST Kevin Kofler wrote: >>  > IMHO, you need to rethink your whole CI approach. This is increasingly >>  > being the one bottleneck slowing down Qt development and releases. It >>  > might make more sense to try a different approach, such as allowing all >>  > commits through initially, then making CI runs at regular intervals, and >>  > triggering reverts if things broke. >> >>  Which will happen ALL the time. We'll never get back down: when we released >>  Qt 4.2, 4.3 and 4.4, we were happy if only 10 tests failed (that only >>  happened for QWS). For the other platforms, the normal number was a hundred >>  tests failing. Then we spent weeks trying to get the number down. >> >>  Sorry, I don't want to go back to that. > > That's not exactly how I remember it from the Qt 4.6 and 4.7 times where there > was no CI yet, but we were actively fixing tests. There were always a few red > tests on testr.troll.no, but they were mostly flacky tests. What is it > compared to now with about 100 BLACKLIST files in qtbase alone? (there was no > blacklist at the time) > > That said, I agree we should not go back to that. > >>  > Qt is being developed very much as a corporate project. (I write "as" >>  > rather than "like" because that's what Qt is, despite Open Governance.) >>  > It would help to look at how community Free Software projects do things. >>  > They tend to be more efficient. And some company-developed Free Software >>  > projects have already adopted such processes. >> >>  It would not do us well to look at poorer practices than what we have. Just >>  because everyone else is where we were 10 years ago is no reason for us to >>  go back to it. Show us a *better* model, one that still prevents failures >>  from being added, and we'll consider it. > > How pretentious are you, thinking that everybody else has poorer practice? > Other projects still manage to release product with passing test. And might > not get ludicrous release delay "because of the CI system" that was supposed > to help, but gets in the way instead. > > Anyway, here is some example of models which works: > > In LLVM, devs commit directly. buildbots build the trunk continuously. In case > of failure, the buildbot maintainer quickly find out which commit likely broke > the test and reverts the commit imediatly (or commit a fix if the fix is > trivial) > This works because there are buildbot maintainers taking care of the build > status, and they are not afraid to revert. Also the build and test time is > reasonable (while still being big), and individual developer can easily run > all the tests on their machine before submitting patches. (Very few platform > specific tests). > > On other projects I've seen on github with travis and co.: the tests are run > for every pull request individually, before it is integrated. The reviewer > sees the result of the tests and decide whether to merge on not based on the > result. If one sees that the failures is obviously unrelated to the patch, the > reviewer will override and merge anyway. > > I think this model could be easily applied to Qt. > > In particular, there should be an option to merge a patch directly without > going through CI. (If you are scared of abuse, limit it to admin or > maintainers). > This could be used (exceptionally) for urgent patches such as patches that > fixes the CI and that are not being integrated quickly enough because of other > unrelated failures, continuing to block the CI for days. That way, the CI > would not get in the way. > > In Summary: The CI should be a tool helping the development, and not slowing > it down. And having a way to override the CI for important patches should be > an easy and quick way to improve things a bit. You seem to ignore that fact that CI is used to build final release binaries. So it doesn't matter if you can merge patch bypassing CI or not, to get release you have to pass through it. > > -- > Olivier > > Woboq - Qt services and support - https://woboq.com - https://code.woboq.org > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From oswald.buddenhagen at qt.io Fri Feb 9 12:39:49 2018 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Fri, 9 Feb 2018 12:39:49 +0100 Subject: [Development] Qt branches & proposal how to continue with those In-Reply-To: <1612485.zHsb0QH5hg@maurice> References: <14514062.8z7eoau313@tjmaciei-mobl1> <1612485.zHsb0QH5hg@maurice> Message-ID: <20180209113949.GA5665@troll08> On Fri, Feb 09, 2018 at 12:07:08PM +0100, Olivier Goffart wrote: > On other projects I've seen on github with travis and co.: the tests are run > for every pull request individually, before it is integrated. The reviewer > sees the result of the tests and decide whether to merge on not based on the > result. If one sees that the failures is obviously unrelated to the patch, the > reviewer will override and merge anyway. > > I think this model could be easily applied to Qt. > no, that's exactly the thing that does *not* work for qt. the computing capacity required to support that model (with the primitive tools we're apparently capable of utilizing) would be *enormous*. (of course, one can argue that all the pointlessly failed integrations effectively thwart the advantage of batch integrations. somebody would have to do the math to make an actual judgment call.) another reason why this model may not work too well is qt's abysmal test coverage in many areas. as annoying as the current system is, it *does* prevent non-obvious, indirect breakages from going in from time to time, because people can't just deny responsibility past a certain point. From ville.voutilainen at gmail.com Fri Feb 9 13:04:24 2018 From: ville.voutilainen at gmail.com (Ville Voutilainen) Date: Fri, 9 Feb 2018 14:04:24 +0200 Subject: [Development] Qt branches & proposal how to continue with those In-Reply-To: <1612485.zHsb0QH5hg@maurice> References: <14514062.8z7eoau313@tjmaciei-mobl1> <1612485.zHsb0QH5hg@maurice> Message-ID: On 9 February 2018 at 13:07, Olivier Goffart wrote: > Anyway, here is some example of models which works: > > In LLVM, devs commit directly. buildbots build the trunk continuously. In case > of failure, the buildbot maintainer quickly find out which commit likely broke > the test and reverts the commit imediatly (or commit a fix if the fix is > trivial) > This works because there are buildbot maintainers taking care of the build > status, and they are not afraid to revert. Also the build and test time is > reasonable (while still being big), and individual developer can easily run > all the tests on their machine before submitting patches. (Very few platform > specific tests). Well, it really can't hurt much to give another example. When I contribute to GCC, I write my patch, ssh into a compile farm, pull the repo, apply my patch and run the testsuite. After that I submit it for review. There are people running CI-like build runs, but those don't block commits. Once a patch has been accepted, I just push it. If something breaks despite testing, that's very rare and can be dealt with after-the-fact. > In Summary: The CI should be a tool helping the development, and not slowing > it down. And having a way to override the CI for important patches should be > an easy and quick way to improve things a bit. Fully agreed, but we already can do such overrides in emergency situations, and we probably don't want to enable just everybody to do so. Having said all this, there's ongoing active work to fix the CI problems. From Rainer.Keller at qt.io Fri Feb 9 14:18:56 2018 From: Rainer.Keller at qt.io (Rainer Keller) Date: Fri, 9 Feb 2018 14:18:56 +0100 Subject: [Development] Nominating Kari Oikarinen for Approver Status Message-ID: Hello everybody, I'd like to nominate Kari Oikarinen for approver status in the Qt Project. Kari has been contributing to Qt for Device Creation, COIN and several other parts of the Qt project. He also is the maintainer of the Qt Debug Bridge. His track record can be found under: https://codereview.qt-project.org/#q,owner:kari.oikarinen,n,z https://codereview.qt-project.org/#q,reviewer:kari.oikarinen,n,z With regards, Rainer From Simon.Hausmann at qt.io Fri Feb 9 14:22:57 2018 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Fri, 9 Feb 2018 13:22:57 +0000 Subject: [Development] Nominating Kari Oikarinen for Approver Status In-Reply-To: References: Message-ID: +1 Simon ________________________________ From: Development on behalf of Rainer Keller Sent: Friday, February 9, 2018 2:18:56 PM To: development at qt-project.org Subject: [Development] Nominating Kari Oikarinen for Approver Status Hello everybody, I'd like to nominate Kari Oikarinen for approver status in the Qt Project. Kari has been contributing to Qt for Device Creation, COIN and several other parts of the Qt project. He also is the maintainer of the Qt Debug Bridge. His track record can be found under: https://codereview.qt-project.org/#q,owner:kari.oikarinen,n,z https://codereview.qt-project.org/#q,reviewer:kari.oikarinen,n,z With regards, Rainer _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian.kandeler at qt.io Fri Feb 9 14:24:56 2018 From: christian.kandeler at qt.io (Christian Kandeler) Date: Fri, 9 Feb 2018 14:24:56 +0100 Subject: [Development] Nominating Kari Oikarinen for Approver Status In-Reply-To: References: Message-ID: <20180209142456.1399e89d@ckandeler-archlinux> On Fri, 9 Feb 2018 14:18:56 +0100 Rainer Keller wrote: > I'd like to nominate Kari Oikarinen for approver status in the Qt Project. +1 Christian From robin.burchell at crimson.no Fri Feb 9 14:28:57 2018 From: robin.burchell at crimson.no (Robin Burchell) Date: Fri, 09 Feb 2018 14:28:57 +0100 Subject: [Development] Nominating Kari Oikarinen for Approver Status In-Reply-To: References: Message-ID: <1518182937.1324884.1265255712.116DB919@webmail.messagingengine.com> +1, and I'm surprised it wasn't already the case actually :) -- Robin Burchell robin at crimson.no On Fri, Feb 9, 2018, at 2:18 PM, Rainer Keller wrote: > Hello everybody, > > I'd like to nominate Kari Oikarinen for approver status in the Qt Project. > > Kari has been contributing to Qt for Device Creation, COIN and several > other parts of the Qt project. He also is the maintainer of the Qt Debug > Bridge. His track record can be found under: > > https://codereview.qt-project.org/#q,owner:kari.oikarinen,n,z > https://codereview.qt-project.org/#q,reviewer:kari.oikarinen,n,z > > With regards, > Rainer > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From annulen at yandex.ru Fri Feb 9 14:48:29 2018 From: annulen at yandex.ru (Konstantin Tokarev) Date: Fri, 09 Feb 2018 16:48:29 +0300 Subject: [Development] Qt branches & proposal how to continue with those In-Reply-To: References: <14795953.F2orM6F176@tjmaciei-mobl1> Message-ID: <42881518184109@web54j.yandex.ru> 09.02.2018, 10:03, "Kevin Kofler" : > IMHO, you need to rethink your whole CI approach. This is increasingly being > the one bottleneck slowing down Qt development and releases. It might make > more sense to try a different approach, such as allowing all commits through > initially, then making CI runs at regular intervals, and triggering reverts > if things broke. >From what I see, CI is not the bottleneck, or at least not the only one. From reading this list I got impression that situation is quite different. We may have stable branch with a good number of fresh unreleased commits, but release team rejects possibility of making point release, because release process requires a lot of time and they need that time for doing something more important [1]. One notable example was with Qt 5.9.3, when Linux binaries were accidentally built using too fresh GCC version. It was proposed that we rebuild 5.9.3 tag as is using different toolchain, so no new merges were needed and CI delays could have only minimal influence on the release timing. Anyway this was rejected, apparently because verifying binaries before releasing them requires too much effort [2]. [1] Please don't take this as I'm trying to put a blame on anyone, I'm willingly believe release team is doing their best [2] https://www.mail-archive.com/development at qt-project.org/msg30384.html -- Regards, Konstantin From annulen at yandex.ru Fri Feb 9 15:13:00 2018 From: annulen at yandex.ru (Konstantin Tokarev) Date: Fri, 09 Feb 2018 17:13:00 +0300 Subject: [Development] Qt branches & proposal how to continue with those In-Reply-To: <42881518184109@web54j.yandex.ru> References: <14795953.F2orM6F176@tjmaciei-mobl1> <42881518184109@web54j.yandex.ru> Message-ID: <147591518185580@web54j.yandex.ru> 09.02.2018, 16:48, "Konstantin Tokarev" : > 09.02.2018, 10:03, "Kevin Kofler" : >>  IMHO, you need to rethink your whole CI approach. This is increasingly being >>  the one bottleneck slowing down Qt development and releases. It might make >>  more sense to try a different approach, such as allowing all commits through >>  initially, then making CI runs at regular intervals, and triggering reverts >>  if things broke. > > From what I see, CI is not the bottleneck, or at least not the only one. From reading > this list I got impression that situation is quite different. We may have stable branch > with a good number of fresh unreleased commits, but release team rejects possibility > of making point release, because release process requires a lot of time and they > need that time for doing something more important [1]. > > One notable example was with Qt 5.9.3, when Linux binaries were accidentally built > using too fresh GCC version. It was proposed that we rebuild 5.9.3 tag as is using > different toolchain, so no new merges were needed and CI delays could have only > minimal influence on the release timing. Anyway this was rejected, apparently > because verifying binaries before releasing them requires too much effort [2]. So, I think that instead of putting money into increasing CI capacity, it would be better for TQtC to spend it on the following things: 1. Dedicate enough developers' time into making releasing process (i.e., all steps which have to be done with sources and binaries after Coin integration succeeds) as fully automated as it's feasible 2. Find a way to eleminate Coin downtimes, when it doesn't operate at all or uses only part of capacity 3. Work on eleminating hidded Coin downtimes, when integration time out or fail because of infrastructure issues. I mean cases when compilation does not start or never finishes, independent of code being under integration, so this is totally not about flaky tests. I guess if these issues were solved, current capacity could be good enough to reach the promised land of continuous delivery. -- Regards, Konstantin From thiago.macieira at intel.com Fri Feb 9 16:57:35 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 9 Feb 2018 07:57:35 -0800 Subject: [Development] Suggestion: switch binary builds to OpenSSL 1.1 in Qt 5.11 In-Reply-To: References: <3028229.9F9WlbBkjx@tjmaciei-mobl1> Message-ID: <1943690.xHuxWiDLCH@tjmaciei-mobl1> On Friday, 9 February 2018 02:59:31 PST Giuseppe D'Angelo wrote: > OpenSUSE Leap 42.3 also has 1.0.2 [7]. This release is too old. It still has Qt 5.6. But I know for a time openSUSE backported the OpenSSL 1.1 patch onto Qt 5.9. Now Tumbleweed has Qt 5.10 anyway. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From annulen at yandex.ru Fri Feb 9 17:01:31 2018 From: annulen at yandex.ru (Konstantin Tokarev) Date: Fri, 09 Feb 2018 19:01:31 +0300 Subject: [Development] Suggestion: switch binary builds to OpenSSL 1.1 in Qt 5.11 In-Reply-To: <1943690.xHuxWiDLCH@tjmaciei-mobl1> References: <3028229.9F9WlbBkjx@tjmaciei-mobl1> <1943690.xHuxWiDLCH@tjmaciei-mobl1> Message-ID: <516851518192091@web12o.yandex.ru> 09.02.2018, 18:57, "Thiago Macieira" : > On Friday, 9 February 2018 02:59:31 PST Giuseppe D'Angelo wrote: >>  OpenSUSE Leap 42.3 also has 1.0.2 [7]. > > This release is too old. It still has Qt 5.6. Note that people often work on old distros with new Qt, installed from official packages > > But I know for a time openSUSE backported the OpenSSL 1.1 patch onto Qt 5.9. > Now Tumbleweed has Qt 5.10 anyway. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com >   Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From thiago.macieira at intel.com Fri Feb 9 17:17:12 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 9 Feb 2018 08:17:12 -0800 Subject: [Development] Qt branches & proposal how to continue with those In-Reply-To: <1612485.zHsb0QH5hg@maurice> References: <14514062.8z7eoau313@tjmaciei-mobl1> <1612485.zHsb0QH5hg@maurice> Message-ID: <1922788.3dT0Ehmkic@tjmaciei-mobl1> On Friday, 9 February 2018 03:07:08 PST Olivier Goffart wrote: > > Which will happen ALL the time. We'll never get back down: when we > > released > > Qt 4.2, 4.3 and 4.4, we were happy if only 10 tests failed (that only > > happened for QWS). For the other platforms, the normal number was a > > hundred > > tests failing. Then we spent weeks trying to get the number down. > > > > Sorry, I don't want to go back to that. > > That's not exactly how I remember it from the Qt 4.6 and 4.7 times where > there was no CI yet, but we were actively fixing tests. There were always a > few red tests on testr.troll.no, but they were mostly flacky tests. What is > it compared to now with about 100 BLACKLIST files in qtbase alone? (there > was no blacklist at the time) Testr is the second generation tool. I am thinking of the previous one, reported on desert.troll.no. I remember *once* seeing a "0" test failure reported, again QWS. We do have BLACKLISTs this time and I complain every time I see one being added without even an attempt at figuring out what's wrong with the test, or when the match is overly aggressive ("it fails on Ubuntu in the CI, so it must fail for everyone using Ubuntu!"). But also remember we have more tests than 10 years ago, probably by a factor of 2. Finally, back then "1" failure indicated that the entire test executable failed, whether it was 1 test function, 1 test row, or the program crashed. > > It would not do us well to look at poorer practices than what we have. > > Just > > because everyone else is where we were 10 years ago is no reason for us to > > go back to it. Show us a *better* model, one that still prevents failures > > from being added, and we'll consider it. > > How pretentious are you, thinking that everybody else has poorer practice? > Other projects still manage to release product with passing test. And might > not get ludicrous release delay "because of the CI system" that was supposed > to help, but gets in the way instead. I didn't say everyone does. I even gave an example of a project that has better practices. But I am making a subjective judgement that allowing breakages in and then fixing them later is a poorer practice. I do not apologise for it. I am also not saying our method is perfect. Clearly it is not, and that's not even talking about the implementation and infra. > Anyway, here is some example of models which works: > > In LLVM, devs commit directly. buildbots build the trunk continuously. In > case of failure, the buildbot maintainer quickly find out which commit > likely broke the test and reverts the commit imediatly (or commit a fix if > the fix is trivial) Who reverts the commit, the bot or the maintainer? If it depends on a person, what happens if the person doesn't? This sounds like our third-generation CI, when we switched to Git, remember that? Each team had a repository, which the CI built and, if it passed, merged onto the mainline. If the build was broken, someone in the team had to apply a fix or a revert. Do you remember what happened? It took days to get a failure removed. Sometimes upwards of a week, if the attempt at fix did not actually fix the issue. > This works because there are buildbot maintainers taking care of the build > status, and they are not afraid to revert. Also the build and test time is > reasonable (while still being big), and individual developer can easily run > all the tests on their machine before submitting patches. (Very few platform > specific tests). Therein lies the problem: for any one developer to run all the Qt tests, it takes a LOT of time. And you usually can't use your machine while it runs the UI tests. > On other projects I've seen on github with travis and co.: the tests are > run for every pull request individually, before it is integrated. The > reviewer sees the result of the tests and decide whether to merge on not > based on the result. If one sees that the failures is obviously unrelated > to the patch, the reviewer will override and merge anyway. And I use that for TinyCBOR. But what happens to pull request B when pull request A is merged? Now the test result is stale. It should be re-done by merging the target branch back into the PR, or by rebasing (which most projects don't do), to confirm there are no issues caused by the combination of changes. More often than not, the maintainer applies a judgement call and accepts the stale results. TinyCBOR has half a dozen .c source files and three QtTest tests (one of them is just compilation). It takes about 30 seconds to launch, compile and test MSVC 2013, 2015 and 2017 on AppVeyor. But it takes about 8 minutes on Travis. Of those, 7 minutes and 30 seconds are spent updating running apt-get. > I think this model could be easily applied to Qt. The part where each change is tested before hand, yes. We've always wanted this. The part where changes are merged together and accepted without verifying whether they cause problems with each other, not so much. > In particular, there should be an option to merge a patch directly without > going through CI. (If you are scared of abuse, limit it to admin or > maintainers). That already exists. It's called "talk to Ossi" and he uses it for changelogs and the version number bumps. > This could be used (exceptionally) for urgent patches such as patches that > fixes the CI and that are not being integrated quickly enough because of > other unrelated failures, continuing to block the CI for days. That way, > the CI would not get in the way. We have the method. We just don't use it. > In Summary: The CI should be a tool helping the development, and not slowing > it down. And having a way to override the CI for important patches should > be an easy and quick way to improve things a bit. It should not be easy to override the CI. It should be possible, not easy. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Fri Feb 9 16:53:19 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 9 Feb 2018 07:53:19 -0800 Subject: [Development] Suggestion: switch binary builds to OpenSSL 1.1 in Qt 5.11 In-Reply-To: References: <3028229.9F9WlbBkjx@tjmaciei-mobl1> Message-ID: <4937037.kOSkHZeN6P@tjmaciei-mobl1> On Friday, 9 February 2018 00:42:55 PST Timur Pocheptsov wrote: > Andy, do you have any feedback from our customers about this? My anecdotal > evidence so far - I have 0 bug-reports complaining they see a message: > "Incompatible version of OpenSSL" (qsslsocket_openssl_symbols.cpp, line > 1025), this means for me people using our binaries mostly have OpenSSL > version below 1.1. That's not the error message that i've seen reported. This is #qt channel yesterday: 10:37 < _gpg_> anyone knows which version of ssl is needed for the latest Qt release please ? i'm stuck with qt.network.ssl: QSslSocket: cannot call unresolved function SSLv23_client_method errors The issue was the 5.10.0 binary with OpenSSL 1.1. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Fri Feb 9 17:21:33 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 9 Feb 2018 08:21:33 -0800 Subject: [Development] Suggestion: switch binary builds to OpenSSL 1.1 in Qt 5.11 In-Reply-To: <516851518192091@web12o.yandex.ru> References: <3028229.9F9WlbBkjx@tjmaciei-mobl1> <1943690.xHuxWiDLCH@tjmaciei-mobl1> <516851518192091@web12o.yandex.ru> Message-ID: <20852560.ZRchJfoY4s@tjmaciei-mobl1> On Friday, 9 February 2018 08:01:31 PST Konstantin Tokarev wrote: > 09.02.2018, 18:57, "Thiago Macieira" : > > On Friday, 9 February 2018 02:59:31 PST Giuseppe D'Angelo wrote: > >> OpenSUSE Leap 42.3 also has 1.0.2 [7]. > > > > This release is too old. It still has Qt 5.6. > > Note that people often work on old distros with new Qt, installed from > official packages Nothing wrong with that. That's what LTS is for. That's also why OpenSSL 1.0 is as secure as 1.1: both branches are being maintained by upstream. My point is that you can't talk about whether a distro has OpenSSL 1.1 if it's too old to have had a chance to migrate. I'm sure no distro is shipping with OpenSSL 1.2 right now, and yet that's not a problem :-) -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From ville.voutilainen at gmail.com Fri Feb 9 17:32:20 2018 From: ville.voutilainen at gmail.com (Ville Voutilainen) Date: Fri, 9 Feb 2018 18:32:20 +0200 Subject: [Development] Qt branches & proposal how to continue with those In-Reply-To: <1922788.3dT0Ehmkic@tjmaciei-mobl1> References: <14514062.8z7eoau313@tjmaciei-mobl1> <1612485.zHsb0QH5hg@maurice> <1922788.3dT0Ehmkic@tjmaciei-mobl1> Message-ID: On 9 February 2018 at 18:17, Thiago Macieira wrote: > We do have BLACKLISTs this time and I complain every time I see one being > added without even an attempt at figuring out what's wrong with the test, or > when the match is overly aggressive ("it fails on Ubuntu in the CI, so it must It gives me no end of heartburn that we prefer having integrations be blocked for days to doing over-aggressive blacklisting. Having flaky tests is indistinguishable from having no tests at all, so it boggles my mind why some of us are so worried about potentially over-done blacklists. From giuseppe.dangelo at kdab.com Fri Feb 9 19:04:30 2018 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Fri, 9 Feb 2018 19:04:30 +0100 Subject: [Development] Suggestion: switch binary builds to OpenSSL 1.1 in Qt 5.11 In-Reply-To: <1943690.xHuxWiDLCH@tjmaciei-mobl1> References: <3028229.9F9WlbBkjx@tjmaciei-mobl1> <1943690.xHuxWiDLCH@tjmaciei-mobl1> Message-ID: <577c67ba-13fe-e4f3-5329-7ccb6053cfc3@kdab.com> Il 09/02/2018 16:57, Thiago Macieira ha scritto: > This release is too old. It still has Qt 5.6. > > But I know for a time openSUSE backported the OpenSSL 1.1 patch onto Qt 5.9. > Now Tumbleweed has Qt 5.10 anyway. The point isn't which version of Qt comes with the distribution, but the binary builds. Given people do use binary builds (to have an up-to-date Qt) but not mess with OpenSSL, the outcome will be that SSL will not be functional for the users of the distributions I mentioned before. Does TQC have any statistics to share here? If the argument becomes "those people can stay with LTS or build from sources", then well, let's go all in for the binary builds, shall we? Like build with C++17 and GCC7? Cheers, -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4007 bytes Desc: Firma crittografica S/MIME URL: From thiago.macieira at intel.com Fri Feb 9 19:39:39 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 9 Feb 2018 10:39:39 -0800 Subject: [Development] Qt branches & proposal how to continue with those In-Reply-To: References: <1922788.3dT0Ehmkic@tjmaciei-mobl1> Message-ID: <4741199.fbBPMcuoBn@tjmaciei-mobl1> On Friday, 9 February 2018 08:32:20 PST Ville Voutilainen wrote: > On 9 February 2018 at 18:17, Thiago Macieira wrote: > > We do have BLACKLISTs this time and I complain every time I see one being > > added without even an attempt at figuring out what's wrong with the test, > > or when the match is overly aggressive ("it fails on Ubuntu in the CI, so > > it must > It gives me no end of heartburn that we prefer having integrations be > blocked for days to doing > over-aggressive blacklisting. Having flaky tests is indistinguishable > from having no tests at all, > so it boggles my mind why some of us are so worried about potentially > over-done blacklists. I'm not asking someone to spend days figuring out what's wrong. I know it takes time. But I am asking to do a minimal investigation. In most cases of blacklisting, the test has been failing for days, if not months. Spending an hour or two to understand why it's failing and whether it's something that only happens in the CI should be the norm. One of the consequences of blacklisting is that "out of sight is out of mind". We'll never remove those blacklists again and that makes us have a false sense of security, that we have tested, when in fact we're just ignoring the failures. That is just like the Qt CI back in 2006-2009, which is what I said I don't want to get back to. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Fri Feb 9 19:44:38 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 9 Feb 2018 10:44:38 -0800 Subject: [Development] Suggestion: switch binary builds to OpenSSL 1.1 in Qt 5.11 In-Reply-To: <577c67ba-13fe-e4f3-5329-7ccb6053cfc3@kdab.com> References: <3028229.9F9WlbBkjx@tjmaciei-mobl1> <1943690.xHuxWiDLCH@tjmaciei-mobl1> <577c67ba-13fe-e4f3-5329-7ccb6053cfc3@kdab.com> Message-ID: <21438517.s3S0DQbiCe@tjmaciei-mobl1> On Friday, 9 February 2018 10:04:30 PST Giuseppe D'Angelo wrote: > Il 09/02/2018 16:57, Thiago Macieira ha scritto: > > This release is too old. It still has Qt 5.6. > > > > But I know for a time openSUSE backported the OpenSSL 1.1 patch onto Qt > > 5.9. Now Tumbleweed has Qt 5.10 anyway. > > The point isn't which version of Qt comes with the distribution, but the > binary builds. Given people do use binary builds (to have an up-to-date > Qt) but not mess with OpenSSL, the outcome will be that SSL will not be > functional for the users of the distributions I mentioned before. Oh! I hadn't thought of that. On Windows, it shouldn't be a problem since people need to install OpenSSL manually, so they'll naturally get 1.1. On Mac, we haven't used OpenSSL for a few releases. The problem is the current crop of Linux stable distributions. > Does TQC have any statistics to share here? > > If the argument becomes "those people can stay with LTS or build from > sources", then well, let's go all in for the binary builds, shall we? > Like build with C++17 and GCC7? We already build with C++17, but with GCC 5. But I say people who need OpenSSL 1.0 should stay with 5.10, one of the LTS, build from sources, or use their distribution's packages. There are a lot of options. UNLESS this will make the Qt SDK installer and maintenance tool not work. Since I don't use it, I don't know: does it ship with OpenSSL or does it expect to find one in the Linux target system, in order to perform the downloads? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From ville.voutilainen at gmail.com Fri Feb 9 19:46:23 2018 From: ville.voutilainen at gmail.com (Ville Voutilainen) Date: Fri, 9 Feb 2018 20:46:23 +0200 Subject: [Development] Qt branches & proposal how to continue with those In-Reply-To: <4741199.fbBPMcuoBn@tjmaciei-mobl1> References: <1922788.3dT0Ehmkic@tjmaciei-mobl1> <4741199.fbBPMcuoBn@tjmaciei-mobl1> Message-ID: On 9 February 2018 at 20:39, Thiago Macieira wrote: > On Friday, 9 February 2018 08:32:20 PST Ville Voutilainen wrote: >> On 9 February 2018 at 18:17, Thiago Macieira > wrote: >> > We do have BLACKLISTs this time and I complain every time I see one being >> > added without even an attempt at figuring out what's wrong with the test, >> > or when the match is overly aggressive ("it fails on Ubuntu in the CI, so >> > it must >> It gives me no end of heartburn that we prefer having integrations be >> blocked for days to doing >> over-aggressive blacklisting. Having flaky tests is indistinguishable >> from having no tests at all, >> so it boggles my mind why some of us are so worried about potentially >> over-done blacklists. > > I'm not asking someone to spend days figuring out what's wrong. I know it > takes time. > > But I am asking to do a minimal investigation. In most cases of blacklisting, > the test has been failing for days, if not months. Spending an hour or two to > understand why it's failing and whether it's something that only happens in > the CI should be the norm. The problem is that a large amount of tests have been failing, for weeks. In some cases, months. In some cases, for a year. That results in a restage storm, and carves a doubt in every submitter's mind whether CI failures are something to really bother about beyond hitting the restage button. I doubt either of us thinks that to be optimal. > One of the consequences of blacklisting is that "out of sight is out of mind". > We'll never remove those blacklists again and that makes us have a false sense > of security, that we have tested, when in fact we're just ignoring the > failures. That is just like the Qt CI back in 2006-2009, which is what I said > I don't want to get back to. Currently the people working on blacklist patches create a bug report for every flaky test that they have to blacklist. Whether we believe those bugs to be eventually resolved is another matter, but having every contributor restage every patch more than half a dozen times because there are flaky test failures in tests *COMPLETELY* unrelated to anything the submitted change does is unacceptable, and it's high time we rectify that problem, even if a small percentage of our tests gets overly-aggressively blacklisted. From ville.voutilainen at gmail.com Fri Feb 9 19:55:17 2018 From: ville.voutilainen at gmail.com (Ville Voutilainen) Date: Fri, 9 Feb 2018 20:55:17 +0200 Subject: [Development] Qt branches & proposal how to continue with those In-Reply-To: References: <1922788.3dT0Ehmkic@tjmaciei-mobl1> <4741199.fbBPMcuoBn@tjmaciei-mobl1> Message-ID: On 9 February 2018 at 20:46, Ville Voutilainen wrote: >> But I am asking to do a minimal investigation. In most cases of blacklisting, >> the test has been failing for days, if not months. Spending an hour or two to >> understand why it's failing and whether it's something that only happens in >> the CI should be the norm. > > The problem is that a large amount of tests have been failing, for > weeks. In some cases, > months. In some cases, for a year. That results in a restage storm, > and carves a doubt > in every submitter's mind whether CI failures are something to really > bother about beyond > hitting the restage button. I doubt either of us thinks that to be optimal. Also, our blacklist patch submitters *do* minimal investigation and more. There's been a whole shebang of suggested flaky tests, which have been deemed to not be caused by flakiness in tests, after proper investigation. And another matter to consider is that both because of CI infra problems and flaky tests, it's been next to impossible to get anything into e.g. qtbase for two weeks. Why some of those flaky tests seem to be hit more often isn't exactly known, but our statistics information does support their being flaky, and we've seen every one of these tests fail before in spurious manners, we just haven't done anything to it, due to some extent some people adamantly opposing blacklisting in general, and some demanding that there's a thorough investigation almost tantamount to 100% proof that a test is flaky before a possibly temporary blacklisting is even considered. It's also perhaps worth realizing that the current flakiness fixes and blacklists haven't gone in, because flaky tests here and there and everywhere prevent integrating those fixes. From Jake.Petroules at qt.io Fri Feb 9 21:14:22 2018 From: Jake.Petroules at qt.io (Jake Petroules) Date: Fri, 9 Feb 2018 20:14:22 +0000 Subject: [Development] Goodbye Message-ID: Steve Jobs once said: > “I have looked in the mirror every morning and asked myself: "If today were the last day of my life, would I want to do what I am about to do today?" And whenever the answer has been "No" for too many days in a row, I know I need to change something.” After 8 years of Qt, it's time to say goodbye. Both from my employment in The Qt Company and my roles in the Qt Project. I'd like to thank those of you in the company and in the Qt Project who have supported me over the years in various ways. It's been a great adventure. Friday, February 23rd will be my last day. I hereby relinquish my role as Maintainer of Apple build system support across all projects under the Qt Project umbrella (nominating Oswald Buddenhagen as my replacement), and my role as Maintainer of the Apple watchOS platform (nominating Tor Arne Vestbø as my replacement). Please feel free to contact me at jake.petroules at petroules.com if you have any questions, comments, or otherwise. I wish you all the best. Sincerely, Jake Petroules From samuel.gaist at edeltech.ch Fri Feb 9 23:28:02 2018 From: samuel.gaist at edeltech.ch (Samuel Gaist) Date: Fri, 9 Feb 2018 23:28:02 +0100 Subject: [Development] Goodbye In-Reply-To: References: Message-ID: <7DF1C50B-32EE-48C2-A15C-825B745B253F@edeltech.ch> > On 9 Feb 2018, at 21:14, Jake Petroules wrote: > > Steve Jobs once said: > >> “I have looked in the mirror every morning and asked myself: "If today were the last day of my life, would I want to do what I am about to do today?" And whenever the answer has been "No" for too many days in a row, I know I need to change something.” > > > After 8 years of Qt, it's time to say goodbye. Both from my employment in The Qt Company and my roles in the Qt Project. I'd like to thank those of you in the company and in the Qt Project who have supported me over the years in various ways. It's been a great adventure. Friday, February 23rd will be my last day. > > I hereby relinquish my role as Maintainer of Apple build system support across all projects under the Qt Project umbrella (nominating Oswald Buddenhagen as my replacement), and my role as Maintainer of the Apple watchOS platform (nominating Tor Arne Vestbø as my replacement). > > Please feel free to contact me at jake.petroules at petroules.com if you have any questions, comments, or otherwise. > > I wish you all the best. > > Sincerely, > Jake Petroules > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > Hi Jake, -2 ;-) Sad to see you go but grateful for all what you did. Thanks for the reviews, collaboration, insights of the Apple platforms and all the rest. Good luck for your next endeavours ! Best regards, Samuel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From szehowe.koh at gmail.com Sat Feb 10 00:35:30 2018 From: szehowe.koh at gmail.com (Sze Howe Koh) Date: Sat, 10 Feb 2018 07:35:30 +0800 Subject: [Development] Qt branches & proposal how to continue with those In-Reply-To: References: <3586F83C-F715-4B4E-BFA1-A24EF62946FA@qt.io> <833e801049d7d35ed1dab558afafd7fb.squirrel@squirrel.six.silmor.de> <45E55A9F-D3E3-4FC4-B239-74E2BBBA7AFC@qt.io> <20180201111913.GC14103@troll08> <475241517484976@web4j.yandex.ru> <9ABE2AC4-87A1-4F9F-8543-5DCA73D8B79F@qt.io> <20180201145307.GE14103@troll08> <20180208220733.GB1702@klara.mpi.htwm.de> Message-ID: On 9 February 2018 at 15:54, Lars Knoll wrote: >> On 9 Feb 2018, at 07:52, Kevin Kofler wrote: >> >> André Pönitz wrote: >>> I think you need to start differentiating between Qt-without-Webengine >>> and QtWebengine. >>> >>> And maybe "we" should do that, too. >> >> I would be entirely in favor of separate (more frequent and/or more aligned >> with Chromium security fixes) QtWebEngine releases. I am already updating >> QtWebEngine in Fedora on a separate schedule from the core Qt updates (with >> the intent of delivering security updates faster), so it would not be a >> problem for me if the releases were entirely separate. And it would surely >> get security fixes delivered in a more timely manner. > > We’ve been discussing this in the past, and most people agreed that releasing QtWebEngine on an independent schedule would be a good thing. But there’s still a couple of things that need sorting out before that can happen, both in the CI and how we create/package our product and SDK as well as in QtWebengine which for example still uses private API of some other parts of Qt. Is updating the Chromium backend alone a source- and binary-compatible act? I'm wondering if it's feasible (and desirable) to introduce "sub-patch" releases, where the only change is the updated Chromium backend -- not even bugfixes in Qt-controlled code. For example, if Chromium is updated between Qt 5.10.0 and Qt 5.10.1, then: 1. Branch off the v5.10.0 tag (call it the "5.10.0-x" branch, for Chromium updates only) 2. Update Chromium in 5.10.0-x and release "Qt WebEngine 5.10.0-1" 3. Merge 5.10.0-x into 5.10 The idea is to provide security updates in a timely manner, without: * Worrying about private API breakages * Requiring a full-blown Qt release * Making Qt WebEngine's version numbering go out of sync with the rest of Qt This approach would be most beneficial for a non-LTS branch, least beneficial for an LTS branch in "Very Strict" mode. I thought this might be an easy option since Qt WebEngine is already listed as a separate component in the Qt installer (please correct me if I'm underestimating something in the process). Regards, Sze-Howe From denis.shienkov at gmail.com Sat Feb 10 09:45:42 2018 From: denis.shienkov at gmail.com (Denis Shienkov) Date: Sat, 10 Feb 2018 11:45:42 +0300 Subject: [Development] Goodbye In-Reply-To: References: Message-ID: <86d04a9e-52b2-de73-2092-df5b4d14fde0@gmail.com> Wow, Jake, what will be with QBS? BR, Denis 09.02.2018 23:14, Jake Petroules пишет: > Steve Jobs once said: > >> “I have looked in the mirror every morning and asked myself: "If today were the last day of my life, would I want to do what I am about to do today?" And whenever the answer has been "No" for too many days in a row, I know I need to change something.” > > After 8 years of Qt, it's time to say goodbye. Both from my employment in The Qt Company and my roles in the Qt Project. I'd like to thank those of you in the company and in the Qt Project who have supported me over the years in various ways. It's been a great adventure. Friday, February 23rd will be my last day. > > I hereby relinquish my role as Maintainer of Apple build system support across all projects under the Qt Project umbrella (nominating Oswald Buddenhagen as my replacement), and my role as Maintainer of the Apple watchOS platform (nominating Tor Arne Vestbø as my replacement). > > Please feel free to contact me at jake.petroules at petroules.com if you have any questions, comments, or otherwise. > > I wish you all the best. > > Sincerely, > Jake Petroules > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From rich at kde.org Sat Feb 10 12:21:24 2018 From: rich at kde.org (Richard Moore) Date: Sat, 10 Feb 2018 11:21:24 +0000 Subject: [Development] Goodbye In-Reply-To: References: Message-ID: ​Thanks for all your hard work, and good luck for the future Jake Rich. ​ On 9 February 2018 at 20:14, Jake Petroules wrote: > Steve Jobs once said: > > > “I have looked in the mirror every morning and asked myself: "If today > were the last day of my life, would I want to do what I am about to do > today?" And whenever the answer has been "No" for too many days in a row, I > know I need to change something.” > > > After 8 years of Qt, it's time to say goodbye. Both from my employment in > The Qt Company and my roles in the Qt Project. I'd like to thank those of > you in the company and in the Qt Project who have supported me over the > years in various ways. It's been a great adventure. Friday, February 23rd > will be my last day. > > I hereby relinquish my role as Maintainer of Apple build system support > across all projects under the Qt Project umbrella (nominating Oswald > Buddenhagen as my replacement), and my role as Maintainer of the Apple > watchOS platform (nominating Tor Arne Vestbø as my replacement). > > Please feel free to contact me at jake.petroules at petroules.com if you > have any questions, comments, or otherwise. > > I wish you all the best. > > Sincerely, > Jake Petroules > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jake.Petroules at qt.io Sat Feb 10 21:46:27 2018 From: Jake.Petroules at qt.io (Jake Petroules) Date: Sat, 10 Feb 2018 20:46:27 +0000 Subject: [Development] Goodbye In-Reply-To: <86d04a9e-52b2-de73-2092-df5b4d14fde0@gmail.com> References: <86d04a9e-52b2-de73-2092-df5b4d14fde0@gmail.com> Message-ID: <541992D8-B0D5-4DA9-AB9D-266B9308BA9F@qt.io> It will be in good hands with Christian Kandeler and Joerg Bornemann. Not to worry! > On Feb 10, 2018, at 12:45 AM, Denis Shienkov wrote: > > Wow, Jake, what will be with QBS? > > BR, > > Denis > > > 09.02.2018 23:14, Jake Petroules пишет: >> Steve Jobs once said: >> >>> “I have looked in the mirror every morning and asked myself: "If today were the last day of my life, would I want to do what I am about to do today?" And whenever the answer has been "No" for too many days in a row, I know I need to change something.” >> >> After 8 years of Qt, it's time to say goodbye. Both from my employment in The Qt Company and my roles in the Qt Project. I'd like to thank those of you in the company and in the Qt Project who have supported me over the years in various ways. It's been a great adventure. Friday, February 23rd will be my last day. >> >> I hereby relinquish my role as Maintainer of Apple build system support across all projects under the Qt Project umbrella (nominating Oswald Buddenhagen as my replacement), and my role as Maintainer of the Apple watchOS platform (nominating Tor Arne Vestbø as my replacement). >> >> Please feel free to contact me at jake.petroules at petroules.com if you have any questions, comments, or otherwise. >> >> I wish you all the best. >> >> Sincerely, >> Jake Petroules >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petroules at qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io From ekke at ekkes-corner.org Sun Feb 11 12:17:20 2018 From: ekke at ekkes-corner.org (ekke) Date: Sun, 11 Feb 2018 12:17:20 +0100 Subject: [Development] Goodbye In-Reply-To: References: Message-ID: <63c70c5e-bd67-3e85-af82-dad616f6aa91@ekkes-corner.org> Jake, thx for all the valuable help I got from you while using Qt to develop mobile Apps wish you the best for the future ekke Am 09.02.18 um 21:14 schrieb Jake Petroules: > Steve Jobs once said: > >> “I have looked in the mirror every morning and asked myself: "If today were the last day of my life, would I want to do what I am about to do today?" And whenever the answer has been "No" for too many days in a row, I know I need to change something.” > > After 8 years of Qt, it's time to say goodbye. Both from my employment in The Qt Company and my roles in the Qt Project. I'd like to thank those of you in the company and in the Qt Project who have supported me over the years in various ways. It's been a great adventure. Friday, February 23rd will be my last day. > > I hereby relinquish my role as Maintainer of Apple build system support across all projects under the Qt Project umbrella (nominating Oswald Buddenhagen as my replacement), and my role as Maintainer of the Apple watchOS platform (nominating Tor Arne Vestbø as my replacement). > > Please feel free to contact me at jake.petroules at petroules.com if you have any questions, comments, or otherwise. > > I wish you all the best. > > Sincerely, > Jake Petroules > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From aha_1980 at gmx.de Sun Feb 11 14:16:55 2018 From: aha_1980 at gmx.de (=?UTF-8?Q?Andr=c3=a9_Hartmann?=) Date: Sun, 11 Feb 2018 14:16:55 +0100 Subject: [Development] Goodbye In-Reply-To: References: Message-ID: Hi Jake, I'd also like to thank you for all your work on Qt and especially QBS. Best wishes for your future! André Am 09.02.2018 um 21:14 schrieb Jake Petroules: > Steve Jobs once said: > >> “I have looked in the mirror every morning and asked myself: "If today were the last day of my life, would I want to do what I am about to do today?" And whenever the answer has been "No" for too many days in a row, I know I need to change something.” > > > After 8 years of Qt, it's time to say goodbye. Both from my employment in The Qt Company and my roles in the Qt Project. I'd like to thank those of you in the company and in the Qt Project who have supported me over the years in various ways. It's been a great adventure. Friday, February 23rd will be my last day. > > I hereby relinquish my role as Maintainer of Apple build system support across all projects under the Qt Project umbrella (nominating Oswald Buddenhagen as my replacement), and my role as Maintainer of the Apple watchOS platform (nominating Tor Arne Vestbø as my replacement). > > Please feel free to contact me at jake.petroules at petroules.com if you have any questions, comments, or otherwise. > > I wish you all the best. > > Sincerely, > Jake Petroules > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > From christian.kandeler at qt.io Mon Feb 12 10:14:38 2018 From: christian.kandeler at qt.io (Christian Kandeler) Date: Mon, 12 Feb 2018 10:14:38 +0100 Subject: [Development] Goodbye In-Reply-To: References: Message-ID: <20180212101438.0770930e@ckandeler-archlinux> On Fri, 9 Feb 2018 21:14:22 +0100 Jake Petroules wrote: > Steve Jobs once said: > > > “I have looked in the mirror every morning and asked myself: "If today were the last day of my life, would I want to do what I am about to do today?" And whenever the answer has been "No" for too many days in a row, I know I need to change something.” Yeah, but he also said "Let's treat this cancer with some random herbs instead of actual medicine", so I'm not sure you should just blindly follow his advice. Just sayin'. > After 8 years of Qt, it's time to say goodbye. Both from my employment in The Qt Company and my roles in the Qt Project. I'd like to thank those of you in the company and in the Qt Project who have supported me over the years in various ways. It's been a great adventure. Friday, February 23rd will be my last day. > > I hereby relinquish my role as Maintainer of Apple build system support across all projects under the Qt Project umbrella (nominating Oswald Buddenhagen as my replacement), and my role as Maintainer of the Apple watchOS platform (nominating Tor Arne Vestbø as my replacement). I'm missing the part where you provide the qbs project with a new macOS freak, so I'm afraid I can't accept this resignation. Best wishes, Christian From oswald.buddenhagen at qt.io Mon Feb 12 14:53:36 2018 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Mon, 12 Feb 2018 14:53:36 +0100 Subject: [Development] [HEADS UP] 5.9 now in cherry-pick mode; 5.10 closed Message-ID: <20180212135336.GA8114@troll08> moin, this decision was executed now: On Mon, Feb 05, 2018 at 10:35:56AM +0000, Lars Knoll wrote: > This means we’ll go with something close to option 2b that Ossi outlined below: > > * We put 5.9 in cherry-picking mode in line with QUIP 5. > * There is currently no 5.10.2 release planned. The main reason to do one would be to be an urgent security update. This means we also leave 5.10 branch behind and close it. > * If we have a larger security issue that deserves a release (and not just a patch) from 5.10, we can still do that from the branch on top of 5.10.1 (maybe doing a one time merge from 5.9 to 5.10 if we want those fixes as well) > * Instead we put our focus on getting 5.11 out as quickly as we can. Let’s branch now, create first alpha and then beta packages as quickly as possible. Not having to merge from 5.10 will ease this significantly. Getting 5.11 out quick will hopefully also make Webengine not fall too far/long behind upstream security patches. > > Of course, we continue having regular releases from 5.9, but with it being in strict mode, the frequency of releases will maybe drop a bit (from every 6 weeks currently to maybe every 8-10 weeks). Let’s also now plan for at least two patch level releases of 5.11 before 5.12 comes out. there will be final forward merges from 5.10 and 5.9 to 5.11 still, so don't cherry-pick anything just yet. only if your commits to 5.9 don't show up on 5.11 in a few days, you need to forward-pick them. new and not yet integrated fixes should go to 5.11 and be picked to 5.9 if necessary, after we announce the completion of the final merges. picks to 5.6 should be done from 5.9 only, which means two levels of picking (please remove the first pick footer before pushing). From aapo.keskimolo at qt.io Mon Feb 12 15:10:35 2018 From: aapo.keskimolo at qt.io (=?iso-8859-1?Q?Aapo_Keskim=F6l=F6?=) Date: Mon, 12 Feb 2018 14:10:35 +0000 Subject: [Development] CI status update Message-ID: Dear Qt developers, As we all know, there have been challenges in our CI system. To let everyone know, we have established CI task force and allocated 5 experienced developers to help CI team fixing and stabilize CI. Following areas are under extensive care as long as needed: * Flaky cases * CI infrastructure bottlenecks * Coin bugs and development (garbage collector, opennebula, product module support) We have also arranged workshop with original Coin developers in Oslo that will take place on week 26th of Feb that will be focusing on solving the most pressing issues. If you find any problems in CI that you suspect being flaky or needs studying, please contact sami.nurmenniemi at qt.io He is in charge of overall picture / prioritization of the situation. Kind regards, Coin Team -------------- next part -------------- An HTML attachment was scrubbed... URL: From edward.welbourne at qt.io Tue Feb 13 12:08:54 2018 From: edward.welbourne at qt.io (Edward Welbourne) Date: Tue, 13 Feb 2018 11:08:54 +0000 Subject: [Development] Suggestion: switch binary builds to OpenSSL 1.1 in Qt 5.11 In-Reply-To: <21438517.s3S0DQbiCe@tjmaciei-mobl1> References: <3028229.9F9WlbBkjx@tjmaciei-mobl1> <1943690.xHuxWiDLCH@tjmaciei-mobl1> <577c67ba-13fe-e4f3-5329-7ccb6053cfc3@kdab.com>, <21438517.s3S0DQbiCe@tjmaciei-mobl1> Message-ID: On Friday, 9 February 2018 10:04:30 PST Giuseppe D'Angelo wrote: > The point isn't which version of Qt comes with the distribution, but the > binary builds. Given people do use binary builds (to have an up-to-date > Qt) but not mess with OpenSSL, the outcome will be that SSL will not be > functional for the users of the distributions I mentioned before. Well, conversely, those who use our binary distributions on more modern releases of those distributions have the opposite problem; when Debian/testing upgraded to OpenSSL 1.1, it gave me problems, obliging me to downgrade OpenSSL in order to continue using Qt. If folk are willing to upgrade Qt on an old distro, I don't think it's any more unreasonable to ask for a new OpenSSL version than to ask folk using up-to-date distros to downgrade their OpenSSL to accommodate a Qt that's contemporary with the up-to-date rest of their distribution. If anything, expecting the latter is more unreasonable than expecting the former. Eddy. From annulen at yandex.ru Tue Feb 13 12:13:57 2018 From: annulen at yandex.ru (Konstantin Tokarev) Date: Tue, 13 Feb 2018 14:13:57 +0300 Subject: [Development] Suggestion: switch binary builds to OpenSSL 1.1 in Qt 5.11 In-Reply-To: References: <3028229.9F9WlbBkjx@tjmaciei-mobl1> <1943690.xHuxWiDLCH@tjmaciei-mobl1> <577c67ba-13fe-e4f3-5329-7ccb6053cfc3@kdab.com>, <21438517.s3S0DQbiCe@tjmaciei-mobl1> Message-ID: <282551518520437@web29g.yandex.ru> 13.02.2018, 14:09, "Edward Welbourne" : > On Friday, 9 February 2018 10:04:30 PST Giuseppe D'Angelo wrote: >>  The point isn't which version of Qt comes with the distribution, but the >>  binary builds. Given people do use binary builds (to have an up-to-date >>  Qt) but not mess with OpenSSL, the outcome will be that SSL will not be >>  functional for the users of the distributions I mentioned before. > > Well, conversely, those who use our binary distributions on more modern > releases of those distributions have the opposite problem; when > Debian/testing upgraded to OpenSSL 1.1, it gave me problems, obliging me > to downgrade OpenSSL in order to continue using Qt. AFAIU you should install libssl1.0.2 package instead of downgrading anything AFAIK all good binary distros provide packages for parallel openssl versions when they are not binary compatible However, implementing QTBUG-65922 would certainly make life easier for some folks. > > If folk are willing to upgrade Qt on an old distro, I don't think it's > any more unreasonable to ask for a new OpenSSL version than to ask folk > using up-to-date distros to downgrade their OpenSSL to accommodate a Qt > that's contemporary with the up-to-date rest of their distribution. If > anything, expecting the latter is more unreasonable than expecting the > former. > >         Eddy. > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From jani.heikkinen at qt.io Tue Feb 13 12:41:14 2018 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Tue, 13 Feb 2018 11:41:14 +0000 Subject: [Development] Qt 5.10.1 and Qt Creator 4.5.1 released In-Reply-To: References: Message-ID: Hi all, We have released Qt 5.10.1 and Qt Creator 4.5.1 today, see http://blog.qt.io/blog/2018/02/13/qt-5-10-1-released/ and http://blog.qt.io/blog/2018/02/13/qt-creator-4-5-1-released/ Big thanks to everyone involved! br, Jani From frederik.gladhorn at qt.io Tue Feb 13 13:13:20 2018 From: frederik.gladhorn at qt.io (Frederik Gladhorn) Date: Tue, 13 Feb 2018 13:13:20 +0100 Subject: [Development] Google Summer of Code Message-ID: <3011498.pqlVzRuCsn@frederik-thinkcentre-m93p> Hi all, The Qt Project has been accepted as mentor organization for GSoC. Yay! https://summerofcode.withgoogle.com/organizations/5388456415461376/ We now should collect ideas for projects that students could work on, we started here: https://wiki.qt.io/Google_Summer_of_Code/2018/Project_Ideas For students it's a good idea to start talking to people in areas you are interested in already. We have not yet set the criteria for being accepted, but I imagine you should at least have pushed a change or two to Qt's codereview and have some C++ knowledge (or willingness to learn), depending on the task. http://wiki.qt.io/Qt_Contribution_Guidelines will help you getting started. Check out KDE's guidelines, many things apply to Qt (both for students and mentors): https://community.kde.org/GSoC I'd like to invite everyone to join #qt-gsoc on freenode. Ask questions about procedure in #qt-gsoc, programming questions then in #qt- labs on IRC/freenode. This mailing list is also a good place to discuss about potential work this summer. People that have been active in developing Qt can of course be mentors, let me know if you want to be part of the mentor team, signing up for mentoring is not a commitment yet. Note that you cannot be mentor and student at the same time. We will aim to have at least two mentors for each project and that mentoring does take time and commitment, it's not an easy task (not to discourage you, the more mentors we have, the better). The general overview page for Qt GSoC is here: https://wiki.qt.io/Google_Summer_of_Code/2018 Right now the organization page for GSoC shows "The Qt Company", which is a mistake we made when applying for the program. It of course should be the "Qt Project". This is the first time we'll participate in GSoC, so I don't expect us to get too many slots, we'll find out as we go, I do hope we'll have some great applications and get interesting things into Qt. Cheers, Frederik From thiago.macieira at intel.com Tue Feb 13 17:22:36 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 13 Feb 2018 08:22:36 -0800 Subject: [Development] Google Summer of Code In-Reply-To: <3011498.pqlVzRuCsn@frederik-thinkcentre-m93p> References: <3011498.pqlVzRuCsn@frederik-thinkcentre-m93p> Message-ID: <34515127.QZGRYTYsAe@tjmaciei-mobl1> On terça-feira, 13 de fevereiro de 2018 04:13:20 PST Frederik Gladhorn wrote: > Hi all, > > The Qt Project has been accepted as mentor organization for GSoC. Yay! > https://summerofcode.withgoogle.com/organizations/5388456415461376/ That reads "The Qt Company", not "The Qt Project". > We now should collect ideas for projects that students could work on, we > started here: > https://wiki.qt.io/Google_Summer_of_Code/2018/Project_Ideas Would've been nice to be told we were applying, so we could contribute to the ideas list. > Right now the organization page for GSoC shows "The Qt Company", which is a > mistake we made when applying for the program. It of course should be the > "Qt Project". -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From b.terrier at gmail.com Wed Feb 14 12:22:34 2018 From: b.terrier at gmail.com (Benjamin TERRIER) Date: Wed, 14 Feb 2018 12:22:34 +0100 Subject: [Development] Google Summer of Code In-Reply-To: <34515127.QZGRYTYsAe@tjmaciei-mobl1> References: <3011498.pqlVzRuCsn@frederik-thinkcentre-m93p> <34515127.QZGRYTYsAe@tjmaciei-mobl1> Message-ID: 2018-02-13 17:22 GMT+01:00 Thiago Macieira : > > On terça-feira, 13 de fevereiro de 2018 04:13:20 PST Frederik Gladhorn wrote: > > Hi all, > > > > The Qt Project has been accepted as mentor organization for GSoC. Yay! > > https://summerofcode.withgoogle.com/organizations/5388456415461376/ > > That reads "The Qt Company", not "The Qt Project". > > > We now should collect ideas for projects that students could work on, we > > started here: > > https://wiki.qt.io/Google_Summer_of_Code/2018/Project_Ideas > > Would've been nice to be told we were applying, so we could contribute to the > ideas list. > That's because according to the Qt Project governance model, if the mailing list has never been informed that the Qt Project was applying, then the Qt project was not applying. So it looks to me that the Qt Company applied for the Qt Project. Or am I missing something? Anyway that's a great idea, and I like the idea of an IncludeOS port of Qt. Is there some decisions already made about the licensing of the contributions? Like, are contributions going to be released under GPL/LGPL/Commercial license like most of Qt, or are they going to be GPL/Commercial only? Regards, Benjamin From ritt.ks at gmail.com Wed Feb 14 12:36:13 2018 From: ritt.ks at gmail.com (Konstantin Ritt) Date: Wed, 14 Feb 2018 14:36:13 +0300 Subject: [Development] Suggestion: switch binary builds to OpenSSL 1.1 in Qt 5.11 In-Reply-To: <282551518520437@web29g.yandex.ru> References: <3028229.9F9WlbBkjx@tjmaciei-mobl1> <1943690.xHuxWiDLCH@tjmaciei-mobl1> <577c67ba-13fe-e4f3-5329-7ccb6053cfc3@kdab.com> <21438517.s3S0DQbiCe@tjmaciei-mobl1> <282551518520437@web29g.yandex.ru> Message-ID: Can we have both OpenSSL 1.0.x and 1.1.x supported when configured with -openssl-runtime and choose 1.0 or 1.1 with -openssl-linked? Anyhow? Regards, Konstantin 2018-02-13 14:13 GMT+03:00 Konstantin Tokarev : > > > 13.02.2018, 14:09, "Edward Welbourne" : > > On Friday, 9 February 2018 10:04:30 PST Giuseppe D'Angelo wrote: > >> The point isn't which version of Qt comes with the distribution, but > the > >> binary builds. Given people do use binary builds (to have an up-to-date > >> Qt) but not mess with OpenSSL, the outcome will be that SSL will not be > >> functional for the users of the distributions I mentioned before. > > > > Well, conversely, those who use our binary distributions on more modern > > releases of those distributions have the opposite problem; when > > Debian/testing upgraded to OpenSSL 1.1, it gave me problems, obliging me > > to downgrade OpenSSL in order to continue using Qt. > > AFAIU you should install libssl1.0.2 package instead of downgrading > anything > > AFAIK all good binary distros provide packages for parallel openssl > versions > when they are not binary compatible > > However, implementing QTBUG-65922 would certainly make life easier for > some folks. > > > > > If folk are willing to upgrade Qt on an old distro, I don't think it's > > any more unreasonable to ask for a new OpenSSL version than to ask folk > > using up-to-date distros to downgrade their OpenSSL to accommodate a Qt > > that's contemporary with the up-to-date rest of their distribution. If > > anything, expecting the latter is more unreasonable than expecting the > > former. > > > > Eddy. > > _______________________________________________ > > Development mailing list > > Development at qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development > > -- > Regards, > Konstantin > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rich at kde.org Wed Feb 14 13:35:04 2018 From: rich at kde.org (Richard Moore) Date: Wed, 14 Feb 2018 12:35:04 +0000 Subject: [Development] Suggestion: switch binary builds to OpenSSL 1.1 in Qt 5.11 In-Reply-To: References: <3028229.9F9WlbBkjx@tjmaciei-mobl1> <1943690.xHuxWiDLCH@tjmaciei-mobl1> <577c67ba-13fe-e4f3-5329-7ccb6053cfc3@kdab.com> <21438517.s3S0DQbiCe@tjmaciei-mobl1> <282551518520437@web29g.yandex.ru> Message-ID: On 14 February 2018 at 11:36, Konstantin Ritt wrote: > Can we have both OpenSSL 1.0.x and 1.1.x supported when configured with > -openssl-runtime and choose 1.0 or 1.1 with -openssl-linked? Anyhow? > > ​No. Rich.​ -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Wed Feb 14 16:10:42 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 14 Feb 2018 07:10:42 -0800 Subject: [Development] Google Summer of Code In-Reply-To: References: <3011498.pqlVzRuCsn@frederik-thinkcentre-m93p> <34515127.QZGRYTYsAe@tjmaciei-mobl1> Message-ID: <3173220.e0cRi1y0XJ@tjmaciei-mobl1> On quarta-feira, 14 de fevereiro de 2018 03:22:34 PST Benjamin TERRIER wrote: > > Would've been nice to be told we were applying, so we could contribute to > > the ideas list. > > That's because according to the Qt Project governance model, if the > mailing list has never been informed > that the Qt Project was applying, then the Qt project was not applying. > So it looks to me that the Qt Company applied for the Qt Project. Sounds like it. > Or am I missing something? > > Anyway that's a great idea, and I like the idea of an IncludeOS port of Qt. > > Is there some decisions already made about the licensing of the > contributions? Like, are contributions going to be released under > GPL/LGPL/Commercial license like most of Qt, > or are they going to be GPL/Commercial only? If they land in the repository, they need to follow the regular licensing. And this is GSoC, everything needs to be Open Source. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From frederik.gladhorn at qt.io Thu Feb 15 11:04:40 2018 From: frederik.gladhorn at qt.io (Frederik Gladhorn) Date: Thu, 15 Feb 2018 11:04:40 +0100 Subject: [Development] Google Summer of Code In-Reply-To: <34515127.QZGRYTYsAe@tjmaciei-mobl1> References: <3011498.pqlVzRuCsn@frederik-thinkcentre-m93p> <34515127.QZGRYTYsAe@tjmaciei-mobl1> Message-ID: <5032642.EDmkvRyVWC@frederik-thinkcentre-m93p> Hello Thiago, I tried to clarify things with my mail. It was a bit of a chance that we got in at all, we got the name wrong and probably a ton of other things. All taken into account, I think it's actually pretty great that we got in and I'd rather we prove now that Qt is something students should work on than dwell on our beginner mistakes. I assure you there was no bad intent, just a complete lack of coordination. I learned that we had applied the same day I sent the mail. On tirsdag 13. februar 2018 17.22.36 CET Thiago Macieira wrote: > On terça-feira, 13 de fevereiro de 2018 04:13:20 PST Frederik Gladhorn wrote: > > Hi all, > > > > The Qt Project has been accepted as mentor organization for GSoC. Yay! > > https://summerofcode.withgoogle.com/organizations/5388456415461376/ > > That reads "The Qt Company", not "The Qt Project". As mentioned, it was a mistake, coordination and such... I mentioned this at the end of my original mail. https://summerofcode.withgoogle.com/organizations/5388456415461376/ is now fixed. Please don't let this stop you from getting involved. > > We now should collect ideas for projects that students could work on, we > > started here: > > https://wiki.qt.io/Google_Summer_of_Code/2018/Project_Ideas > > Would've been nice to be told we were applying, so we could contribute to > the ideas list. Yes, please do contribute now. There is nothing preventing us from getting a great ideas page in place, actually that's currently our main focus, getting the page polished and filled with interesting projects. Everyone can add to the page, so please do. Cheers, Frederik From frederik.gladhorn at qt.io Thu Feb 15 11:09:19 2018 From: frederik.gladhorn at qt.io (Frederik Gladhorn) Date: Thu, 15 Feb 2018 11:09:19 +0100 Subject: [Development] Google Summer of Code In-Reply-To: References: <3011498.pqlVzRuCsn@frederik-thinkcentre-m93p> <34515127.QZGRYTYsAe@tjmaciei-mobl1> Message-ID: <1537900.Y2jC3uFqls@frederik-thinkcentre-m93p> On onsdag 14. februar 2018 12.22.34 CET Benjamin TERRIER wrote: > 2018-02-13 17:22 GMT+01:00 Thiago Macieira : > > On terça-feira, 13 de fevereiro de 2018 04:13:20 PST Frederik Gladhorn wrote: > > > Hi all, > > > > > > The Qt Project has been accepted as mentor organization for GSoC. Yay! > > > https://summerofcode.withgoogle.com/organizations/5388456415461376/ > > > > That reads "The Qt Company", not "The Qt Project". > > > > > We now should collect ideas for projects that students could work on, we > > > started here: > > > https://wiki.qt.io/Google_Summer_of_Code/2018/Project_Ideas > > > > Would've been nice to be told we were applying, so we could contribute to > > the ideas list. > > That's because according to the Qt Project governance model, if the > mailing list has never been informed > that the Qt Project was applying, then the Qt project was not applying. > So it looks to me that the Qt Company applied for the Qt Project. > Or am I missing something? Yes. We did, we should have announced it beforehand. Please believe me that there was no bad intention, quite the opposite. The Qt Company will support projects and mentor some, we'd love to have the community involved, as usual, just drop me a line and I'll add you to the list of mentors. I hope we end up doing a good job and will continue this next year in a more coordinated fashion :) > Anyway that's a great idea, and I like the idea of an IncludeOS port of Qt. > > Is there some decisions already made about the licensing of the > contributions? Like, are contributions going to be released under > GPL/LGPL/Commercial license like most of Qt, > or are they going to be GPL/Commercial only? As Thiago says, the work needs to follow all the usual procedures of contributing to Qt. Cheers, Frederik > > Regards, > > Benjamin > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From thiago.macieira at intel.com Thu Feb 15 17:19:50 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 15 Feb 2018 08:19:50 -0800 Subject: [Development] FW: [core] RFC 8323 on CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets Message-ID: <2963273.ukR84vDBye@tjmaciei-mobl1> FYI [links are broken, but you get the message] -----Original Message----- From: core [mailto:core-bounces at ietf.org] On Behalf Of rfc-editor at rfc- editor.org Sent: Wednesday, February 14, 2018 5:35 PM To: ietf-announce at ietf.org; rfc-dist at rfc-editor.org Cc: drafts-update-ref at iana.org; core at ietf.org; rfc-editor at rfc-editor.org Subject: [core] RFC 8323 on CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets A new Request for Comments is now available in online RFC libraries. RFC 8323 Title: CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets Author: C. Bormann, S. Lemay, H. Tschofenig, K. Hartke, B. Silverajan, B. Raymor, Ed. Status: Standards Track Stream: IETF Date: February 2018 Mailbox: cabo at tzi.org, slemay at zebra.com, Hannes.Tschofenig at gmx.net, hartke at tzi.org, Bilhanan.Silverajan at tut.fi, brianraymor at hotmail.com Pages: 54 Characters: 110771 Updates: RFC 7641, RFC 7959 I-D Tag: draft-ietf-core-coap-tcp-tls-11.txt URL: https://na01.safelinks.protection.outlook.com/?url=https %3A%2F%2Fwww.rfc-editor.org%2Finfo%2Frfc8323&data=04%7C01%7Cdthaler %40microsoft.com %7C9ca4aa3e503d4add198a08d57414e0d5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636542555383393659%7CUnknown %7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D %7C-1&sdata=c9EgxpKCaOhsgnkrP1QspjRw8DmLxWlybOtOsqL6qYY%3D&reserved=0 DOI: 10.17487/RFC8323 The Constrained Application Protocol (CoAP), although inspired by HTTP, was designed to use UDP instead of TCP. The message layer of CoAP over UDP includes support for reliable delivery, simple congestion control, and flow control. Some environments benefit from the availability of CoAP carried over reliable transports such as TCP or Transport Layer Security (TLS). This document outlines the changes required to use CoAP over TCP, TLS, and WebSockets transports. It also formally updates RFC 7641 for use with these transports and RFC 7959 to enable the use of larger messages over a reliable transport. This document is a product of the Constrained RESTful Environments Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://na01.safelinks.protection.outlook.com/?url=https %3A%2F%2Fwww.rfc-editor.org%2Fstandards&data=04%7C01%7Cdthaler%40microsoft.com %7C9ca4aa3e503d4add198a08d57414e0d5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636542555383393659%7CUnknown %7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D %7C-1&sdata=ZLUTQDmkGqerQ3YAFZRAt6qspHyABJOwC53R2QAzGDE%3D&reserved=0) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor at rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. ----------------------------------------- -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From jhihn at gmx.com Thu Feb 15 22:34:14 2018 From: jhihn at gmx.com (Jason H) Date: Thu, 15 Feb 2018 22:34:14 +0100 Subject: [Development] webgl text Message-ID: I have s simple UI where I have a few buttons, a LOT of text, I basically use the buttons to assign values to the text. (I'll attach a pic) I am using a TextEdit and DocumentHandler to do this. Select text, click button, it changes the background color. Or vice versa. It works extremely well on desktop, and I can see the events come across and be processed, but the update to the UI is forever (~30s). I don't know WebGL, if anything can be done that well but wanted to point it out. I know it's early yet, I'm hoping it could be further optimized. Also the TextEdit doesn't scroll. It's about 1000 lines of text, about 60 words per line, just messing with the background color for the text. -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2018-02-15 at 4.16.33 PM.png Type: image/png Size: 27807 bytes Desc: not available URL: From tony.sarajarvi at qt.io Fri Feb 16 08:20:11 2018 From: tony.sarajarvi at qt.io (=?iso-8859-1?Q?Tony_Saraj=E4rvi?=) Date: Fri, 16 Feb 2018 07:20:11 +0000 Subject: [Development] CI going down for update Message-ID: Hi We'll take the CI down for update for a short while. The web page won't work at all during that time, since we'll close the whole server. Thanks for your patience. -Tony -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony.sarajarvi at qt.io Fri Feb 16 15:44:49 2018 From: tony.sarajarvi at qt.io (=?iso-8859-1?Q?Tony_Saraj=E4rvi?=) Date: Fri, 16 Feb 2018 14:44:49 +0000 Subject: [Development] CI going down for update In-Reply-To: References: Message-ID: Hi We have to do things the hard way, meaning copying over a lot of stuff instead of just converting stuff. No unexpected things have poped up during the hard way however, but the copy phase takes a lot of time. ETA (or nothing really arrives now... so EToC): in a few hours. -T From: Tony Sarajärvi Sent: perjantai 16. helmikuuta 2018 9.20 To: 'development at qt-project.org' Subject: CI going down for update Hi We'll take the CI down for update for a short while. The web page won't work at all during that time, since we'll close the whole server. Thanks for your patience. -Tony -------------- next part -------------- An HTML attachment was scrubbed... URL: From Simon.Hausmann at qt.io Fri Feb 16 16:09:33 2018 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Fri, 16 Feb 2018 15:09:33 +0000 Subject: [Development] CI going down for update In-Reply-To: References: , Message-ID: Thanks for the update! Good luck and thanks for working on this :) Simon ________________________________ From: Tony Sarajärvi Sent: Friday, February 16, 2018 3:44:49 PM To: development at qt-project.org Subject: RE: CI going down for update Hi We have to do things the hard way, meaning copying over a lot of stuff instead of just converting stuff. No unexpected things have poped up during the hard way however, but the copy phase takes a lot of time. ETA (or nothing really arrives now… so EToC): in a few hours. -T From: Tony Sarajärvi Sent: perjantai 16. helmikuuta 2018 9.20 To: 'development at qt-project.org' Subject: CI going down for update Hi We’ll take the CI down for update for a short while. The web page won’t work at all during that time, since we’ll close the whole server. Thanks for your patience. -Tony -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony.sarajarvi at qt.io Mon Feb 19 09:12:40 2018 From: tony.sarajarvi at qt.io (=?utf-8?B?VG9ueSBTYXJhasOkcnZp?=) Date: Mon, 19 Feb 2018 08:12:40 +0000 Subject: [Development] CI going down for update In-Reply-To: References: , Message-ID: Hi Let me recap what we did last weekend. * The Coin storage now has more storage space available. This should mean less rebooting the system for cleanup. * We also noticed a VMware teak that increases the I/O from the storage. This could potentially make Coin more stable as the bandwidth doesn’t run out. * We now have LVM installed, so further expansion of the storage is easier now. Because we installed LVM, we had to redo the partitions. This required us to move data about a lot. We could have just deleted the logs and artifacts and let Coin rebuild them (we would have gotten the system up already on Friday evening), but by copying over all the data from a backup we enabled Coin to resume like nothing had happened (didn’t need to rebuild all the existing artifacts). It also enabled all the current logs to be visible for our company internal users that read the data straight from Coin instead of testresults.qt.io where they are published. With all the flaky autotests we had, we might have ended up trying to recover from lost artifacts until Saturday morning anyway. So the delay wasn’t bad if we think about it that way 😊 On an unrelated note. We’ve reverted some of the build hosts to Ubuntu 16.04 as the underlying platform. It looks like it’s just as stable if not more stable than the 17.xx ones. At least as of yet, not a single one has crashed! If this continues, this is _very_ good news for the CI. It will knock down a very annoying problem where the hosts that’s running all the virtual machines kept crashing and failing all the builds. Let’s hope this trend continues. Happy building! -Tony From: Simon Hausmann Sent: perjantai 16. helmikuuta 2018 17.10 To: Tony Sarajärvi ; development at qt-project.org Subject: Re: CI going down for update Thanks for the update! Good luck and thanks for working on this :) Simon ________________________________ From: Tony Sarajärvi Sent: Friday, February 16, 2018 3:44:49 PM To: development at qt-project.org Subject: RE: CI going down for update Hi We have to do things the hard way, meaning copying over a lot of stuff instead of just converting stuff. No unexpected things have poped up during the hard way however, but the copy phase takes a lot of time. ETA (or nothing really arrives now… so EToC): in a few hours. -T From: Tony Sarajärvi Sent: perjantai 16. helmikuuta 2018 9.20 To: 'development at qt-project.org' > Subject: CI going down for update Hi We’ll take the CI down for update for a short while. The web page won’t work at all during that time, since we’ll close the whole server. Thanks for your patience. -Tony -------------- next part -------------- An HTML attachment was scrubbed... URL: From parthpartani9724 at gmail.com Mon Feb 19 23:30:26 2018 From: parthpartani9724 at gmail.com (Parth Partani) Date: Tue, 20 Feb 2018 04:00:26 +0530 Subject: [Development] Introduction Message-ID: Hi, I am Parth , and I am looking forward to contribute to this organisation and be part of Gsoc18. I am bit experienced with c/c++ , Qt , Opengl , etc. I have read the Idea page of Gsoc and I was interested in 3d Map Item project . Can someone suggest me how to get started with this project or contribute to issues/bug reports to get understanding with the code base. Thank You From tuukka.turunen at qt.io Tue Feb 20 07:45:33 2018 From: tuukka.turunen at qt.io (Tuukka Turunen) Date: Tue, 20 Feb 2018 06:45:33 +0000 Subject: [Development] Introduction In-Reply-To: References: Message-ID: Hi, This is great to hear :) There are multiple ways to contribute: https://wiki.qt.io/Contribute For code contributions, instructions are here: http://wiki.qt.io/Qt_Contribution_Guidelines One good way to get started is to fix some easy bug or even just improve the documentation a bit to test the contribution, review and merge process. You can find bugs and suggestions for new features at: https://bugreports.qt.io/projects/QTBUG When you make a contribution, add some of the people who have been working with the area as reviewers. Yours, Tuukka On 20/02/2018, 0.30, "Development on behalf of Parth Partani" wrote: Hi, I am Parth , and I am looking forward to contribute to this organisation and be part of Gsoc18. I am bit experienced with c/c++ , Qt , Opengl , etc. I have read the Idea page of Gsoc and I was interested in 3d Map Item project . Can someone suggest me how to get started with this project or contribute to issues/bug reports to get understanding with the code base. Thank You _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From alexander.blasche at qt.io Tue Feb 20 08:04:55 2018 From: alexander.blasche at qt.io (Alex Blasche) Date: Tue, 20 Feb 2018 07:04:55 +0000 Subject: [Development] Introduction In-Reply-To: References: Message-ID: Hi Parth, As you know this project deals with qtlocation (http://code.qt.io/cgit/qt/qtlocation.git/). The main contact for the project is Paolo Angelelli (on CC). In particular he would be able to provide the technical details and directions. -- Alex > -----Original Message----- > From: Development [mailto:development- > bounces+alexander.blasche=qt.io at qt-project.org] On Behalf Of Parth Partani > Sent: Monday, 19 February 2018 23:30 > To: development at qt-project.org > Subject: [Development] Introduction > > Hi, > I am Parth , and I am looking forward to contribute to this organisation and be > part of Gsoc18. I am bit experienced with c/c++ , Qt , Opengl , etc. I have read > the Idea page of Gsoc and I was interested in 3d Map Item project . Can > someone suggest me how to get started with this project or contribute to > issues/bug reports to get understanding with the code base. > Thank You > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From jani.heikkinen at qt.io Tue Feb 20 11:14:35 2018 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Tue, 20 Feb 2018 10:14:35 +0000 Subject: [Development] Qt 5.11 Alpha released In-Reply-To: References: Message-ID: Hi all, We have release Qt 5.11 Alpha today, see http://blog.qt.io/blog/2018/02/20/qt-5-11-alpha-released/ Big thanks to everyone involved! br, Jani Heikkinen Release Manager From wyc8094 at gmail.com Wed Feb 21 05:16:22 2018 From: wyc8094 at gmail.com (Yuchen Wang) Date: Wed, 21 Feb 2018 12:16:22 +0800 Subject: [Development] My understanding on a GoSC project Message-ID: <2885A7B8-D098-43B8-B6DE-A4BAC753D1CF@gmail.com> Dear all: My name is Yuchen Wong, a student from China. I have 3-year experience in c++ programming and quite interested in the Valhalla Offline routing plugin. In my opinion, it is a wrapper of Valhalla. In the guideline from qt, a GeoService plugin should implement at least one ManagerEngine class. Thus I think we can divide this project into following steps: - Investigating Valhalla’s document and divide its function. - Match Valhalla’s function with the functions we want to implement. - Code following what we have got. - Documentation It is the last year of my undergraduate. I wanna have fun with this project during my last summer vacation. 3 months is quite OK for me i believe. Yuchen Wong 2018.2.21 Sent from my iPad From harald.kjolberg at qt.io Wed Feb 21 13:44:22 2018 From: harald.kjolberg at qt.io (=?utf-8?B?SGFyYWxkIEtqw7hsYmVyZw==?=) Date: Wed, 21 Feb 2018 12:44:22 +0000 Subject: [Development] Prebuilt 32-bit versjon for MSVC 2017 Message-ID: Hi, Currently Qt ships with 32-bit binaries for MSVC 2015, but not for MSVC 2017. The Qt Company have received requests for adding prebuilt 32-bit binaries also for MSVC 2017. By adding more prebuilt binaries, we increase the complexity, and add to the overall maintenance of our QA system. Our preferred approach would be to add binaries for MSVC 2017 and remove the binaries for MSVC 2015, as the numbers of binaries in the build remains the same. It will still be possible to manually build Qt for MSVC 2015, in the same way as it is possible to manually build for MSVC 2017 today. Feedback and viewpoints are much appreciated and will enable us to make the best possible decision. Best regards, Harald Kjølberg Product Manager - Qt for Application Development From paolo.angelelli at qt.io Wed Feb 21 13:53:15 2018 From: paolo.angelelli at qt.io (Paolo Angelelli) Date: Wed, 21 Feb 2018 13:53:15 +0100 Subject: [Development] My understanding on a GoSC project In-Reply-To: <2885A7B8-D098-43B8-B6DE-A4BAC753D1CF@gmail.com> References: <2885A7B8-D098-43B8-B6DE-A4BAC753D1CF@gmail.com> Message-ID: <20180221135315.335790da@qdesktop> Hi Yuchen, great to hear you are interested in this project! You are quite right there, such a plugin should essentially wrap valhalla. The project steps you describe seem already a good approximation of a potential project. Actually, a starting point for wrapping Valhalla could be looking at the project https://github.com/rinigus/osmscout-server, where valhalla is wrapped into a standalone server. Some missing bits, imo, are - documentation of a data generation pipeline (Valhalla needs data to work on, and the outcome of the project should ideally contain instructions and tools to produce these data starting from the OSM db file(s)), - Example QML application using the plugin If you are serious about this project, next step would be trying to find a mentor for it, who will also help you writing the project proposal. Please contact us on IRC (Freenode, #qt-gsoc channel), or write me an email, so we can take it further! best, Paolo On Wed, 21 Feb 2018 12:16:22 +0800 Yuchen Wang wrote: > Dear all: > > My name is Yuchen Wong, a student from China. I have 3-year experience in c++ programming and quite interested in the Valhalla Offline routing plugin. > > In my opinion, it is a wrapper of Valhalla. In the guideline from qt, a GeoService plugin should implement at least one ManagerEngine class. Thus I think we can divide this project into following steps: > > - Investigating Valhalla’s document and divide its function. > - Match Valhalla’s function with the functions we want to implement. > - Code following what we have got. > - Documentation > > It is the last year of my undergraduate. I wanna have fun with this project during my last summer vacation. 3 months is quite OK for me i believe. > > Yuchen Wong > 2018.2.21 > > Sent from my iPad > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From enmarantispam at gmail.com Wed Feb 21 14:04:04 2018 From: enmarantispam at gmail.com (NIkolai Marchenko) Date: Wed, 21 Feb 2018 16:04:04 +0300 Subject: [Development] Prebuilt 32-bit versjon for MSVC 2017 In-Reply-To: References: Message-ID: This dedication to dropping MSVC2015x32 seems quite stange after the whole controversy of dropping MSVC2013 and how many people prefered to tread very carefully and slowly. Unlike msvc 2013, 15th compiler is way better and doesn't restrain Qt codebase nearly as much On Wed, Feb 21, 2018 at 3:44 PM, Harald Kjølberg wrote: > > Hi, > > Currently Qt ships with 32-bit binaries for MSVC 2015, but not for MSVC > 2017. The Qt Company have received requests for adding prebuilt 32-bit > binaries also for MSVC 2017. By adding more prebuilt binaries, we increase > the complexity, and add to the overall maintenance of our QA system. Our > preferred approach would be to add binaries for MSVC 2017 and remove the > binaries for MSVC 2015, as the numbers of binaries in the build remains the > same. It will still be possible to manually build Qt for MSVC 2015, in the > same way as it is possible to manually build for MSVC 2017 today. Feedback > and viewpoints are much appreciated and will enable us to make the best > possible decision. > > > > > Best regards, > Harald Kjølberg > Product Manager - Qt for Application Development > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fromqt at tungware.se Wed Feb 21 14:15:35 2018 From: fromqt at tungware.se (Henry Skoglund) Date: Wed, 21 Feb 2018 14:15:35 +0100 Subject: [Development] Prebuilt 32-bit versjon for MSVC 2017 In-Reply-To: References: Message-ID: <0c714fea-ec53-5bd0-f5a5-2bccda4e94c1@tungware.se> Hi, if I want to download prebuilt Qt binaries for the UWP platform then I can choose between 32-bit and 64-bit flavors of both MSVC 2015 and MSVC 2017. It should be possible to offer the same variety for the Win32 versions, especially since I think the # of downloads for the Win32 Qt versions exceed the # of downloads for the UWP platform (for example, UWP requires Windows 10, but Win32 versions also work on Windows 7 and 8). Rgrds Henry On 2018-02-21 14:04, NIkolai Marchenko wrote: > This dedication to dropping MSVC2015x32 seems quite stange after the > whole controversy of dropping MSVC2013 and how many people prefered to > tread very carefully and slowly. > > Unlike msvc 2013, 15th compiler is way better and doesn't restrain Qt > codebase nearly as much > > On Wed, Feb 21, 2018 at 3:44 PM, Harald Kjølberg > wrote: > > > Hi, > > Currently Qt ships with 32-bit binaries for MSVC 2015, but not for > MSVC 2017. The Qt Company have received requests for adding prebuilt > 32-bit binaries also for MSVC 2017. By adding more prebuilt > binaries, we increase the complexity, and add to the overall > maintenance of our QA system. Our preferred approach would be to add > binaries for MSVC 2017 and remove the binaries for MSVC 2015, as the > numbers of binaries in the build remains the same. It will still be > possible to manually build Qt for MSVC 2015, in the same way as it > is possible to manually build for MSVC 2017 today. Feedback and > viewpoints are much appreciated and will enable us to make the best > possible decision. > > > > > Best regards, > Harald Kjølberg > Product Manager - Qt for Application Development > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > > > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > From Maurice.Kalinowski at qt.io Wed Feb 21 14:22:27 2018 From: Maurice.Kalinowski at qt.io (Maurice Kalinowski) Date: Wed, 21 Feb 2018 13:22:27 +0000 Subject: [Development] Prebuilt 32-bit versjon for MSVC 2017 In-Reply-To: <0c714fea-ec53-5bd0-f5a5-2bccda4e94c1@tungware.se> References: <0c714fea-ec53-5bd0-f5a5-2bccda4e94c1@tungware.se> Message-ID: The reason we have had x86 and x64 packages for UWP is not to target those two architectures for the desktop, but rather that the x86 version also works for the emulators for Windows Phone 8 / Windows 10 Mobile as well as Windows 10 IoT (Core). Given that two out of those are basically gone by now, I'd be fine with dropping UWP x86 packages, but keep the arm packages for out embedded user base on Windows 10 IoT. BR, Maurice > -----Ursprüngliche Nachricht----- > Von: Development [mailto:development- > bounces+maurice.kalinowski=qt.io at qt-project.org] Im Auftrag von Henry > Skoglund > Gesendet: Wednesday, February 21, 2018 2:16 PM > An: development at qt-project.org > Betreff: Re: [Development] Prebuilt 32-bit versjon for MSVC 2017 > > Hi, > if I want to download prebuilt Qt binaries for the UWP platform then I can > choose between 32-bit and 64-bit flavors of both MSVC 2015 and MSVC 2017. > > It should be possible to offer the same variety for the Win32 versions, > especially since I think the # of downloads for the Win32 Qt versions exceed > the # of downloads for the UWP platform (for example, UWP requires > Windows 10, but Win32 versions also work on Windows 7 and 8). > > Rgrds Henry > > > On 2018-02-21 14:04, NIkolai Marchenko wrote: > > This dedication to dropping MSVC2015x32 seems quite stange after the > > whole controversy of dropping MSVC2013 and how many people prefered to > > tread very carefully and slowly. > > > > Unlike msvc 2013, 15th compiler is way better and doesn't restrain Qt > > codebase nearly as much > > > > On Wed, Feb 21, 2018 at 3:44 PM, Harald Kjølberg > > > wrote: > > > > > > Hi, > > > > Currently Qt ships with 32-bit binaries for MSVC 2015, but not for > > MSVC 2017. The Qt Company have received requests for adding prebuilt > > 32-bit binaries also for MSVC 2017. By adding more prebuilt > > binaries, we increase the complexity, and add to the overall > > maintenance of our QA system. Our preferred approach would be to add > > binaries for MSVC 2017 and remove the binaries for MSVC 2015, as the > > numbers of binaries in the build remains the same. It will still be > > possible to manually build Qt for MSVC 2015, in the same way as it > > is possible to manually build for MSVC 2017 today. Feedback and > > viewpoints are much appreciated and will enable us to make the best > > possible decision. > > > > > > > > > > Best regards, > > Harald Kjølberg > > Product Manager - Qt for Application Development > > > > > > > > _______________________________________________ > > Development mailing list > > Development at qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development > > > > > > > > > > > > _______________________________________________ > > Development mailing list > > Development at qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development > > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From oswald.buddenhagen at qt.io Wed Feb 21 14:44:56 2018 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Wed, 21 Feb 2018 14:44:56 +0100 Subject: [Development] [HEADS UP] 5.9 now in cherry-pick mode; 5.10 closed In-Reply-To: <20180212135336.GA8114@troll08> References: <20180212135336.GA8114@troll08> Message-ID: <20180221134456.GA18454@troll08> On Mon, Feb 12, 2018 at 02:53:36PM +0100, Oswald Buddenhagen wrote: > there will be final forward merges from 5.10 and 5.9 to 5.11 still, so > don't cherry-pick anything just yet. only if your commits to 5.9 don't > show up on 5.11 in a few days, you need to forward-pick them. new and > not yet integrated fixes should go to 5.11 and be picked to 5.9 if > necessary, after we announce the completion of the final merges. > much later than expected, all merges have been completed. if any commit is missing from a relevant branch, it needs to be forward or backward picked now. > picks to 5.6 should be done from 5.9 only, which means two levels of > picking (please remove the first pick footer before pushing). > From fromqt at tungware.se Wed Feb 21 16:46:35 2018 From: fromqt at tungware.se (Henry Skoglund) Date: Wed, 21 Feb 2018 16:46:35 +0100 Subject: [Development] Prebuilt 32-bit versjon for MSVC 2017 In-Reply-To: References: <0c714fea-ec53-5bd0-f5a5-2bccda4e94c1@tungware.se> Message-ID: <89b7305b-726a-b78b-10cf-468843c092fe@tungware.se> On 2018-02-21 14:22, Maurice Kalinowski wrote: > The reason we have had x86 and x64 packages for UWP is not to target those two architectures for the desktop, but rather that the x86 version also works for the emulators for Windows Phone 8 / Windows 10 Mobile as well as Windows 10 IoT (Core). > > Given that two out of those are basically gone by now, I'd be fine with dropping UWP x86 packages, but keep the arm packages for out embedded user base on Windows 10 IoT. > > BR, > Maurice This is very good news. Several times in the Qt Forums I've helped people who wanted 32-bit prebuilt MSVC2017 Qt binaries, and ended up downloading the UWP version for building Win32 apps. Of course Visual Studio when building UWP apps does not use the linker switch /SUBSYSTEM:WINDOWS,6.2 setting to disallow starting the .exe file on Windows 7 (but allowing the same .exe to run on Windows 10). Instead you get a missing .dll error like "The program can't start because api-ms-win-core-rtlsupport-l1-2-0.dll is missing from your computer." And this leads to people struggling with trying to install that .dll etc. Windows 7 (see for example here https://forum.qt.io/topic/85047/can-t-launch-application-dll-is-missing ) But Visual Studio uses the same switch set to /SUBSYSTEM:WINDOWS,6.0 to disallow MSVC2015/MSVC2017 Win32 apps to run on Windows XP and Win2K3, go figure. Rgrds Henry From edward.welbourne at qt.io Wed Feb 21 17:43:23 2018 From: edward.welbourne at qt.io (Edward Welbourne) Date: Wed, 21 Feb 2018 16:43:23 +0000 Subject: [Development] Qt 5.11 Alpha released In-Reply-To: References: , Message-ID: Jani Heikkinen (20 February 2018 11:14) > We have release Qt 5.11 Alpha today, see http://blog.qt.io/blog/2018/02/20/qt-5-11-alpha-released/ and so, of course, we also have 5.11 API reviews, vs v5.10.1: https://codereview.qt-project.org/221039 qtbase https://codereview.qt-project.org/221040 qtdeclarative https://codereview.qt-project.org/221041 qtmultimedia https://codereview.qt-project.org/221042 qttools https://codereview.qt-project.org/221043 qtxmlpatterns https://codereview.qt-project.org/221044 qtlocation https://codereview.qt-project.org/221045 qtconnectivity https://codereview.qt-project.org/221046 qtwayland https://codereview.qt-project.org/221047 qt3d https://codereview.qt-project.org/221048 qtserialbus https://codereview.qt-project.org/221049 qtandroidextras https://codereview.qt-project.org/221050 qtwebengine https://codereview.qt-project.org/221051 qtcharts https://codereview.qt-project.org/221052 qtgamepad https://codereview.qt-project.org/221053 qtremoteobjects See the review comments for guidance, consult actual source for definitive views of code - note that these reviews are generated by a script that filters out changes deemed boring; it has learned, on this iteration, to not waste your time with s/Q_DECL_FINAL/final/ or s/Q_QDOC/Q_CLANG_QDOC/ changes; and to ignore the addition of Q_DECL_COLD_FUNCTION. Speaking of which, please accept my apologies for not delivering this two days ago - I got distracted by trying to revamp the script to be a bit smarter about detecting boring changes that add a line, among other things. Eddy. From thiago.macieira at intel.com Wed Feb 21 18:18:33 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 21 Feb 2018 09:18:33 -0800 Subject: [Development] Qt 5.11 Alpha released In-Reply-To: References: Message-ID: <2441882.nvQGjUDfBK@tjmaciei-mobl1> On Wednesday, 21 February 2018 08:43:23 PST Edward Welbourne wrote: > and so, of course, we also have 5.11 API reviews, vs v5.10.1: Thanks, Eddy! -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From tim at klingt.org Thu Feb 22 10:39:50 2018 From: tim at klingt.org (Tim Blechmann) Date: Thu, 22 Feb 2018 16:39:50 +0700 Subject: [Development] Prebuilt 32-bit versjon for MSVC 2017 In-Reply-To: References: Message-ID: > Currently Qt ships with 32-bit binaries for MSVC 2015, but not for > MSVC 2017. The Qt Company have received requests for adding prebuilt > 32-bit binaries also for MSVC 2017. By adding more prebuilt binaries, > we increase the complexity, and add to the overall maintenance of our > QA system. Our preferred approach would be to add binaries for MSVC > 2017 and remove the binaries for MSVC 2015, as the numbers of > binaries in the build remains the same. It will still be possible to > manually build Qt for MSVC 2015, in the same way as it is possible to > manually build for MSVC 2017 today. Feedback and viewpoints are much > appreciated and will enable us to make the best possible decision. the ABI of msvc2015 and msvc2017 is the same. so unlike earlier msvc releases, one can mix binaries from both compilers. in theory. in practice there is a still unresolved compiler bug in msvc2017 (we've experienced it only with static libs and debug builds, but i'm not sure if it has any implication on the binaries you want to release): https://developercommunity.visualstudio.com/content/problem/76198/vs-2017-compiler-creates-broken-debug-build-using.html cheers, tim From tuukka.turunen at qt.io Thu Feb 22 14:14:14 2018 From: tuukka.turunen at qt.io (Tuukka Turunen) Date: Thu, 22 Feb 2018 13:14:14 +0000 Subject: [Development] [Qt-creator] Requesting repository for telemetry plugin in Qt Creator Message-ID: Hi, +1 for creating the repo, but what about qt/qtanalytics as a name? This item could be useful also for other applications. Yours, Tuukka From: Qt-creator on behalf of Tino Pyssysalo Date: Thursday, 22 February 2018 at 13.04 To: "qt-creator at qt-project.org" Subject: [Qt-creator] Requesting repository for telemetry plugin in Qt Creator Description: Telemetry plugin (frontend) to collect usage data from Qt Creator to help improving Qt, Qt features, and Qt tools. Non-personal data items, such as duration the user spent in design mode, will be collected in a way, which is completely transparent to the user. Responsible: Tino Pyssysalo Repository: qt-creator/plugin-telemetry --- Tino Pyssysalo Senior Manager The Qt Company Hämeenkatu 14 C 25 33100 Tampere, Finland tino.pyssysalo at qt.io +358 40 8615475 http://qt.io The future is Written with Qt --- -------------- next part -------------- An HTML attachment was scrubbed... URL: From Simon.Hausmann at qt.io Thu Feb 22 14:26:57 2018 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Thu, 22 Feb 2018 13:26:57 +0000 Subject: [Development] [Qt-creator] Requesting repository for telemetry plugin in Qt Creator In-Reply-To: References: Message-ID: 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 2:14:14 PM To: Tino Pyssysalo; qt-creator at qt-project.org; development at qt-project.org Subject: Re: [Development] [Qt-creator] Requesting repository for telemetry plugin in Qt Creator Hi, +1 for creating the repo, but what about qt/qtanalytics as a name? This item could be useful also for other applications. Yours, Tuukka From: Qt-creator on behalf of Tino Pyssysalo Date: Thursday, 22 February 2018 at 13.04 To: "qt-creator at qt-project.org" Subject: [Qt-creator] Requesting repository for telemetry plugin in Qt Creator Description: Telemetry plugin (frontend) to collect usage data from Qt Creator to help improving Qt, Qt features, and Qt tools. Non-personal data items, such as duration the user spent in design mode, will be collected in a way, which is completely transparent to the user. Responsible: Tino Pyssysalo Repository: qt-creator/plugin-telemetry --- Tino Pyssysalo Senior Manager The Qt Company Hämeenkatu 14 C 25 33100 Tampere, Finland tino.pyssysalo at qt.io +358 40 8615475 http://qt.io The future is Written with Qt --- -------------- next part -------------- An HTML attachment was scrubbed... URL: From annulen at yandex.ru Thu Feb 22 14:42:55 2018 From: annulen at yandex.ru (Konstantin Tokarev) Date: Thu, 22 Feb 2018 16:42:55 +0300 Subject: [Development] [Qt-creator] Requesting repository for telemetry plugin in Qt Creator In-Reply-To: References: Message-ID: <94751519306975@web5o.yandex.ru> 22.02.2018, 16:39, "Ryein Goddard" : > This might be nice to make pretty charts to show to managers, but to be completely honest I think it is 100% useless.  If you don't know what people are using your software for, or how then you aren't communicating with them.  You know once upon a time companies just talked with people to figure out what they wanted and what they were having difficulties with.  Why not just take a few surveys a year? Well, there are things that are hard to report via survey, e.g. rate of crashes or memory leaking in clangbackend > > On 02/22/2018 08:26 AM, 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 2:14:14 PM >> To: Tino Pyssysalo; qt-creator at qt-project.org; development at qt-project.org >> Subject: Re: [Development] [Qt-creator] Requesting repository for telemetry plugin in Qt Creator >> >> Hi, >> >> +1 for creating the repo, but what about qt/qtanalytics as a name? This item could be useful also for other applications. >> >> Yours, >> >>                              Tuukka >> >> From: Qt-creator on behalf of Tino Pyssysalo >> Date: Thursday, 22 February 2018 at 13.04 >> To: "qt-creator at qt-project.org" >> Subject: [Qt-creator] Requesting repository for telemetry plugin in Qt Creator >> >> Description: >> >> Telemetry plugin (frontend) to collect usage data from Qt Creator to help improving Qt, Qt features, and Qt tools. >> >> Non-personal data items, such as duration the user spent in design mode, will be collected in a way, which is completely transparent to the user. >> >> Responsible: Tino Pyssysalo >> >> Repository: qt-creator/plugin-telemetry >> >> --- >> >> Tino Pyssysalo >> >> Senior Manager >> >> The Qt Company >> >> Hämeenkatu 14 C 25 >> >> 33100 Tampere, Finland >> >> tino.pyssysalo at qt.io >> >> +358 40 8615475 >> >> http://qt.io >> >> The future is Written with Qt >> >> --- >> >> _______________________________________________ Qt-creator mailing list Qt-creator at qt-project.org http://lists.qt-project.org/mailman/listinfo/qt-creator > , > > _______________________________________________ > Qt-creator mailing list > Qt-creator at qt-project.org > http://lists.qt-project.org/mailman/listinfo/qt-creator --  Regards, Konstantin From tuukka.turunen at qt.io Thu Feb 22 14:47:40 2018 From: tuukka.turunen at qt.io (Tuukka Turunen) Date: Thu, 22 Feb 2018 13:47:40 +0000 Subject: [Development] [Qt-creator] Requesting repository for telemetry plugin in Qt Creator In-Reply-To: References: Message-ID: Hi Simon, Is that an item to decide at repo creation time or something to address later during implementation / code review? For example consider requesting a repo for qt/qtcharts – should we have known what data users want to visualize with it before having a repository (or only during the implementation of the feature)? That said, I do agree that we should discuss about the topic if we are to collect user analytics data – and to also learn what kind of data is valuable to collect (noting that there are strict rules for anything that can be considered personal data). My view is that creating the requested repository and developing the code in the open is very good for transparency and also provides good opportunities for discussion during the implementation. Yours, Tuukka From: Simon Hausmann Date: Thursday, 22 February 2018 at 15.26 To: Tuukka Turunen , Tino Pyssysalo , "qt-creator at qt-project.org" , "development at qt-project.org" Subject: Re: [Development] [Qt-creator] Requesting repository for telemetry plugin in Qt Creator 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 2:14:14 PM To: Tino Pyssysalo; qt-creator at qt-project.org; development at qt-project.org Subject: Re: [Development] [Qt-creator] Requesting repository for telemetry plugin in Qt Creator Hi, +1 for creating the repo, but what about qt/qtanalytics as a name? This item could be useful also for other applications. Yours, Tuukka From: Qt-creator on behalf of Tino Pyssysalo Date: Thursday, 22 February 2018 at 13.04 To: "qt-creator at qt-project.org" Subject: [Qt-creator] Requesting repository for telemetry plugin in Qt Creator Description: Telemetry plugin (frontend) to collect usage data from Qt Creator to help improving Qt, Qt features, and Qt tools. Non-personal data items, such as duration the user spent in design mode, will be collected in a way, which is completely transparent to the user. Responsible: Tino Pyssysalo Repository: qt-creator/plugin-telemetry --- Tino Pyssysalo Senior Manager The Qt Company Hämeenkatu 14 C 25 33100 Tampere, Finland tino.pyssysalo at qt.io +358 40 8615475 http://qt.io The future is Written with Qt --- -------------- next part -------------- An HTML attachment was scrubbed... URL: From Marco.Bubke at qt.io Thu Feb 22 14:54:33 2018 From: Marco.Bubke at qt.io (Marco Bubke) Date: Thu, 22 Feb 2018 13:54:33 +0000 Subject: [Development] [Qt-creator] Requesting repository for telemetry plugin in Qt Creator In-Reply-To: <94751519306975@web5o.yandex.ru> References: , <94751519306975@web5o.yandex.ru> Message-ID: > Well, there are things that are hard to report via survey, e.g. rate of crashes or memory leaking in clangbackend We have a crash handler in the works, which is much more useful than this. And memory leaks can simply be investigated simply by debugging. I don't see how this plugin could help here. Anyway, we disabled the crash recovery already, so most memory leaks should be gone. ________________________________ From: Development on behalf of Konstantin Tokarev Sent: Thursday, February 22, 2018 2:42:55 PM To: Ryein Goddard; Simon Hausmann Cc: development at qt-project.org; qt-creator at qt-project.org Subject: Re: [Development] [Qt-creator] Requesting repository for telemetry plugin in Qt Creator 22.02.2018, 16:39, "Ryein Goddard" : > This might be nice to make pretty charts to show to managers, but to be completely honest I think it is 100% useless. If you don't know what people are using your software for, or how then you aren't communicating with them. You know once upon a time companies just talked with people to figure out what they wanted and what they were having difficulties with. Why not just take a few surveys a year? Well, there are things that are hard to report via survey, e.g. rate of crashes or memory leaking in clangbackend > > On 02/22/2018 08:26 AM, 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 2:14:14 PM >> To: Tino Pyssysalo; qt-creator at qt-project.org; development at qt-project.org >> Subject: Re: [Development] [Qt-creator] Requesting repository for telemetry plugin in Qt Creator >> >> Hi, >> >> +1 for creating the repo, but what about qt/qtanalytics as a name? This item could be useful also for other applications. >> >> Yours, >> >> Tuukka >> >> From: Qt-creator on behalf of Tino Pyssysalo >> Date: Thursday, 22 February 2018 at 13.04 >> To: "qt-creator at qt-project.org" >> Subject: [Qt-creator] Requesting repository for telemetry plugin in Qt Creator >> >> Description: >> >> Telemetry plugin (frontend) to collect usage data from Qt Creator to help improving Qt, Qt features, and Qt tools. >> >> Non-personal data items, such as duration the user spent in design mode, will be collected in a way, which is completely transparent to the user. >> >> Responsible: Tino Pyssysalo >> >> Repository: qt-creator/plugin-telemetry >> >> --- >> >> Tino Pyssysalo >> >> Senior Manager >> >> The Qt Company >> >> Hämeenkatu 14 C 25 >> >> 33100 Tampere, Finland >> >> tino.pyssysalo at qt.io >> >> +358 40 8615475 >> >> http://qt.io >> >> The future is Written with Qt >> >> --- >> >> _______________________________________________ Qt-creator mailing list Qt-creator at qt-project.org http://lists.qt-project.org/mailman/listinfo/qt-creator > , > > _______________________________________________ > Qt-creator mailing list > Qt-creator at qt-project.org > http://lists.qt-project.org/mailman/listinfo/qt-creator -- Regards, Konstantin _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From Simon.Hausmann at qt.io Thu Feb 22 14:58:11 2018 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Thu, 22 Feb 2018 13:58:11 +0000 Subject: [Development] [Qt-creator] Requesting repository for telemetry plugin in Qt Creator In-Reply-To: References: , Message-ID: Hi, For the charts it's indeed not so relevant what kind of charts we can visualize. That is an implementation detail indeed. But whether visualization data in charts is relevant to the users of Qt and whether we would like to make this part of the Qt project is certainly a question we'd clarify up-front before commencing development. With the given description in this request, it is not evident to me how this fits into the scope of the Qt project, hence my question. I'm not asking about the protocol details, encoding format and memory consumption. I'm wondering about how the requested repository fits into Qt, and that is not clear to me with the provided information. I don't feel that this is an implementation question, it's as fundamental as the name of the repository itself. Differently put: I'm giving -1 simply because I think more information should be presented to clarify the scope. I'm not saying that this would never ever fit into Qt. We request the same for other modules (say cloudmessaging), so I think it makes sense to do that here, too. Simon ________________________________ From: Tuukka Turunen Sent: Thursday, February 22, 2018 2:47:40 PM To: Simon Hausmann; Tino Pyssysalo; qt-creator at qt-project.org; development at qt-project.org Subject: Re: [Development] [Qt-creator] Requesting repository for telemetry plugin in Qt Creator Hi Simon, Is that an item to decide at repo creation time or something to address later during implementation / code review? For example consider requesting a repo for qt/qtcharts – should we have known what data users want to visualize with it before having a repository (or only during the implementation of the feature)? That said, I do agree that we should discuss about the topic if we are to collect user analytics data – and to also learn what kind of data is valuable to collect (noting that there are strict rules for anything that can be considered personal data). My view is that creating the requested repository and developing the code in the open is very good for transparency and also provides good opportunities for discussion during the implementation. Yours, Tuukka From: Simon Hausmann Date: Thursday, 22 February 2018 at 15.26 To: Tuukka Turunen , Tino Pyssysalo , "qt-creator at qt-project.org" , "development at qt-project.org" Subject: Re: [Development] [Qt-creator] Requesting repository for telemetry plugin in Qt Creator 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 2:14:14 PM To: Tino Pyssysalo; qt-creator at qt-project.org; development at qt-project.org Subject: Re: [Development] [Qt-creator] Requesting repository for telemetry plugin in Qt Creator Hi, +1 for creating the repo, but what about qt/qtanalytics as a name? This item could be useful also for other applications. Yours, Tuukka From: Qt-creator on behalf of Tino Pyssysalo Date: Thursday, 22 February 2018 at 13.04 To: "qt-creator at qt-project.org" Subject: [Qt-creator] Requesting repository for telemetry plugin in Qt Creator Description: Telemetry plugin (frontend) to collect usage data from Qt Creator to help improving Qt, Qt features, and Qt tools. Non-personal data items, such as duration the user spent in design mode, will be collected in a way, which is completely transparent to the user. Responsible: Tino Pyssysalo Repository: qt-creator/plugin-telemetry --- Tino Pyssysalo Senior Manager The Qt Company Hämeenkatu 14 C 25 33100 Tampere, Finland tino.pyssysalo at qt.io +358 40 8615475 http://qt.io The future is Written with Qt --- -------------- next part -------------- An HTML attachment was scrubbed... URL: From tino.pyssysalo at qt.io Thu Feb 22 14:58:55 2018 From: tino.pyssysalo at qt.io (Tino Pyssysalo) Date: Thu, 22 Feb 2018 13:58:55 +0000 Subject: [Development] [Qt-creator] Requesting repository for telemetry plugin in Qt Creator In-Reply-To: References: Message-ID: <297808CB-E1C3-484B-B316-8232EF714033@qt.io> 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 2:14:14 PM To: Tino Pyssysalo; qt-creator at qt-project.org; development at qt-project.org Subject: Re: [Development] [Qt-creator] Requesting repository for telemetry plugin in Qt Creator Hi, +1 for creating the repo, but what about qt/qtanalytics as a name? This item could be useful also for other applications. Yours, Tuukka From: Qt-creator on behalf of Tino Pyssysalo Date: Thursday, 22 February 2018 at 13.04 To: "qt-creator at qt-project.org" Subject: [Qt-creator] Requesting repository for telemetry plugin in Qt Creator Description: Telemetry plugin (frontend) to collect usage data from Qt Creator to help improving Qt, Qt features, and Qt tools. Non-personal data items, such as duration the user spent in design mode, will be collected in a way, which is completely transparent to the user. Responsible: Tino Pyssysalo Repository: qt-creator/plugin-telemetry --- Tino Pyssysalo Senior Manager The Qt Company Hämeenkatu 14 C 25 33100 Tampere, Finland tino.pyssysalo at qt.io +358 40 8615475 http://qt.io The future is Written with Qt --- -------------- next part -------------- An HTML attachment was scrubbed... URL: From Marco.Bubke at qt.io Thu Feb 22 15:36:34 2018 From: Marco.Bubke at qt.io (Marco Bubke) Date: Thu, 22 Feb 2018 14:36:34 +0000 Subject: [Development] [Qt-creator] Requesting repository for telemetry plugin in Qt Creator In-Reply-To: <297808CB-E1C3-484B-B316-8232EF714033@qt.io> References: , <297808CB-E1C3-484B-B316-8232EF714033@qt.io> Message-ID: It would be nice if you can explain what data you want to collect and how it will be help the creator development. In my view it is quite hard to collect data about not implemented features, so you could only provide information about what feature is used. So the data could be used to see what should be polished. But could this not lead to false impression because people don't use a 'very useful' features because the implementation is 'suboptimal'. Would in that case not JIRA a much better source of information? ________________________________ From: Qt-creator on behalf of Tino Pyssysalo Sent: Thursday, February 22, 2018 2:58:55 PM To: Simon Hausmann; Tuukka Turunen; qt-creator at qt-project.org; development at qt-project.org Subject: 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 2:14:14 PM To: Tino Pyssysalo; qt-creator at qt-project.org; development at qt-project.org Subject: Re: [Development] [Qt-creator] Requesting repository for telemetry plugin in Qt Creator Hi, +1 for creating the repo, but what about qt/qtanalytics as a name? This item could be useful also for other applications. Yours, Tuukka From: Qt-creator on behalf of Tino Pyssysalo Date: Thursday, 22 February 2018 at 13.04 To: "qt-creator at qt-project.org" Subject: [Qt-creator] Requesting repository for telemetry plugin in Qt Creator Description: Telemetry plugin (frontend) to collect usage data from Qt Creator to help improving Qt, Qt features, and Qt tools. Non-personal data items, such as duration the user spent in design mode, will be collected in a way, which is completely transparent to the user. Responsible: Tino Pyssysalo Repository: qt-creator/plugin-telemetry --- Tino Pyssysalo Senior Manager The Qt Company Hämeenkatu 14 C 25 33100 Tampere, Finland tino.pyssysalo at qt.io +358 40 8615475 http://qt.io The future is Written with Qt --- -------------- next part -------------- An HTML attachment was scrubbed... URL: From Simon.Hausmann at qt.io Thu Feb 22 15:45:43 2018 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Thu, 22 Feb 2018 14:45:43 +0000 Subject: [Development] [Qt-creator] Requesting repository for telemetry plugin in Qt Creator In-Reply-To: <297808CB-E1C3-484B-B316-8232EF714033@qt.io> References: , <297808CB-E1C3-484B-B316-8232EF714033@qt.io> Message-ID: Hi, Thanks for the update, this is starting to make more sense to me. So do I understand correctly that you'd like to have one API that you could use from a proprietary Qt Creator plugin (for commercial tooling) as well as from the installer framework, and the repository that you're requesting contains that API, along with the ability to dispatch to a variable backend? Beyond the dispatching, what functionality would you want to place into such a repository? Can you explain what these two use-cases have in common, beyond a too generic "void collectData(const QString &key, const QVariant &value)" type of functionality? A better understanding of the common patterns and the API helps in finding a good name I think. Simon ________________________________ From: Tino Pyssysalo Sent: Thursday, February 22, 2018 2:58:55 PM To: Simon Hausmann; Tuukka Turunen; qt-creator at qt-project.org; development at qt-project.org Subject: Re: [Development] [Qt-creator] 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 2:14:14 PM To: Tino Pyssysalo; qt-creator at qt-project.org; development at qt-project.org Subject: Re: [Development] [Qt-creator] Requesting repository for telemetry plugin in Qt Creator Hi, +1 for creating the repo, but what about qt/qtanalytics as a name? This item could be useful also for other applications. Yours, Tuukka From: Qt-creator on behalf of Tino Pyssysalo Date: Thursday, 22 February 2018 at 13.04 To: "qt-creator at qt-project.org" Subject: [Qt-creator] Requesting repository for telemetry plugin in Qt Creator Description: Telemetry plugin (frontend) to collect usage data from Qt Creator to help improving Qt, Qt features, and Qt tools. Non-personal data items, such as duration the user spent in design mode, will be collected in a way, which is completely transparent to the user. Responsible: Tino Pyssysalo Repository: qt-creator/plugin-telemetry --- Tino Pyssysalo Senior Manager The Qt Company Hämeenkatu 14 C 25 33100 Tampere, Finland tino.pyssysalo at qt.io +358 40 8615475 http://qt.io The future is Written with Qt --- -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Thu Feb 22 17:05:43 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 22 Feb 2018 08:05:43 -0800 Subject: [Development] Prebuilt 32-bit versjon for MSVC 2017 In-Reply-To: References: Message-ID: <5613543.3MlVmS3JDW@tjmaciei-mobl1> On Thursday, 22 February 2018 01:39:50 PST Tim Blechmann wrote: > > Currently Qt ships with 32-bit binaries for MSVC 2015, but not for > > MSVC 2017. The Qt Company have received requests for adding prebuilt > > 32-bit binaries also for MSVC 2017. By adding more prebuilt binaries, > > we increase the complexity, and add to the overall maintenance of our > > QA system. Our preferred approach would be to add binaries for MSVC > > 2017 and remove the binaries for MSVC 2015, as the numbers of > > binaries in the build remains the same. It will still be possible to > > manually build Qt for MSVC 2015, in the same way as it is possible to > > manually build for MSVC 2017 today. Feedback and viewpoints are much > > appreciated and will enable us to make the best possible decision. > > the ABI of msvc2015 and msvc2017 is the same. so unlike earlier msvc > releases, one can mix binaries from both compilers. In theory. In practice, we've found that it doesn't work for Qt, at least because of the Q_COMPILER_xxx defines as MSVC 2015 has fewer C++11 features than 2017. > in theory. in practice there is a still unresolved compiler bug in > msvc2017 (we've experienced it only with static libs and debug builds, > but i'm not sure if it has any implication on the binaries you want to > release): That's another one: everything compiled with MSVC 2017 has incorrect initialisation sequneces. You're running on borrowed time, until Microsoft fixes it (they're saying they'll fix it in the 15.7 release in May). Note I did not say "static". -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From apoenitz at t-online.de Thu Feb 22 20:05:42 2018 From: apoenitz at t-online.de (=?iso-8859-1?Q?Andr=E9_P=F6nitz?=) Date: Thu, 22 Feb 2018 20:05:42 +0100 Subject: [Development] [Qt-creator] Requesting repository for telemetry plugin in Qt Creator In-Reply-To: <94751519306975@web5o.yandex.ru> References: <94751519306975@web5o.yandex.ru> Message-ID: <20180222190542.GA1455@klara.mpi.htwm.de> On Thu, Feb 22, 2018 at 04:42:55PM +0300, Konstantin Tokarev wrote: > 22.02.2018, 16:39, "Ryein Goddard" : > > This might be nice to make pretty charts to show to managers, but to be > > completely honest I think it is 100% useless.  I fully subscribe to that. > > If you don't know what people > > are using your software for, or how then you aren't communicating with > > them.  You know once upon a time companies just talked with people to figure > > out what they wanted and what they were having difficulties with.  Why not > > just take a few surveys a year? > > Well, there are things that are hard to report via survey, e.g. rate of > crashes or memory leaking in clangbackend 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. 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 nor in how to improve Qt Creator in general. In fact, I consider all of that irrelevant and detrimental and would strongly prefer to *not* get access to such information, and neither to anyone's interpretation what bug report this information may relate to. That makes a clear -1 from my side for technical reasons already. Neither legal nor ethical considerations are likely to improve that. Andre' (not speaking for any company etc etc) From sierdzio at gmail.com Thu Feb 22 21:01:59 2018 From: sierdzio at gmail.com (Tomasz Siekierda) Date: Thu, 22 Feb 2018 21:01:59 +0100 Subject: [Development] [Qt-creator] Requesting repository for telemetry plugin in Qt Creator In-Reply-To: <20180222190542.GA1455@klara.mpi.htwm.de> References: <94751519306975@web5o.yandex.ru> <20180222190542.GA1455@klara.mpi.htwm.de> Message-ID: Another point: if you do collect usage data, please bear in mind that sometimes a feature can be used very rarely, but still be vital. In other words, do not consider a feature as "unnecessary" or "can be deprecated" if it is not used often. For example, I mostly do mobile and desktop apps, but I still do want the remote linux deployment to work smoothly for rare occasions when I need to use it. On 22 February 2018 at 20:05, André Pönitz wrote: > > On Thu, Feb 22, 2018 at 04:42:55PM +0300, Konstantin Tokarev wrote: > > 22.02.2018, 16:39, "Ryein Goddard" : > > > This might be nice to make pretty charts to show to managers, but to be > > > completely honest I think it is 100% useless. > > I fully subscribe to that. > > > > If you don't know what people > > > are using your software for, or how then you aren't communicating with > > > them. You know once upon a time companies just talked with people to > figure > > > out what they wanted and what they were having difficulties with. Why > not > > > just take a few surveys a year? > > > > Well, there are things that are hard to report via survey, e.g. rate of > > crashes or memory leaking in clangbackend > > 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. > > 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 > nor in how to improve Qt Creator in general. In fact, I consider all of > that > irrelevant and detrimental and would strongly prefer to *not* get access > to such > information, and neither to anyone's interpretation what bug report this > information may relate to. > > That makes a clear -1 from my side for technical reasons already. > > Neither legal nor ethical considerations are likely to improve that. > > Andre' (not speaking for any company etc etc) > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From apoenitz at t-online.de Thu Feb 22 21:42:59 2018 From: apoenitz at t-online.de (=?iso-8859-1?Q?Andr=E9_P=F6nitz?=) Date: Thu, 22 Feb 2018 21:42:59 +0100 Subject: [Development] [Qt-creator] Requesting repository for telemetry plugin in Qt Creator In-Reply-To: <297808CB-E1C3-484B-B316-8232EF714033@qt.io> References: <297808CB-E1C3-484B-B316-8232EF714033@qt.io> Message-ID: <20180222204259.GB1455@klara.mpi.htwm.de> On Thu, Feb 22, 2018 at 01:58:55PM +0000, Tino Pyssysalo wrote: > Hi, > > The idea is to develop a generic library/plugin, which anyone could use for > analytics. I see no reason why this can't be done as part of e.g. the commercial Qt offering, with customers being free to deploy that if they feel it helps their own offering (for whatever reasons that I luckily do not need to comprehend), nor do I see a reason why this should be used by the Qt Project's Qt Creator, especially when the people potentially acting on the results expressed severe dislike and doubts on the usefulness of such analytics for their work. For an Open Source solution there is e.g. KUserFeedback. I haven't used that myself, but judging from the description it appears to do what you claim to want to do, and judging from a quick look at the code and the name of the author I am ready to bet its implementation is sane. So I really have a hard time to see a gap here that needs to be filled. > 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 At some point you need to qualify what you mean when you use the word "we". Your current use of "we" clearly does not include myself, nor, if you allow me to extrapolate from the grapevine, the majority of the Qt Creator team. So, - who is "we"? - why is "us" (the Qt Creator team) not part of "we" when the topic is related to Qt Creator? - what data do you intent to collect exactly? - what mechanism do you plan to use to translate the collected data into what actions? Andre' From pasi.keranen at qt.io Fri Feb 23 08:05:38 2018 From: pasi.keranen at qt.io (=?utf-8?B?UGFzaSBLZXLDpG5lbg==?=) Date: Fri, 23 Feb 2018 07:05:38 +0000 Subject: [Development] [Qt-creator] Requesting repository for telemetry plugin in Qt Creator In-Reply-To: <20180222204259.GB1455@klara.mpi.htwm.de> References: <297808CB-E1C3-484B-B316-8232EF714033@qt.io> <20180222204259.GB1455@klara.mpi.htwm.de> Message-ID: <407AF18F-8EDB-482F-9530-A6629D25FB4B@qt.io> Hi there, +1 for having a generic telemetry plugin in Qt. This is great initiative and very much the way today's app and application industry works. UX studies performed by UX experts have been minimized and targeted for specific (usually new/experimental) features or upcoming new software (like we did with Qt 3D Studio back in last spring). And the mass information on "how do our users use the SW? do they find the stuff we've put in there? how often they hit a wall in doing sequence X? how many crashes do they experience when doing Y?" is collected via automated telemetry. It is great as it brings data from the actual user in their actual work and you can then use that to concentrate on functionality that really matters to your users. Making stuff they repeat hundred times a week easier and faster, making them more productive. I see definite need for this in Qt 3D Studio so please don’t make this just with Qt Creator in mind. Also, in my humble opinion, in order to be relevant in today's UI development, Qt should also offer this kind of a plug-in to our customers. A ready-to-go plug-in that automatically ensures the data is collected in a way that fulfills data privacy acts and respects the privacy of the user would be great. Especially for startups and smaller companies, but also for bigger companies wanting to switch to the modern way of doing UI development. It is not as easy to do as one might think at glance. I would ask anyone who has not done work with usability and user experience people in the past to give this way of working a chance. I've worked 7 years in application development while we grew usability knowledge in the team over that time. The first time I got to observe a real world user working with our software in actual real world situation was eye opening. We had gotten so many important things wrong in our idealistic thinking and forgotten to handle certain cases that occur on the field. Also you become blind to your own creations faults as you just know how the software works. It's just a fact of life. Regards, Pasi Keränen -- Senior Manager, 3D The Qt Company On 22/02/2018, 22.36, "Development on behalf of André Pönitz" wrote: On Thu, Feb 22, 2018 at 01:58:55PM +0000, Tino Pyssysalo wrote: > Hi, > > The idea is to develop a generic library/plugin, which anyone could use for > analytics. I see no reason why this can't be done as part of e.g. the commercial Qt offering, with customers being free to deploy that if they feel it helps their own offering (for whatever reasons that I luckily do not need to comprehend), nor do I see a reason why this should be used by the Qt Project's Qt Creator, especially when the people potentially acting on the results expressed severe dislike and doubts on the usefulness of such analytics for their work. For an Open Source solution there is e.g. KUserFeedback. I haven't used that myself, but judging from the description it appears to do what you claim to want to do, and judging from a quick look at the code and the name of the author I am ready to bet its implementation is sane. So I really have a hard time to see a gap here that needs to be filled. > 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 At some point you need to qualify what you mean when you use the word "we". Your current use of "we" clearly does not include myself, nor, if you allow me to extrapolate from the grapevine, the majority of the Qt Creator team. So, - who is "we"? - why is "us" (the Qt Creator team) not part of "we" when the topic is related to Qt Creator? - what data do you intent to collect exactly? - what mechanism do you plan to use to translate the collected data into what actions? Andre' _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From Maurice.Kalinowski at qt.io Fri Feb 23 08:33:20 2018 From: Maurice.Kalinowski at qt.io (Maurice Kalinowski) Date: Fri, 23 Feb 2018 07:33:20 +0000 Subject: [Development] [Qt-creator] Requesting repository for telemetry plugin in Qt Creator In-Reply-To: <297808CB-E1C3-484B-B316-8232EF714033@qt.io> References: <297808CB-E1C3-484B-B316-8232EF714033@qt.io> Message-ID: “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.io at qt-project.org] Im Auftrag von Tino Pyssysalo Gesendet: Thursday, February 22, 2018 2:59 PM An: Simon Hausmann ; Tuukka Turunen ; qt-creator at qt-project.org; development at 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 2:14:14 PM To: Tino Pyssysalo; qt-creator at qt-project.org; development at qt-project.org Subject: Re: [Development] [Qt-creator] Requesting repository for telemetry plugin in Qt Creator Hi, +1 for creating the repo, but what about qt/qtanalytics as a name? This item could be useful also for other applications. Yours, Tuukka From: Qt-creator > on behalf of Tino Pyssysalo > Date: Thursday, 22 February 2018 at 13.04 To: "qt-creator at qt-project.org" > Subject: [Qt-creator] Requesting repository for telemetry plugin in Qt Creator Description: Telemetry plugin (frontend) to collect usage data from Qt Creator to help improving Qt, Qt features, and Qt tools. Non-personal data items, such as duration the user spent in design mode, will be collected in a way, which is completely transparent to the user. Responsible: Tino Pyssysalo Repository: qt-creator/plugin-telemetry --- Tino Pyssysalo Senior Manager The Qt Company Hämeenkatu 14 C 25 33100 Tampere, Finland tino.pyssysalo at qt.io +358 40 8615475 http://qt.io The future is Written with Qt --- -------------- next part -------------- An HTML attachment was scrubbed... URL: From pasi.keranen at qt.io Fri Feb 23 08:53:33 2018 From: pasi.keranen at qt.io (=?utf-8?B?UGFzaSBLZXLDpG5lbg==?=) Date: Fri, 23 Feb 2018 07:53:33 +0000 Subject: [Development] [Qt-creator] Requesting repository for telemetry plugin in Qt Creator In-Reply-To: References: <297808CB-E1C3-484B-B316-8232EF714033@qt.io> Message-ID: 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-creator at qt-project.org" , "development at 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.io at qt-project.org] Im Auftrag von Tino Pyssysalo Gesendet: Thursday, February 22, 2018 2:59 PM An: Simon Hausmann ; Tuukka Turunen ; qt-creator at qt-project.org; development at 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 2:14:14 PM To: Tino Pyssysalo; qt-creator at qt-project.org; development at qt-project.org Subject: Re: [Development] [Qt-creator] Requesting repository for telemetry plugin in Qt Creator Hi, +1 for creating the repo, but what about qt/qtanalytics as a name? This item could be useful also for other applications. Yours, Tuukka From: Qt-creator > on behalf of Tino Pyssysalo > Date: Thursday, 22 February 2018 at 13.04 To: "qt-creator at qt-project.org" > Subject: [Qt-creator] Requesting repository for telemetry plugin in Qt Creator Description: Telemetry plugin (frontend) to collect usage data from Qt Creator to help improving Qt, Qt features, and Qt tools. Non-personal data items, such as duration the user spent in design mode, will be collected in a way, which is completely transparent to the user. Responsible: Tino Pyssysalo Repository: qt-creator/plugin-telemetry --- Tino Pyssysalo Senior Manager The Qt Company Hämeenkatu 14 C 25 33100 Tampere, Finland tino.pyssysalo at qt.io +358 40 8615475 http://qt.io The future is Written with Qt --- -------------- next part -------------- An HTML attachment was scrubbed... URL: From Simon.Hausmann at qt.io Fri Feb 23 09:00:33 2018 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Fri, 23 Feb 2018 08:00:33 +0000 Subject: [Development] [Qt-creator] Requesting repository for telemetry plugin in Qt Creator In-Reply-To: References: <297808CB-E1C3-484B-B316-8232EF714033@qt.io> , Message-ID: 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-creator at qt-project.org; development at 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-creator at qt-project.org" , "development at 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.io at qt-project.org] Im Auftrag von Tino Pyssysalo Gesendet: Thursday, February 22, 2018 2:59 PM An: Simon Hausmann ; Tuukka Turunen ; qt-creator at qt-project.org; development at 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 2:14:14 PM To: Tino Pyssysalo; qt-creator at qt-project.org; development at qt-project.org Subject: Re: [Development] [Qt-creator] Requesting repository for telemetry plugin in Qt Creator Hi, +1 for creating the repo, but what about qt/qtanalytics as a name? This item could be useful also for other applications. Yours, Tuukka From: Qt-creator > on behalf of Tino Pyssysalo > Date: Thursday, 22 February 2018 at 13.04 To: "qt-creator at qt-project.org" > Subject: [Qt-creator] Requesting repository for telemetry plugin in Qt Creator Description: Telemetry plugin (frontend) to collect usage data from Qt Creator to help improving Qt, Qt features, and Qt tools. Non-personal data items, such as duration the user spent in design mode, will be collected in a way, which is completely transparent to the user. Responsible: Tino Pyssysalo Repository: qt-creator/plugin-telemetry --- Tino Pyssysalo Senior Manager The Qt Company Hämeenkatu 14 C 25 33100 Tampere, Finland tino.pyssysalo at qt.io +358 40 8615475 http://qt.io The future is Written with Qt --- -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias.hunger at gmail.com Fri Feb 23 09:08:40 2018 From: tobias.hunger at gmail.com (Tobias Hunger) Date: Fri, 23 Feb 2018 09:08:40 +0100 Subject: [Development] [Qt-creator] Requesting repository for telemetry plugin in Qt Creator In-Reply-To: References: Message-ID: Hi Pasi, On Feb 23, 2018 08:05, "Pasi Keränen" wrote: Hi there, +1 for having a generic telemetry plugin in Qt. I planned to stay out of this, but -1 since I am totally confused about the scope of this project at this point. So are we talking about a generic telemetry framework for Qt applications or about watching Qt Creator users specifically? Tino started by making the claim that this is a generic library and then kept listing Qt Creator specific integrations. You focus entirely onto the generic part, leaving out creator completely. What exactly are we talking about here? A Qt creator spyware plug-in (which does more than what we discuss here I hope:-) would be a matter of a couple of weeks to do, putting a generic framework into place with all the bits and pieces for that to be actually useful in a wide list of possible contexts is a very different beast. This is great initiative and very much the way today's app and application industry works. UX studies performed by UX experts have been minimized and targeted for specific (usually new/experimental) features or upcoming new software (like we did with Qt 3D Studio back in last spring). And the mass information on "how do our users use the SW? do they find the stuff we've put in there? how often they hit a wall in doing sequence X? how many crashes do they experience when doing Y?" is collected via automated telemetry. It is great as it brings data from the actual user in their actual work and you can then use that to concentrate on functionality that really matters to your users. Making stuff they repeat hundred times a week easier and faster, making them more productive. I see value in this approach when you can do lots of small releases fast. So you can do evaluate the effect of small changes by doing one change to evaluate per release and measure how that effects usage. We can not do more than two releases per year in Qt. Is this approach even applicable to us? I want to also point out that answering any of the questions you used as an example require *way* more information than I am even remotely comfortable to collect. I see definite need for this in Qt 3D Studio so please don’t make this just with Qt Creator in mind. Also, in my humble opinion, in order to be relevant in today's UI development, Qt should also offer this kind of a plug-in to our customers. A ready-to-go plug-in that automatically ensures the data is collected in a way that fulfills data privacy acts and respects the privacy of the user would be great. Especially for startups and smaller companies, but also for bigger companies wanting to switch to the modern way of doing UI development. It is not as easy to do as one might think at glance. I agree that having a general framework has value to some customers. Such a framework would need to be integrated into big solutions like Google analytics or something similar so the users can actually evaluate the collected data and cross-reference that to other data they collect. Just dumping data into some server somewhere does not help anybody. Will the server-side code be part of this project by the way? What about evaluation of the collected data? Is that in scope for this project, too? I would ask anyone who has not done work with usability and user experience people in the past to give this way of working a chance. I've worked 7 years in application development while we grew usability knowledge in the team over that time. The first time I got to observe a real world user working with our software in actual real world situation was eye opening. We had gotten so many important things wrong in our idealistic thinking and forgotten to handle certain cases that occur on the field. Also you become blind to your own creations faults as you just know how the software works. It's just a fact of life. Sure. We do way too little validation of what we do against the real world usage. Let us do some usability studies, let us talk to users, let us do surveys, let's evaluate all the data users provide to us on the mailing list, the bug tracker, the forums, stack overflow and in lots of other places. We do have a very active and supportive community of users and customers, let us use the feedback they provide already! Collecting some semi-random data from a self-selected group of users and dumping that onto a server somewhere is next to useless compared to all the other options we have already. Even in an ideal situation (which we do not have within Qt!), metrics are not comparable to a real user study where you actually watch users doing their thing. This is even more true when not leaving out any information that can be used to identify individual users from the collected data, which we obviously will do. Best Regards, Tobias -------------- next part -------------- An HTML attachment was scrubbed... URL: From volker.krause at kdab.com Fri Feb 23 10:20:23 2018 From: volker.krause at kdab.com (Volker Krause) Date: Fri, 23 Feb 2018 10:20:23 +0100 Subject: [Development] [Qt-creator] Requesting repository for telemetry plugin in Qt Creator In-Reply-To: <297808CB-E1C3-484B-B316-8232EF714033@qt.io> References: <297808CB-E1C3-484B-B316-8232EF714033@qt.io> Message-ID: <6309590.hPuPXUXxHT@vkpc19> Hi, as numerous people have asked me to comment on this by now, let me just do that here publicly (representing KDE's KUserFeedback, not KDAB): Tino is well aware of KUserFeedback, we discussed that last year already in detail. So it definitely was considered as a possible solution for this. I do not know why it was ultimately decided to implement a new framework, in particular if that's due to conceptual or technical reasons, or licensing. With the KDAB hat back on, we do use KUserFeedback in GammaRay since mid last year, and it has so far provided a few useful insights, in particular regarding to what extend we still need to support ancient Qt versions. But as with any data, it's not the ultimate answer to all questions, and you need to be very careful how to interpret it obviously. We have so far not received any negative feedback with e.g. privacy concerns, but the approach KUserFeedback takes there by default (and that we followed in GammaRay) is intentionally very restrained. Regards, Volker On Thursday, 22 February 2018 14:58:55 CET Tino Pyssysalo wrote: > 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 2:14:14 PM > To: Tino Pyssysalo; qt-creator at qt-project.org; development at qt-project.org > Subject: Re: [Development] [Qt-creator] Requesting repository for telemetry > plugin in Qt Creator > > > > Hi, > > > > +1 for creating the repo, but what about qt/qtanalytics as a name? This item > could be useful also for other applications. > > > Yours, > > > > Tuukka > > > > From: Qt-creator on > behalf of Tino Pyssysalo Date: Thursday, 22 > February 2018 at 13.04 > To: "qt-creator at qt-project.org" > Subject: [Qt-creator] Requesting repository for telemetry plugin in Qt > Creator > > > Description: > > > > Telemetry plugin (frontend) to collect usage data from Qt Creator to help > improving Qt, Qt features, and Qt tools. > Non-personal data items, such as duration the user spent in design mode, > will be collected in a way, which is completely transparent to the user. > > > Responsible: Tino Pyssysalo > > > > Repository: qt-creator/plugin-telemetry > > > > > > --- > > Tino Pyssysalo > > Senior Manager > > > > The Qt Company > > Hämeenkatu 14 C 25 > > 33100 Tampere, Finland > > tino.pyssysalo at qt.io > > +358 40 8615475 > > http://qt.io > > > > The future is Written with Qt > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4664 bytes Desc: not available URL: From pasi.keranen at qt.io Fri Feb 23 10:33:03 2018 From: pasi.keranen at qt.io (=?utf-8?B?UGFzaSBLZXLDpG5lbg==?=) Date: Fri, 23 Feb 2018 09:33:03 +0000 Subject: [Development] [Qt-creator] Requesting repository for telemetry plugin in Qt Creator In-Reply-To: References: Message-ID: <622C9E3B-DB34-4188-A189-3D14FFD19E1A@qt.io> Hi Tobias, I planned to stay out of this, but -1 since I am totally confused about the scope of this project at this point. So are we talking about a generic telemetry framework for Qt applications or about watching Qt Creator users specifically? Tino started by making the claim that this is a generic library and then kept listing Qt Creator specific integrations. You focus entirely onto the generic part, leaving out creator completely. What exactly are we talking about here? My understanding at this point is that this is meant to be a telemetry framework for Qt applications and first integration point that has been in discussions is Qt Creator. I intentionally left Qt Creator out as I don’t feel comfortable talking what they need/don’t need. So instead I concentrated on what I see Qt 3D Studio needs as I feel much more comfortable to talk about that based on our experiences, our engagements with customers and the usability and UI work we’ve done so far in Qt 3D Studio project. I’m always in favor of iterative development as you very very rarely understand the scope and needs at the beginning. So I understand the need to have a “reference integration to try out” even if we talk about aiming towards generic telemetry plugin. And it seems quite obvious from these discussions that we don’t yet know ourselves a lot about how to collect data, what type of data is to be collected and how to process it. We seem to be a bit divided in to individuals thinking this is inherently bad and morally dubious. And individuals (like myself) who see this as great idea to be able to get more data on how people use our tools. Not just from big customers and people who come to our events. But also from people out there in universities, small companies, startups, the people we rarely meet in person. Once we have understanding on what exactly are we after, then it would be good to move towards a generic Qt framework prototype. Maybe integrate against a known and trusted third party framework, add features to the API iteratively based on learnings and iterations. Then move on to publish this as tech preview and while we investigate integrating against another 3rd party framework so that we end up with a truly generic, Qt-like wrapper for specific functionality. A Qt creator spyware plug-in (which does more than what we discuss here I hope:-) would be a matter of a couple of weeks to do, putting a generic framework into place with all the bits and pieces for that to be actually useful in a wide list of possible contexts is a very different beast. I object to using “Spyware” term in this context. Spyware is SW that does things behind your back. Siphons contact information, user account info etc. without telling you. We’re NOT talking about such use cases here! I don’t think anyone in The Qt Company wants to do such things. From what I hear the intention is to track certain things in an open, transparent manner, respecting the communitys clear wish to keep things in the open and for the benefit of our end users. This is great initiative and very much the way today's app and application industry works. UX studies performed by UX experts have been minimized and targeted for specific (usually new/experimental) features or upcoming new software (like we did with Qt 3D Studio back in last spring). And the mass information on "how do our users use the SW? do they find the stuff we've put in there? how often they hit a wall in doing sequence X? how many crashes do they experience when doing Y?" is collected via automated telemetry. It is great as it brings data from the actual user in their actual work and you can then use that to concentrate on functionality that really matters to your users. Making stuff they repeat hundred times a week easier and faster, making them more productive. I see value in this approach when you can do lots of small releases fast. So you can do evaluate the effect of small changes by doing one change to evaluate per release and measure how that effects usage. We can not do more than two releases per year in Qt. Is this approach even applicable to us? Qt 3D Studio plans to do 4 releases per year, so for us this is definitely applicable. Qt Creator does also more than 2 releases a year so perhaps this could be useful for them as well, but as I said. I’m not comfortable talking on their behalf on this. I want to also point out that answering any of the questions you used as an example require *way* more information than I am even remotely comfortable to collect. This is where we definitely differ as individuals. I use software from Apple, Adobe etc. and I’m 100% fine giving them information on my usage statistics as it means the SW might get better over time for me. If e.g. Blender would some day ask me “are you ok for us to track your usage of the SW” I’d be 100% ok to do that as I see that it definitely could improve a lot from observing users. I see the poitive side of this type of usability and user data collection. So taking this in to account, perhaps our solution should somehow enforce possibility to opt-in/opt-out to accommodate for both you and me? I agree that having a general framework has value to some customers. Good to hear we’re in agreement on some level at least! :) Such a framework would need to be integrated into big solutions like Google analytics or something similar so the users can actually evaluate the collected data and cross-reference that to other data they collect. Just dumping data into some server somewhere does not help anybody. Will the server-side code be part of this project by the way? What about evaluation of the collected data? Is that in scope for this project, too? All these are good questions that I’d rather not try to answer in a meeting/email thread/chat thread, but rather prototype hands on iteratively. Just may way of approaching stuff and having experienced so many frustrating analysis paralysis moments and moments where theoretical discussions have proven something “absolutely impossible” only for competition then coming out with that exact feature a few moments later. Just try to do it and see how it goes, collect experience and modify your target setting based on that. Listen to customers, community and you shouldn’t go horribly wrong. Let us do some usability studies, let us talk to users, let us do surveys, let's evaluate all the data users provide to us on the mailing list, the bug tracker, the forums, stack overflow and in lots of other places. We do have a very active and supportive community of users and customers, let us use the feedback they provide already! Yup, we’ve done usability studies with Qt 3D Studio, we’ve done talking with SOME key customers and yes we’ve even fixed a lot of issues they’ve pointed out in Qt 3D Studio. I’m watching our bug tracker all the time, it’s part of the daily work. But let’s be honest.. we CAN’T talk to every user out there, only the biggest ones, only the ones that happen to participate our events. Qt 3D Studio is not talking to probably 95-97% of our users at the moment as we just can’t. Even this mailing list doesn’t cover all of our users. And crawling through all these email threads, no thanks, that is very very inefficient use of time in my opinion. This forum is great for discussing ideas, formulating, pointing out what needs to be considered (like in this case, it’s loud and clear that privacy and opt-in are of great importance to our community for atelemetry feature). Data collection would (when implemented correctly) automate the input collection and bring in data from all over the user base, that is why I see great value in it. Collecting some semi-random data from a self-selected group of users and dumping that onto a server somewhere is next to useless compared to all the other options we have already. Even in an ideal situation (which we do not have within Qt!), metrics are not comparable to a real user study where you actually watch users doing their thing. Perhaps first version will start with a set of data that might turn out to be ”semi random” and “not so useful for understanding users”. But I believe in learning, iterating and improvement. Next iteration we should improve and collect less random set of data that also then helps us in understanding our users better. And so on and so on. Yes I agree, metrics are ADDITIONAL tool. Not replacement for anything. Visiting users and talking with them does sometime open a whole new point of view in to what you are doing. Those can provide revolutionary ideas for you. That isn’t replaced with metrics. But metrics are great for iterative development, as you point out above. Honing and fine tuning the set of functionality you already have in your application. Regards, Pasi -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias.hunger at gmail.com Fri Feb 23 11:22:02 2018 From: tobias.hunger at gmail.com (Tobias Hunger) Date: Fri, 23 Feb 2018 11:22:02 +0100 Subject: [Development] [Qt-creator] Requesting repository for telemetry plugin in Qt Creator In-Reply-To: <622C9E3B-DB34-4188-A189-3D14FFD19E1A@qt.io> References: <622C9E3B-DB34-4188-A189-3D14FFD19E1A@qt.io> Message-ID: Hi Pasi, On Fri, Feb 23, 2018 at 10:33 AM, Pasi Keränen wrote: > I object to using “Spyware” term in this context. Spyware is SW that does > things behind your back. I noticed that my mail could be read in the way you read it pretty much right after sending it. I need to apologize for expressing myself so poorly! What I meant to say that it is possible to write a spyware plugin (following pretty much exactly what you lay out below) for creator or any one Qt application that will collect basically everything about a user and to feed that into a database on the internet somewhere in a couple of weeks. On the other hand the task of writing a framework that does anonymized data collection that follows all the relevant data protection laws and standards and that pushes it to a server that is easy to manage and set up is an entirely different scope. I wanted to find out where our discussion is between these two poles. I did not intend to imply that what we are discussing here is spyware. > Siphons contact information, user account info etc. > without telling you. We’re NOT talking about such use cases here! I don’t > think anyone in The Qt Company wants to do such things. From what I hear the > intention is to track certain things in an open, transparent manner, > respecting the communitys clear wish to keep things in the open and for the > benefit of our end users. I am sorry for giving the impression that I thought anybody here is considering spyware. That was not my intention and I want to apologize to anybody that got that impression. Best Regards, Tobias From tuukka.turunen at qt.io Fri Feb 23 11:26:51 2018 From: tuukka.turunen at qt.io (Tuukka Turunen) Date: Fri, 23 Feb 2018 10:26:51 +0000 Subject: [Development] [Qt-creator] Requesting repository for telemetry plugin in Qt Creator In-Reply-To: <6309590.hPuPXUXxHT@vkpc19> References: <297808CB-E1C3-484B-B316-8232EF714033@qt.io> <6309590.hPuPXUXxHT@vkpc19> Message-ID: Hi, Use of KUserFeedback is problematic due to its license. Adding 3rd party L/GPL components is something I do not want to do (already wrote "we", but let's use "I" instead to avoid need to define what is meant by we :) The reason for avoiding adding any 3rd party components with viral licenses is coming from the commercial licensee needs. If KUserFeedback does what is needed from the discussed Qt add-on module, and the persons who wrote it are interested in contributing it to Qt, that could be one approach. That said, I have not looked into KUserFeedback myself beyond licensing. Yours, Tuukka On 23/02/2018, 11.22, "Development on behalf of Volker Krause" wrote: Hi, as numerous people have asked me to comment on this by now, let me just do that here publicly (representing KDE's KUserFeedback, not KDAB): Tino is well aware of KUserFeedback, we discussed that last year already in detail. So it definitely was considered as a possible solution for this. I do not know why it was ultimately decided to implement a new framework, in particular if that's due to conceptual or technical reasons, or licensing. With the KDAB hat back on, we do use KUserFeedback in GammaRay since mid last year, and it has so far provided a few useful insights, in particular regarding to what extend we still need to support ancient Qt versions. But as with any data, it's not the ultimate answer to all questions, and you need to be very careful how to interpret it obviously. We have so far not received any negative feedback with e.g. privacy concerns, but the approach KUserFeedback takes there by default (and that we followed in GammaRay) is intentionally very restrained. Regards, Volker On Thursday, 22 February 2018 14:58:55 CET Tino Pyssysalo wrote: > 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 2:14:14 PM > To: Tino Pyssysalo; qt-creator at qt-project.org; development at qt-project.org > Subject: Re: [Development] [Qt-creator] Requesting repository for telemetry > plugin in Qt Creator > > > > Hi, > > > > +1 for creating the repo, but what about qt/qtanalytics as a name? This item > could be useful also for other applications. > > > Yours, > > > > Tuukka > > > > From: Qt-creator on > behalf of Tino Pyssysalo Date: Thursday, 22 > February 2018 at 13.04 > To: "qt-creator at qt-project.org" > Subject: [Qt-creator] Requesting repository for telemetry plugin in Qt > Creator > > > Description: > > > > Telemetry plugin (frontend) to collect usage data from Qt Creator to help > improving Qt, Qt features, and Qt tools. > Non-personal data items, such as duration the user spent in design mode, > will be collected in a way, which is completely transparent to the user. > > > Responsible: Tino Pyssysalo > > > > Repository: qt-creator/plugin-telemetry > > > > > > --- > > Tino Pyssysalo > > Senior Manager > > > > The Qt Company > > Hämeenkatu 14 C 25 > > 33100 Tampere, Finland > > tino.pyssysalo at qt.io > > +358 40 8615475 > > http://qt.io > > > > The future is Written with Qt > From Simon.Hausmann at qt.io Fri Feb 23 11:45:01 2018 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Fri, 23 Feb 2018 10:45:01 +0000 Subject: [Development] [Qt-creator] Requesting repository for telemetry plugin in Qt Creator In-Reply-To: <6309590.hPuPXUXxHT@vkpc19> References: <297808CB-E1C3-484B-B316-8232EF714033@qt.io>, <6309590.hPuPXUXxHT@vkpc19> Message-ID: I just had a look at KUserFeedback and I'm impressed. Looks like a really good combination of very useful providers, UI, administration and server bits - all in one relatively small package. And for those not liking the PHP server part, it appears that that would be a piece that is relatively easy to replace - although the code looks very clean. Also very cool that you're using this in production for GammaRay. /That/ is something that would be awesome as part of the Qt project IMHO. Sensible scope, production tested and easy to use. (But I can totally understand that it might make more sense to remain in the KDE frameworks) Simon ________________________________ From: Development on behalf of Volker Krause Sent: Friday, February 23, 2018 10:20:23 AM To: development at qt-project.org; qt-creator at qt-project.org Subject: Re: [Development] [Qt-creator] Requesting repository for telemetry plugin in Qt Creator Hi, as numerous people have asked me to comment on this by now, let me just do that here publicly (representing KDE's KUserFeedback, not KDAB): Tino is well aware of KUserFeedback, we discussed that last year already in detail. So it definitely was considered as a possible solution for this. I do not know why it was ultimately decided to implement a new framework, in particular if that's due to conceptual or technical reasons, or licensing. With the KDAB hat back on, we do use KUserFeedback in GammaRay since mid last year, and it has so far provided a few useful insights, in particular regarding to what extend we still need to support ancient Qt versions. But as with any data, it's not the ultimate answer to all questions, and you need to be very careful how to interpret it obviously. We have so far not received any negative feedback with e.g. privacy concerns, but the approach KUserFeedback takes there by default (and that we followed in GammaRay) is intentionally very restrained. Regards, Volker On Thursday, 22 February 2018 14:58:55 CET Tino Pyssysalo wrote: > 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 2:14:14 PM > To: Tino Pyssysalo; qt-creator at qt-project.org; development at qt-project.org > Subject: Re: [Development] [Qt-creator] Requesting repository for telemetry > plugin in Qt Creator > > > > Hi, > > > > +1 for creating the repo, but what about qt/qtanalytics as a name? This item > could be useful also for other applications. > > > Yours, > > > > Tuukka > > > > From: Qt-creator on > behalf of Tino Pyssysalo Date: Thursday, 22 > February 2018 at 13.04 > To: "qt-creator at qt-project.org" > Subject: [Qt-creator] Requesting repository for telemetry plugin in Qt > Creator > > > Description: > > > > Telemetry plugin (frontend) to collect usage data from Qt Creator to help > improving Qt, Qt features, and Qt tools. > Non-personal data items, such as duration the user spent in design mode, > will be collected in a way, which is completely transparent to the user. > > > Responsible: Tino Pyssysalo > > > > Repository: qt-creator/plugin-telemetry > > > > > > --- > > Tino Pyssysalo > > Senior Manager > > > > The Qt Company > > Hämeenkatu 14 C 25 > > 33100 Tampere, Finland > > tino.pyssysalo at qt.io > > +358 40 8615475 > > http://qt.io > > > > The future is Written with Qt > -------------- next part -------------- An HTML attachment was scrubbed... URL: From edward.welbourne at qt.io Fri Feb 23 11:54:56 2018 From: edward.welbourne at qt.io (Edward Welbourne) Date: Fri, 23 Feb 2018 10:54:56 +0000 Subject: [Development] [Qt-creator] Requesting repository for telemetry plugin in Qt Creator In-Reply-To: <20180222190542.GA1455@klara.mpi.htwm.de> References: <94751519306975@web5o.yandex.ru>, <20180222190542.GA1455@klara.mpi.htwm.de> Message-ID: 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. 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. From volker.krause at kdab.com Fri Feb 23 11:57:59 2018 From: volker.krause at kdab.com (Volker Krause) Date: Fri, 23 Feb 2018 11:57:59 +0100 Subject: [Development] [Qt-creator] Requesting repository for telemetry plugin in Qt Creator In-Reply-To: References: <6309590.hPuPXUXxHT@vkpc19> Message-ID: <6466384.2dccOQdpTL@vkpc19> On Friday, 23 February 2018 11:45:01 CET Simon Hausmann wrote: > I just had a look at KUserFeedback and I'm impressed. > > Looks like a really good combination of very useful providers, UI, > administration and server bits - all in one relatively small package. And > for those not liking the PHP server part, it appears that that would be a > piece that is relatively easy to replace - although the code looks very > clean. I don't like the PHP part either, it was just the easiest technology to deploy on the available servers at the time. The interface is very simple JSON/REST though, so it's indeed easy to explore alternatives. > Also very cool that you're using this in production for GammaRay. > > /That/ is something that would be awesome as part of the Qt project IMHO. > Sensible scope, production tested and easy to use. (But I can totally > understand that it might make more sense to remain in the KDE frameworks) Contribution of the entire KUserFeedback framework under the Qt CLA seems unlikely, but as indicated during previous discussions, a conversation about finding a more acceptable FOSS license to address the commercial user concerns is certainly possible. Regards, Volker > ________________________________ > From: Development > on behalf of Volker Krause Sent: Friday, February > 23, 2018 10:20:23 AM > To: development at qt-project.org; qt-creator at qt-project.org > Subject: Re: [Development] [Qt-creator] Requesting repository for telemetry > plugin in Qt Creator > > Hi, > > as numerous people have asked me to comment on this by now, let me just do > that here publicly (representing KDE's KUserFeedback, not KDAB): > > Tino is well aware of KUserFeedback, we discussed that last year already in > detail. So it definitely was considered as a possible solution for this. > I do not know why it was ultimately decided to implement a new framework, in > particular if that's due to conceptual or technical reasons, or licensing. > > > With the KDAB hat back on, we do use KUserFeedback in GammaRay since mid > last year, and it has so far provided a few useful insights, in particular > regarding to what extend we still need to support ancient Qt versions. But > as with any data, it's not the ultimate answer to all questions, and you > need to be very careful how to interpret it obviously. We have so far not > received any negative feedback with e.g. privacy concerns, but the approach > KUserFeedback takes there by default (and that we followed in GammaRay) is > intentionally very restrained. > > Regards, > Volker > > On Thursday, 22 February 2018 14:58:55 CET Tino Pyssysalo wrote: > > 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 2:14:14 PM > > To: Tino Pyssysalo; qt-creator at qt-project.org; development at qt-project.org > > Subject: Re: [Development] [Qt-creator] Requesting repository for > > telemetry > > plugin in Qt Creator > > > > > > > > > > Hi, > > > > > > > > +1 for creating the repo, but what about qt/qtanalytics as a name? This > > item could be useful also for other applications. > > > > > > > > Yours, > > > > Tuukka > > > > From: Qt-creator > > on behalf of Tino Pyssysalo > > Date: Thursday, 22 > > > February 2018 at 13.04 > > To: "qt-creator at qt-project.org" > > Subject: [Qt-creator] Requesting repository for telemetry plugin in Qt > > Creator > > > > > > > > Description: > > > > > > > > Telemetry plugin (frontend) to collect usage data from Qt Creator to help > > improving Qt, Qt features, and Qt tools. > > > > Non-personal data items, such as duration the user spent in design mode, > > will be collected in a way, which is completely transparent to the user. > > > > > > > > Responsible: Tino Pyssysalo > > > > > > > > Repository: qt-creator/plugin-telemetry > > > > > > > > > > > > --- > > > > Tino Pyssysalo > > > > Senior Manager > > > > > > > > The Qt Company > > > > Hämeenkatu 14 C 25 > > > > 33100 Tampere, Finland > > > > tino.pyssysalo at qt.io > > > > +358 40 8615475 > > > > http://qt.io > > > > > > > > The future is Written with Qt Volker Krause | volker.krause at kdab.com | Director Automotive KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel. +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4664 bytes Desc: not available URL: From adam.treat at qt.io Fri Feb 23 13:28:35 2018 From: adam.treat at qt.io (Adam Treat) Date: Fri, 23 Feb 2018 12:28:35 +0000 Subject: [Development] [Qt-creator] Requesting repository for telemetry plugin in Qt Creator In-Reply-To: References: <297808CB-E1C3-484B-B316-8232EF714033@qt.io> , , Message-ID: +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-creator at qt-project.org; development at 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-creator at qt-project.org; development at 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-creator at qt-project.org" , "development at 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.io at qt-project.org] Im Auftrag von Tino Pyssysalo Gesendet: Thursday, February 22, 2018 2:59 PM An: Simon Hausmann ; Tuukka Turunen ; qt-creator at qt-project.org; development at 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 2:14:14 PM To: Tino Pyssysalo; qt-creator at qt-project.org; development at qt-project.org Subject: Re: [Development] [Qt-creator] Requesting repository for telemetry plugin in Qt Creator Hi, +1 for creating the repo, but what about qt/qtanalytics as a name? This item could be useful also for other applications. Yours, Tuukka From: Qt-creator > on behalf of Tino Pyssysalo > Date: Thursday, 22 February 2018 at 13.04 To: "qt-creator at qt-project.org" > Subject: [Qt-creator] Requesting repository for telemetry plugin in Qt Creator Description: Telemetry plugin (frontend) to collect usage data from Qt Creator to help improving Qt, Qt features, and Qt tools. Non-personal data items, such as duration the user spent in design mode, will be collected in a way, which is completely transparent to the user. Responsible: Tino Pyssysalo Repository: qt-creator/plugin-telemetry --- Tino Pyssysalo Senior Manager The Qt Company Hämeenkatu 14 C 25 33100 Tampere, Finland tino.pyssysalo at qt.io +358 40 8615475 http://qt.io The future is Written with Qt --- -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.loehning at qt.io Fri Feb 23 15:59:01 2018 From: robert.loehning at qt.io (=?UTF-8?Q?Robert_L=c3=b6hning?=) Date: Fri, 23 Feb 2018 15:59:01 +0100 Subject: [Development] [Qt-creator] Requesting repository for telemetry plugin in Qt Creator In-Reply-To: References: <94751519306975@web5o.yandex.ru> <20180222190542.GA1455@klara.mpi.htwm.de> Message-ID: 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 at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > From markus.maier.sw at gmail.com Fri Feb 23 16:03:26 2018 From: markus.maier.sw at gmail.com (Markus Maier) Date: Fri, 23 Feb 2018 16:03:26 +0100 Subject: [Development] Prebuilt 32-bit versjon for MSVC 2017 In-Reply-To: <5613543.3MlVmS3JDW@tjmaciei-mobl1> References: <5613543.3MlVmS3JDW@tjmaciei-mobl1> Message-ID: Hello, just to add my opinion as a current user of the MSVC 2015 32 bit binaries. When selecting an MSVC version to use with Qt, one should keep in mind that Microsoft tends to change things in the compilers even in minor releases. I had quite some issues with one of the updates of MSVC2013 which broke things in my code together with a prebuilt version of Qt. Something similar might happen again when Microsoft fixes the bug mentioned by Thiago. That's why I decided for my projects to always stick with the MSVC version before the current version, where updates are not likely to break something in builds anymore. I believe the same reasons should also apply for choosing a MSVC version for prebuilt 32 bit binaries. Another point might be: whoever uses prebuilt 32 bit binaries now and wants to switch to a static build of Qt would currently be forced to downgrade the compiler because MSVC 2017 as of now doesn't support static builds of Qt (QTBUG-59721). Best regards Markus Maier -------------- next part -------------- An HTML attachment was scrubbed... URL: From roland.m.winklmeier at gmail.com Fri Feb 23 16:33:18 2018 From: roland.m.winklmeier at gmail.com (Roland Winklmeier) Date: Fri, 23 Feb 2018 16:33:18 +0100 Subject: [Development] Prebuilt 32-bit versjon for MSVC 2017 In-Reply-To: References: Message-ID: 2018-02-21 13:44 GMT+01:00 Harald Kjølberg : > > Hi, > > Currently Qt ships with 32-bit binaries for MSVC 2015, but not for MSVC > 2017. The Qt Company have received requests for adding prebuilt 32-bit > binaries also for MSVC 2017. By adding more prebuilt binaries, we increase > the complexity, and add to the overall maintenance of our QA system. Our > preferred approach would be to add binaries for MSVC 2017 and remove the > binaries for MSVC 2015, as the numbers of binaries in the build remains the > same. It will still be possible to manually build Qt for MSVC 2015, in the > same way as it is possible to manually build for MSVC 2017 today. Feedback > and viewpoints are much appreciated and will enable us to make the best > possible decision. > I'm using MSVC 2017 with Qt5 2015 prebuilt binaries. I never had issues with this combination so far, but still would appreciate to have the also have the 32 bit binaries prebuilt with 2017. So I'm happy to hear that this is considered. A little bit offtopic: I think those discussions about prebuilt binaries would be less controversal, if it would be easier to produce custom Qt installers. I'm aware that I can build 32 bit with MSVC 2017 on my own, but creating an installer for my colleagues is a mystery to me. Yes, its easy enough to _build_ Qt yourself. I regularly do that. But its a pain to produce any kind of installers to share it with team members or relocate the built. I would produce more custom prebuilts of Qt, if the documentation about how to create custom installers is up to date and accurate. I tried once to follow http://code.qt.io/cgit/qtsdk/qtsdk.git/tree/packaging-tools/README but it was so much dependent on the Qt CI infrastructure (shares, node names etc), hard to follow and presumably outdated (it referenced Qt 5.5). R. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jani.heikkinen at qt.io Fri Feb 23 16:49:11 2018 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Fri, 23 Feb 2018 15:49:11 +0000 Subject: [Development] Qt 5.11 Beta1 snapshot available In-Reply-To: References: Message-ID: Hi, First Qt 5.11 Beta1 snapshot available via online installer. Please take a tour to see what is working and what not Have a nice weekend! br, jani -------------- next part -------------- An HTML attachment was scrubbed... URL: From tino.pyssysalo at qt.io Fri Feb 23 16:58:02 2018 From: tino.pyssysalo at qt.io (Tino Pyssysalo) Date: Fri, 23 Feb 2018 15:58:02 +0000 Subject: [Development] [Qt-creator] Requesting repository for telemetry plugin in Qt Creator In-Reply-To: References: <297808CB-E1C3-484B-B316-8232EF714033@qt.io> Message-ID: <53044D9E-EE7F-4B44-A725-9DB0CE96188F@qt.io> I’ll clarify little bit, as my earlier comment about “any backend” has been confusing. I requested a repo for a QtCreator analytics plugin, but we realized why not to use a similar solution in other tools as well. I want to concentrate on a Qt Creator plugin first to fully understand the problem domain. Once that is done we can discuss how to move forward with this project”. Our intention is usage data collection, but nothing else at this point. Obviously, we plan to use the collected data to improve Qt. As a concrete example, we have provided a lot of nice features in Qt Quick Designer in the recent Qt Creator releases, but we have no idea, if the use of Qt Quick Designer has changed in any way. This kind of data would be very valuable to us. -- Tino On 23/02/2018, 14.28, "Adam Treat" > wrote: +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-creator at qt-project.org; development at 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-creator at qt-project.org; development at 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-creator at qt-project.org" , "development at 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.io at qt-project.org] Im Auftrag von Tino Pyssysalo Gesendet: Thursday, February 22, 2018 2:59 PM An: Simon Hausmann ; Tuukka Turunen ; qt-creator at qt-project.org; development at 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 2:14:14 PM To: Tino Pyssysalo; qt-creator at qt-project.org; development at qt-project.org Subject: Re: [Development] [Qt-creator] Requesting repository for telemetry plugin in Qt Creator Hi, +1 for creating the repo, but what about qt/qtanalytics as a name? This item could be useful also for other applications. Yours, Tuukka From: Qt-creator > on behalf of Tino Pyssysalo > Date: Thursday, 22 February 2018 at 13.04 To: "qt-creator at qt-project.org" > Subject: [Qt-creator] Requesting repository for telemetry plugin in Qt Creator Description: Telemetry plugin (frontend) to collect usage data from Qt Creator to help improving Qt, Qt features, and Qt tools. Non-personal data items, such as duration the user spent in design mode, will be collected in a way, which is completely transparent to the user. Responsible: Tino Pyssysalo Repository: qt-creator/plugin-telemetry --- Tino Pyssysalo Senior Manager The Qt Company Hämeenkatu 14 C 25 33100 Tampere, Finland tino.pyssysalo at qt.io +358 40 8615475 http://qt.io The future is Written with Qt --- -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam.treat at qt.io Fri Feb 23 17:19:45 2018 From: adam.treat at qt.io (Adam Treat) Date: Fri, 23 Feb 2018 16:19:45 +0000 Subject: [Development] [Qt-creator] Requesting repository for telemetry plugin in Qt Creator In-Reply-To: References: <94751519306975@web5o.yandex.ru> <20180222190542.GA1455@klara.mpi.htwm.de> , Message-ID: "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 at qt-project.org; qt-creator at 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 at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From fabrice.salvaire at orange.fr Fri Feb 23 18:25:14 2018 From: fabrice.salvaire at orange.fr (Fabrice Salvaire) Date: Fri, 23 Feb 2018 18:25:14 +0100 Subject: [Development] Control 2 : Does StackView garbage collect popped items ? Message-ID: Dear all, I am experimenting a way to implement a wizard interface featuring a next and previous page navigation using QML Control 2. I tried to achieve this using StackView but I receive the error "TypeError: Type error' when I try to access popped items later, for example with console.info(popped_item_array)  It looks like a kind of garbage collection of the Qt object returned by push and pop.  But I could not figure out any explanation of this behaviour on the Qt doc https://doc-snapshots.qt.io/qt5-5.11/qml-qtquick-controls2-stackview.html#unwinding-items-via-pop Note: I hope I am on the right channel for such technical question. Cheers, Fabrice From ekke at ekkes-corner.org Fri Feb 23 19:25:48 2018 From: ekke at ekkes-corner.org (ekke) Date: Fri, 23 Feb 2018 19:25:48 +0100 Subject: [Development] Control 2 : Does StackView garbage collect popped items ? In-Reply-To: References: Message-ID: Am 23.02.18 um 18:25 schrieb Fabrice Salvaire: > Dear all, > > I am experimenting a way to implement a wizard interface featuring a > next and previous page navigation using QML Control 2. > > I tried to achieve this using StackView but I receive the error > "TypeError: Type error' when I try to access popped items later, for > example with console.info(popped_item_array)  It looks like a kind of > garbage collection of the Qt object returned by push and pop.  But I > could not figure out any explanation of this behaviour on the Qt doc > https://doc-snapshots.qt.io/qt5-5.11/qml-qtquick-controls2-stackview.html#unwinding-items-via-pop > > Note: I hope I am on the right channel for such technical question. Hi Fabrice, the developers list is for the developers of Qt you should use the 'interest' list (users of Qt) or ask at the Forum https://forum.qt.io/category/12/qml-and-qt-quick BTW: here's a blog article and demo app at github about QQC2 StackView: https://appbus.wordpress.com/2016/05/27/stacked-pages-app/ it's from 2016 - so not all is covered but perhaps will give you some ideas ekke From tobias.hunger at gmail.com Mon Feb 26 10:18:56 2018 From: tobias.hunger at gmail.com (Tobias Hunger) Date: Mon, 26 Feb 2018 10:18:56 +0100 Subject: [Development] [Qt-creator] Requesting repository for telemetry plugin in Qt Creator In-Reply-To: <53044D9E-EE7F-4B44-A725-9DB0CE96188F@qt.io> References: <297808CB-E1C3-484B-B316-8232EF714033@qt.io> <53044D9E-EE7F-4B44-A725-9DB0CE96188F@qt.io> Message-ID: Hi Tino, On Fri, Feb 23, 2018 at 4:58 PM, Tino Pyssysalo wrote: > I’ll clarify little bit, as my earlier comment about “any backend” has been > confusing. I requested a repo for a QtCreator analytics plugin, but we > realized why not to use a similar solution in other tools as well. I want to > concentrate on a Qt Creator plugin first to fully understand the problem > domain. Once that is done we can discuss how to move forward with this > project”. Our intention is usage data collection, but nothing else at this > point. Obviously, we plan to use the collected data to improve Qt. As a > concrete example, we have provided a lot of nice features in Qt Quick > Designer in the recent Qt Creator releases, but we have no idea, if the use > of Qt Quick Designer has changed in any way. This kind of data would be very > valuable to us. So this is a simple creator plugin to collect data about Qt Creator users. That makes the scope clear to me, so I can step retract my -1 for undefined scope. A repository in the qt-creator namespace makes sense to me for that scope, but considering the experimental nature of this work, a playground project might work out better. I am not deep enough in the usual practices to have a firm opinion on that topic. Best Regards, Tobias From annulen at yandex.ru Mon Feb 26 12:30:49 2018 From: annulen at yandex.ru (Konstantin Tokarev) Date: Mon, 26 Feb 2018 14:30:49 +0300 Subject: [Development] [Qt-creator] Requesting repository for telemetry plugin in Qt Creator In-Reply-To: References: <94751519306975@web5o.yandex.ru>, <20180222190542.GA1455@klara.mpi.htwm.de> Message-ID: <74011519644649@web5o.yandex.ru> 23.02.2018, 13:55, "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. Having statistics may also be valuable when you need to explain prioritization to managers. -- Regards, Konstantin From alexander.blasche at qt.io Mon Feb 26 14:00:31 2018 From: alexander.blasche at qt.io (Alex Blasche) Date: Mon, 26 Feb 2018 13:00:31 +0000 Subject: [Development] Qt Visual Studio Tools 2.2 released today Message-ID: Hi, For those who do not follow the Qt development blogs, we just published the first VS Addin release since the redesign imposed by Visual Studio API changes in MSVC 2013 and beyond. This was a long journey in the making. The last non-TP release was in June 2013. For more details please see: http://blog.qt.io/blog/2018/02/26/qt-visual-studio-tools-2-2-0-released/ I would like to express my thanks to all parties that made this happen. To everybody else : Have fun and feedback is very welcome. -- Alex From aapo.keskimolo at qt.io Mon Feb 26 14:52:22 2018 From: aapo.keskimolo at qt.io (=?iso-8859-1?Q?Aapo_Keskim=F6l=F6?=) Date: Mon, 26 Feb 2018 13:52:22 +0000 Subject: [Development] FW: Coin maintenance notification In-Reply-To: References: Message-ID: Coin production was updated today (see forwarded mail with details). The service had to restarted shortly after to fix clan compile error that started occurring during MacOS 10.12 builds. From: Aapo Keskimölö Sent: Monday, February 26, 2018 2:10 PM To: Qt Development Subject: Coin maintenance notification Coin production was updated today with fixes for garbage collector, qml crashes and web ui. Changelog: https://codereview.qt-project.org/#/c/221376/ Ystävällisin terveisin / Kind regards, Aapo Keskimölö | Software Engineer aapo.keskimolo at qt.io | +358 44 559 2378 -------------- next part -------------- An HTML attachment was scrubbed... URL: From edward.welbourne at qt.io Mon Feb 26 18:06:08 2018 From: edward.welbourne at qt.io (Edward Welbourne) Date: Mon, 26 Feb 2018 17:06:08 +0000 Subject: [Development] [Qt-creator] Requesting repository for telemetry plugin in Qt Creator In-Reply-To: References: <94751519306975@web5o.yandex.ru> <20180222190542.GA1455@klara.mpi.htwm.de> , Message-ID: Am 23.02.2018 um 11:54 schrieb Edward Welbourne: >> 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. Robert Loehning (23 February 2018 15:59) > 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? You don't necessarily know - but you do at least know it sees a lot of use, as distinct from the things that no-one uses. That, in turn, might be because the thing doesn't work, or is too confusing; or it might mean it does a thing no-one feels any need to do. However, you have now separated two classes of feature from one another: you won't waste time asking users why they never use the heavily-used feature; and you won't assume that users know how to use the feature you know none of them use. You'll have more information along with just "what proportion use which features what proportions of the time"; some of this may help you to distinguish between the various possible explanations. When you look into the feature that no-one uses much, you may find that most users that do use it have a crash report following close on the heels of their use of it; you can make an educated guess at why they don't use it after that. For another feature, users may methodically work their way through the steps your tutoral for the feature outlined and never touch it again; it's probagly useless. You won't be throwing away your other ways of getting information from users; you can ask them, in all the usual ways, what they like best and what ticks them off about each feature. That's quite likely to distinguish, among the ones that are commonly used, the ones that are fun from the ones that are time-consuming pain points. Data on how your users use your product can contribute to your understanding of what questions to ask your users and what work to prioritise. Like all data, of course, you have to use it intelligently to get actionable information out of it; the possibility that you might misunderstand it doesn't mean it's worthless; it *supplements* the other sources of insight into how best to use your time, it doesn't replace them. All of which, of course, does depend on taking care that the process of collecting the data does not, in itself, cause greater harm than the benefits that you can glean from using the information, once collected, Eddy. From Marco.Bubke at qt.io Mon Feb 26 18:29:22 2018 From: Marco.Bubke at qt.io (Marco Bubke) Date: Mon, 26 Feb 2018 17:29:22 +0000 Subject: [Development] [Qt-creator] Requesting repository for telemetry plugin in Qt Creator In-Reply-To: References: <94751519306975@web5o.yandex.ru> <20180222190542.GA1455@klara.mpi.htwm.de> , , Message-ID: Edward Welbourne: > When you look into the feature that no-one uses much, you may find that most users > that do use it have a crash report following close on the heels of their > use of it; you can make an educated guess at why they don't use it after that. We have already a crash reporter, which would provide us with that information. I am pushing this since some time but we need a server installation. Sorry, with my current experience I don't think that we need something much more complicated and fuzzy if we don't get something simple like a crash handler working. And I only speak about a customization of an already existing server and setting up the VM. I have that done very long ago but nobody stepped in to productise it. So I don't believe that we can fly to the stars if we cannot fly to the moon, but it is much easier to dream about the stars than to go to the moon. 😉 ________________________________ From: Development on behalf of Edward Welbourne Sent: Monday, February 26, 2018 6:06:08 PM To: Robert Loehning; André Pönitz Cc: development at qt-project.org; qt-creator at 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: >> 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. Robert Loehning (23 February 2018 15:59) > 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? You don't necessarily know - but you do at least know it sees a lot of use, as distinct from the things that no-one uses. That, in turn, might be because the thing doesn't work, or is too confusing; or it might mean it does a thing no-one feels any need to do. However, you have now separated two classes of feature from one another: you won't waste time asking users why they never use the heavily-used feature; and you won't assume that users know how to use the feature you know none of them use. You'll have more information along with just "what proportion use which features what proportions of the time"; some of this may help you to distinguish between the various possible explanations. When you look into the feature that no-one uses much, you may find that most users that do use it have a crash report following close on the heels of their use of it; you can make an educated guess at why they don't use it after that. For another feature, users may methodically work their way through the steps your tutoral for the feature outlined and never touch it again; it's probagly useless. You won't be throwing away your other ways of getting information from users; you can ask them, in all the usual ways, what they like best and what ticks them off about each feature. That's quite likely to distinguish, among the ones that are commonly used, the ones that are fun from the ones that are time-consuming pain points. Data on how your users use your product can contribute to your understanding of what questions to ask your users and what work to prioritise. Like all data, of course, you have to use it intelligently to get actionable information out of it; the possibility that you might misunderstand it doesn't mean it's worthless; it *supplements* the other sources of insight into how best to use your time, it doesn't replace them. All of which, of course, does depend on taking care that the process of collecting the data does not, in itself, cause greater harm than the benefits that you can glean from using the information, once collected, Eddy. _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexei.fedotov at gmail.com Tue Feb 27 09:45:25 2018 From: alexei.fedotov at gmail.com (Alexei Fedotov) Date: Tue, 27 Feb 2018 11:45:25 +0300 Subject: [Development] Fwd: qrandom.cpp build problem: please advise In-Reply-To: References: Message-ID: Hi folks, qtbase/src/corelib/global/qrandom.cpp has the following code #if QT_CONFIG(getentropy) # include #elif !defined(Q_OS_BSD4) && !defined(Q_OS_WIN) # include "qdeadlinetimer.h" # include "qhashfunctions.h" # if QT_CONFIG(getauxval) # include # endif #endif // !QT_CONFIG(getentropy) ./configure sets getentropy in qtbase/src/corelib/qtcore-config_p.h to 1, but I have no sys/random.h Maybe getentropy comes from a modern compiler, not from system headers So the build fails. I wonder if this is a bug. -- Carry a towel http://dataved.ru/ +7 916 562 8095 [1] Join Alexei Fedotov @linkedin, http://ru.linkedin.com/in/dataved/ [2] Join Alexei Fedotov @facebook, http://www.facebook.com/openmeetings [3] Start using Apache Openmeetings today, http://openmeetings.apache.org/ From edward.welbourne at qt.io Tue Feb 27 10:11:36 2018 From: edward.welbourne at qt.io (Edward Welbourne) Date: Tue, 27 Feb 2018 09:11:36 +0000 Subject: [Development] Fwd: qrandom.cpp build problem: please advise In-Reply-To: References: , Message-ID: Alexei Fedotov (27 February 2018 09:45) > ./configure sets getentropy in qtbase/src/corelib/qtcore-config_p.h to 1, So the config.tests/unix/getentropy/ test passed. > but I have no sys/random.h which that test neglects to #include, so this lack doesn't keep it from failing. See if https://codereview.qt-project.org/221462 helps. (It's not ideal; it should make the test fail for you, though, so you'll have the feature turned off, despite being available, so you won't hit your compilation problem.) > Maybe getentropy comes from a modern compiler, not from system headers Apparently it comes from - at least, that's what the test seems to expect and its man-page claims. The author of this code may suggest some better solution, once his USAish time-zone reaches its daytime, Eddy. From Simon.Hausmann at qt.io Tue Feb 27 10:36:07 2018 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Tue, 27 Feb 2018 09:36:07 +0000 Subject: [Development] Nominating Ville Voutilainen as approver Message-ID: Hi, I would like to nominate Ville as approver. Due to his work in the GCC project he is certainly experienced with strict code reviews. Based on my interaction with him I'm convinced that he has successfully demonstrated the same skill set during code reviews in Qt. Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From edward.welbourne at qt.io Tue Feb 27 10:39:10 2018 From: edward.welbourne at qt.io (Edward Welbourne) Date: Tue, 27 Feb 2018 09:39:10 +0000 Subject: [Development] Nominating Ville Voutilainen as approver In-Reply-To: References: Message-ID: Simon Hausmann (27 February 2018 10:36) > I would like to nominate Ville as approver. +1 (full disclosure: the three of us all work for TQtC) Eddy. From Frederik.Gladhorn at qt.io Tue Feb 27 10:39:50 2018 From: Frederik.Gladhorn at qt.io (Frederik Gladhorn) Date: Tue, 27 Feb 2018 09:39:50 +0000 Subject: [Development] Nominating Ville Voutilainen as approver In-Reply-To: References: Message-ID: +1 he's also getting his hands dirty with flaky tests and making things work in general :-) Cheers, Frederik From: Simon Hausmann Sent: Tuesday, February 27, 10:36 Subject: [Development] Nominating Ville Voutilainen as approver To: development at qt-project.org Hi, I would like to nominate Ville as approver. Due to his work in the GCC project he is certainly experienced with strict code reviews. Based on my interaction with him I'm convinced that he has successfully demonstrated the same skill set during code reviews in Qt. Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From Shawn.Rutledge at qt.io Tue Feb 27 10:43:00 2018 From: Shawn.Rutledge at qt.io (Shawn Rutledge) Date: Tue, 27 Feb 2018 09:43:00 +0000 Subject: [Development] Nominating Ville Voutilainen as approver In-Reply-To: References: Message-ID: <4FC54EC4-FBF3-44FF-A1E6-191451F63029@qt.io> +1 > On 27 Feb 2018, at 10:36, Simon Hausmann wrote: > > Hi, > > I would like to nominate Ville as approver. Due to his work in the GCC project he is certainly experienced with strict code reviews. Based on my interaction with him I'm convinced that he has successfully demonstrated the same skill set during code reviews in Qt. > > > > Simon > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From sergio.martins at kdab.com Tue Feb 27 10:58:16 2018 From: sergio.martins at kdab.com (=?UTF-8?Q?Martins=2C_S=C3=A9rgio?=) Date: Tue, 27 Feb 2018 09:58:16 +0000 Subject: [Development] Nominating Ville Voutilainen as approver In-Reply-To: References: Message-ID: +1 On 2018-02-27 09:36, Simon Hausmann wrote: > Hi, > > > I would like to nominate Ville as approver. Due to his work in the GCC > project he is certainly experienced with strict code reviews. Based on > my interaction with him I'm convinced that he has successfully > demonstrated the same skill set during code reviews in Qt. > > > > > Simon > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Sérgio Martins | sergio.martins at kdab.com | Senior Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - The Qt, C++ and OpenGL Experts From sean.harmer at kdab.com Tue Feb 27 11:18:34 2018 From: sean.harmer at kdab.com (Sean Harmer) Date: Tue, 27 Feb 2018 10:18:34 +0000 Subject: [Development] Nominating Ville Voutilainen as approver In-Reply-To: References: Message-ID: +1 Cheers, Sean On 27/02/2018 09:36, Simon Hausmann wrote: > Hi, > > > I would like to nominate Ville as approver. Due to his work in the GCC > project he is certainly experienced with strict code reviews. Based on > my interaction with him I'm convinced that he has successfully > demonstrated the same skill set during code reviews in Qt. > > > > > Simon > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -- Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK KDAB (UK) Ltd, a KDAB Group company Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090 Mobile: +44 (0)7545 140604 KDAB - Qt Experts From samuel.gaist at edeltech.ch Tue Feb 27 11:26:10 2018 From: samuel.gaist at edeltech.ch (Samuel Gaist) Date: Tue, 27 Feb 2018 11:26:10 +0100 Subject: [Development] Nominating Ville Voutilainen as approver In-Reply-To: References: Message-ID: <783CBEC5-7919-4C1E-9883-8BB2515A4FA4@edeltech.ch> +1 Best regards Samuel > On 27 Feb 2018, at 10:36, Simon Hausmann wrote: > > Hi, > > I would like to nominate Ville as approver. Due to his work in the GCC project he is certainly experienced with strict code reviews. Based on my interaction with him I'm convinced that he has successfully demonstrated the same skill set during code reviews in Qt. > > > > Simon > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From Marco.Bubke at qt.io Tue Feb 27 13:12:35 2018 From: Marco.Bubke at qt.io (Marco Bubke) Date: Tue, 27 Feb 2018 12:12:35 +0000 Subject: [Development] [Qt-creator] Requesting repository for telemetry plugin in Qt Creator In-Reply-To: References: <94751519306975@web5o.yandex.ru> <20180222190542.GA1455@klara.mpi.htwm.de> , , , Message-ID: I was ask to provide more info about the crash dump server. It is called Socorro: https://github.com/mozilla-services/socorro Like you can see it was developed originally for Firefox: https://crash-stats.mozilla.com/topcrashers/?product=Firefox&version=58.0.2 There are many statistics about crashes and the stack trace which is very helpful for the developer to prioritize bug reports and fix crashes. We already have client support for that in Qt Creator but we need a server instance where we can send the crash dumps. ________________________________ From: Development on behalf of Marco Bubke Sent: Monday, February 26, 2018 6:29:22 PM To: Edward Welbourne; Robert Loehning; André Pönitz Cc: development at qt-project.org; Ryein Goddard; qt-creator at qt-project.org Subject: Re: [Development] [Qt-creator] Requesting repository for telemetry plugin in Qt Creator Edward Welbourne: > When you look into the feature that no-one uses much, you may find that most users > that do use it have a crash report following close on the heels of their > use of it; you can make an educated guess at why they don't use it after that. We have already a crash reporter, which would provide us with that information. I am pushing this since some time but we need a server installation. Sorry, with my current experience I don't think that we need something much more complicated and fuzzy if we don't get something simple like a crash handler working. And I only speak about a customization of an already existing server and setting up the VM. I have that done very long ago but nobody stepped in to productise it. So I don't believe that we can fly to the stars if we cannot fly to the moon, but it is much easier to dream about the stars than to go to the moon. 😉 ________________________________ From: Development on behalf of Edward Welbourne Sent: Monday, February 26, 2018 6:06:08 PM To: Robert Loehning; André Pönitz Cc: development at qt-project.org; qt-creator at 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: >> 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. Robert Loehning (23 February 2018 15:59) > 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? You don't necessarily know - but you do at least know it sees a lot of use, as distinct from the things that no-one uses. That, in turn, might be because the thing doesn't work, or is too confusing; or it might mean it does a thing no-one feels any need to do. However, you have now separated two classes of feature from one another: you won't waste time asking users why they never use the heavily-used feature; and you won't assume that users know how to use the feature you know none of them use. You'll have more information along with just "what proportion use which features what proportions of the time"; some of this may help you to distinguish between the various possible explanations. When you look into the feature that no-one uses much, you may find that most users that do use it have a crash report following close on the heels of their use of it; you can make an educated guess at why they don't use it after that. For another feature, users may methodically work their way through the steps your tutoral for the feature outlined and never touch it again; it's probagly useless. You won't be throwing away your other ways of getting information from users; you can ask them, in all the usual ways, what they like best and what ticks them off about each feature. That's quite likely to distinguish, among the ones that are commonly used, the ones that are fun from the ones that are time-consuming pain points. Data on how your users use your product can contribute to your understanding of what questions to ask your users and what work to prioritise. Like all data, of course, you have to use it intelligently to get actionable information out of it; the possibility that you might misunderstand it doesn't mean it's worthless; it *supplements* the other sources of insight into how best to use your time, it doesn't replace them. All of which, of course, does depend on taking care that the process of collecting the data does not, in itself, cause greater harm than the benefits that you can glean from using the information, once collected, Eddy. _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexei.fedotov at gmail.com Tue Feb 27 13:46:49 2018 From: alexei.fedotov at gmail.com (Alexei Fedotov) Date: Tue, 27 Feb 2018 15:46:49 +0300 Subject: [Development] Fwd: qrandom.cpp build problem: please advise In-Reply-To: References: Message-ID: Hi Edward, thanks for a quick solution! The patch worked for me (with -recheck-all). I defensively used long include instead of a short "random.h". -- Carry a towel http://dataved.ru/ +7 916 562 8095 [1] Join Alexei Fedotov @linkedin, http://ru.linkedin.com/in/dataved/ [2] Join Alexei Fedotov @facebook, http://www.facebook.com/openmeetings [3] Start using Apache Openmeetings today, http://openmeetings.apache.org/ On Tue, Feb 27, 2018 at 12:11 PM, Edward Welbourne wrote: > Alexei Fedotov (27 February 2018 09:45) >> ./configure sets getentropy in qtbase/src/corelib/qtcore-config_p.h to 1, > > So the config.tests/unix/getentropy/ test passed. > >> but I have no sys/random.h > > which that test neglects to #include, so this lack doesn't keep it from failing. > See if > https://codereview.qt-project.org/221462 > helps. (It's not ideal; it should make the test fail for you, though, > so you'll have the feature turned off, despite being available, so > you won't hit your compilation problem.) > >> Maybe getentropy comes from a modern compiler, not from system headers > > Apparently it comes from - at least, that's > what the test seems to expect and its man-page claims. > > The author of this code may suggest some better solution, once > his USAish time-zone reaches its daytime, > > Eddy. From aapo.keskimolo at qt.io Tue Feb 27 14:41:58 2018 From: aapo.keskimolo at qt.io (=?iso-8859-1?Q?Aapo_Keskim=F6l=F6?=) Date: Tue, 27 Feb 2018 13:41:58 +0000 Subject: [Development] Coin maintenance notification In-Reply-To: References: Message-ID: Coin production was restarted today because it was failing connections to Opennebula after it was restarted. Changelog: https://codereview.qt-project.org/#/c/221521/ Ystävällisin terveisin / Kind regards, Aapo Keskimölö | Software Engineer aapo.keskimolo at qt.io | +358 44 559 2378 -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexei.fedotov at gmail.com Tue Feb 27 14:42:19 2018 From: alexei.fedotov at gmail.com (Alexei Fedotov) Date: Tue, 27 Feb 2018 16:42:19 +0300 Subject: [Development] QHash, QSharedPointer, QScopedPointer, etc absence Message-ID: Hello guys, There is a number of C++-style headers which AFAIU just include the C-style header. I wonder why they do not appear in my workspace. Is there some magic invocation of the build script which creates them automatically? -- Carry a towel http://dataved.ru/ +7 916 562 8095 [1] Join Alexei Fedotov @linkedin, http://ru.linkedin.com/in/dataved/ [2] Join Alexei Fedotov @facebook, http://www.facebook.com/openmeetings [3] Start using Apache Openmeetings today, http://openmeetings.apache.org/ From annulen at yandex.ru Tue Feb 27 14:48:09 2018 From: annulen at yandex.ru (Konstantin Tokarev) Date: Tue, 27 Feb 2018 16:48:09 +0300 Subject: [Development] Coin maintenance notification In-Reply-To: References: Message-ID: <9041519739289@web39j.yandex.ru> 27.02.2018, 16:42, "Aapo Keskimölö" : > Coin production was restarted today because it was failing connections to Opennebula after it was restarted. > > Changelog: > > https://codereview.qt-project.org/#/c/221521/ This is not a public page which everyone here can open, so at least commit title should be added to this changelog :) > > Ystävällisin terveisin / Kind regards, > > Aapo Keskimölö | Software Engineer > > aapo.keskimolo at qt.io | +358 44 559 2378 > > , > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development --  Regards, Konstantin From thiago.macieira at intel.com Tue Feb 27 16:12:07 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 27 Feb 2018 07:12:07 -0800 Subject: [Development] Fwd: qrandom.cpp build problem: please advise In-Reply-To: References: Message-ID: <2098989.MG7ht681lK@tjmaciei-mobl1> On terça-feira, 27 de fevereiro de 2018 01:11:36 PST Edward Welbourne wrote: > Apparently it comes from - at least, that's > what the test seems to expect and its man-page claims. > > The author of this code may suggest some better solution, once > his USAish time-zone reaches its daytime, Originally qrandom.cpp used getrandom(), which is in sys/random.h. Apparently I forgot to remove the dependency when I switched to getentropy(). -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From lars.knoll at qt.io Tue Feb 27 18:50:34 2018 From: lars.knoll at qt.io (Lars Knoll) Date: Tue, 27 Feb 2018 17:50:34 +0000 Subject: [Development] Nominating Ville Voutilainen as approver In-Reply-To: <783CBEC5-7919-4C1E-9883-8BB2515A4FA4@edeltech.ch> References: <783CBEC5-7919-4C1E-9883-8BB2515A4FA4@edeltech.ch> Message-ID: <2808E132-F354-4BEF-9712-6B7E7FA6535A@qt.io> Another +1 :) Cheers, Lars > On 27 Feb 2018, at 11:26, Samuel Gaist wrote: > > +1 > > Best regards > > Samuel > >> On 27 Feb 2018, at 10:36, Simon Hausmann wrote: >> >> Hi, >> >> I would like to nominate Ville as approver. Due to his work in the GCC project he is certainly experienced with strict code reviews. Based on my interaction with him I'm convinced that he has successfully demonstrated the same skill set during code reviews in Qt. >> >> >> >> Simon >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From aapo.keskimolo at qt.io Wed Feb 28 10:22:05 2018 From: aapo.keskimolo at qt.io (=?iso-8859-1?Q?Aapo_Keskim=F6l=F6?=) Date: Wed, 28 Feb 2018 09:22:05 +0000 Subject: [Development] Coin maintenance notification In-Reply-To: References: Message-ID: Coin was restarted to recover the testresults.qt.io web page that had died. Ystävällisin terveisin / Kind regards, Aapo Keskimölö | Software Engineer aapo.keskimolo at qt.io | +358 44 559 2378 -------------- next part -------------- An HTML attachment was scrubbed... URL: From announce at qt-project.org Wed Feb 28 12:28:09 2018 From: announce at qt-project.org (List for announcements regarding Qt releases and development) Date: Wed, 28 Feb 2018 11:28:09 +0000 Subject: [Development] [Announce] Qt Automotive Suite 2.0 released Message-ID: Hi, Qt Automotive Suite 2.0 is released today. For more information about the release please read blog post from blog.qt.io/blog/2018/02/27/introducing-qt-automotive-suite-2-0/ br, Jani Heikkinen Release Manager _______________________________________________ Announce mailing list Announce at qt-project.org http://lists.qt-project.org/mailman/listinfo/announce From perezmeyer at gmail.com Wed Feb 28 17:40:29 2018 From: perezmeyer at gmail.com (=?UTF-8?Q?Lisandro_Dami=C3=A1n_Nicanor_P=C3=A9rez_Meyer?=) Date: Wed, 28 Feb 2018 13:40:29 -0300 Subject: [Development] API breackage in Qt3D Message-ID: Hi! today I was packaging Qt3D (meaning the the submodule) for Debian and noticed that some symbols where missing. We understood that Qt3D (the submodule) was API/ABI stable, but Konstantin Tokarev pointed out: https://abi-laboratory.pro/tracker/timeline/qt/ "NOTE: The libQt53D* objects are introduced in the library since 5.5.0 but with no stable ABI guarantee, so analysis of these objects was not performed." But then Thiago pointed out: well, we need to start having it stable it's no longer in experimental state $ git config -f .gitmodules --get submodule.qt3d.status addon qt3d left preview status in 5.7 if there are libs inside that aren't stable ABI, they should be moved to a separate module So bringing up the issue here. -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ -------------- next part -------------- +#MISSING: 5.10.1# _ZN13Qt3DAnimation14QChannelMapper10addMappingEPNS_15QChannelMappingE at Qt_5 5.9.0 +#MISSING: 5.10.1# _ZN13Qt3DAnimation14QChannelMapper13removeMappingEPNS_15QChannelMappingE at Qt_5 5.9.0 +#MISSING: 5.10.1# _ZN10Qt3DExtras19QMetalRoughMaterial12setBaseColorERK6QColor at Qt_5 5.9.0 +#MISSING: 5.10.1# _ZN10Qt3DExtras19QMetalRoughMaterial12setMetalnessEf at Qt_5 5.9.0 +#MISSING: 5.10.1# _ZN10Qt3DExtras19QMetalRoughMaterial12setRoughnessEf at Qt_5 5.9.0 +#MISSING: 5.10.1# _ZN10Qt3DExtras19QMetalRoughMaterial16baseColorChangedERK6QColor at Qt_5 5.9.0 +#MISSING: 5.10.1# _ZN10Qt3DExtras19QMetalRoughMaterial16metalnessChangedEf at Qt_5 5.9.0 +#MISSING: 5.10.1# _ZN10Qt3DExtras19QMetalRoughMaterial16roughnessChangedEf at Qt_5 5.9.0 +#MISSING: 5.10.1# _ZN10Qt3DExtras22QOrbitCameraController12setLookSpeedEf at Qt_5 5.7.1~20161122 +#MISSING: 5.10.1# _ZN10Qt3DExtras22QOrbitCameraController13cameraChangedEv at Qt_5 5.7.1~20161122 +#MISSING: 5.10.1# _ZN10Qt3DExtras22QOrbitCameraController14setLinearSpeedEf at Qt_5 5.7.1~20161122 +#MISSING: 5.10.1# _ZN10Qt3DExtras22QOrbitCameraController16lookSpeedChangedEv at Qt_5 5.7.1~20161122 +#MISSING: 5.10.1# _ZN10Qt3DExtras22QOrbitCameraController18linearSpeedChangedEv at Qt_5 5.7.1~20161122 +#MISSING: 5.10.1# _ZN10Qt3DExtras22QOrbitCameraController9setCameraEPN10Qt3DRender7QCameraE at Qt_5 5.7.1~20161122 +#MISSING: 5.10.1# _ZN10Qt3DExtras27QTexturedMetalRoughMaterial12setBaseColorEPN10Qt3DRender16QAbstractTextureE at Qt_5 5.9.0 +#MISSING: 5.10.1# _ZN10Qt3DExtras27QTexturedMetalRoughMaterial12setMetalnessEPN10Qt3DRender16QAbstractTextureE at Qt_5 5.9.0 +#MISSING: 5.10.1# _ZN10Qt3DExtras27QTexturedMetalRoughMaterial12setRoughnessEPN10Qt3DRender16QAbstractTextureE at Qt_5 5.9.0 +#MISSING: 5.10.1# _ZN10Qt3DExtras27QTexturedMetalRoughMaterial13normalChangedEPN10Qt3DRender16QAbstractTextureE at Qt_5 5.9.0 +#MISSING: 5.10.1# _ZN10Qt3DExtras27QTexturedMetalRoughMaterial16baseColorChangedEPN10Qt3DRender16QAbstractTextureE at Qt_5 5.9.0 +#MISSING: 5.10.1# _ZN10Qt3DExtras27QTexturedMetalRoughMaterial16metalnessChangedEPN10Qt3DRender16QAbstractTextureE at Qt_5 5.9.0 +#MISSING: 5.10.1# _ZN10Qt3DExtras27QTexturedMetalRoughMaterial16roughnessChangedEPN10Qt3DRender16QAbstractTextureE at Qt_5 5.9.0 +#MISSING: 5.10.1# _ZN10Qt3DExtras27QTexturedMetalRoughMaterial19setAmbientOcclusionEPN10Qt3DRender16QAbstractTextureE at Qt_5 5.9.0 +#MISSING: 5.10.1# _ZN10Qt3DExtras27QTexturedMetalRoughMaterial23ambientOcclusionChangedEPN10Qt3DRender16QAbstractTextureE at Qt_5 5.9.0 +#MISSING: 5.10.1# _ZN10Qt3DExtras27QTexturedMetalRoughMaterial9setNormalEPN10Qt3DRender16QAbstractTextureE at Qt_5 5.9.0 +#MISSING: 5.10.1# _ZN10Qt3DExtras27QTexturedMetalRoughMaterialC1ERNS_34QTexturedMetalRoughMaterialPrivateEPN8Qt3DCore5QNodeE at Qt_5 5.9.0 +#MISSING: 5.10.1# _ZN10Qt3DExtras27QTexturedMetalRoughMaterialC2ERNS_34QTexturedMetalRoughMaterialPrivateEPN8Qt3DCore5QNodeE at Qt_5 5.9.0 +#MISSING: 5.10.1# _ZN10Qt3DExtras27QTexturedMetalRoughMaterialD0Ev at Qt_5 5.9.0 +#MISSING: 5.10.1# _ZN10Qt3DExtras27QTexturedMetalRoughMaterialD1Ev at Qt_5 5.9.0 +#MISSING: 5.10.1# _ZN10Qt3DExtras27QTexturedMetalRoughMaterialD2Ev at Qt_5 5.9.0 +#MISSING: 5.10.1# _ZN10Qt3DExtras28QFirstPersonCameraController12setLookSpeedEf at Qt_5 5.7.1~20161122 +#MISSING: 5.10.1# _ZN10Qt3DExtras28QFirstPersonCameraController13cameraChangedEv at Qt_5 5.7.1~20161122 +#MISSING: 5.10.1# _ZN10Qt3DExtras28QFirstPersonCameraController14setLinearSpeedEf at Qt_5 5.7.1~20161122 +#MISSING: 5.10.1# _ZN10Qt3DExtras28QFirstPersonCameraController15setAccelerationEf at Qt_5 5.9.0 +#MISSING: 5.10.1# _ZN10Qt3DExtras28QFirstPersonCameraController15setDecelerationEf at Qt_5 5.9.0 +#MISSING: 5.10.1# _ZN10Qt3DExtras28QFirstPersonCameraController16lookSpeedChangedEv at Qt_5 5.7.1~20161122 +#MISSING: 5.10.1# _ZN10Qt3DExtras28QFirstPersonCameraController18linearSpeedChangedEv at Qt_5 5.7.1~20161122 +#MISSING: 5.10.1# _ZN10Qt3DExtras28QFirstPersonCameraController19accelerationChangedEf at Qt_5 5.9.0 +#MISSING: 5.10.1# _ZN10Qt3DExtras28QFirstPersonCameraController19decelerationChangedEf at Qt_5 5.9.0 +#MISSING: 5.10.1# _ZN10Qt3DExtras28QFirstPersonCameraController9setCameraEPN10Qt3DRender7QCameraE at Qt_5 5.7.1~20161122 +#MISSING: 5.10.1# _ZNK10Qt3DExtras22QOrbitCameraController11linearSpeedEv at Qt_5 5.7.1~20161122 +#MISSING: 5.10.1# _ZNK10Qt3DExtras22QOrbitCameraController6cameraEv at Qt_5 5.7.1~20161122 +#MISSING: 5.10.1# _ZNK10Qt3DExtras22QOrbitCameraController9lookSpeedEv at Qt_5 5.7.1~20161122 +#MISSING: 5.10.1# _ZNK10Qt3DExtras27QTexturedMetalRoughMaterial16ambientOcclusionEv at Qt_5 5.9.0 +#MISSING: 5.10.1# _ZNK10Qt3DExtras27QTexturedMetalRoughMaterial6normalEv at Qt_5 5.9.0 +#MISSING: 5.10.1# _ZNK10Qt3DExtras27QTexturedMetalRoughMaterial9baseColorEv at Qt_5 5.9.0 +#MISSING: 5.10.1# _ZNK10Qt3DExtras27QTexturedMetalRoughMaterial9metalnessEv at Qt_5 5.9.0 +#MISSING: 5.10.1# _ZNK10Qt3DExtras27QTexturedMetalRoughMaterial9roughnessEv at Qt_5 5.9.0 +#MISSING: 5.10.1# _ZNK10Qt3DExtras28QFirstPersonCameraController11linearSpeedEv at Qt_5 5.7.1~20161122 +#MISSING: 5.10.1# _ZNK10Qt3DExtras28QFirstPersonCameraController12accelerationEv at Qt_5 5.9.0 +#MISSING: 5.10.1# _ZNK10Qt3DExtras28QFirstPersonCameraController12decelerationEv at Qt_5 5.9.0 +#MISSING: 5.10.1# _ZNK10Qt3DExtras28QFirstPersonCameraController6cameraEv at Qt_5 5.7.1~20161122 +#MISSING: 5.10.1# _ZNK10Qt3DExtras28QFirstPersonCameraController9lookSpeedEv at Qt_5 5.7.1~20161122 +#MISSING: 5.10.1# _ZN13Qt3DAnimation9Animation5Quick20Quick3DChannelMapper12mappingCountEP16QQmlListPropertyINS_15QChannelMappingEE at Qt_5 5.9.0 +#MISSING: 5.10.1# _ZN13Qt3DAnimation9Animation5Quick20Quick3DChannelMapper13appendMappingEP16QQmlListPropertyINS_15QChannelMappingEEPS4_ at Qt_5 5.9.0 +#MISSING: 5.10.1# _ZN13Qt3DAnimation9Animation5Quick20Quick3DChannelMapper13clearMappingsEP16QQmlListPropertyINS_15QChannelMappingEE at Qt_5 5.9.0 +#MISSING: 5.10.1# _ZN13Qt3DAnimation9Animation5Quick20Quick3DChannelMapper9mappingAtEP16QQmlListPropertyINS_15QChannelMappingEEi at Qt_5 5.9.0 +#MISSING: 5.10.1# _ZN10Qt3DRender20QRenderAspectPrivate17renderSynchronousEv at Qt_5 5.7.1~20161122 +#MISSING: 5.10.1# _ZN10Qt3DRender6Render8Renderer14clearDirtyBitsE6QFlagsINS0_16AbstractRenderer20BackendNodeDirtyFlagEE at Qt_5 5.7.1~20161122 +#MISSING: 5.10.1# _ZN10Qt3DRender6Render8Renderer17createOrUpdateVAOEPNS0_13RenderCommandEPN8Qt3DCore7QHandleINS0_23OpenGLVertexArrayObjectELj16EEEPPS6_ at Qt_5_PRIVATE_API 5.9.2 +#MISSING: 5.10.1# _ZN10Qt3DRender6Render8Renderer8doRenderEv at Qt_5 5.7.1~20161122 +#MISSING: 5.10.1# _ZNK10Qt3DRender6Render22UpdateLevelOfDetailJob19viewMatrixForCameraERKN8Qt3DCore7QNodeIdER10QMatrix4x4S7_ at Qt_5 5.9.0 From perezmeyer at gmail.com Wed Feb 28 18:06:00 2018 From: perezmeyer at gmail.com (=?UTF-8?Q?Lisandro_Dami=C3=A1n_Nicanor_P=C3=A9rez_Meyer?=) Date: Wed, 28 Feb 2018 14:06:00 -0300 Subject: [Development] API breackage in Qt3D In-Reply-To: References: Message-ID: On 28 February 2018 at 13:40, Lisandro Damián Nicanor Pérez Meyer wrote: > Hi! today I was packaging Qt3D (meaning the the submodule) for Debian > and noticed that some symbols where missing. Sorry, forgot to mention that the previously attached txt shows each missing symbol. Some of them might be private. At the end of the each line you can find the version in we first detected the symbol. -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ From thiago.macieira at intel.com Wed Feb 28 18:31:16 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 28 Feb 2018 09:31:16 -0800 Subject: [Development] API breackage in Qt3D In-Reply-To: References: Message-ID: <1976948.HTjXFhJHH2@tjmaciei-mobl1> On Wednesday, 28 February 2018 08:40:29 PST Lisandro Damián Nicanor Pérez Meyer wrote: > if there are libs inside that aren't stable ABI, they should > be moved to a separate module So asking the maintainers: is the whole Qt3D module keeping binary compatibility? If not, which libraries in it are not? I haven't reviewed Lisandro's list, but at least one symbol (the first one) is not private API and did change. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center