[Releasing] Meeting minutes: Qt 5.0.2 release team meeting 05.03.2013

[Salovaara Akseli]

Hi,

Qt 5.0.1 release team has continued work as Qt 5.0.2 release team with few additional members. Release team for Qt 5.0.2 at the moment: Ahumada Sergio, Eklund Iikka, Harmer Sean, Hausmann Simon, Kleint Friedemann, Koehne Kai, Macieira Thiago, Motyka Rafal, Salovaara Akseli. If someone else is willing to participate to Qt 5.0.2 release team work please send me an email.
There will be separate call for Qt 5.1 release team later.

Meeting minutes from Qt 5.0.2 release team meeting 05.03.2013
- Two new reference installers available  for Qt 5.0.2: MSVC2010 (32bit) OpenGL and MSVC2012 64bit / Win8. Note: OpenGL packages doesn't have Webkit2 support.
- Content of current installer packages (http://releases.qt-project.org/digia/5.0.2/) is not yet up to date as things have been lately blocked in CI.
- Creator 2.7.0 to be included into Qt 5.0.2 packages (decision depends on 2.7 RC release schedule).
- No changes for MinGW tool chain even performance issues have been reported. Possible tool chain changes will be handled on Qt 5.1.
- Possibility for decreasing ICU library size (QTBUG-29828) is investigated but aimed mainly for Qt 5.1.
- Autotests will stay as part of src packages.
- Next meeting: Tuesday 12.03.2013 09:00 CET.

The irc log below.

Br,
Akseli

(9:02:37 AM) akseli: iieklund: kkoehne: ramotyka: tronical: thiago: ZapB: ping
(9:02:43 AM) kkoehne_home: akseli: pong
(9:02:45 AM) iieklund: akseli: pong
(9:02:45 AM) thiago: akseli: pong
(9:02:50 AM) ZapB: akseli: pong
(9:03:07 AM) fkleint [~fkleint at 62.220.2.194] entered the room.
(9:03:43 AM) akseli: Time to start Qt 5.0.2 release meeeting
(9:03:56 AM) akseli: I'm proposing following agenda:
(9:03:56 AM) akseli: Installer status
(9:03:56 AM) akseli: MinGW performance issues & update
(9:03:56 AM) akseli: ICU library size (https://bugreports.qt-project.org/browse/QTBUG-29828)
(9:03:56 AM) akseli: Autotests on src packages (can those be removed)
(9:03:56 AM) akseli: Next meeting
(9:04:08 AM) tronical: akseli: pong
(9:04:17 AM) thiago: ok
(9:04:18 AM) akseli: Any additional items for the agenda?
(9:04:30 AM) kkoehne_home: akseli: qt creator 2.7.0 for 5.0.2?
(9:04:51 AM) akseli: kkoehne_home: good point, noted
(9:05:17 AM) iieklund: ok, I'll start
(9:05:34 AM) iieklund: installers are available in the same place as before
(9:05:47 AM) iieklund: two new reference installers added
(9:05:56 AM) iieklund: msvc2010 (32bit) opengl
(9:06:07 AM) iieklund: and msvc2012 64bit / Win8
(9:06:30 AM) iieklund: the content though is not up to date as things are blocked in ci
(9:06:59 AM) iieklund: but feel free to test the installers, especially the new reference installers
(9:07:23 AM) ***thiago will try one of them if he has the time
(9:07:35 AM) iieklund: and the installers will be uploaded to mirror brain in near future
(9:07:37 AM) fkleint: OPenGL looks good, except that Creator was built against 5.0.1
(9:07:41 AM) ***ZapB will try the msvc2010 opengl one later today
(9:07:42 AM) fkleint: thanks for that
(9:07:48 AM) iieklund: fkleint: yes
(9:08:00 AM) iieklund: kakoehne: did you change the qt version in confs already?
(9:08:10 AM) iieklund: kkoehne_home: ^
(9:08:13 AM) kkoehne_home: iieklund: Yes, next round should be build with 5.0.2
(9:08:18 AM) iieklund: ok, thanks
(9:08:59 AM) iieklund: that's the status briefly.....I will send email to lists when we start uploading packages to mirror brain
(9:09:13 AM) ramotyka: akseli: pong
(9:09:19 AM) kkoehne_home: iieklund: Alright, so we distribute already candidate packages? Nice.
(9:09:28 AM) iieklund: yes
(9:09:44 AM) kkoehne_home: iieklund: But then we should really list the SHAs somewhere.
(9:10:01 AM) iieklund: hmm, or I would say snapshots
(9:10:07 AM) iieklund: maybe not release candidates
(9:10:17 AM) akseli: not release candidates yet, snapshots
(9:10:20 AM) iieklund: http://origin.releases.qt-project.org/digia/5.0.2/
(9:10:40 AM) thiago: they are release candidates, but we don't tag them anymore
(9:10:45 AM) thiago: people didn't like them last time around
(9:11:30 AM) kkoehne_home: akseli, iieklund: Whatever you call em :) Still, how about having an md5sum.txt in http://origin.releases.qt-project.org/digia/5.0.2/latest/ ?
(9:11:59 AM) iieklund: kkoehne_home: good point, I'll check when I'll automate that
(9:12:05 AM) kkoehne_home: akseli, iieklund: Just one command on the server: md5sum *>md5sum.txt
(9:12:10 AM) iieklund: yep :)
(9:12:47 AM) iieklund: next?
(9:12:57 AM) akseli: how about opengl and webkit2? there was some discussion about those earlier... tronical^
(9:13:13 AM) fkleint: Fixed already, I hope ;-)
(9:13:33 AM) kkoehne_home: fkleint: So is there a webkit2 in the opengl packages now?
(9:13:50 AM) fkleint: No, only kidding. but WebKit 1 examples work
(9:14:05 AM) fkleint: Jocezlyn told me it is a bit involved, order of manweeks
(9:14:42 AM) kkoehne_home: Okay, so something IMO for the known issues.
(9:14:44 AM) tronical: agreed with Jocelyn :)
(9:15:12 AM) thiago: so no webkit2 in the opengl package?
(9:15:37 AM) tronical: note: it's not a very hard piece of work to do and it doesn't require webkit knowledge I think. so it could be done by anyone with a particular interest in this configuration ;-)
(9:16:08 AM) fkleint: Urm, if you fix qwizard_win in return ...
(9:16:18 AM) tronical: doesn't require windows knowledge? ;-)
(9:16:45 AM) tronical: I guess I couldn't run away from that ;). anyway, just thought I'd point that out
(9:16:54 AM) fkleint: but, it would be preferable if the WebkIt team did it, I guess
(9:17:08 AM) tronical: naturally this is a question of priorities and it appears to be of higher priority by the desktop gl folks that for the webkit folks :)
(9:17:18 AM) tronical: that=than
(9:17:59 AM) fkleint: yep, could the WebKit folks please adjust the priorities accordingly?
(9:18:27 AM) tronical: well, we argue that there are other things that are more important (that was exactly my point)
(9:18:48 AM) tronical: (ok, I can't speak for the entire team, so the "we" is not a fair word to use)
(9:20:35 AM) fkleint: ok, this would probably have to be discussed in another meeting, but for the ordinary WebKit users priorities would be 1) make OpnGL fly 2) reduce/scrap ICU dependency on Windows 3) reduce overall library size.
(9:20:54 AM) kkoehne_home: Alright, given the schedule of 5.0.2 and the ETA 'of manweeks' it seems unrealistic for 5.0.2 anyway.
(9:21:02 AM) akseli: in case opengl packages won't have webkit1 can we all live with that and release opengl package with Qt 5.0.2 release?
(9:21:20 AM) fkleint: They have WebKit 1, but not WebKit 2
(9:21:21 AM) kkoehne_home: akseli: they have webkit1, just not webkit2
(9:21:34 AM) thiago: what functionality gets suppressed with webkit2 being missing?
(9:21:35 AM) fkleint: I think this is ok, known issue
(9:21:37 AM) akseli: fklkeint: sorry, webkit2
(9:21:39 AM) tronical: thiago: the qml2 integration
(9:22:06 AM) thiago: so it means no webkit in qtquick2?
(9:22:13 AM) tronical: yep
(9:22:28 AM) thiago: that needs to be in the release notes
(9:24:12 AM) akseli: sounds like a decision, opengl & webkit2 status needs to be made clear on release notes when time comes if not fixed.
(9:24:20 AM) ZapB: +1
(9:24:42 AM) akseli: next item: Qt Creator 2.7.0 for Qt 5.0.2
(9:25:55 AM) akseli: both are aimed to be released quite closely .. I guess we should try to synch those releases somehow. any risks from that? kkoehne_home ^
(9:26:26 AM) kkoehne_home: akseli: Talked to eike. RIght now it seems 2.7.0 will be released indeed in two weeks.
(9:26:44 AM) fkleint: Well, one should not delay the other I would say. I am not sure what the status of QBS support is
(9:26:46 AM) kkoehne_home: akseli: It has some improvements for qt 5.0, namely support for the Qt Quick2 Designer
(9:26:58 AM) fkleint: andre is not here...
(9:27:12 AM) kkoehne_home: fkleint: I talked to Eike and Andre, and they're fine with trying.
(9:27:26 AM) kkoehne_home: fkleint: If we don't have an RC this Friday we may still revert the decision.
(9:27:31 AM) fkleint: oki
(9:28:08 AM) kkoehne_home: akseli: So I propose switching to creator 2.7 branch, whith the option to revert if 2.7 RC doesn't make it this Friday.
(9:28:19 AM) iieklund: kkoehne_home: is the qt / toolchain registration "api" the same in 2.7? No need to update qt/toolchain registration in installscripts?
(9:28:27 AM) kkoehne_home: iieklund: No, that should be the same.
(9:28:30 AM) iieklund: ok
(9:28:39 AM) fkleint: [famous last words]
(9:28:41 AM) kkoehne_home: iieklund: The only additional work is getting the qml2puppet packaged & installed
(9:28:49 AM) iieklund: ah, that one
(9:29:07 AM) kkoehne_home: iieklund: I'm looking into this.
(9:29:11 AM) iieklund: ok, thanks
(9:29:38 AM) akseli: sounds like a plan, let's try to have creator 2.7.0 & qt 5.0.2 synchronized and check status for that on e.g. next tuesday
(9:30:07 AM) akseli: next item: MinGW performance issues & update for that?
(9:30:30 AM) akseli: I think this have been discussed to be fixed on Qt 5.1.0 - am I right?
(9:30:35 AM) fkleint: What exactly are the issues?
(9:30:40 AM) kkoehne_home: akseli: That would be my proposal.
(9:31:15 AM) kkoehne_home: fkleint: Turned out that the exception handling model of the current toolchain (SJLJ) has quite some performance impact.
(9:31:27 AM) kkoehne_home: fkleint: E.g. creator startup times are about 20%-25% slower.
(9:31:39 AM) kkoehne_home: fkleint: That's mostly due to QtCore being compiled with exceptions on.
(9:31:54 AM) kkoehne_home: thiago: ^^ Btw, what's the reason for that again?
(9:32:14 AM) fkleint: Hm, first time I hear it
(9:32:29 AM) fkleint: I think we have some try {} catch in destructors/event loops?
(9:32:30 AM) kkoehne_home: fkleint: there's an alternative exception model (dw2), which has issues if you throw exceptions through stacks with e.g. Windows dlls (windows callbacks).
(9:32:42 AM) thiago: SJLJ requires a call to setjmp() in each exception-starting block
(9:32:47 AM) thiago: it's active
(9:33:04 AM) thiago: or was the question why QtCore has exceptions enabled?
(9:33:45 AM) thiago: also, exceptions through windows code is not a problem
(9:34:00 AM) kkoehne_home: thiago: Yes, why it's enabled.
(9:34:02 AM) thiago: exceptions travelling through non-C++ code is unspecified behaviour. We've warned people about that.
(9:34:23 AM) thiago: it's enabled in QtCore because some classes in it are supposed to be exception-safe
(9:34:27 AM) thiago: especially the tool classes
(9:35:00 AM) kkoehne_home: thiago: Okay.
(9:35:55 AM) kkoehne_home: akseli: So to summarize, I'd like to change the toolchain to a dw2 based one for 5.1. I personally think we can live with the current one for 5.0.2, unless someone feels strongly about it.
(9:36:26 AM) thiago: keep the current one for now
(9:36:31 AM) thiago: it's an ABI change, so better warn people
(9:36:47 AM) kkoehne_home: akseli: There's a slight chance that we can even use it also to update the gcc version (depending on when gcc 4.8 is out)
(9:37:28 AM) thiago: gcc 4.8 will probably be out around May
(9:37:35 AM) thiago: too late for 5.1 probably
(9:38:01 AM) akseli: so decision is that mingw toolchain change will be handled on 5.1 and not changed for 5.0.2?
(9:38:06 AM) tronical: thiago: isn't it even worse, that setjmp is called for each function that may require any cleanup (i.e. has objects on the stack and then calls other functions)?
(9:38:14 AM) kkoehne_home: akseli: I think so.
(9:38:15 AM) ZapB: akseli: sounds sensible
(9:38:34 AM) thiago: tronical: yes, any exception block. Not just try {} catch {}.
(9:38:50 AM) tronical: ah, that's what you mean with exception block. right :)
(9:38:50 AM) thiago: any object with a destructor calling a function that may throw requires a call to setjmp.
(9:38:56 AM) thiago: it's horrible.
(9:39:00 AM) tronical: agreed!
(9:39:05 AM) tronical: (iOS is using it, btw - on arm :)
(9:39:11 AM) thiago: ugh!
(9:39:14 AM) thiago: stupid
(9:39:27 AM) tronical: mostly stupid for C++, great for objective C :)
(9:39:41 AM) thiago: anyway
(9:39:50 AM) kkoehne_home: akseli: Next point? :)
(9:39:53 AM) akseli: Next item: ICU library size (e.g. https://bugreports.qt-project.org/browse/QTBUG-29828) ^^
(9:40:09 AM) iieklund: yes
(9:40:27 AM) iieklund: the icudt49 is about 18mb
(9:40:39 AM) iieklund: it should be possible to reduce the size of that
(9:40:41 AM) ZapB: ouch
(9:40:57 AM) thiago: has anyone measured?
(9:41:06 AM) kkoehne_home: thiago: Measured what?
(9:41:11 AM) iieklund: kai have you looked into ICU Data customizer
(9:41:12 AM) iieklund: ?
(9:41:33 AM) kkoehne_home: well, there's http://apps.icu-project.org/datacustom/ , where you can just deselect stuff :)
(9:41:56 AM) iieklund: yes, but what we can deselect :) ?
(9:41:57 AM) kkoehne_home: The hard question is what is actually used by Qt at all, and which one might be used, but is not important.
(9:42:15 AM) thiago: measured if it can be made smaller
(9:42:25 AM) thiago: that's the question: what can we de-select?
(9:42:30 AM) kkoehne_home: My approach would be to try to come up with a profile that matches our Qt 4.x features.
(9:42:35 AM) thiago: timezone data, for example
(9:42:56 AM) kkoehne_home: thiago: Well, there's this 5.1 patch that will make use of some of it?
(9:43:17 AM) thiago: QtCore uses it only for codecs and and collation
(9:43:28 AM) kkoehne_home: I can come up with a proposal based on best measure. But I doubt that we have extensive coverage in autotests.
(9:43:29 AM) thiago: 5.1 will use the timezone data, if john finishes his work
(9:43:40 AM) thiago: the question is: what does webkit need it for?
(9:43:53 AM) kkoehne_home: tronical: ^^ :)
(9:44:19 AM) tronical: thiago: line breaking for example
(9:44:25 AM) tronical: thiago: not calendaring, etc.
(9:44:34 AM) tronical: thiago: generally speaking unicode properties of characters
(9:44:46 AM) kkoehne_home: tronical: So if you go to http://apps.icu-project.org/datacustom/ , which of the top sections do we need at all?
(9:44:47 AM) tronical: collaction, too, I think
(9:45:28 AM) tronical: kkoehne_home: can't say 100%, but I think break iterator, collators and maybe charset mapping tables
(9:46:10 AM) ***tronical quickly double checks collation. but I'm sure about break iterator and charset mapping (codecs)
(9:46:20 AM) tronical: ACK, collaction is also used by webkit
(9:46:52 AM) tronical: what's in misc? :)
(9:47:35 AM) kkoehne_home: tronical: e.g. timezone data, it seems
(9:47:41 AM) thiago: btw, I don't know where u_strToCase is in
(9:47:48 AM) thiago: I assumed it was in collator. You need to verify.
(9:48:06 AM) kkoehne_home: thiago: Okay, will do.
(9:48:18 AM) kkoehne_home: is it safe to assume that we only need the official supported languages?
(9:48:31 AM) thiago: it seems to come from uloc.h
(9:48:34 AM) kkoehne_home: e.g. that we can drop zone/km.res (Kmehr)
(9:48:35 AM) thiago: no
(9:48:38 AM) thiago: we need all languages
(9:49:12 AM) thiago: but we can trim the codec list to the same as the built-in codecs
(9:49:53 AM) kkoehne_home: thiago: well, the currency, language, timezone information in misc is already 6,6MB
(9:50:04 AM) kkoehne_home: thiago: We somehow managed with less in Qt 4 times :)
(9:50:28 AM) thiago: because we used whateve came with the OS
(9:50:59 AM) kkoehne_home: thiago: So we don't have this fallback any more, at all?
(9:51:05 AM) thiago: if webkit didn't need it, I'd suggest turning off the codecs
(9:51:16 AM) thiago: and turn off qicucodec
(9:52:08 AM) thiago: QLocale::to{Upper,Lower} has no fallback: we need the localisation tables
(9:52:13 AM) thiago: QCollator requires the collation tables
(9:52:23 AM) kkoehne_home: thiago: We should clarify with Lars. I thought his intend was to rather get rid of the internal QtCore ones. But I might be wrong.
(9:52:34 AM) thiago: yes, we need to get rid of the internal QtCore wes
(9:52:36 AM) thiago: ones
(9:52:42 AM) thiago: we haven't done that yet, though
(9:53:01 AM) kkoehne_home: thiago: Anyway, it feels stupid to ship the whole world for a small helloworld. Maybe we can come up with two profiles, and let the user decide when he packages his app.
(9:53:02 AM) thiago: the point is that we now have functionality that requires ICU. New functionality that wasn't there before.
(9:53:22 AM) kkoehne_home: thiago: Functionality that a lot of users don't care about, and shouldn't pay for.
(9:53:29 AM) thiago: we could ship a small, stub library too that supports English and basic codecs
(9:53:35 AM) thiago: no other locales, no other codecs
(9:53:54 AM) thiago: make it REALLY basic so no one gets ideas about shipping it in any context where internationalisation is required
(9:54:04 AM) kkoehne_home: thiago: Okay, that sounds actually good.
(9:54:20 AM) kkoehne_home: akseli: I'll actually try it out, and send a proposal to the mailing list.
(9:54:22 AM) ***tronical thought it was always a strength of Qt that i18n worked out of the box
(9:54:32 AM) thiago: note this will affect webkit too: it might not be able to decode webpages in certain codecs
(9:54:34 AM) akseli: kkoehne_home: ok, thank you
(9:54:55 AM) akseli: then next item: Autotests on src packages (can those be removed)
(9:55:04 AM) akseli: Autotests in src packages (can those be removed): we are currently shipping src packages with autotests. is there any reason why those couldn't be removed from src packages?
(9:55:04 AM) thiago: akseli: keep them there
(9:55:12 AM) kkoehne_home: tronical: Right. But would you go to Qt 5 if you don't have immediate benefits, but additional dependencies of about 15 MB , for your small app?
(9:55:12 AM) akseli: ok, why?
(9:55:22 AM) ZapB: can we make this icu customisation tool part of the deployment/internationalisation somehow? i.e. allow people to build their own versin for their needs
(9:55:48 AM) kkoehne_home: ZapB: It's here: http://apps.icu-project.org/datacustom/
(9:56:06 AM) kkoehne_home: ZapB: NOt sure whether there's any benefit of having it in a separate domain, too.
(9:56:18 AM) tronical: kkoehne_home: that's the same argument as to why we decided to go unicode all over the place in Qt and let QFont not have a charset: most developers don't understand the complexity behind supporting more than just the western world. and they shouldn't. it's a strenght of Qt that they don't have to worry about that stuff at all but can cater to users on the entire planet.
(9:56:28 AM) ZapB: kkoehne_home: sure but I mean to be run automagically somehow
(9:57:11 AM) thiago: akseli: people run tests
(9:57:15 AM) thiago: akseli: therefore, keep them in the source
(9:57:35 AM) kkoehne_home: tronical: Sure. But again, some developers don't want to support more than just the western world, or even their own company PC's :)
(9:57:42 AM) kkoehne_home: tronical: Let's give them the choice.
(9:57:55 AM) thiago: kkoehne_home: I'm not talking about "Western World"
(9:57:58 AM) tronical: kkoehne_home: I think that's a very limited viewpoint of our customers
(9:58:02 AM) thiago: kkoehne_home: I'm being serious: make it work for *English*
(9:58:12 AM) thiago: kkoehne_home: let it fail for German too. Then people will not get ideas.
(9:58:21 AM) kkoehne_home: thiago: Okay.
(9:58:32 AM) thiago: kkoehne_home: for example, failing to uppercase "ö" to "Ö"
(9:58:36 AM) tronical: It's Qt's job to make life easier for developers, not to make them have to learn about codecs and complexities of languages
(9:58:50 AM) kkoehne_home: tronical: Maybe, but there's the fact that people complain. A lot.
(9:59:07 AM) thiago: kkoehne_home: QString("köhne").toUpper() == "KöHNE"
(9:59:18 AM) tronical: kkoehne_home: that doesn't make them representative for the entire user base of Qt. what about all the users in say asia that are happy that this works out of the box and are therefore not complaining?
(9:59:24 AM) kkoehne_home: tronical: Fine with me. You might have noticed that I write myself with oe for these reasons :)
(9:59:53 AM) kkoehne_home: tronical: Alright. I'm even fine with using the fully icu by default. let's just ship a stripped down version as a drop-in replacement, too.
(10:00:23 AM) kkoehne_home: tronical, thiago: Let's move this to the mailing list.
(10:00:33 AM) tronical: kkoehne_home: right, opt-in for those who make a conscious _choice_ about limiting themselves to less functionality is good IMHO. making that opt-in easy that is
(10:01:12 AM) kkoehne_home: ZapB: Maging that magically: The real issue isn't the selection website, but compiling your own ICU afterwards.
(10:01:17 AM) tronical: kkoehne_home: so the developer who wants to write that little app can easily switch to a smaller "package" after he noticed that it's too big for his taste :)
(10:01:34 AM) kkoehne_home: tronical: Yes :)
(10:01:53 AM) akseli: ICU topic continues on mailing list then.. lets check status of that on next meeting
(10:02:34 AM) thiago: when do you propose?
(10:02:51 AM) akseli: about autotests in src packages: does all agree that those are needed in src packages and should stay there?
(10:03:12 AM) iieklund: autotests in src packages, was it decided to keep them?
(10:03:14 AM) kkoehne_home: akseli: This is 5.1 material anyway, give me some time :)
(10:03:50 AM) hanne [~linaae at 84.49.38.202] entered the room.
(10:04:22 AM) kkoehne_home: iieklund: I think we always had them. + I guess maybe the .pro files would need adoption if they woulnd't be there.
(10:04:49 AM) iieklund: hmm yes I remember there was some dependency to autotests?
(10:05:06 AM) iieklund: ok, se we keep them then
(10:05:56 AM) akseli: alright, next meeting: proposing to have on next Tuesday 08:00 CET. We should then have installers with content up to date, results from those and also Creator 2.7 RC where to base decisions
(10:06:06 AM) thiago: I cannot join any time next week
(10:06:14 AM) thiago: so feel free to choose an European-friendly time
(10:06:49 AM) ZapB: an hour later would be good for me :)
(10:07:10 AM) kkoehne_home: Both 8:00 and 9:00 CET is fine with me.
(10:07:12 AM) iieklund: 09:00 CET is fine for me
(10:08:17 AM) akseli: 09:00 CET sounds like a plan, i will send invitations later today
(10:08:41 AM) ZapB: akseli: thanks
(10:08:41 AM) akseli: i guess that was all, thank you all for the meeting:)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/releasing/attachments/20130306/6b97cd8a/attachment.html>