From jani.heikkinen at theqtcompany.com Thu Jan 7 09:45:53 2016 From: jani.heikkinen at theqtcompany.com (Heikkinen Jani) Date: Thu, 7 Jan 2016 08:45:53 +0000 Subject: [Releasing] Meeting minutes: Qt release team meeting 05.01.2016 In-Reply-To: References: , Message-ID: Meeting minutes from Qt Release Team meeting 5th January 2016 Qt 5.6 status: - Unfortunately some build related changes are waiting for a fix to https://bugreports.qt.io/browse/QTQAINFRA-943 * Those needs to be in well before RC, issues linked in QTQAINFRA-943 --> We need to postpone branching a while. Let's hope we get needed changes in soon & we can start soft branching already during next week Qt 5.7 status: - Some QNX/std::atomic related changes missing from dev branch atm * Needs to be fixed before FF, bug report to be created by Thiago * Simon has a patch available, waiting for comments from QNX folks - No other FF/branch blockers known at the moment --> We cannot start branching yet :( --> FF will be delayed a while ( a week at least). We will check the status at next weeks meeting Qt 5.5.2 plans: - No plans to release Qt 5.5.2 at all; let's focus to get 5.6 and 5.7 out. Next meeting: 12.1.2016 16:00 CET br, Jani irc log below: [16:00:58] akseli: iieklund: thiago: fkleint: ZapB: tronical: vladimirM: aholza: peter-h: mapaaso: ankokko: fkleint: carewolf: fregl: ablasche: ping [16:01:14] jaheikki3: pong [16:02:27] jaheikki3: pong [16:03:26] jaheikki3: pong [16:03:35] time to start qt release team meeting [16:03:46] on agenda today: [16:03:53] Qt 5.6 status [16:03:59] 0) happy new year everyone [16:04:23] thanks, same to you [16:04:26] Yeah, true. Happy new year for everyone! [16:04:33] Qt 5.7 status [16:04:42] Qt 5.5.2 plans [16:04:51] Any additional item to the agenda? [16:06:38] Ok, let's start from 5.6: [16:07:06] Beta was finally released just before Christmas, wuhuu! [16:07:36] Feedback has been pretty positive, I don't know anything which were badly broken [16:08:23] Of course there was bugs as usual, most important ones linked in RC metabug [16:08:33] oh, ius thereone? [16:08:37] oh, is there one? [16:08:48] jaheikki3: has there been much feedback, given the release timing (christmas/NY)? [16:09:23] Whatever happened to Eskil's proposal to do this by priority / fix version? (no longer have metabugs)? [16:10:23] fkleint: yes there is. But I think we should move to use 'fix to' field as Eskil proposed [16:10:33] hm,ok, but Id? [16:10:35] Issues to be fixed before Qt 5.6.0 RC https://bugreports.qt.io/browse/QTBUG-48845 (Created: 19/Oct/15) [16:11:21] thanks akseli! [16:11:47] w00t: At least I haven't heard anything... [16:11:53] when is the target for RC & for branching? [16:12:06] someone said ossi wanted a second beta [16:12:14] ossi said... [16:12:43] Target for RC is 26th Jan [16:12:45] -*- lqi just wants to know when 5.6.0 branch out and will do the 5.5->5.6 merge before that [16:13:14] So we need to start branching already during this week and finalize it during next one [16:13:23] yes, there are at least three issues marked as P1 pending which all depend on the CI, you know, not falsifying the build environment. [16:13:54] note that the std::atomic changes still aren't in [16:14:02] ossi|tt: hmm, but why second beta? [16:14:02] do you want me to add them to the bug? [16:14:09] I need the QNX toolchain in the CI patched [16:14:17] what is passing through CI now doesn't actually work in the real world in many configs [16:14:27] jaheikki3: some of my changes are rather intrusive [16:14:58] thiago: Please do [16:15:04] jaheikki3: i won't insist on an actual second beta, but there is no way we make an rc a few days after i put them in. [16:15:53] jaheikki3: and that requires that the CI is actually fixed in the first place. it doesn't seem that the task is on the immediate TODO list at all. [16:15:56] ossi|tt: I agree. We should have time to create snapshot & test those well before beta. When those changes are coming in? [16:16:07] yeah, exactly... [16:16:15] ossi|tt: how soon can the CI be fixed? [16:16:38] ask simon, fregl and jedrzej [16:17:20] i have no business in this. i'm not going to learn go *and* how the thing works to fix it myself. [16:17:23] ossi|tt: this is about not using make install and the install roots but instead creating tarballs of the build directories? [16:17:31] fregl: yes [16:17:49] OK, it was not on my list of priorities for 5.6 because I didn't think this was a blocker. [16:18:13] fregl: you mean, except that it's marked as P1 and multiple 5.6 P1 depend on it? ;) [16:18:20] sure [16:18:59] ossi|tt: what is the bug id(s)? [16:19:11] fregl: make install needs to work... [16:19:26] of course, if we don't test it, packagers will [16:19:40] jaheikki3: all linked from https://bugreports.qt.io/browse/QTQAINFRA-943 [16:19:49] but they've already resorted to creating their own sources from Git... [16:20:20] ossi|tt: thanks [16:21:18] thiago: make install works just fine [16:21:56] ok, but it seems we cannot start branching yet [16:22:24] not until QNX is fixed, at least [16:22:25] the problem is that ossi|tt wants to make it not work for in prefix builds in the future [16:23:21] thiago: we decided we don't want to patch the qnx toolchain so heavily - our customers won't have the patches either, iirc [16:23:22] it's mostly windows users being affected, as the default are non-prefix builds there. and framework builds are affected as well. [16:23:40] fregl: fair enough. But we will patch. [16:23:41] that was discussing with Simon, none of use felt comfy making the qnx changes [16:23:53] fregl: just lightly [16:24:03] thiago: What is the bug id for QNX issue? [16:24:03] the std::atomic code must be fixed [16:24:09] jaheikki3: I haven't created one yet [16:24:20] thiago: OK [16:25:20] fregl: and customers will have to patch it. The patch will be in the qtbase source code. [16:25:22] thiago: OK, I haven't personally looked at the patches, seems like we might be talking about different patches [16:25:37] fregl: possibly. I only care about std::atomic. [16:26:07] Ok, let's continue with these issues offline & postpone branching at least a week. Let's check the situation in next meeting, ok? [16:26:14] ok [16:26:51] Then Qt 5.7 status: [16:27:11] fregl: uh... we are talking about different things. My patches are for 5.7. [16:27:12] my bad. [16:27:48] thiago: ah, good if that doesn't block 5.6 [16:27:51] nope [16:28:03] it comes on now for 5.7... [16:28:13] :) [16:28:31] well, there I'm a hint less worried about the schedule [16:29:32] So we need to postpone 5.7 FF & branching a while because of those QNX changes? If we try to keep current plans we should start branching 8th Jan & finalize it 15th Jan (=FF)... [16:29:43] yeah [16:30:01] I am sending Simon, rafael and the QNX folks an email asking for an update. [16:30:53] Ok, great. Let's check 5.7 branching & ff again after a week as well [16:30:54] simon has the patch, we're just waiting for a position from the QNX folks on what they'd like us to do [16:31:04] other blockers besides this? [16:31:24] At least I don't know any at the moment [16:34:17] That's all about 5.7 at the moment. Then 5.5.2 "plans" [16:34:28] I have a question about 5.5.2 plans [16:34:31] are there any plans? :-) [16:35:27] I'd like to not create a 5.5.2 and rather get many 5.6.x releases out [16:35:35] agreed [16:35:40] let's focus on getting 5.6 out [16:35:52] that was my proposal as well [16:35:53] one question is how many people really need/want a 5.5.2 and if there is any extremely strong reason for it [16:36:14] the only reason for 5.5.2 is because 5.6 is late [16:36:17] At least I haven't heard anyone requesting 5.5.2 so heavily [16:36:27] if we could easily create a 5.5.2, I'd say do it. But we know it isn't easy. [16:36:39] yes, but considering the effort, 5.5.2 would probably make it even later [16:36:52] since it's the same people doing the work on two pieces of infrastructure [16:36:54] thiago: true. doing 5.6 and starting 5.7 will take so much effort [16:37:45] doing 3 releases at same time would be a big mess i think.... [16:38:25] so I think we should focus on 5.6 and 5.7 and drop 5.5.2 at this point [16:39:05] and if someone introduces really good reasons for 5.5.2 lets then think it again [16:39:14] fregl: Do you have support's opinion on this? [16:39:24] fregl: a ton of fixes went to 5.5... [16:39:44] fregl: and there are some 5.5.0->5.5.1 regressions unfortunately.. [16:40:06] 5.5 branch does contain fixes and some are important [16:40:18] for people carrying 5.5 for long term (linux distros), they should take those patches [16:40:22] but we can't find the time to release [16:40:53] gotta go for boarding my flight [16:41:24] fkleint: we discussed about 5.5.2 in mgmt meeting (support mgmt was there as well) and no one disagreed about dropping it at the moment [16:41:31] Oh,aha [16:41:43] thiago: ok, thanks about participation [16:41:51] they will realize it only afterwards, I think ;-) [16:41:59] ;) [16:42:51] yeah, but as I said we can rethink this later if needed. But let's focus now to 5.6 and 5.7 [16:44:48] ultimately by the time 5.6.0 comes out most will have forgotten about wanting 5.5.2, its mainly because 5.6.0 has taken so long that it started to become an issue, get 5.6.0 out then it is easier to promote the whole LTS thing and people will forget about 5.5.2 [16:45:16] though it would be better if it was clear what the plan was either way, its not helping us in communicating to customers about if/when it is coming [16:46:58] anshaw: Well, the plan is not to do 5.5.2 ;) And we can maybe change the plan if someone gives good reasons enough [16:47:10] Then we should really have closed the 5.5 branch...all this branch confusion and merge issues [16:47:12] anyways [16:47:16] exactly [16:48:44] Ok, This was all at this time. Let's have new meeting after a week at normal time (16:00 CET) [16:49:36] Thanks for your participation. Bye! [16:49:39] bye -------------- next part -------------- An HTML attachment was scrubbed... URL: From jani.heikkinen at theqtcompany.com Wed Jan 13 11:44:30 2016 From: jani.heikkinen at theqtcompany.com (Heikkinen Jani) Date: Wed, 13 Jan 2016 10:44:30 +0000 Subject: [Releasing] Meeting minutes: Qt release team meeting 12.01.2016 Message-ID: Meeting minutes from Qt Release Team meeting 12th January 2016 Qt 5.6 status: - QTQAINFRA-943 should be now fixed but fixes aren't in qt5.git yet * Update 13th Jan: qt5.git integration succeed, fixes for QTQAINFRA-943 in. Unfortunately changes waiting for it aren't in yet --> branching cannot start yet. Hoping we get missing changes in during this week and we so on can start branching at the begining of next week. - RC blocker list here: https://bugreports.qt.io/issues/?filter=17225 Qt 5.7 status: - No progress with QNX/std::atomic related issues --> Cannot start FF/Branching yet, hoping we can progress with those during next week Qt 4.8 & bugreports.qt.io: - Qt 4.8 branch has been closed for a while (except security fixes) and support has ended - bugreports.qt.io has some 1500+ bugs reported \ open \ in progress against Qt 4.8.x versions - Agreed to close those Qt 4.8 and older bugs with proper message * ' 'please re-open if still valid in Qt 5' or something similar Next meeting 19th Jan 2016 16:00 CET br, Jani irc log below: [17:00:32] akseli: iieklund: thiago: fkleint: ZapB: tronical: vladimirM: aholza: peter-h: mapaaso: ankokko: fkleint: carewolf: fregl: ablasche: ping [17:00:56] jaheikki3: pong [17:02:12] jaheikki3: pong [17:02:56] time to start qt release team meeting [17:03:04] On agenda today: [17:03:21] Qt 5.6 status [17:03:32] Qt 5.7 status [17:03:52] Qt 4.8 & bugreports.qt.io [17:04:02] Something else to the agenda? [17:05:21] pong [17:06:13] Ok, let's start from Qt 5.6 status: [17:07:11] unfortunately we cannot start branching yet. QTQAINFRA-943 should be now fixed but fixes aren't in qt5.git yet [17:07:38] And so on changes waiting for it aren't in yet either [17:08:29] qt5.git integration ongoing, let's hope it will integrate at this time. [17:10:07] New Qt 5.6 RC blocker list here (with Fix Version/s: 5.6.0 RC): https://bugreports.qt.io/issues/?filter=17225 [17:10:40] Any comments/questions? [17:11:19] -*- thiago forgot to create his task from last week [17:11:40] thiago: Was that for 5.7? [17:11:55] yeah [17:12:13] I'm just saying stuff aloud, sorry [17:12:50] No problem, I planned to ask it a bit later ;) [17:14:06] Ok, I think it was all about 5.6 at this time. Hoping we get qt5.git integrated & those missing changes in during this week and we can start branching at the begining of next week... [17:14:15] Then Qt 5.7 status: [17:14:47] thiago: is there some progress with that QNX/std::atomic related issues? [17:15:14] no reply from anyone [17:15:47] I shortly discussed with Simon and he said he haven't had time fo that yet [17:15:59] ok, thanks [17:17:14] So we need still postpone the FF and branching. Let's hope we can progress with those during next week. I'll keep pushing Simon. [17:17:45] thiago: could you create that bug report, it will make follow up easier? [17:18:55] yep [17:20:58] Ok, that was all about 5.7 at this time. [17:21:22] Then 4.8 & bug reports. Akseli [17:21:27] Qt 4.8 branch has been closed for a while (except security fixes) and support has ended [17:21:32] bugreports.qt.io has some 1500+ bugs reported \ open \ in progress against Qt 4.8.x versions (some of those reported against Qt5.x as well) [17:21:37] Some of Qt 4.8.x bugs might have been fixed and bugreport status has not been updated correctly but it is quite obvious most of 4.8.x bugs are in reality on "won't fix" status. [17:21:41] Should we take some actions for Qt 4.8.x (and older) bugs reported on bugreports.qt.io e.g. batch close Qt 4.8.x bugs with proper description? [17:21:45] or just leave those bugs open for now? [17:22:12] Hm, maybe check with ablasche, [17:22:12] if they are reported only against 4.8 and no later version, they should be closed [17:22:19] JIRA-technically [17:22:27] it's possible they still apply anyway, though [17:22:32] [but mgmt workshop going on ATM] [17:22:45] but the close message can say we will repoen if it can be reproduced with 5.x [17:23:24] fears another mailbox flood [17:23:39] batch close can be done without sending email ;) [17:24:12] "reopen if it can be reproduced with 5.x" was something i was thinking [17:24:14] +1, I think we could close all 4.8 (and older) bugs with message 'please re-open if still valid in Qt 5' or something similar [17:25:04] i can consult ablasche later about technicalities if closing 4.8 and older bugs is ok for everyone [17:26:39] yeah, I think that's the way to go [17:26:59] +1 [17:27:21] [Note though Symbian bugs won't be accepted in Qt 5 ;-) ] [17:27:31] and other dead platforms.. [17:27:55] true [17:28:03] I'm guessing even if there's no mail when closing, the comments from people having their bug closed as one of the 1500 might be... fun? [17:29:14] yes, that's what I am afraid of [17:29:18] well, by definition they can't be reproduced in Qt 5 [17:29:57] realistically, i think closing things that aren't going to be looked at is better than leaving them open indefinitely [17:29:58] akseli: fkleint: important to ensure that you don't close bugs with 4.8 bugs with Qt 5.x tags [17:30:29] some people will of course be disappointed about that, but if the message is worded carefully enough there won't be many of those :) [17:30:39] yeah, I totally agree on that, but some people might get "upset" - not much you can do about that [17:31:20] the interesting thing is that those bugs are dead already, but the act of closing them makes them live [17:32:41] that is not dead which can eternal lie [17:33:15] Hm..maybe the ones with no-longer-existing Nokia/etc-ids should be closed independently first..but that out of the scope of this meeting [17:36:09] Akseli will take care of closing those bugs with proper message. Let's then see what kind of discussion will arise. I'll add that plan in the meeting memo as well, at least some will notice it already from there [17:36:32] if they're assigned to "Closed Nokia identity", they should be simply unassigned [17:37:30] I think it was all at this time. Let's end this meeting now & have new one 19th Jan at this same time. OK? [17:38:05] +1 [17:38:49] Thanks for your participation! [17:38:51] bye [17:39:01] bye [17:39:05] bye -------------- next part -------------- An HTML attachment was scrubbed... URL: From oswald.buddenhagen at theqtcompany.com Wed Jan 13 15:07:24 2016 From: oswald.buddenhagen at theqtcompany.com (Oswald Buddenhagen) Date: Wed, 13 Jan 2016 15:07:24 +0100 Subject: [Releasing] Meeting minutes: Qt release team meeting 12.01.2016 In-Reply-To: References: Message-ID: <20160113140724.GA22076@troll08.it.local> On Wed, Jan 13, 2016 at 10:44:30AM +0000, Heikkinen Jani wrote: > - Agreed to close those Qt 4.8 and older bugs with proper message > > * ' 'please re-open if still valid in Qt 5' or something similar > we already did that before (and i was mightily annoyed by it). how can this even be possible at this point? *don't* touch it. From Lars.Knoll at theqtcompany.com Thu Jan 14 10:50:51 2016 From: Lars.Knoll at theqtcompany.com (Knoll Lars) Date: Thu, 14 Jan 2016 09:50:51 +0000 Subject: [Releasing] Meeting minutes: Qt release team meeting 12.01.2016 Message-ID: <5639805E-6081-48A6-A7E5-435CA5AF5081@theqtcompany.com> Hi Thiago, Can you explain in more detail what’s blocking 5.7 on QNX? As far as I understand, it’s mainly that std::atomic is not properly implemented in their libstdc++, right? Do we have any other options apart from patching the QNX SDK, as I don’t believe that to be a very good option? Thanks, Lars On 13/01/16 11:44, "Releasing on behalf of Heikkinen Jani" wrote: >Meeting minutes from Qt Release Team meeting 12th January 2016 > > >Qt 5.6 status: >- QTQAINFRA-943 should be now fixed but fixes aren't in qt5.git yet > * Update 13th Jan: qt5.git integration succeed, >fixes for QTQAINFRA-943 in. Unfortunately >changes waiting for it aren't in yet >--> branching cannot start yet. Hoping we get missing changes in during this week and we so on can start branching at the begining of next week. >- RC blocker > list here: >https://bugreports.qt.io/issues/?filter=17225 > > > >Qt 5.7 status: >- No progress with QNX/std::atomic related issues >--> Cannot start FF/Branching yet, hoping we can progress with those during next week > > >Qt 4.8 & bugreports.qt.io: >- Qt 4.8 branch has been closed for a while (except security fixes) and support has ended >- bugreports.qt.io has some 1500+ bugs reported \ open \ in progress against Qt 4.8.x versions >- Agreed to close those Qt 4.8 and older bugs with proper message > >* ' 'please re-open if still valid in Qt 5' or something similar > > >Next meeting 19th Jan 2016 16:00 CET > > >br, >Jani > > >irc log below: >[17:00:32] akseli: iieklund: thiago: fkleint: ZapB: tronical: vladimirM: aholza: peter-h: mapaaso: ankokko: fkleint: carewolf: fregl: ablasche: ping >[17:00:56] jaheikki3: pong >[17:02:12] jaheikki3: pong >[17:02:56] time to start qt release team meeting >[17:03:04] On agenda today: >[17:03:21] Qt 5.6 status >[17:03:32] Qt 5.7 status >[17:03:52] Qt 4.8 & bugreports.qt.io >[17:04:02] Something else to the agenda? >[17:05:21] pong >[17:06:13] Ok, let's start from Qt 5.6 status: >[17:07:11] unfortunately we cannot start branching yet. QTQAINFRA-943 should be now fixed but fixes aren't in qt5.git yet >[17:07:38] And so on changes waiting for it aren't in yet either >[17:08:29] qt5.git integration ongoing, let's hope it will integrate at this time. >[17:10:07] New Qt 5.6 RC blocker list here (with Fix Version/s: 5.6.0 RC): https://bugreports.qt.io/issues/?filter=17225 >[17:10:40] Any comments/questions? >[17:11:19] -*- thiago forgot to create his task from last week >[17:11:40] thiago: Was that for 5.7? >[17:11:55] yeah >[17:12:13] I'm just saying stuff aloud, sorry >[17:12:50] No problem, I planned to ask it a bit later ;) >[17:14:06] Ok, I think it was all about 5.6 at this time. Hoping we get qt5.git integrated & those missing changes in during this week and we can start branching at the begining of next week... >[17:14:15] Then Qt 5.7 status: >[17:14:47] thiago: is there some progress with that QNX/std::atomic related issues? >[17:15:14] no reply from anyone >[17:15:47] I shortly discussed with Simon and he said he haven't had time fo that yet >[17:15:59] ok, thanks >[17:17:14] So we need still postpone the FF and branching. Let's hope we can progress with those during next week. I'll keep pushing Simon. >[17:17:45] thiago: could you create that bug report, it will make follow up easier? >[17:18:55] yep >[17:20:58] Ok, that was all about 5.7 at this time. >[17:21:22] Then 4.8 & bug reports. Akseli >[17:21:27] Qt 4.8 branch has been closed for a while (except security fixes) and support has ended >[17:21:32] bugreports.qt.io has some 1500+ bugs reported \ open \ in progress against Qt 4.8.x versions (some of those reported against Qt5.x as well) >[17:21:37] Some of Qt 4.8.x bugs might have been fixed and bugreport status has not been updated correctly but it is quite obvious most of 4.8.x bugs are in reality on "won't fix" status. >[17:21:41] Should we take some actions for Qt 4.8.x (and older) bugs reported on bugreports.qt.io e.g. batch close Qt 4.8.x bugs with proper description? >[17:21:45] or just leave those bugs open for now? >[17:22:12] Hm, maybe check with ablasche, >[17:22:12] if they are reported only against 4.8 and no later version, they should be closed >[17:22:19] JIRA-technically >[17:22:27] it's possible they still apply anyway, though >[17:22:32] [but mgmt workshop going on ATM] >[17:22:45] but the close message can say we will repoen if it can be reproduced with 5.x >[17:23:24] fears another mailbox flood >[17:23:39] batch close can be done without sending email ;) >[17:24:12] "reopen if it can be reproduced with 5.x" was something i was thinking > >[17:24:14] +1, I think we could close all 4.8 (and older) bugs with message 'please re-open if still valid in Qt 5' or something similar >[17:25:04] i can consult ablasche later about technicalities if closing 4.8 and older bugs is ok for everyone >[17:26:39] yeah, I think that's the way to go >[17:26:59] +1 >[17:27:21] [Note though Symbian bugs won't be accepted in Qt 5 ;-) ] >[17:27:31] and other dead platforms.. >[17:27:55] true >[17:28:03] I'm guessing even if there's no mail when closing, the comments from people having their bug closed as one of the 1500 might be... fun? >[17:29:14] yes, that's what I am afraid of >[17:29:18] well, by definition they can't be reproduced in Qt 5 >[17:29:57] realistically, i think closing things that aren't going to be looked at is better than leaving them open indefinitely >[17:29:58] akseli: fkleint: important to ensure that you don't close bugs with 4.8 bugs with Qt 5.x tags >[17:30:29] some people will of course be disappointed about that, but if the message is worded carefully enough there won't be many of those :) >[17:30:39] yeah, I totally agree on that, but some people might get "upset" - not much you can do about that >[17:31:20] the interesting thing is that those bugs are dead already, but the act of closing them makes them live >[17:32:41] that is not dead which can eternal lie >[17:33:15] Hm..maybe the ones with no-longer-existing Nokia/etc-ids should be closed independently first..but that out of the scope of this meeting >[17:36:09] Akseli will take care of closing those bugs with proper message. Let's then see what kind of discussion will arise. I'll add that plan in the meeting memo as well, at least some will notice it already from there >[17:36:32] if they're assigned to "Closed Nokia identity", they should be simply unassigned >[17:37:30] I think it was all at this time. Let's end this meeting now & have new one 19th Jan at this same time. OK? >[17:38:05] +1 >[17:38:49] Thanks for your participation! >[17:38:51] bye >[17:39:01] bye >[17:39:05] bye > > > > > > From jhihn at gmx.com Thu Jan 14 14:55:05 2016 From: jhihn at gmx.com (Jason H) Date: Thu, 14 Jan 2016 14:55:05 +0100 Subject: [Releasing] Meeting minutes: Qt release team meeting 12.01.2016 In-Reply-To: <5639805E-6081-48A6-A7E5-435CA5AF5081@theqtcompany.com> References: <5639805E-6081-48A6-A7E5-435CA5AF5081@theqtcompany.com> Message-ID: > On 13/01/16 11:44, "Releasing on behalf of Heikkinen Jani" wrote: > > >Meeting minutes from Qt Release Team meeting 12th January 2016 > > > > > >Qt 5.6 status: > >- QTQAINFRA-943 should be now fixed but fixes aren't in qt5.git yet > > * Update 13th Jan: qt5.git integration succeed, > >fixes for QTQAINFRA-943 in. Unfortunately > >changes waiting for it aren't in yet > >--> branching cannot start yet. Hoping we get missing changes in during this week and we so on can start branching at the begining of next week. > >- RC blocker > > list here: > >https://bugreports.qt.io/issues/?filter=17225 > > > > > > > >Qt 5.7 status: > >- No progress with QNX/std::atomic related issues > >--> Cannot start FF/Branching yet, hoping we can progress with those during next week > > > > > >Qt 4.8 & bugreports.qt.io: > >- Qt 4.8 branch has been closed for a while (except security fixes) and support has ended > >- bugreports.qt.io has some 1500+ bugs reported \ open \ in progress against Qt 4.8.x versions > >- Agreed to close those Qt 4.8 and older bugs with proper message > > > >* ' 'please re-open if still valid in Qt 5' or something similar > > > > If I were to come up with code for OSX/iOS Multimedia recording backend configuration by tommorow, it would not be in the 5.7 release? From thiago.macieira at intel.com Thu Jan 14 18:57:09 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 14 Jan 2016 09:57:09 -0800 Subject: [Releasing] Meeting minutes: Qt release team meeting 12.01.2016 In-Reply-To: <5639805E-6081-48A6-A7E5-435CA5AF5081@theqtcompany.com> References: <5639805E-6081-48A6-A7E5-435CA5AF5081@theqtcompany.com> Message-ID: <1456341.1sUVTUUaFL@tjmaciei-mobl4> On Thursday 14 January 2016 09:50:51 Knoll Lars wrote: > Hi Thiago, > > Can you explain in more detail what’s blocking 5.7 on QNX? As far as I > understand, it’s mainly that std::atomic is not properly implemented in > their libstdc++, right? Right. QNX folks gave us a patch, but it hasn't been applied to the toolchain in the CI yet. > Do we have any other options apart from patching the QNX SDK, as I don’t > believe that to be a very good option? Not easily. I'd have to hunt down the uses of QAtomicPointer that fail to compile and replace with QAtomicInteger, then do manual conversions. I know only of one in qlogging.cpp, the one that first causes a compilation error. There may be more, we just don't know. I'd rather apply the fix instead. Note that they're also working on an updated version of their SDK, which should happen soon but not in time for our branching. So this problem will go away in time and users won't have to patch for long, if at all (the updated SDK could happen before the 5.7 final). [The same thing happened back in Qt 4 days for QAtomicPointer, which caused compilation errors in many platforms. Instead of working around in the QtDBus code that used that construct, I insisted on having the atomic code (all ours, in src/corelib/arch) be fixed] -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Lars.Knoll at theqtcompany.com Thu Jan 14 19:24:46 2016 From: Lars.Knoll at theqtcompany.com (Knoll Lars) Date: Thu, 14 Jan 2016 18:24:46 +0000 Subject: [Releasing] Meeting minutes: Qt release team meeting 12.01.2016 In-Reply-To: <1456341.1sUVTUUaFL@tjmaciei-mobl4> References: <5639805E-6081-48A6-A7E5-435CA5AF5081@theqtcompany.com> <1456341.1sUVTUUaFL@tjmaciei-mobl4> Message-ID: <65D8FAE6-D0B9-4CA1-BC3F-5CF85447C530@theqtcompany.com> On 14/01/16 18:57, "Thiago Macieira" wrote: >On Thursday 14 January 2016 09:50:51 Knoll Lars wrote: >> Hi Thiago, >> >> Can you explain in more detail what’s blocking 5.7 on QNX? As far as I >> understand, it’s mainly that std::atomic is not properly implemented in >> their libstdc++, right? > >Right. QNX folks gave us a patch, but it hasn't been applied to the toolchain >in the CI yet. > >> Do we have any other options apart from patching the QNX SDK, as I don’t >> believe that to be a very good option? > >Not easily. I'd have to hunt down the uses of QAtomicPointer that fail to >compile and replace with QAtomicInteger, then do manual conversions. >I know only of one in qlogging.cpp, the one that first causes a compilation >error. There may be more, we just don't know. > >I'd rather apply the fix instead. Well, this works in 5.6, I guess because we're not using std::atomic there. Why aren't we continuing to use that code path until QNX has released a fixed tool chain? Cheers, Lars > >Note that they're also working on an updated version of their SDK, which >should happen soon but not in time for our branching. So this problem will go >away in time and users won't have to patch for long, if at all (the updated >SDK could happen before the 5.7 final). > >[The same thing happened back in Qt 4 days for QAtomicPointer, >which caused compilation errors in many platforms. Instead of working around >in the QtDBus code that used that construct, I insisted on having the atomic >code (all ours, in src/corelib/arch) be fixed] > >-- >Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > From thiago.macieira at intel.com Fri Jan 15 01:25:50 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 14 Jan 2016 16:25:50 -0800 Subject: [Releasing] Meeting minutes: Qt release team meeting 12.01.2016 In-Reply-To: <65D8FAE6-D0B9-4CA1-BC3F-5CF85447C530@theqtcompany.com> References: <5639805E-6081-48A6-A7E5-435CA5AF5081@theqtcompany.com> <1456341.1sUVTUUaFL@tjmaciei-mobl4> <65D8FAE6-D0B9-4CA1-BC3F-5CF85447C530@theqtcompany.com> Message-ID: <1475538.lKXDEOl9Tt@tjmaciei-mobl4> On Thursday 14 January 2016 18:24:46 Knoll Lars wrote: > >I'd rather apply the fix instead. > > > Well, this works in 5.6, I guess because we're not using std::atomic there. > Why aren't we continuing to use that code path until QNX has released a > fixed tool chain? Because it's the old atomic code, some of which I rewrote for 5.0, most of which are the same ones Brad made public for 4.4, with the initial implementations from 4.0. There are problems with them, as evidenced by the bug reports received in the last year. Some are serious problems, like the 32-bit ARM code for 64-bit integers. And I think that the AArch64 codepath is just completely busted -- unless Q_COMPILER_ATOMICS is defined, in which case we are back where we started. I don't test non-IA and, most importantly, I don't want to maintain the hand- written assembly anymore. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From robin+qt at viroteck.net Fri Jan 15 01:37:53 2016 From: robin+qt at viroteck.net (Robin Burchell) Date: Fri, 15 Jan 2016 01:37:53 +0100 Subject: [Releasing] Meeting minutes: Qt release team meeting 12.01.2016 In-Reply-To: <1475538.lKXDEOl9Tt@tjmaciei-mobl4> References: <5639805E-6081-48A6-A7E5-435CA5AF5081@theqtcompany.com> <1456341.1sUVTUUaFL@tjmaciei-mobl4> <65D8FAE6-D0B9-4CA1-BC3F-5CF85447C530@theqtcompany.com> <1475538.lKXDEOl9Tt@tjmaciei-mobl4> Message-ID: <1452818273.89676.492608738.00A6DB11@webmail.messagingengine.com> On Fri, Jan 15, 2016, at 01:25 AM, Thiago Macieira wrote: > I don't test non-IA and, most importantly, I don't want to maintain the > hand-written assembly anymore. Given that 5.6 is LTS and thus will require support anyway, what does dropping it in 5.7 gain? From Lars.Knoll at theqtcompany.com Fri Jan 15 10:21:19 2016 From: Lars.Knoll at theqtcompany.com (Knoll Lars) Date: Fri, 15 Jan 2016 09:21:19 +0000 Subject: [Releasing] Meeting minutes: Qt release team meeting 12.01.2016 In-Reply-To: <1475538.lKXDEOl9Tt@tjmaciei-mobl4> References: <5639805E-6081-48A6-A7E5-435CA5AF5081@theqtcompany.com> <1456341.1sUVTUUaFL@tjmaciei-mobl4> <65D8FAE6-D0B9-4CA1-BC3F-5CF85447C530@theqtcompany.com> <1475538.lKXDEOl9Tt@tjmaciei-mobl4> Message-ID: On 15/01/16 01:25, "Releasing on behalf of Thiago Macieira" wrote: >On Thursday 14 January 2016 18:24:46 Knoll Lars wrote: >> >I'd rather apply the fix instead. >> >> >> Well, this works in 5.6, I guess because we're not using std::atomic there. >> Why aren't we continuing to use that code path until QNX has released a >> fixed tool chain? > >Because it's the old atomic code, some of which I rewrote for 5.0, most of >which are the same ones Brad made public for 4.4, with the initial >implementations from 4.0. > >There are problems with them, as evidenced by the bug reports received in the >last year. Some are serious problems, like the 32-bit ARM code for 64-bit >integers. And I think that the AArch64 codepath is just completely busted -- >unless Q_COMPILER_ATOMICS is defined, in which case we are back where we >started. Well, I wouldn’t have any problems if we in this case disable atomics for 64bit integers on 32bit (I don’t think we use those anywhere ourselves), and require proper atomics for AARCH64. I think we only support 32bit on QNX anyway. And of course switch over to C++11 atomics as soon as a fixed toolchain is out. Cheers, Lars > >I don't test non-IA and, most importantly, I don't want to maintain the hand- >written assembly anymore. > >-- >Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > >_______________________________________________ >Releasing mailing list >Releasing at qt-project.org >http://lists.qt-project.org/mailman/listinfo/releasing From thiago.macieira at intel.com Fri Jan 15 23:24:07 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 15 Jan 2016 14:24:07 -0800 Subject: [Releasing] Meeting minutes: Qt release team meeting 12.01.2016 In-Reply-To: <1452818273.89676.492608738.00A6DB11@webmail.messagingengine.com> References: <5639805E-6081-48A6-A7E5-435CA5AF5081@theqtcompany.com> <1475538.lKXDEOl9Tt@tjmaciei-mobl4> <1452818273.89676.492608738.00A6DB11@webmail.messagingengine.com> Message-ID: <1693481.iV5vbm7DKY@tjmaciei-mobl4> On Friday 15 January 2016 01:37:53 Robin Burchell wrote: > On Fri, Jan 15, 2016, at 01:25 AM, Thiago Macieira wrote: > > I don't test non-IA and, most importantly, I don't want to maintain the > > hand-written assembly anymore. > > Given that 5.6 is LTS and thus will require support anyway, what does > dropping it in 5.7 gain? It gains us a proper implementation, the same one most people will be using in 5.6 because C++11 is the default for any application using qmake, we've warned people to move to C++11 and GCC 6.0 even makes C++14 the default. Read: the 5.6 implementation is not proper. The reason we can't get a proper one is because we cannot require std::atomic. I have fixed the bugs we've found, but I cannot guarantee there aren't more. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Fri Jan 15 23:30:44 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 15 Jan 2016 14:30:44 -0800 Subject: [Releasing] Meeting minutes: Qt release team meeting 12.01.2016 In-Reply-To: References: <5639805E-6081-48A6-A7E5-435CA5AF5081@theqtcompany.com> <1475538.lKXDEOl9Tt@tjmaciei-mobl4> Message-ID: <3689655.d7zB9JQuPb@tjmaciei-mobl4> On Friday 15 January 2016 09:21:19 Knoll Lars wrote: > >There are problems with them, as evidenced by the bug reports received in > >the last year. Some are serious problems, like the 32-bit ARM code for > >64-bit integers. And I think that the AArch64 codepath is just completely > >busted -- unless Q_COMPILER_ATOMICS is defined, in which case we are back > >where we started. > > > Well, I wouldn’t have any problems if we in this case disable atomics for > 64bit integers on 32bit (I don’t think we use those anywhere ourselves), > and require proper atomics for AARCH64. I think we only support 32bit on > QNX anyway. I've fixed that bug now. The problem wasn't that the implementation failed to compile... it compiled and worked some time, but not in others. QTBUG-49168: MIPS's 3-argument testAndSet was broken at runtime QTBUG-48197: IA-64 3-argument testAndSet failed to compile QTBUG-46949: 64-bit atomics on iOS caused segfault 50% of the time (bad alignment) These are just from 2015. Three different architectures, three separate issues and only one of them was a compile-time failure. > And of course switch over to C++11 atomics as soon as a fixed toolchain is > out. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From jani.heikkinen at theqtcompany.com Wed Jan 20 09:03:10 2016 From: jani.heikkinen at theqtcompany.com (Heikkinen Jani) Date: Wed, 20 Jan 2016 08:03:10 +0000 Subject: [Releasing] Meeting minutes: Qt release team meeting 19.01.2016 Message-ID: Meeting minutes from Qt Release Team meeting 19th January 2016 Qt 5.6 status - Most of changes which were blocking the branching should be in now * merge from 5.5 to 5.6 still ongoing * https://codereview.qt-project.org/#/c/144374/ still missing --> Better to wait those in before start branching. Target to start branching today or at least during this week --> If we can start soft branching today target schedule for Qt 5.6 will be: * finalize branching 27.1, * RC 10.2 * final release 24.2 Qt 5.7 status - there is a fix for std::atomic issue available but not in yet * When integrated we need to get https://codereview.qt-project.org/139151 + dependencies in before we can start soft branching - License Header changes coming in all the time. some already in. Not blocking the soft branching, can be taken in during soft branching period - Adding published add-on modules to qt5.git ongoing. Not blocking the soft branching, can be taken in during soft branching period --> Hoping we can start soft branching at the end of this week & have FF and final branch a week after that Next meeting Tue 26th Jan 16:00 CET br, Jani irc log below: [17:00:23] akseli: iieklund: thiago: fkleint: ZapB: tronical: vladimirM: aholza: peter-h: mapaaso: ankokko: fkleint: carewolf: fregl: ablasche: ping [17:00:30] jaheikki3: pong [17:00:32] jaheikki3: pong [17:00:56] jaheikki3: pong [17:01:02] jaheikki3: pong [17:02:29] Time to start qt release team meeting [17:02:34] on agenda today: [17:02:42] qt 5.6.0 status [17:02:52] qt 5.7 status [17:03:10] Any additional item to the agenda? [17:05:28] pong [17:05:37] Ok, let's start from 5.6 status: [17:06:15] all changes which were blocking the branching should be in now [17:06:35] qt5.git integration has succeed couple of times with those [17:07:18] unfortunately we haven't been able to produce proper snapshot for testing yet [17:09:31] There is some changes needed for export tool to be able to handle those published enterprise add-on modules [17:10:01] Work is ongoing & we should be able to create snapshot for testing really soon [17:10:35] But I think we are ready to start soft branching from 5.6 -> 5.6.0 now & finalize it after a week [17:11:17] if no-one objects I'll ask ossi|tt to start that as soon as possible [17:12:35] In addition to this we need to do official API review as well. fregl organized that last time and I'll ask him to do it again at this time as well [17:13:25] looks like no objections [17:13:28] +1 [17:14:20] great. let's start soft branching latest tomorrow. so the target schedule for 5.6.0 will be: [17:14:45] jaheikki3: i can do it right away [17:14:50] finalize branching 27.1, RC 10.2 and final release 24.2 [17:14:55] ossi|tt: Great! [17:16:13] 5.5->5.6 merge still ongoing [17:16:18] qtbase [17:17:03] ok, i should wait for that. not that it's not possible to do it nonetheless, but it's an unnecessary complication. [17:17:40] yep https://codereview.qt-project.org/#/c/145313/ [17:18:38] ok, let's wait that [17:19:36] I think it was all about 5.6 at this time. ossi|tt, please inform me when 5.6.0 branch is available and I'll sen info about that in ML [17:20:04] then Qt 5.7 status: [17:20:09] jaheikki3: probably, you'll need to remind me. ^^ [17:20:16] jaheikki3: it's then done within 10 minutes. [17:20:26] ossi|tt: OK ;) [17:22:10] there is a fix for std::atomic issue available but not in yet [17:22:42] jaheikki3: speaking of which, i think we need to wait for https://codereview.qt-project.org/144374 to integrate (which should work now that https://codereview.qt-project.org/146356 is in) - having the branches have different version of that would be a bit of a nightmare, i think. [17:24:14] ossi|tt: Ok, should we try it immediately? [17:25:07] thiago: so when it is integrated is https://codereview.qt-project.org/139151 only change needed to be in before we can start soft branching & preparations of FF ? [17:25:27] jaheikki3: i suppose we could. but it presumably makes no sense if we want a submodule update with the qtbase merge integrated as well. [17:25:45] ossi|tt: ah, true [17:26:48] jaheikki3: the change comes in a group [17:28:03] thiago: OK, i noticed the dependencies [17:28:24] hoping we could get those in during this week. [17:28:34] jaheikki3: there are two more but they're mostly harmless and it's the configure update [17:28:45] for 5.7 there is also those license header changes coming all the time. some of those are already in, hoping we will get most of done during this week as well [17:29:54] And adding those published add-ons (charts, datavis, VKB) as qt5 add-on modules is ongoing as well [17:30:02] for 5.7 [17:30:40] Hoping we can get those in during this week as well. [17:31:58] So it seems we could start soft branching quite soon, maybe already at the end of this week & so on have branching & ff at the end of next week [17:33:58] I think we should get those std:atomic related changes in before starting soft branching as well as most of license header changes. adding those add-ons can be done during soft branching period. OK? [17:34:44] comments / questions? [17:34:54] sounds good [17:35:16] +1 [17:35:42] yep, it helps [17:36:25] +1 [17:36:54] sorry guys, got to run. thanks for meeting [17:39:02] ok, it was all at this time. Let's have new meeting after a week at this same time, OK? [17:44:11] ok [17:44:44] ok, let's end this meeting now & have new one 26.1 16:00 CET [17:44:56] thanks for your participation, bye! [17:45:01] bye [17:45:06] bb -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Thu Jan 21 00:38:34 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 20 Jan 2016 15:38:34 -0800 Subject: [Releasing] Meeting minutes: Qt release team meeting 19.01.2016 In-Reply-To: References: Message-ID: <4075255.m2BkbMLqhN@tjmaciei-mobl4> On Wednesday 20 January 2016 08:03:10 Heikkinen Jani wrote: > - there is a fix for std::atomic issue available but not in yet > > * When integrated we need to get > https://codereview.qt-project.org/139151 + dependencies in before we can > start soft branching Update: they integrated yesterday. The only pending thing is the configure check, which I can do after the branching. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 From jani.heikkinen at theqtcompany.com Mon Jan 25 12:39:22 2016 From: jani.heikkinen at theqtcompany.com (Heikkinen Jani) Date: Mon, 25 Jan 2016 11:39:22 +0000 Subject: [Releasing] HEADS UP: Qt 5.6.0 branching ongoing In-Reply-To: References: Message-ID: ‘5.6.0’ branch is now available, please start using it for the changes targeted to Qt5.6.0 release. We will merge ‘5.6’ branch to ‘5.6.0’ Monday 1st February so there should be enough time to finalize ongoing changes in ‘5.6’ and start using '5.6.0'. All new changes for Qt5.6.0 should be done in ‘5.6.0’ branch from now on. Target is to release Qt5.6.0 RC quite soon so please make sure all blockers will be fixed as soon as possible. Blocker list here: https://bugreports.qt.io/issues/?filter=17225 Please make sure all Qt 5.6.0 blockers are found from blocker list (== set 5.6.0 RC as fix version(s)): We should fix all blockers before RC & minimize changes between RC and final. And please remember: Do not add any 'nice to have' -changes in anymore (P0 & P1 bug fixes mostly, in some special cases p2 fixes might be ok as well). Best regards, Jani Heikkinen Release Manager | The Qt Company The Qt Company / Digia Finland Ltd, Elektroniikkatie 13, 90590 Oulu, Finland Email: jani.heikkinen at theqtcompany.com | Mobile: + 358 50 48 73 735 www.qt.io |Qt Blog: http://blog.qt.digia.com/ | Twitter: @QtbyDigia, @Qtproject Facebook: www.facebook.com/qt From tuukka.turunen at theqtcompany.com Tue Jan 26 08:30:10 2016 From: tuukka.turunen at theqtcompany.com (Turunen Tuukka) Date: Tue, 26 Jan 2016 07:30:10 +0000 Subject: [Releasing] Removal of engin.io from Qt 5.7 Message-ID: Hi, I would like to propose removal of the engin.io cloud service support module Enginio (http://doc.qt.io/qt-5/enginio-index.html) from Qt 5.7 release packages. It has been deprecated since Qt 5.6 and no longer developed further. Also the backend will be shut down most likely during H2/16: http://blog.qt.io/blog/2016/01/26/notification-for-all-qt-cloud-services-users There are many good things in the engin.io service, but it never really gained enough momentum. The code of Enginio module remains in the Qt repositories, in case it is later seen useful for further use. Qt is actively used with many different cloud services already. Perhaps with somewhat more effort than was needed to use engin.io. "Cloud compatibility" is very relevant for Qt and with the effort saved from developing and maintaining Enginio module, we should be able to improve in that area even further. Yours, Tuukka -------------- next part -------------- An HTML attachment was scrubbed... URL: From Lars.Knoll at theqtcompany.com Tue Jan 26 08:45:12 2016 From: Lars.Knoll at theqtcompany.com (Knoll Lars) Date: Tue, 26 Jan 2016 07:45:12 +0000 Subject: [Releasing] Removal of engin.io from Qt 5.7 Message-ID: +1 for removing. It doesn’t make a whole lot of sense to have it without the backend :) Cheers, Lars On 26/01/16 08:30, "Releasing on behalf of Turunen Tuukka" wrote: > >Hi, > >I would like to propose removal of the engin.io cloud service support module Enginio (http://doc.qt.io/qt-5/enginio-index.html) from Qt 5.7 release packages. It has > been deprecated since Qt 5.6 and no longer developed further. > >Also the backend will be shut down most likely during H2/16: > >http://blog.qt.io/blog/2016/01/26/notification-for-all-qt-cloud-services-users > >There are many good things in the engin.io service, but it never really gained enough momentum. The code of Enginio module remains in the Qt repositories, in case it is later seen useful for further use. > >Qt is actively used with many different cloud services already. Perhaps with somewhat more effort than was needed to use engin.io. “Cloud compatibility” is very relevant for Qt and with the effort saved from developing > and maintaining Enginio module, we should be able to improve in that area even further. > > >Yours, > > Tuukka > From pgquiles at elpauer.org Tue Jan 26 09:26:45 2016 From: pgquiles at elpauer.org (Pau Garcia i Quiles) Date: Tue, 26 Jan 2016 09:26:45 +0100 Subject: [Releasing] Removal of engin.io from Qt 5.7 In-Reply-To: References: Message-ID: Hello, Has releasing the backend as open source been considered? On Tue, Jan 26, 2016 at 8:45 AM, Knoll Lars wrote: > +1 for removing. It doesn’t make a whole lot of sense to have it without > the backend :) > > Cheers, > Lars > > > > > On 26/01/16 08:30, "Releasing on behalf of Turunen Tuukka" < > releasing-bounces at qt-project.org on behalf of > tuukka.turunen at theqtcompany.com> wrote: > > > > >Hi, > > > >I would like to propose removal of the engin.io cloud service support > module Enginio (http://doc.qt.io/qt-5/enginio-index.html) from Qt 5.7 > release packages. It has > > been deprecated since Qt 5.6 and no longer developed further. > > > >Also the backend will be shut down most likely during H2/16: > > > > > http://blog.qt.io/blog/2016/01/26/notification-for-all-qt-cloud-services-users > < > http://blog.qt.io/blog/2016/01/26/notification-for-all-qt-cloud-services-users/ > > > > > >There are many good things in the engin.io service, but it never really > gained enough momentum. The code of Enginio module remains in the Qt > repositories, in case it is later seen useful for further use. > > > >Qt is actively used with many different cloud services already. Perhaps > with somewhat more effort than was needed to use engin.io. “Cloud > compatibility” is very relevant for Qt and with the effort saved from > developing > > and maintaining Enginio module, we should be able to improve in that > area even further. > > > > > >Yours, > > > > Tuukka > > > _______________________________________________ > Releasing mailing list > Releasing at qt-project.org > http://lists.qt-project.org/mailman/listinfo/releasing > -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) -------------- next part -------------- An HTML attachment was scrubbed... URL: From Maurice.Kalinowski at theqtcompany.com Tue Jan 26 10:45:43 2016 From: Maurice.Kalinowski at theqtcompany.com (Kalinowski Maurice) Date: Tue, 26 Jan 2016 09:45:43 +0000 Subject: [Releasing] Removal of engin.io from Qt 5.7 In-Reply-To: References: Message-ID: Hi, https://github.com/qtcloudservices OpenSourcing has been announced several months ago. I am not sure about completeness though. BR, Maurice From: Releasing [mailto:releasing-bounces at qt-project.org] On Behalf Of Pau Garcia i Quiles Sent: Tuesday, January 26, 2016 9:27 AM To: Knoll Lars Cc: releasing at qt-project.org Subject: Re: [Releasing] Removal of engin.io from Qt 5.7 Hello, Has releasing the backend as open source been considered? On Tue, Jan 26, 2016 at 8:45 AM, Knoll Lars > wrote: +1 for removing. It doesn’t make a whole lot of sense to have it without the backend :) Cheers, Lars On 26/01/16 08:30, "Releasing on behalf of Turunen Tuukka" on behalf of tuukka.turunen at theqtcompany.com> wrote: > >Hi, > >I would like to propose removal of the engin.io cloud service support module Enginio (http://doc.qt.io/qt-5/enginio-index.html) from Qt 5.7 release packages. It has > been deprecated since Qt 5.6 and no longer developed further. > >Also the backend will be shut down most likely during H2/16: > >http://blog.qt.io/blog/2016/01/26/notification-for-all-qt-cloud-services-users > >There are many good things in the engin.io service, but it never really gained enough momentum. The code of Enginio module remains in the Qt repositories, in case it is later seen useful for further use. > >Qt is actively used with many different cloud services already. Perhaps with somewhat more effort than was needed to use engin.io. “Cloud compatibility” is very relevant for Qt and with the effort saved from developing > and maintaining Enginio module, we should be able to improve in that area even further. > > >Yours, > > Tuukka > _______________________________________________ Releasing mailing list Releasing at qt-project.org http://lists.qt-project.org/mailman/listinfo/releasing -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuukka.turunen at theqtcompany.com Tue Jan 26 13:49:33 2016 From: tuukka.turunen at theqtcompany.com (Turunen Tuukka) Date: Tue, 26 Jan 2016 12:49:33 +0000 Subject: [Releasing] Removal of engin.io from Qt 5.7 In-Reply-To: References: Message-ID: From: Pau Garcia i Quiles [mailto:pgquiles at elpauer.org] Sent: tiistaina 26. tammikuuta 2016 10.27 To: Knoll Lars Cc: Turunen Tuukka ; releasing at qt-project.org Subject: Re: [Releasing] Removal of engin.io from Qt 5.7 Hello, Has releasing the backend as open source been considered? Open-sourcing the backend is not an option, as the backend is partially based on assets not allowed to be open sourced. Yours, Tuukka On Tue, Jan 26, 2016 at 8:45 AM, Knoll Lars > wrote: +1 for removing. It doesn’t make a whole lot of sense to have it without the backend :) Cheers, Lars On 26/01/16 08:30, "Releasing on behalf of Turunen Tuukka" on behalf of tuukka.turunen at theqtcompany.com> wrote: > >Hi, > >I would like to propose removal of the engin.io cloud service support module Enginio (http://doc.qt.io/qt-5/enginio-index.html) from Qt 5.7 release packages. It has > been deprecated since Qt 5.6 and no longer developed further. > >Also the backend will be shut down most likely during H2/16: > >http://blog.qt.io/blog/2016/01/26/notification-for-all-qt-cloud-services-users > >There are many good things in the engin.io service, but it never really gained enough momentum. The code of Enginio module remains in the Qt repositories, in case it is later seen useful for further use. > >Qt is actively used with many different cloud services already. Perhaps with somewhat more effort than was needed to use engin.io. “Cloud compatibility” is very relevant for Qt and with the effort saved from developing > and maintaining Enginio module, we should be able to improve in that area even further. > > >Yours, > > Tuukka > _______________________________________________ Releasing mailing list Releasing at qt-project.org http://lists.qt-project.org/mailman/listinfo/releasing -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhihn at gmx.com Tue Jan 26 18:56:42 2016 From: jhihn at gmx.com (Jason H) Date: Tue, 26 Jan 2016 18:56:42 +0100 Subject: [Releasing] Removal of engin.io from Qt 5.7 In-Reply-To: References: , Message-ID: An HTML attachment was scrubbed... URL: From jedrzej.nowacki at theqtcompany.com Wed Jan 27 10:42:35 2016 From: jedrzej.nowacki at theqtcompany.com (=?utf-8?B?SsSZZHJ6ZWo=?= Nowacki) Date: Wed, 27 Jan 2016 10:42:35 +0100 Subject: [Releasing] Removal of engin.io from Qt 5.7 In-Reply-To: References: Message-ID: <5150141.zNPBBU8aiL@42> On Tuesday 26 of January 2016 07:30:10 Turunen Tuukka wrote: > Hi, > > I would like to propose removal of the engin.io cloud service support module > Enginio (http://doc.qt.io/qt-5/enginio-index.html) from Qt 5.7 release > packages. It has been deprecated since Qt 5.6 and no longer developed > further. > > Also the backend will be shut down most likely during H2/16: > http://blog.qt.io/blog/2016/01/26/notification-for-all-qt-cloud-services-us > ers -users/> > > There are many good things in the engin.io service, but it never really > gained enough momentum. The code of Enginio module remains in the Qt > repositories, in case it is later seen useful for further use. > > Qt is actively used with many different cloud services already. Perhaps with > somewhat more effort than was needed to use engin.io. "Cloud compatibility" > is very relevant for Qt and with the effort saved from developing and > maintaining Enginio module, we should be able to improve in that area even > further. > > Yours, > > Tuukka +1 From my side. Cheers, Jędrek From jedrzej.nowacki at theqtcompany.com Wed Jan 27 16:40:38 2016 From: jedrzej.nowacki at theqtcompany.com (=?utf-8?B?SsSZZHJ6ZWo=?= Nowacki) Date: Wed, 27 Jan 2016 16:40:38 +0100 Subject: [Releasing] Removal of engin.io from Qt 5.7 In-Reply-To: References: Message-ID: <2187953.64LKhBFC9W@42> What is the idea for Qt5.6 which is LTS? Does it make sense to include QtEnginio there? Cheers, Jędrek On Tuesday 26 of January 2016 07:45:12 Knoll Lars wrote: > +1 for removing. It doesn’t make a whole lot of sense to have it without the > backend :) > Cheers, > Lars > > > > > On 26/01/16 08:30, "Releasing on behalf of Turunen Tuukka" > tuukka.turunen at theqtcompany.com> wrote: > > > > > > >Hi, > > > > > > > >I would like to propose removal of the engin.io cloud service support > >module Enginio (http://doc.qt.io/qt-5/enginio-index.html) from Qt 5.7 > >release packages. It has > > > been deprecated since Qt 5.6 and no longer developed further. > > > > > >Also the backend will be shut down most likely during H2/16: > > > >http://blog.qt.io/blog/2016/01/26/notification-for-all-qt-cloud-services-us > >ers > > >users/> > > > > > > >There are many good things in the engin.io service, but it never really > >gained enough momentum. The code of Enginio module remains in the Qt > >repositories, in case it is later seen useful for further use. > > > > > > >Qt is actively used with many different cloud services already. Perhaps > >with somewhat more effort than was needed to use engin.io. “Cloud > >compatibility” is very relevant for Qt and with the effort saved from > >developing > > > and maintaining Enginio module, we should be able to improve in that area > > even further. > > > > > > > > > > >Yours, > > > > > > > > Tuukka > > > > > > _______________________________________________ > Releasing mailing list > Releasing at qt-project.org > http://lists.qt-project.org/mailman/listinfo/releasing From tuukka.turunen at theqtcompany.com Wed Jan 27 23:04:57 2016 From: tuukka.turunen at theqtcompany.com (Turunen Tuukka) Date: Wed, 27 Jan 2016 22:04:57 +0000 Subject: [Releasing] Removal of engin.io from Qt 5.7 In-Reply-To: <2187953.64LKhBFC9W@42> References: <2187953.64LKhBFC9W@42> Message-ID: > -----Original Message----- > From: Nowacki Jedrzej > Sent: keskiviikkona 27. tammikuuta 2016 17.41 > To: releasing at qt-project.org > Cc: Knoll Lars ; Turunen Tuukka > > Subject: Re: [Releasing] Removal of engin.io from Qt 5.7 > > What is the idea for Qt5.6 which is LTS? Does it make sense to include > QtEnginio there? > As decided earlier it is included in the Qt 5.6.0 packages, but marked as deprecated. As such, it is not subject to the LTS promise. It can be dropped out from some patch release of Qt 5.6.x, if it not longer needed. Yours, Tuukka > Cheers, > Jędrek > > On Tuesday 26 of January 2016 07:45:12 Knoll Lars wrote: > > +1 for removing. It doesn’t make a whole lot of sense to have it > > +without the > > backend :) > > > Cheers, > > Lars > > > > > > > > > > On 26/01/16 08:30, "Releasing on behalf of Turunen Tuukka" > > > tuukka.turunen at theqtcompany.com> wrote: > > > > > > > > > > > >Hi, > > > > > > > > > > > >I would like to propose removal of the engin.io cloud service support > > >module Enginio (http://doc.qt.io/qt-5/enginio-index.html) from Qt 5.7 > > >release packages. It has > > > > > been deprecated since Qt 5.6 and no longer developed further. > > > > > > > > >Also the backend will be shut down most likely during H2/16: > > > > > >http://blog.qt.io/blog/2016/01/26/notification-for-all-qt-cloud-servi > > >ces-us > > >ers > > > > >ices-> >users/> > > > > > > > > > > >There are many good things in the engin.io service, but it never > > >really gained enough momentum. The code of Enginio module remains in > > >the Qt repositories, in case it is later seen useful for further use. > > > > > > > > > > >Qt is actively used with many different cloud services already. > > >Perhaps with somewhat more effort than was needed to use engin.io. > > >“Cloud compatibility” is very relevant for Qt and with the effort > > >saved from developing > > > > > and maintaining Enginio module, we should be able to improve in that > > > area even further. > > > > > > > > > > > > > > > > >Yours, > > > > > > > > > > > > Tuukka > > > > > > > > > > _______________________________________________ > > Releasing mailing list > > Releasing at qt-project.org > > http://lists.qt-project.org/mailman/listinfo/releasing From oswald.buddenhagen at theqtcompany.com Thu Jan 28 12:17:44 2016 From: oswald.buddenhagen at theqtcompany.com (Oswald Buddenhagen) Date: Thu, 28 Jan 2016 12:17:44 +0100 Subject: [Releasing] Removal of engin.io from Qt 5.7 In-Reply-To: References: <2187953.64LKhBFC9W@42> Message-ID: <20160128111744.GA13616@troll08.it.local> On Wed, Jan 27, 2016 at 10:04:57PM +0000, Turunen Tuukka wrote: > From: Nowacki Jedrzej > > What is the idea for Qt5.6 which is LTS? Does it make sense to include > > QtEnginio there? > > > > As decided earlier it is included in the Qt 5.6.0 packages, but marked > as deprecated. As such, it is not subject to the LTS promise. It can > be dropped out from some patch release of Qt 5.6.x, if it not longer > needed. > i'd approach this differently: we already concluded that we cannot *really* remove any modules (specifically, webkit and quick1 so far) before qt6, as "just use the old versions if you still need them" has already proven to be spectacularly unworkable. the consequence is that these modules will be still available in the installer, but only as sources and with a big fat warning (or something). with that in mind, it may be reasonable to "remove" enginio right away as well, given that discouraging people from using it is acutely urgent. From Simon.Hausmann at theqtcompany.com Fri Jan 29 09:01:36 2016 From: Simon.Hausmann at theqtcompany.com (Hausmann Simon) Date: Fri, 29 Jan 2016 08:01:36 +0000 Subject: [Releasing] Removal of engin.io from Qt 5.7 In-Reply-To: <20160128111744.GA13616@troll08.it.local> References: <2187953.64LKhBFC9W@42> , <20160128111744.GA13616@troll08.it.local> Message-ID: Hi, Just to clarify: What Ossi is proposing is - starting with Qt 5.6.0 - to stop including qtenginio in the binary packages. In contrast to that Tuukka's proposal is to include the binaries in Qt 5.6.0 but _stop_ including them in subsequent 5.6.x releases. Which way should we go? Simon P.S.: I'm in favor of Ossi's suggestion. ________________________________________ From: Releasing on behalf of Oswald Buddenhagen Sent: Thursday, January 28, 2016 12:17 To: Turunen Tuukka Cc: releasing at qt-project.org Subject: Re: [Releasing] Removal of engin.io from Qt 5.7 On Wed, Jan 27, 2016 at 10:04:57PM +0000, Turunen Tuukka wrote: > From: Nowacki Jedrzej > > What is the idea for Qt5.6 which is LTS? Does it make sense to include > > QtEnginio there? > > > > As decided earlier it is included in the Qt 5.6.0 packages, but marked > as deprecated. As such, it is not subject to the LTS promise. It can > be dropped out from some patch release of Qt 5.6.x, if it not longer > needed. > i'd approach this differently: we already concluded that we cannot *really* remove any modules (specifically, webkit and quick1 so far) before qt6, as "just use the old versions if you still need them" has already proven to be spectacularly unworkable. the consequence is that these modules will be still available in the installer, but only as sources and with a big fat warning (or something). with that in mind, it may be reasonable to "remove" enginio right away as well, given that discouraging people from using it is acutely urgent. _______________________________________________ Releasing mailing list Releasing at qt-project.org http://lists.qt-project.org/mailman/listinfo/releasing From Lars.Knoll at theqtcompany.com Fri Jan 29 11:49:18 2016 From: Lars.Knoll at theqtcompany.com (Knoll Lars) Date: Fri, 29 Jan 2016 10:49:18 +0000 Subject: [Releasing] Removal of engin.io from Qt 5.7 In-Reply-To: References: <2187953.64LKhBFC9W@42> <20160128111744.GA13616@troll08.it.local> Message-ID: <645F1A8F-F338-4B6C-9DB5-FDD444A3B8A5@theqtcompany.com> Agree that it would make most sense to remove the binaries already from 5.6.0. That’s a better and clearer message than removing them in a patch level release. Cheers, Lars On 29/01/16 09:01, "Releasing on behalf of Hausmann Simon" wrote: >Hi, > >Just to clarify: > >What Ossi is proposing is - starting with Qt 5.6.0 - to stop including qtenginio in the binary packages. > >In contrast to that Tuukka's proposal is to include the binaries in Qt 5.6.0 but _stop_ including them in subsequent 5.6.x releases. > > >Which way should we go? > > >Simon > >P.S.: I'm in favor of Ossi's suggestion. > >________________________________________ >From: Releasing on behalf of Oswald Buddenhagen >Sent: Thursday, January 28, 2016 12:17 >To: Turunen Tuukka >Cc: releasing at qt-project.org >Subject: Re: [Releasing] Removal of engin.io from Qt 5.7 > >On Wed, Jan 27, 2016 at 10:04:57PM +0000, Turunen Tuukka wrote: >> From: Nowacki Jedrzej >> > What is the idea for Qt5.6 which is LTS? Does it make sense to include >> > QtEnginio there? >> > >> >> As decided earlier it is included in the Qt 5.6.0 packages, but marked >> as deprecated. As such, it is not subject to the LTS promise. It can >> be dropped out from some patch release of Qt 5.6.x, if it not longer >> needed. >> >i'd approach this differently: >we already concluded that we cannot *really* remove any modules >(specifically, webkit and quick1 so far) before qt6, as "just use the >old versions if you still need them" has already proven to be >spectacularly unworkable. the consequence is that these modules will be >still available in the installer, but only as sources and with a big fat >warning (or something). >with that in mind, it may be reasonable to "remove" enginio right away >as well, given that discouraging people from using it is acutely urgent. >_______________________________________________ >Releasing mailing list >Releasing at qt-project.org >http://lists.qt-project.org/mailman/listinfo/releasing >_______________________________________________ >Releasing mailing list >Releasing at qt-project.org >http://lists.qt-project.org/mailman/listinfo/releasing From tuukka.turunen at theqtcompany.com Fri Jan 29 13:38:52 2016 From: tuukka.turunen at theqtcompany.com (Turunen Tuukka) Date: Fri, 29 Jan 2016 12:38:52 +0000 Subject: [Releasing] Removal of engin.io from Qt 5.7 In-Reply-To: <645F1A8F-F338-4B6C-9DB5-FDD444A3B8A5@theqtcompany.com> References: <2187953.64LKhBFC9W@42> <20160128111744.GA13616@troll08.it.local> <645F1A8F-F338-4B6C-9DB5-FDD444A3B8A5@theqtcompany.com> Message-ID: > -----Original Message----- > From: Knoll Lars > Sent: perjantaina 29. tammikuuta 2016 12.49 > To: Hausmann Simon ; > Buddenhagen Oswald ; > Turunen Tuukka > Cc: releasing at qt-project.org > Subject: Re: [Releasing] Removal of engin.io from Qt 5.7 > > Agree that it would make most sense to remove the binaries already from > 5.6.0. That’s a better and clearer message than removing them in a patch > level release. That is fine for me as well. -- Tuukka > > Cheers, > Lars > > > > On 29/01/16 09:01, "Releasing on behalf of Hausmann Simon" bounces at qt-project.org on behalf of > Simon.Hausmann at theqtcompany.com> wrote: > > >Hi, > > > >Just to clarify: > > > >What Ossi is proposing is - starting with Qt 5.6.0 - to stop including qtenginio > in the binary packages. > > > >In contrast to that Tuukka's proposal is to include the binaries in Qt 5.6.0 but > _stop_ including them in subsequent 5.6.x releases. > > > > > >Which way should we go? > > > > > >Simon > > > >P.S.: I'm in favor of Ossi's suggestion. > > > >________________________________________ > >From: Releasing on behalf of Oswald > >Buddenhagen > >Sent: Thursday, January 28, 2016 12:17 > >To: Turunen Tuukka > >Cc: releasing at qt-project.org > >Subject: Re: [Releasing] Removal of engin.io from Qt 5.7 > > > >On Wed, Jan 27, 2016 at 10:04:57PM +0000, Turunen Tuukka wrote: > >> From: Nowacki Jedrzej > >> > What is the idea for Qt5.6 which is LTS? Does it make sense to > >> > include QtEnginio there? > >> > > >> > >> As decided earlier it is included in the Qt 5.6.0 packages, but > >> marked as deprecated. As such, it is not subject to the LTS promise. > >> It can be dropped out from some patch release of Qt 5.6.x, if it not > >> longer needed. > >> > >i'd approach this differently: > >we already concluded that we cannot *really* remove any modules > >(specifically, webkit and quick1 so far) before qt6, as "just use the > >old versions if you still need them" has already proven to be > >spectacularly unworkable. the consequence is that these modules will be > >still available in the installer, but only as sources and with a big > >fat warning (or something). > >with that in mind, it may be reasonable to "remove" enginio right away > >as well, given that discouraging people from using it is acutely urgent. > >_______________________________________________ > >Releasing mailing list > >Releasing at qt-project.org > >http://lists.qt-project.org/mailman/listinfo/releasing > >_______________________________________________ > >Releasing mailing list > >Releasing at qt-project.org > >http://lists.qt-project.org/mailman/listinfo/releasing From Lars.Knoll at theqtcompany.com Sun Jan 31 20:52:42 2016 From: Lars.Knoll at theqtcompany.com (Knoll Lars) Date: Sun, 31 Jan 2016 19:52:42 +0000 Subject: [Releasing] Removal of engin.io from Qt 5.7 In-Reply-To: References: <2187953.64LKhBFC9W@42> <20160128111744.GA13616@troll08.it.local> <645F1A8F-F338-4B6C-9DB5-FDD444A3B8A5@theqtcompany.com> Message-ID: On 29/01/16 13:38, "Turunen Tuukka" wrote: > > >> -----Original Message----- >> From: Knoll Lars >> Sent: perjantaina 29. tammikuuta 2016 12.49 >> To: Hausmann Simon ; >> Buddenhagen Oswald ; >> Turunen Tuukka >> Cc: releasing at qt-project.org >> Subject: Re: [Releasing] Removal of engin.io from Qt 5.7 >> >> Agree that it would make most sense to remove the binaries already from >> 5.6.0. That’s a better and clearer message than removing them in a patch >> level release. > >That is fine for me as well. Sounds like there's agreement here. Let's do this then :) Cheers, Lars > >-- >Tuukka > >> >> Cheers, >> Lars >> >> >> >> On 29/01/16 09:01, "Releasing on behalf of Hausmann Simon" > bounces at qt-project.org on behalf of >> Simon.Hausmann at theqtcompany.com> wrote: >> >> >Hi, >> > >> >Just to clarify: >> > >> >What Ossi is proposing is - starting with Qt 5.6.0 - to stop including qtenginio >> in the binary packages. >> > >> >In contrast to that Tuukka's proposal is to include the binaries in Qt 5.6.0 but >> _stop_ including them in subsequent 5.6.x releases. >> > >> > >> >Which way should we go? >> > >> > >> >Simon >> > >> >P.S.: I'm in favor of Ossi's suggestion. >> > >> >________________________________________ >> >From: Releasing on behalf of Oswald >> >Buddenhagen >> >Sent: Thursday, January 28, 2016 12:17 >> >To: Turunen Tuukka >> >Cc: releasing at qt-project.org >> >Subject: Re: [Releasing] Removal of engin.io from Qt 5.7 >> > >> >On Wed, Jan 27, 2016 at 10:04:57PM +0000, Turunen Tuukka wrote: >> >> From: Nowacki Jedrzej >> >> > What is the idea for Qt5.6 which is LTS? Does it make sense to >> >> > include QtEnginio there? >> >> > >> >> >> >> As decided earlier it is included in the Qt 5.6.0 packages, but >> >> marked as deprecated. As such, it is not subject to the LTS promise. >> >> It can be dropped out from some patch release of Qt 5.6.x, if it not >> >> longer needed. >> >> >> >i'd approach this differently: >> >we already concluded that we cannot *really* remove any modules >> >(specifically, webkit and quick1 so far) before qt6, as "just use the >> >old versions if you still need them" has already proven to be >> >spectacularly unworkable. the consequence is that these modules will be >> >still available in the installer, but only as sources and with a big >> >fat warning (or something). >> >with that in mind, it may be reasonable to "remove" enginio right away >> >as well, given that discouraging people from using it is acutely urgent. >> >_______________________________________________ >> >Releasing mailing list >> >Releasing at qt-project.org >> >http://lists.qt-project.org/mailman/listinfo/releasing >> >_______________________________________________ >> >Releasing mailing list >> >Releasing at qt-project.org >> >http://lists.qt-project.org/mailman/listinfo/releasing