[Releasing] Meeting minutes: Qt release team meeting 14.01.2014
Jani.Heikkinen at digia.com
Thu Jan 16 09:02:21 CET 2014
Meeting minutes from Qt release team meeting 14.01.2014:
- Plan is to do Qt 5.2.1 at the end of January \ early February.
o Merge from stable to release was done yesterday
o Plan is to do the release candidate immediately when rest of issues from https://bugreports.qt-project.org/browse/QTBUG-35562 is fixed. Currently it seems we could get fixes for remaining issues during this week -> we could have rc out during next week if there isn't any surprises.
- plan for Qt 5.3 is:
o 14.2.2014 Feature Freeze
o 20.2.2014 Alpha Release
o 13.3.2014 Beta Release
o 10.4.2014 Release Candidate
o 29.4.2014 Final Release
- It is possible that Qt3D cannot reach feature stability by feature freeze
o Qt3D as Tech Preview in 5.3?
o AP ZapB: Keep release team updated every week about the situation of Qt3D
- Qt 5.3 tools & versions:
o MinGW upgrade to latest 4.8.2 mingw-builds
o ICU 52-1 to be taken into use
§ Kai promised to pre-build the icu libs for windows targets.
o MSVC updates will be taken as usual, for msvc2010, msvc2012
o Windows installers provided with Qt 5.3
§ MinGW 4.8.2 (32bit)
§ MSVC2010 32bit OpenGL
§ MSVC2012 32bit OpenGL
§ MSVC2013 32bit OpenGL
§ MSVC2013 32bit Angle
§ MSVC2013 64bit OpenGL
§ MSVC2013 64bit Angle
- Plan is to release Qt 4.8.6 during February
o First trial builds from packaging point of view with 4.8.6 done
o mingw-4.8.2 to be taken in the use
§ If possible there should be mignw-4.8.2 and a 4.4 based packages for Qt 4.8.6 just because we usually don't drop toolchains in a patch level release
- Next meeting 27.1.2014 16:00 CET
Irc log below:
[17:00:47] <jaheikki3_> akseli: iieklund: kkoehne: sahumada: thiago: fkleint: ZapB: tronical: wolfgang-b: vladimirM: aholza: peter-h: mapaaso: ankokko ping
[17:00:59] <iieklund_> jaheikki3: pong
[17:01:04] <thiago> jaheikki3_: pong
[17:01:17] <carewolf> pong
[17:01:32] <akseli> jaheikki3_: pong
[17:01:38] <kkoehne> jaheikki3_: pong
[17:01:38] <peter-h> jaheikki3_: pong
[17:01:42] <mapaaso> jaheikki3: pong
[17:01:51] <ZapB> jaheikki3_: pong
[17:02:17] <jaheikki3_> Time to start Qt release team meeting
[17:02:27] <jaheikki3_> On agenda today
[17:02:27] <jaheikki3_> - Qt 5.2.1 schedule
[17:02:27] <jaheikki3_> - Qt 5.3 schedule
[17:02:27] <jaheikki3_> - Qt 5.3 tools & versions
[17:02:43] <jaheikki3_> any additional items to the agenda?
[17:02:48] <ankokko_> jaheikki3_: pong
[17:02:48] <fkleint> jaheikki3: pong
[17:02:51] <thiago> 4.8.6 schedule
[17:02:56] <vladimirM> jaheikki3: pong
[17:03:36] <vladimirM> are there any news about the 5.3 scope?
[17:04:12] <jaheikki3_> thiago: Ok, let's take it in as well. Akseli, prepare yourself to give an overview...
[17:04:36] <akseli> jaheikki3_: sure
[17:06:17] <jaheikki3_> Ok, let's start from qt 5.2.1 schedule and discuss qt5.3 etc after that
[17:06:32] <jaheikki3_> As agreed in previous release team meeting plan is to do at the end of January \ early February.
[17:06:41] <jaheikki3_> Merge from stable to release was done yesterday
[17:06:56] <jaheikki3_> Plan is to start producing snapshots from release branch as soon as possible & do the release candidate immediately when rest of issues from https://bugreports.qt-project.org/browse/QTBUG-35562 is fixed
[17:07:32] <jaheikki3_> iieklund: Anu update about snapshots?
[17:08:06] <iieklund_> jaheikki3_: we should have snapshots available tomorrow or day after that
[17:09:49] <jaheikki3_> ok, great. And at the moment it seems we could get fixes for remaining issues during this week -> we could have rc out during next week if there isn't any suprises
[17:10:02] <jaheikki3_> any questions / comments?
[17:10:29] <vladimirM> yes. we are working to find the root cause for https://bugreports.qt-project.org/browse/QTBUG-35912
[17:11:01] <carewolf> do we normally have rc's for point releases?
[17:11:07] <vladimirM> This issue was the reason for not releasing a Qt5.2 binary overlay as a planned last year
[17:11:42] <vladimirM> we would like to include a fix for this in 5.2.1
[17:12:52] <jaheikki3_> carewolf: In my opinion yes?
[17:13:23] <jaheikki3_> vladimirM: Any estimation when you could have a fix? Issue seems to be p2...
[17:13:35] <thiago> we don't have public RCs
[17:13:44] <thiago> we do create them and smoke test
[17:14:31] <jaheikki3_> thiago: yes, that was a plan...
[17:15:52] <thiago> just answering carewolf's question
[17:16:45] <carewolf> thanks
[17:17:01] <vladimirM> jaheikki3_: no estimation yet. we are working on it...
[17:18:19] <jaheikki3_> OK, but let's target to fix remaining issues as soon as possible and then produce the rc packages for testing. Hoping QTBUG-35912 could be fixed soon as well to get fix in. But because it is P2 I wouldn't like to delay the release because of it...
[17:20:53] <jaheikki3_> I think this is enough about 5.2.1. Let's move to Qt 5.3
[17:20:57] <vladimirM> ok
[17:21:25] <jaheikki3_> As Lars already informed, plan for Qt 5.3 is:
[17:21:35] <jaheikki3_> 14.2.2014 Feature Freeze
[17:21:35] <jaheikki3_> 20.2.2014 Alpha Release
[17:21:35] <jaheikki3_> 13.3.2014 Beta Release
[17:21:35] <jaheikki3_> 10.4.2014 Release Candidate
[17:21:35] <jaheikki3_> 29.4.2014 Final Release
[17:22:13] <jaheikki3_> Lars wrote also: I'd like 5.3 to be less feature oriented then 5.2 has been, and more focused on stability and performance. So that is the scope then...
[17:22:56] <jaheikki3_> Any comments?
[17:23:23] <fkleint> hehe, making the feature freeze so short notice certainly helps reducing feature inflow, not sure aboiut stability & performance, though...
[17:23:25] <ZapB> I don't think we can reach feature stability for Qt3D by then so we'll hav eto do Qt3D as Tech Preview in 5.3
[17:23:58] <ZapB> We're working hard on it but that looks too tight
[17:25:09] <jaheikki3_> Yes, scedule is tight but the goal is to finally get in to April-October release syckle.
[17:25:25] -*- thiago only hopes to get all the stuff he's already made integrated in time for 5.3
[17:25:32] <thiago> but the schedule looks good
[17:25:33] <vladimirM> IMHO, due to a very short time-span till feature freeze, it makes even more sense to collect infos in advance which features are candidates for 5.3
[17:25:36] <ZapB> sure, I understand. Just stating the effect of that on Qt3D status
[17:26:06] <lars> ZapB: we can have somewhat different freeze schedules for add-ons if required, but it would be good to understand where you are.
[17:26:28] <jaheikki3_> ZapB: Yes, I understood that. Thanks for update.
[17:27:20] <ZapB> lars: design is done we think and are busy implementing renderer to test the design out.We'll start merging to upstream very soon now
[17:27:35] <thiago> ZapB: keep us updated every week then
[17:27:43] <ZapB> ack
[17:27:48] <lars> ZapB: that would be great. Pasi is available to help, but he can't do anything as long as stuff is not visible somewhere
[17:28:08] <ZapB> lars: The stuff pasi is looking at is in QtGui
[17:28:15] <lars> ZapB: we could also maybe get another person to help.
[17:28:27] <ZapB> great!
[17:28:39] <ZapB> I'll also start documenting what we have for the design
[17:29:07] <lars> ZapB: sounds good.
[17:30:18] <jaheikki3_> Ok, let's try to get all things ready with that schedule. And try to keep the feature freeze. That helps us then in final steps....
[17:31:19] <lars> thiago: I can have a look at your pending patches on thursday (I'm travelling today and tomorrow)
[17:31:47] <thiago> lars: the problem will be getting them re-reviewed once the CI system eventually finds something
[17:32:00] <lars> hehe... ok, I'll try to help
[17:32:07] <thiago> thanks
[17:32:14] <jaheikki3_> Then Qt 5.3 tools & Versions: Is there already now some updates etc known which needs to be done for 5.3?
[17:32:17] <thiago> even one +1 is enough, because then I can use the maintainer privileges
[17:32:43] <peter-h> jaheikki3_: it would be good to have the new network test server image deployed before the feature freeze, because I need it for a feature (SPDY)...
[17:33:10] <peter-h> IIUC Tony is watchting the test results with the new images already...
[17:33:56] <iieklund_> about tools etc. mingw update was on the table already for 5.2 but newer version was not taken due to some issues with it, kkoehne?
[17:34:04] <lars> thiago: just add me to the stuff you need reviews for. seems like I'm not on all the patches you need to have reviewed
[17:34:22] <kkoehne> iieklund_: well
[17:35:06] <jaheikki3_> peter-h: OK, I know that is in the backlog but will it be ready early enough, I am not sure...
[17:35:21] <kkoehne> iieklund_: Right now we ship with Mingw-builds gcc 4.8.0. I'd love to update to 4.8.2 (latest), but that's BC incompatible.
[17:35:54] <kkoehne> iieklund_: Which would put us in the situation that we'd have two "MinGW 4.8" toolchains e.g. in the online installer.
[17:36:01] <kkoehne> iieklund_: Which looks ugly :)
[17:36:13] <kkoehne> iieklund_: There's no smoking gun reason to upgrade, though.
[17:36:19] <fkleint> who cares aboout BC + MingGW?
[17:36:23] <carewolf> kkoehne: we can not remove the 4.8 version? do we need it?
[17:36:32] <kkoehne> fkleint: we do, since we'd have to ship two toolchains in the online installer.
[17:36:36] <carewolf> we can say it is supported, but we don't ship it
[17:36:36] <peter-h> jaheikki3_: ok, I will discuss with Tony, it would be good to get it deployed anyhow because of hopefully improved stability...
[17:36:57] <jaheikki3_> peter-h: I agree...
[17:37:03] <kkoehne> I had hopes for gcc 4.9 being ready in time ...
[17:37:05] <thiago> kkoehne: what BC break did they do this time?
[17:37:17] <fkleint> hm
[17:37:30] <thiago> let's not bank on 4.9 yet because we wouldn't have enough time to test anyway
[17:37:36] <kkoehne> thiago: It's still the same like last time :) Can't remember the exact name of the exported symbol right now ...
[17:37:49] <thiago> but I do recommend we start choosing one mingw version per year
[17:37:57] <thiago> so this would be the 2014 release
[17:38:18] <kkoehne> thiago: binding it to a calendar year is a bit artifical.
[17:38:20] <thiago> the question is: are they fixing it for a new release? Or is it staying as-is?
[17:38:47] <kkoehne> thiago: they've now managed to publish an official 3.0 version of their headers.
[17:38:59] <thiago> but there's no release containing them?
[17:39:04] <kkoehne> thiago: There is.
[17:39:19] <kkoehne> thiago: It's just not bc compatible with the mingw version we're right now shipping .
[17:39:33] <thiago> I understand
[17:39:45] <thiago> I'm asking, going forward, what will happen?
[17:40:01] <kkoehne> thiago: Well, it seems things have now stabilized.
[17:40:06] <thiago> if they intend on making further releases that are BIC to what we have right now, we'll have to bite the bullet sometime
[17:40:14] <thiago> might as well do it sooner rather than later
[17:41:00] <kkoehne> thiago: Alright. So I'm proposing to upgrade to latest 4.8.2 mingw-builds release then.
[17:41:05] <thiago> +1
[17:41:09] <fkleint> +1
[17:41:13] <iieklund_> then we'd need to provide two MinGW toolchains in the online installer
[17:41:42] <jaheikki3_> iieklund_: is that a problem?
[17:41:45] <kkoehne> iieklund_: Yeah. And at least one of them calls themself 'MinGW 4.8', which is ugly. But well.
[17:41:58] <iieklund_> no, not a problem
[17:42:30] <iieklund_> ok, so we'll update to latest one available
[17:42:51] <iieklund_> next, icu version
[17:42:53] <kkoehne> I'll create new ICU binary packages etc.
[17:42:58] <iieklund_> great
[17:43:07] <kkoehne> Latest ICU is 52-1 AFAIK. And I think we should upgrade.
[17:43:33] <kkoehne> (Currently we're on 51-2)
[17:43:46] <kkoehne> I'm using 52-1 since half a year locally, no problems so far.
[17:43:56] <iieklund_> MSVC updates will be taken as usual, for msvc2010, msvc2012
[17:44:32] <kkoehne> iieklund_: I can build binaries for these. Or do we have scripted that already?
[17:44:44] <iieklund_> kkoehne: not scripted yet
[17:45:03] <thiago> which ICU version matches the Unicode and CLDR that we've just imported into 5.3?
[17:45:07] <iieklund_> msvc2013
[17:46:00] -*- kkoehne doesn't know
[17:47:33] <iieklund_> I believe msvc2013 packages should be provided as well
[17:47:36] <jaheikki3_> Yes, we need to start offering binaries to msvc2013
[17:47:49] <kkoehne> well, I don't have that compiler. fkleint?
[17:47:50] <iieklund_> both angle and opengl I assume
[17:48:25] <thiago> time to drop 2010 packages then?
[17:48:48] <iieklund_> good question, depends on the usage/demand?
[17:49:08] <jaheikki3_> But we cannot increase amount of installers so much so we need to drop some older ones. It has been discussed that we should offer all 4 different installers for 2013 (32, 64 bit openGL & angle)
[17:49:33] <jaheikki3_> Then one 32 bit openGL for 2012 & 2010.
[17:50:00] <jaheikki3_> According to our understanding that setup should cover most of needs
[17:50:16] <thiago> 6 binaries?
[17:50:35] <fkleint> VS2010 is still recommended on Win7, etc
[17:50:41] <thiago> by whom?
[17:50:46] <jaheikki3_> thiago: Yes
[17:50:50] <fkleint> by us ;-)
[17:51:09] <kkoehne> 2010 is AFAIK the last version where you can target XP ...
[17:51:10] <fkleint> There is some crap going on when deploying VS2012 built stuff onto WIn7
[17:51:47] <thiago> ok, 6 sounds about limit
[17:52:00] <kkoehne> fkleint: Reference? Sounds like a serious gotcha ...
[17:52:22] <fkleint> needs investigation still..
[17:52:57] <fkleint> Windows XP can be targeted by VS2012 as well...what do we have, then?
[17:53:49] <jaheikki3_> thiago: agree. And that could be a kind of rule in the future as well: We will offer all 4 versions for latest msvc compiler + 1-2 installer for older ones
[17:53:54] <kkoehne> fkleint: Welll... it can target XP with some hacks. http://blogs.msdn.com/b/vcblog/archive/2012/10/08/10357555.aspx
[17:54:05] <kkoehne> fkleint: I doubt that our vs2012 binaries run on XP.
[17:54:21] <fkleint> preferably OpenGL,well ok,. let's try if that causes protest
[17:54:31] <kkoehne> fkleint: It will. Whatever we choose :)
[17:54:32] <fkleint> our's don;t , but you can set up special env
[17:54:37] <thiago> I think VS2012 targets SSE2 by default
[17:54:45] <thiago> which is part of the reason why it won't run on XP
[17:54:56] <thiago> you need to pass an extra option to the compiler to get non-SSE2 code
[17:55:23] <fkleint> yep, this MSDN article explains how to do this
[17:55:24] <fkleint> anyways
[17:55:41] <fkleint> So, MSVS2013 4, the rest OpenGL 2012/2010?
[17:55:45] <iieklund_> is there a need for 64bit MinGW packages?
[17:55:50] <kkoehne> jaheikki3_: So let's keep 2010 packages for 5.2 , and drop it for 5.3 :)
[17:56:01] <kkoehne> jaheikki3_: erm , 5.3, 5.4 :)
[17:56:06] <fkleint> hehe
[17:56:10] <jaheikki3_> ;)
[17:56:17] <jaheikki3_> Ok for me...
[17:56:25] <kkoehne> iieklund_: We regularly get requests for it. BUt mingw-buidls offers binary packages for 64 bit already ...
[17:56:53] <kkoehne> iieklund_: So I'd count it as 'nice to have'.
[17:57:00] <jaheikki3_> +1
[17:57:07] <thiago> let's just make sure we link to alexei's page quite proeminently
[17:57:14] <iieklund_> kkoehne: hmm, ok
[17:57:58] <jaheikki3_> OK, is tools etc now clear enough? iieklund_^
[17:58:11] <iieklund_> jaheikki3_: quite clear
[17:58:21] <iieklund_> you can proceed
[17:58:38] <jaheikki3_> OK, then 4.8.6. akseli^
[17:59:13] <akseli> First trial builds from packaging point of view with 4.8.6 done
[17:59:37] <thiago> success? :-)
[17:59:52] <akseli> linux, mac & some windows packages done successfully but not all yet
[18:00:12] <akseli> anyway, hopefully able to provide snapshot (not RC) during this week
[18:01:04] <akseli> if all goes well and no major issues found then hopefully able to release during February
[18:01:16] <kkoehne> akseli: We should really aim for a Mingw-builds 4.8.0 based binary, too.
[18:01:26] <kkoehne> akseli: make that 4.8.2 :)
[18:02:28] <akseli> so using same mingw version than 5.2.1 then .. does anyone need mingw44 build anymore?
[18:02:47] <fkleint> I sincerely hope not
[18:02:51] <fkleint> that is so outdated
[18:03:19] <thiago> just don't delete the package from the servers
[18:03:28] <thiago> but a new mingw is defintely helpful
[18:03:29] <kkoehne> thiago: which package?
[18:03:33] <thiago> the mingw44 package
[18:04:45] <kkoehne> If possible I'd like to have a mignw-4.8.2 based package and a 4.4 based for Qt 4.8.2 . Just because we usually don't drop toolchains in a patch level release ...
[18:04:55] <kkoehne> But only if that's not too much work.
[18:06:19] <akseli> kkoehne: you mean 4.4 based for Qt 4.8.6? :)
[18:06:30] <kkoehne> akseli: Argh. Yes :)
[18:06:36] <kkoehne> It's too late for me, apparently.
[18:06:42] <jaheikki3_> ;)
[18:07:07] <akseli> lets try and see how things go:) we might not have mingw-4.8.2 binaries available on first snapshots anyway.
[18:07:55] <jaheikki3_> OK, is there anything else than next meeting then?
[18:08:32] <fkleint> jaheikki3_: Can you unlock the stable branches. then?
[18:08:40] <fkleint> jaheikki3_: will there be a 5.2.2?
[18:09:16] <jaheikki3_> fkleint: 5.3 is coming so soon that I am really hoping we wouldn't need 5.2.2
[18:09:44] <fkleint> hm, ok
[18:09:51] <fkleint> famous last words
[18:09:54] <fkleint> ;-)
[18:09:57] <jaheikki3_> fkleint: But yes, stable can be unlocked. mapaaso: could you handle that?
[18:10:56] <mapaaso> jaheikki3_: ossi promised to unlock it tomorrow, or day after.
[18:11:15] <jaheikki3_> ok, great.
[18:12:22] <jaheikki3_> I think we don't need meeting on next monday so I propose next meeting 27.01.2014.
[18:12:51] <jaheikki3_> at this same time
[18:13:01] <ZapB> ok
[18:14:40] <jaheikki3_> Ok, let's end this meeting now and meet again 27.1.2014 16:00 CET
[18:14:55] <jaheikki3_> Thanks for everyone! Bye.
[18:15:06] <wolfgang-b> bye
[18:15:08] <akseli> bye
[18:15:11] <ZapB> bye
[18:15:14] <ankokko__> bye
[18:15:15] <peter-h> bye
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Releasing