[Releasing] Meeting minutes: Qt 5.0.1 release team meeting 21.01.2013

[Salovaara Akseli]

Hi,

Meeting minutes from Qt 5.0.1 Release team meeting:
- An upgrade of the MinGW 4.7.2 toolchain on build machines & CI system from rev 1 to rev8 (posix threading, sjlj exceptions). Focusing effort on 32-bit for now.
- Qt 5.0.1 can have P1 errors open (each requires decision from Release Team).
- New Qt installer on Qt 5.0.1 doesn't block release. MinGW and VS2012 64bit have priority as new installers.
- VS2010 64bit installer dropped from Qt 5.0.1 release.
- Release Team produces release candidate packages, sanity-checks and announces for community.
- If release candidate packages are found appropriate for release by Release Team decision no rebuild is required.
- Release candidate tags to qtsdk.git (5.0.1-rcX). Modules only with final release tag (5.0.1).
- Next release team meeting: Monday 28.01.2013 at 16.00 (CET)-

The irc log below.

Br,
Akseli

(5:03:36 PM) akseli: thiago, ZapB, kkoehne, sahumada, Rafal_, joaijala, iieklund: ping
(5:03:43 PM) kkoehne: akseli: pong
(5:03:48 PM) johanna_: akseli: pong
(5:03:51 PM) sahumada: akseli: pong
(5:03:58 PM) samuel: akseli: ping
(5:04:55 PM) akseli: It's time to start Qt 5.0.1 release meeting
(5:04:59 PM) thiago: akseli: pong
(5:05:12 PM) iikka [~iikka2 at gprs-internet-bceece-162.dhcp.inet.fi] entered the room.
(5:05:38 PM) akseli: I would like to propose following agenda:
(5:05:45 PM) akseli: Upgrade of the MinGW toolchain?
(5:05:49 PM) akseli: Qt 5.0.1 go\no-go decission criteria (required for later meetings)
(5:05:55 PM) akseli: Packaging status
(5:05:58 PM) akseli: Qt 5.0.1 status
(5:06:09 PM) akseli: Next meeting
(5:06:16 PM) akseli: *Qt Creator 2.6.2 status
(5:06:22 PM) akseli: Next meeting
(5:06:28 PM) akseli: Does anyone have additional items in mind?
(5:08:02 PM) akseli: Feel free to raise topics later but if we start with MinGW toolchain issue: kkoehne^
(5:08:20 PM) kkoehne: Sure. Back in November I proposed a certain mingw toolchain to be bundled with Qt / used in the CI system. This was Mingw-builds x32-4.7.2-release-posix-sjlj-rev1.7z
(5:08:43 PM) kkoehne: The quesition is whether we just stick to it, or do an upgrade. There are two possiblities:
(5:09:04 PM) kkoehne: Keep the configuration (gcc 4.7.2, posix threading, sjlj exceptions), and just upgrade to rev8
(5:09:13 PM) kkoehne: Or also switch to win32 threading lbirary.
(5:09:46 PM) kkoehne: Later one was based on a suggestion on the minw-w64 mailing list by RubenV, one of the driving forces of mingw-w64
(5:10:04 PM) kkoehne: Anyhow, in the meantime other people objected ...
(5:10:37 PM) kkoehne: SO it comes down to: There are differences between the libs, but there's no consensus which one should be used in Qt.
(5:10:38 PM) thiago: why did they object?
(5:11:06 PM) kkoehne: "Kai, I would not recommend to use win32-threads builds, because so the full support for 'C++11 threads support library' will appear only after several years.
(5:11:06 PM) kkoehne: About the current support for 'C++11 threads support library' in MinGW we can not say that it does not exist or it is not working. It exists, and it works. And I think it works quite well."
(5:11:44 PM) kkoehne: Personally, I don't have the insight to make a judged call, so right now I think we should maybe stick with what we've been using before
(5:12:01 PM) kkoehne: (Note that it should really only make a difference for people using std:threads directly, I understand)
(5:12:17 PM) andre_: maybe we should ask for an official recommendation of the mingw "project" (whatever that is...) what to use. there seems to be a bit of fragmentation, with everyone just pushing his pet build
(5:12:47 PM) thiago: that's the problem: there is no such "project"
(5:12:51 PM) kkoehne: exactly.
(5:13:04 PM) thiago: I'd go with the variant that has the most upstream support, though
(5:13:15 PM) thiago: which one do you see the most number of people behind?
(5:13:50 PM) anshaw left the room (quit: Read error: Connection reset by peer).
(5:13:51 PM) kkoehne: Good question ...
(5:13:57 PM) kkoehne: There's a tiny graph on http://sourceforge.net/projects/mingwbuilds/files/host-windows/releases/4.7.2/32-bit/
(5:14:15 PM) kkoehne: for downloads. But since we as the Qt project also download from there, it might be us pushing the posix numbers.
(5:14:44 PM) thiago: you said there was one of the upstream guys coming to us (RubenV)
(5:15:08 PM) kkoehne: yes. and then Nixman (the guy creating mingw-builds) said the opposite.
(5:15:22 PM) thiago: to use something different?
(5:15:38 PM) kkoehne: Yes, he voted for the posix version.
(5:15:46 PM) andre_: do we know which build is more reliable? I don't think speed is the major issue
(5:15:47 PM) kkoehne: (which we have been using so far)
(5:15:59 PM) thiago: can we use the mingw-w64 one for both 32- and 64-bit builds?
(5:16:41 PM) kkoehne: andre_: THis is what the wiki says: http://qt-project.org/wiki/MinGW-64-bit
(5:16:46 PM) kkoehne: thiago: Yes
(5:16:59 PM) kkoehne: andre_: Though the last edit was from rubenv ;)
(5:18:01 PM) thiago: and which one do we know that builds Qt?
(5:18:24 PM) kkoehne: We've been using the posix one so far, successfully. But it also compiles with win32
(5:18:57 PM) thiago: have we got any mingw-w64 successful build?
(5:19:06 PM) kkoehne: thiago: Yes. It compiles in the CI system + packages.
(5:19:12 PM) kkoehne: thiago: the 32 bit version at least.
(5:19:24 PM) kkoehne: thiago: I personally didn't spend too much time on the 64 bit one.
(5:19:53 PM) thiago: that's ok
(5:20:05 PM) johanna_: we have used only win32 in packaging, right iikka?
(5:20:07 PM) thiago: my recommendation is to pick the mingw-w64 build if it works
(5:20:14 PM) kkoehne: As I said, since there's no clear indication from the community (both Qt and Mingw) which to choose I think we should just continue what we've been using so far.
(5:20:14 PM) iikka: johanna_: correct
(5:20:27 PM) kkoehne: iikka, johanna_: Sure?
(5:20:40 PM) iikka: kkoehne: 32bit version
(5:20:45 PM) kkoehne: iikka: Okay :)
(5:21:04 PM) iikka: we haven't tried with 64bit version so far
(5:21:22 PM) kkoehne: AFAIK it compiles fine, but last time I heard there's some crashes in Webkit.
(5:21:32 PM) kkoehne: 64 bit, that is.
(5:21:40 PM) kkoehne: But I can check for the next round.
(5:22:18 PM) thiago: let's stick to the 32-bit for now
(5:22:34 PM) thiago: we'll do some more testing on the 64-bit build for a later release
(5:22:42 PM) kkoehne: The other question is, any objections against upgrading to rev8 ? This should be a fairly safe change, but would require upgrading CI system, build machines, a doc line, and the installer.
(5:24:24 PM) kkoehne: Any practical objections against that? As I wrote it's not a must, but we know that rev8 contains some improvements.
(5:24:27 PM) iikka_ [~iikka2 at gprs-internet-bcee81-96.dhcp.inet.fi] entered the room.
(5:24:32 PM) iik [~iikka2 at gprs-internet-bcee81-96.dhcp.inet.fi] entered the room.
(5:24:48 PM) thiago: no objections apparently
(5:24:55 PM) thiago: go ahead with that
(5:25:06 PM) akseli: That would cause quite a lot work for CI system
(5:25:19 PM) ***andre_ is in favour of upgrading, even if it's unclear that the "improved gdb support" affects us.
(5:25:20 PM) akseli: sorry for late reaction
(5:25:34 PM) iik: sorry, lost connection, what part did I miss?
(5:25:37 PM) kkoehne: akseli: I've to admit I didn't really understand why this is so.
(5:26:06 PM) kkoehne: akseli: Shouldn't this be more than extracting the 7z file somewhere?
(5:26:20 PM) kkoehne: akseli: I mean, not more ?
(5:26:49 PM) akseli: The problem is that CI machines are controlled by puppet and before doing (re)installation it does check that if correct version of MinGW is already installed.
(5:27:11 PM) thiago: so isn't it a matter of telling puppet to upgrade?
(5:27:24 PM) iikka left the room (quit: Ping timeout: 260 seconds).
(5:27:25 PM) akseli: At the moment puppet & mingw configuration doesn't recognize rev e.g. v8
(5:27:29 PM) samuel left the room (quit: Ping timeout: 248 seconds).
(5:28:05 PM) kkoehne: akseli: but if you'd use another way to identify the toolchain, e.g. gcc -v instead of gcc --version, that would help, right?
(5:28:14 PM) akseli: config doesn't specify revision and changing config doesn't work like a charm
(5:28:26 PM) akseli: kkoehne: not certain about that
(5:28:49 PM) kkoehne: akseli: Okay. I still think we should be upgrade at one point, doesn't have to me instantly for the CI system, IMO.
(5:29:07 PM) kkoehne: akseli: But if we want to upgrade the build machines we should decide it now.
(5:29:25 PM) akseli: kkoehne: I agree
(5:29:37 PM) akseli: can everyone live with kkoehnes proposaö
(5:29:41 PM) thiago: I think upgrading is a no-brainer
(5:29:43 PM) thiago: go for it
(5:30:04 PM) thiago: but my opinion still stands that we should switch to mingw-w64 for the long term
(5:30:06 PM) sahumada: to me it looks like we just need to change one character http://qt.gitorious.org/qtqa/sysadmin/blobs/master/puppet/modules/mingw/manifests/windows.pp
(5:30:39 PM) iik: kkoehne: could you briefly go through again the proposal, I got connection lost for a while so I might have missed something
(5:30:46 PM) akseli: so is deceission to upgrade build machines now and CI system as soon as possible but not block release with that?
(5:31:14 PM) kkoehne: iik: We'll stick to the mingw-builds toolchain configuration (posix-sjlj), but use rev8 instead of rev1.
(5:31:39 PM) kkoehne: iik: build machines etc have to be upgraded ASAP, CI system will follow.
(5:31:51 PM) iik: kkoehne: ok, does that affect installer configurations, e.g. namings etc.
(5:32:01 PM) kkoehne: iik: Yes, a bit. I'll take care of it.
(5:32:10 PM) iik: ok
(5:32:39 PM) iik: sounds ok to me then
(5:33:07 PM) akseli: next item: Qt 5.0.1 go\no-go decission criteria
(5:33:39 PM) hanne left the room (quit: Read error: Operation timed out).
(5:33:40 PM) akseli: Since this is a patch release we aren't fully following same practices than on major release
(5:33:52 PM) akseli: There are a lot of fixes on top of 5.0.0 already.
(5:35:05 PM) thiago: do you have suggestions for the criteria?
(5:35:24 PM) akseli: My proposal is that there can be P1 errors open on patch release
(5:35:33 PM) akseli: As long as there is no brown paper bag issues or obvious regression compared to previous release noticed I would see feasible to release Qt 5.0.1.
(5:35:49 PM) akseli: There should not be same P0 bugs two release in a row.
(5:36:05 PM) akseli: at the moment we don't have any P0 bugs open
(5:36:38 PM) thiago: well, P0 means "fix now"
(5:36:45 PM) thiago: I'd say P0 must be zero
(5:36:53 PM) thiago: how many P1 do we have?
(5:38:05 PM) sahumada: like 6
(5:38:31 PM) iikka [~iikka2 at 188.238.218.196] entered the room.
(5:38:33 PM) akseli: 7 P1s
(5:38:44 PM) iik left the room (quit: Ping timeout: 252 seconds).
(5:38:44 PM) iikka_ left the room (quit: Ping timeout: 252 seconds).
(5:39:00 PM) akseli: most of them from lateset vs2010 x64 packges
(5:39:38 PM) thiago: we should strive for zero, but we can make a judgement call on them
(5:39:49 PM) thiago: when releasing is more important than fixing the bug
(5:40:14 PM) thiago: so I propose we review the list of open P1s on each go/no-go meeting
(5:41:12 PM) akseli: thiago: will prepater such list for later meetings
(5:41:12 PM) sahumada: I closed https://bugreports.qt-project.org/browse/QTBUG-28787 (merged in 'release') and I think we can close https://bugreports.qt-project.org/browse/QTBUG-25220 too
(5:41:28 PM) kkoehne: I agree with thiago. We can ignore P1's, but consciously.
(5:41:57 PM) akseli: We are aiming for new pre-build binary packages (mingw, vs2010 64bit, vs2012 64bit). I would like to also propose that these new packages may not prevent Qt 5.0.1 release if Qt 5.0.0 released "old platform"s are releasable.
(5:42:35 PM) akseli: Rationale: There is lot of additional value for Qt 5.0.1 already with existing packages
(5:42:45 PM) kkoehne: akseli: Would that mean that we don't release them at all, or with some lag?
(5:43:20 PM) thiago: akseli: agreed
(5:43:30 PM) akseli: Depending severity of platform and decission of Release team on later release or with some lag if feasible
(5:43:43 PM) thiago: of those three, my preferred order is: mingw, vs2012 64-bit, vs2010 64-bit
(5:43:48 PM) akseli: *severity of problems in platform
(5:43:49 PM) thiago: in fact, I'd even drop the vs2010 64-bit
(5:44:58 PM) akseli: mingw is highly requested. Does others agree with thiago?
(5:45:03 PM) iikka_ [~iikka2 at gprs-internet-bceeba-81.dhcp.inet.fi] entered the room.
(5:45:30 PM) kkoehne: What about the request for opengl ones? Not that I propose getting this into 5.0.1, but if we add more platforms it's hard to get rid of them later on ...
(5:45:49 PM) thiago: native opengl, as opposed to angle?
(5:46:08 PM) kkoehne: thiago: Yes. AFAIK it's a quite popular request.
(5:46:17 PM) iikka_: yes, there was proposal to offer reference installers built against opengl
(5:46:22 PM) thiago: I thought ANGLE was BC with the real OpenGL libs
(5:46:44 PM) kkoehne: https://bugreports.qt-project.org/browse/QTBUG-28715
(5:47:53 PM) thiago: let's put them at a second priority, after mingw and vs2012 64-bit
(5:48:07 PM) iikka left the room (quit: Ping timeout: 246 seconds).
(5:48:09 PM) thiago: btw, let's record a "Finnish consent" to the dropping of vs2010 64-bit
(5:48:14 PM) akseli: Although highly requested I would propose that this will be now left to later releases than 5.0.1. To which will decided by releasing mailin list
(5:48:33 PM) kkoehne: thiago: +1
(5:49:00 PM) akseli: thiago: +1
(5:50:04 PM) thiago: how about the release process itself?
(5:50:06 PM) thiago: how shall we do it?
(5:50:59 PM) thiago: we can do it like we've been doing for 4.8: release team produces packages, announces it, tests it, rinse and repeat
(5:51:24 PM) thiago: or we can do it like we did for 5.0.0: release team produces packages, sanity-checks, announces it, tests it, rinse and repeat
(5:52:12 PM) akseli: I would favor 4.8 process
(5:52:26 PM) thiago: tbh, how is it any different?
(5:53:10 PM) kkoehne: difference is only the sanity check before announcement?
(5:53:18 PM) thiago: is it the one-week interval of testing that is the problem?
(5:53:27 PM) thiago: if so, we can shorten it to twice-a-week
(5:54:22 PM) kkoehne: thiago: Well, with 5.0.0 we effectively just left it to the decision of the RT to decide whether we've a final package or not.
(5:54:50 PM) kkoehne: And honestly I think that's saner than waiting any forced time just because there's a README.txt change, which is technically a new RC.
(5:55:03 PM) thiago: ok, how about this:
(5:55:04 PM) kkoehne: To overstate it a bit.
(5:55:14 PM) thiago: RT produces packages, sanity-checks, announces it
(5:55:21 PM) thiago: the packages are *all* marked "5.0.1"
(5:55:36 PM) thiago: however, we tag each release as a candidate (5.0.1-rc1, 5.0.2-rc2)
(5:55:59 PM) thiago: once we reach a final, we simply add the new tag. No repackaging.
(5:57:13 PM) akseli: thiago: +1
(5:57:36 PM) thiago: the interval between packages can be 3-4 days too
(5:57:55 PM) thiago: package on Monday and Thursday
(5:58:06 PM) thiago: that's a release on Thursday or the next Tuesday (respectively)
(5:58:07 PM) kkoehne: thiago: By tagging you mean git tagging, or package names?
(5:58:12 PM) thiago: git tagging
(5:58:44 PM) thiago: though renaming of the files is a simple thing, I wasn't thinking of that.
(5:58:49 PM) kkoehne: thiago: all modules, or just qtsdk.git?
(5:59:32 PM) thiago: the tagging? Only what's released.
(5:59:32 PM) sahumada: I'd guess only qtsdk.git with 5.0.1-rcX and the modules with 5.0.1
(5:59:46 PM) kkoehne: sounds good then.
(5:59:47 PM) thiago: btw, we need to bring back the "qt-x.x.x" tag
(5:59:51 PM) thiago: the one we used for alpha1
(6:00:09 PM) thiago: if it is not part of the release, it should get the "qt-x.x.x" tag
(6:00:23 PM) thiago: the vx.x.x tag should only be used for the release of a module
(6:00:56 PM) sahumada: thiago: one example of qt-x.x.x module ?
(6:01:12 PM) thiago: oh, never mind. I misread you.
(6:01:23 PM) thiago: +1 on your suggestion
(6:01:32 PM) ***kkoehne has to leave soon.
(6:01:58 PM) sahumada: so we only tag qtsdk.git with v5.0.1-rcX .. and the modules with 5.0.1 once they are released
(6:04:28 PM) ***thiago needs to leave too
(6:04:45 PM) thiago: topics left: next meeting and creator 2.6.2
(6:05:02 PM) iikka_: thiago: before you leave, comments on QTBUG-29075
(6:05:29 PM) thiago: sec...
(6:06:00 PM) thiago: change the build script to pass the right -sysconfdir option
(6:06:17 PM) iikka_: mac as well?
(6:06:34 PM) thiago: yes
(6:06:37 PM) iikka_: ok
(6:06:44 PM) thiago: the question for mac people is: what is the right option
(6:07:07 PM) iikka_: anshaw: ^
(6:07:45 PM) thiago: anyway, for the next meeting, I'm available all week. And it looks like next week too.
(6:07:49 PM) akseli: since this is already on "overtime" and people have to leve3 about next meeting: is next Monday, sametime suitable?
(6:08:13 PM) iikka_: 30mins later would work better for me....
(6:08:19 PM) johanna_: akseli: fine with me
(6:08:26 PM) thiago: it still needs to end at this time
(6:08:36 PM) thiago: at most at 15 past the hour (7 minutes from now)
(6:08:40 PM) iikka_: ok, 17:00 then
(6:08:50 PM) kkoehne: Fine with me.
(6:09:04 PM) thiago: when do we get packages?
(6:09:21 PM) iikka_: build ongoing
(6:09:26 PM) iikka_: some packaging fixes
(6:09:31 PM) thiago: how long does the sanity check take?
(6:09:36 PM) iikka_: but othherwise the same content as last friday
(6:09:58 PM) iikka_: akseli: ^ ... few hours
(6:10:09 PM) akseli: few hours
(6:10:14 PM) iikka_: now we have more platforms to test
(6:10:24 PM) thiago: if we want to release on a Tuesday or Thursday, the meetings should be Monday and Wednesday
(6:11:22 PM) thiago: it's unlikely we'll release this Thursday, so we can skip this Wednesday's meeting
(6:11:32 PM) akseli: On monday
(6:11:35 PM) thiago: next Monday is ok then
(6:12:13 PM) akseli: kkoenhe: time for short Creator update?
(6:14:07 PM) akseli: What I'm aware updated qtsdk to latest 2.6 branch, which will become 2.6.2. There are a couple of crash fixes and 'hangs' that got fixed.
(6:15:17 PM) akseli: I guess it's time to end this meeting. Sorry that it took over reserved time.
(6:15:40 PM) akseli: I will send meeting minutes to releasing mail list
(6:16:06 PM) akseli: Thank you for all participating.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/releasing/attachments/20130122/b44e11f0/attachment.html>