[Releasing] Meeting minutes: Qt 5.1 release team meeting 01.07.2013

[Heikkinen Jani]

Hi,



Meeting minutes from Qt 5.1 release team meeting 01.07.2013:

-        Installers need to rebuild to get rid of the "rc2" in the installation paths and package names. No changes to content itself.

o   This will be done immediately

o   This will be final release option #2

-        Two issues raised as a potential P0 by community

o   QTBUG-31576:Out of range error when using QtQuick1 in conjunction with qt5 when assigning properties over different QML files

§  There is a workaround for this and it is regression from 4.8, not from 5.0.0 -> P2 and this won't be fixed in Qt5.1

o   QTBUG-32134:Qt No Longer Installs Include Files Needed By CMake

§  There is no easy workaround for this. Online "fix proposal": https://codereview.qt-project.org/#change,60232

§  New packages will be created with this change only and if it fixes the issue and doesn't cause regression then change will be taken in the final release

·        Thiago promised to verify the fix during US daytime

§  This will be final release option #1

-        Qt5.1 final release will be done 3rd July 12.00 Oslo time

o   If fix for QTBUG-32134 is ok, then option #1 is released

o   Otherwise option #2 is released

-        Next meeting: Monday 05.08.2013 16:00-17:00 CET with Qt5.1.1( I am on vacation, Rafal will host the meeting)



Br,

Jani



Irc log below:
[17:00:48] <jaheikki3> akseli: iieklund: kkoehne: sahumada: thiago: fkleint: ZapB: tronical:ping
[17:00:54] <iieklund> jaheikki3: pong
[17:00:56] <ZapB> jaheikki3: pong
[17:00:57] <kkoehne> jaheikki3: pong
[17:01:00] <sahumada> jaheikki3: pong
[17:01:07] <fkleint> jaheikki3: pong
[17:01:11] <akseli> jaheikki3: pong
[17:01:27] <thiago> jaheikki3: pong
[17:01:49] <jaheikki3> Time to start Qt 5.1 release meeting
[17:02:12] <jaheikki3> On agenda today:
[17:02:12] <jaheikki3> 5.1 Installer status
[17:02:12] <jaheikki3> 5.1 Error Metrics
[17:02:12] <jaheikki3> 5.1 Final release
[17:02:12] <jaheikki3> Next meeting
[17:02:12] <jaheikki3> Any additional items to agenda?
[17:03:02] <lars> jaheikki3: here as well today :)
[17:03:27] <jaheikki3> lars:great
[17:03:32] <jaheikki3> feel free to bring topics during meeting .. starting then from 5.1 Installers
[17:03:39] <tuturune> jaheikki3: I am also listening, in case you need something from me.
[17:03:53] <iieklund> ok, installers:
[17:03:56] <iieklund> Nothing special to mention, all rc2 offline installers are there.
[17:04:05] <iieklund> online repository update will happen for the final
[17:04:15] <iieklund> Creator version sha is fixed to ea5aa79dca1fc77ee6d8dc8c26e5362e72503ef8
[17:04:30] <kkoehne> ^^ That'll be 2.7.2 then
[17:04:40] <iieklund> We need to "rebuild" installers to get rid of the "rc2" in the installation paths and package names. No changes to content itself
[17:05:11] <iieklund> the "patcher update" that was mentioned last time is in use and works well
[17:06:08] <iieklund> the windows installer shortcuts bug is fixed as well
[17:07:09] <iieklund> also the linux creator desktop entry is fixed so that it will not mix up with the stand alone creator installation
[17:07:35] <jaheikki3> iieklund: So there isn't any other known issue related to installer than installation over existing installation doesn't work?
[17:07:50] <thiago> has anyone noticed that the RC2 is not releasable?
[17:08:09] <iieklund> jaheikki3: no that I'm aware of
[17:08:34] <jaheikki3> thiago: No, at least I don't know that?
[17:09:11] <jaheikki3> thiago:was that question or comment?
[17:09:47] <ZapB> thiago: the lack of working cmake support is a problem imho. Although it's not the officially supported build system many customers use it
[17:10:42] <thiago> the lack of cmake support is one
[17:10:47] <thiago> it's wholly busted on Mac
[17:10:54] <jaheikki3> Lets discuss about those potential p0 a bit later, OK?
[17:10:57] <thiago> ok
[17:10:58] <ZapB> yup steveire and james are nwo working on it
[17:11:15] <jaheikki3> Anything else related to installers?
[17:11:26] <iieklund> jaheikki3: no
[17:11:58] <jaheikki3> OK, let's continue then with error metrics and those potential P0s
[17:12:10] <jaheikki3> Open 5.1.0 issues: 445 (49 more than two weeks ago)
[17:12:31] <jaheikki3> 0 P0, 2 proposals from community
[17:12:44] <jaheikki3> and 31 P1 (3 less than two weeks ago)
[17:13:34] <jaheikki3> Two P0 proposals from community: QTBUG-31576:Out of range error when using QtQuick1 in conjunction with qt5 when assigning properties over different QML files & QTBUG-32134:Qt No Longer Installs Include Files Needed By CMake
[17:13:56] <jaheikki3> Both has had some discussion in the mailing list
[17:14:22] <thiago> I don't know 31576 -- is that easy to reach?
[17:14:35] <thiago> how many files are affected?
[17:14:42] <ZapB> jaheikki3: First one has simple work around to use alias properties (which is even the more preferred solution imho)
[17:14:56] <thiago> is existing code effected?
[17:15:37] <lars> jaheikki3: I've also asked simon to have a look at the first one. But I don't expect an answer before tomorrow
[17:16:01] <lars> thiago: apparently it has been broken since at least 5.0.1, maybe even 5.0.0
[17:16:07] <ZapB> thiago: compared with Qt4 yes, but I don't think it's worked for any Qt5 release
[17:16:10] <kkoehne> thiago: I understood that it affects code used to work with Qt 4. So yes, existing code is affected.
[17:16:45] <thiago> regresion from 4.8, not 5.0 then
[17:16:52] <thiago> with a workaround
[17:16:57] <thiago> sounds like a P2 to me
[17:17:07] <ZapB> agreed
[17:17:09] <kkoehne> thiago: I agree
[17:17:12] <jaheikki3> Agreed
[17:17:41] <jaheikki3> I'll update the issue later
[17:17:44] <lars> yes. let's aim for a fix in 5.1.1
[17:17:46] <thiago> 32134: have we shipped correct cmake files before?
[17:18:18] <lars> I'm a bit worried about the cmake support, as it seems to break quite often.
[17:18:46] <lars> and it's always found out very late in the process
[17:18:50] <thiago> I got a report last night that installed-Mac is wholly broken
[17:18:54] <thiago> I'm compiling right now to confirm
[17:18:56] <ZapB> well this one seems to be caused by headers now only being installed within the frameworks. before they were also installed to include/
[17:19:06] <thiago> that's the issue I've been told
[17:19:16] <thiago> the regression seems to be the installation change, not the cmake issue
[17:19:22] <kkoehne> ... which was breaking qmake too, but we found out a bit earlier.
[17:19:31] <lars> hmmm... why are we changing that this late in the release process?
[17:19:41] <ZapB> good question
[17:19:42] <thiago> I propose P1, revert the installation back to RC1
[17:20:16] <ZapB> thiago: in the absence of a cmake fix, I agree
[17:20:50] <thiago> I think it's wrong not to install outside the framework in the first place
[17:20:50] <kkoehne> thiago: That's reverting around 10 build system patches... I'm not sure this is a good idea.
[17:20:59] <thiago> kkoehne: yes, revert the buildsystem back to RC1
[17:21:25] <thiago> I told ossi that I'd propose that if any of his late changes that seemed not relevant introduced an issue
[17:21:27] <ZapB> steveire: any comment? ^
[17:21:34] <lars> thiago: before we go there... I think there was a reason for the build system patches
[17:21:43] <kkoehne> thiago: I agree that these changes should have never landed after RC1. But now we have them, and I think fixing cmake is easiert than reverting.
[17:22:09] <kkoehne> ossi|tt: ^^
[17:22:20] <steveire> Sorry, was away. Will read backlog
[17:22:44] <thiago> kkoehne: this is not cmake. It's about installing the files where they should be
[17:23:07] <sahumada> in order to revert a change that's it's already merged I'd like to see a bugreport with the issue
[17:23:30] <thiago> lars: agreed. We need to evaluate why the changes were applied. If they're equally priority, we need a fix. If they were fixing P2 or lower, they get reverted.
[17:23:36] <steveire> The late breakage found via the cmake files is generally a result of the buildsystem getting so many changes during each RC cycle so far.
[17:23:41] <thiago> sahumada: QTBUG-32134
[17:23:43] <kkoehne> thiago: I don't have an opinion on this.
[17:24:18] <fkleint> ossi|tt: Around? ^^^^^^^^^^^^^^^^
[17:24:22] <ossi|tt> yes
[17:24:26] <sahumada> that's doesnt explain why we need to revert anything
[17:24:26] <thiago> ossi|tt: why are the headers in frameworks not installed to includedir anymore?
[17:24:41] <ossi|tt> because it's stupid to do so
[17:24:49] <thiago> is that a P1?
[17:24:52] <jaheikki3> thiago:steveire: there is a comment in the issue:Written in the report: Removing the line CONFIG -= qt_install_headers #no need to install these as well seems to fix the problem.
[17:25:12] <jaheikki3> Is this a kind of workaround?
[17:25:23] <thiago> jaheikki3: probably
[17:25:30] <ossi|tt> thiago: i don't remember. it's part of a bigger series of fixes, some of which were assigned p1
[17:25:56] <thiago> so that change gets reverted
[17:26:35] <ossi|tt> good luck with that ...
[17:27:03] <jaheikki3> thiago: But because there is possibility to use CMake with workaround why we need to revert at this point?
[17:27:17] <steveire> Which workaround?
[17:27:18] <lars> another consideration here: we'll have very limited man power to do testing and packaging from next week... :/
[17:27:18] <thiago> jaheikki3: the workaround is not for cmake. It's the reversal.
[17:27:29] <thiago> installing the headers is the reversal
[17:27:48] <jaheikki3> lars: that's true
[17:27:49] <lars> thiago: ossi|tt: is it a one liner? removing the CONFIG -= qt_install_headers?
[17:27:50] <kkoehne> ironically the change to install headers into the private framework was because of a cmake issue ... https://bugreports.qt-project.org/browse/QTBUG-31641
[17:28:56] <ossi|tt> thiago: lars: it's pointless to revert this patch (which would produce merge conflicts to start with, but that's probably somewhat easy), as it restores a state where some configurations would be still broken as previously
[17:29:13] <lars> ossi|tt: ok.
[17:29:35] <ZapB> steveire: any idea on how long it will take for a fix from the cmake side of things?
[17:29:46] <jaheikki3> so we have 2 options: Wait for fix or accept that as a known issue
[17:30:04] <ZapB> +1 for wait for a fix
[17:30:19] <thiago> this is a P1
[17:30:22] <thiago> we need to wait for the fix
[17:30:23] <ossi|tt> thiago: lars: it would be possible to simply comment out the line in the new place for the time being. then all configurations would work (give or take being stupid and confusing)
[17:30:38] <lars> constraints: 4th of July, and limited packaging resources from next week.
[17:30:43] <thiago> it sounds like a one-line change
[17:30:58] <thiago> and packages need to be rebuilt anyway
[17:31:32] <sahumada> is not the same re-building with the same content than to rebuild with new content .. regardless of changing just one line
[17:31:35] <akseli> thiago: different thing to rebuild packages than build qt binaries
[17:31:41] <jaheikki3> thiago: packages yes, but nothing else
[17:32:08] <sahumada> steveire: is your potential change .. a fix or a workaround .. from your point of view ?
[17:32:30] <lars> thiago: ossi|tt: what can go wrong commenting out the one line?
[17:33:37] <steveire> I made https://codereview.qt-project.org/#change,60230 already, but I don't have a mac and I'm guessing at what the path should be.
[17:34:00] <ossi|tt> lars: nothing i'm aware of. but then, i wasn't aware of the problems that making it sane would cause to start with ;)
[17:34:05] <steveire> Not having a mac available today is making for more roundtrips than it should...
[17:34:11] <lars> anyon who can check steveire's patch?
[17:34:21] <thiago> I can
[17:34:22] <sahumada> steveire: is that a fix or a workaround ? (and you forgot the Task-number)
[17:34:45] <jaheikki3> so the change is in QtBase ->whole build & packaging needs to be re-done...
[17:34:47] <thiago> but it doesn't change the fact that installing the global headers is the correct change, IMO
[17:34:49] <lars> if that fixes it it would be preferable over other changes, as it won't affect non cmake related things
[17:35:02] <sahumada> (and the Task-number needs to be a P0 or P1 to be in the release branch)
[17:35:22] <ossi|tt> thiago: it's not. it's a framework build. headers are in frameworks, not at some random other location
[17:35:23] <lars> thiago: is it? sounded like ossi|tt disagreed.
[17:35:47] <ossi|tt> steveire's change is the real thing. reviewing it now.
[17:36:28] <thiago> ossi|tt: maybe, but a post-RC1 change is way too late a behaviour change.
[17:36:34] <thiago> ossi|tt: propose that for 5.2 instead
[17:37:01] <thiago> I propose we install the headers, since we have no clue what else we're breaking.
[17:37:03] <steveire> sahumada: Sorry, the question is a bit loaded. I'm not a mac expert. It's a 'following change' for the removal of the headers from where they were before'. Whether that makes it a fix or a workaround is NotMyDepartment.
[17:37:23] <sahumada> fair enough
[17:37:27] <ossi|tt> steveire's change is fairly broken in many respects
[17:37:57] -*- steveire is not surprised, but wonders if they will be enumerated...
[17:38:14] <thiago> jaheikki3: do we have more topics for this meeting?
[17:38:16] <ossi|tt> steveire: there is no such thing as Headers/$${MODULE_INCNAME}
[17:38:31] <jaheikki3> thiago: 5.1 final
[17:38:54] <jaheikki3> But I quess we need to solve this one before moving to that
[17:38:55] <ossi|tt> steveire: see what qtAddModule() does
[17:38:57] <thiago> we've nominated this issue as showstopper, so we just need to agree on a solution
[17:38:59] <steveire> ossi|tt: Do you want to fix the patch in many respects, or will I?
[17:39:16] <thiago> can we move on with the meeting and handle this elsewhere?
[17:39:20] <steveire> So far you've only mentioned one issue, which != many.
[17:39:20] <ossi|tt> steveire: i don't know enough cmake to do it right. it needs messing with the framework path
[17:39:33] <akseli> thiago: who decided it is showstopper? did i miss some line?
[17:39:36] <steveire> This is just 'paths', not 'cmake' :)
[17:39:39] <sahumada> I disagree with calling this a showstopper .. dont know whether that matters though
[17:39:40] <jaheikki3> Does all agree Thiago?
[17:39:46] <ossi|tt> steveire: well, it's the same issue that repeats in multiple place
[17:39:56] <lars> thiago: have we agreed that it is? We have one problem: If we don't get the package done this week, we have a hard time releasing before middle of july
[17:40:23] <akseli> lars: it would  be august then...
[17:40:27] <steveire> ossi|tt: That's one respect in my book, not many :)
[17:40:31] <thiago> ok, so let's decide on that
[17:40:43] <thiago> I'm proposing that this issue is a showstopper, for two reasons:
[17:41:02] <thiago> 1) it changed the behaviour of the installation way too late, so we don't know what buildsystems broke
[17:41:12] <thiago> and 2) we know that the cmake files we ship are broken
[17:41:24] <ossi|tt> steveire: yeah. maybe. i was thinking from the perspective that the solution needs two "respects" (include path and framework path)
[17:42:01] <ZapB> I agree with Thiago
[17:42:18] <sahumada> I disagree with calling it a showstopper because : 1) reverting changes doesn't ensure we will fix anything 2) people are already testing -rc2 and no P0/P1 have been found 3) cmake is not official and shouldnt stop a release
[17:42:35] <ossi|tt> thiago: 1) well, at this point we know it fairly well. and we also know that 3rd party build systems which rely on the previous bizarre mix of frameworks and external headers will be broken
[17:42:44] <jaheikki3> +1 for sahumada's proposal
[17:42:44] <ZapB> sahumada: it's not official but (paying) customers use it a lot
[17:43:01] <sahumada> ZapB: and there is a fix and a potential workaround
[17:43:12] <sahumada> *potential fix
[17:43:19] <ZapB> so wait for it to get included
[17:43:27] <thiago> I'm proposing a one-line change that makes qmake install the headers where they used to be installed
[17:43:31] <akseli> I disagree delaying release since this would 1) deny release for non-cmake users most likely until august and 2) cmake is not officially supported
[17:43:49] <thiago> sahumada: you mean "no other P0/p1"
[17:43:56] <thiago> sahumada: this is a P0/P1
[17:44:01] <jaheikki3> 5.1.1 is coming pretty soon, we can fix this in 5.1.1
[17:44:24] <thiago> how hard is it to apply a one-line change to the packages?
[17:44:24] <lars> delaying the release by 4 weeks is certainly not a good option, as it makes 5.1 unusable for everybody. releasing with the issue affects cmake users on mac, which is a subgroup
[17:44:34] <sahumada> thiago: I still don't see any P0/P1 .. QTBUG-32134 is unvaluated
[17:44:42] <thiago> s/cmake users/non-qmake users/
[17:44:47] <thiago> we do not know what else we broke
[17:44:57] <thiago> sahumada: we're deciding whether 32134 is P0/P1
[17:44:59] <ossi|tt> thiago: as i said, this doesn't change anything
[17:45:03] <lars> but if reverting the one line only makes the headers install the old way, I'd opt for trying that
[17:45:44] <lars> we can actualy verify that by simply looking at the package content.
[17:46:08] <thiago> btw, revert or remove the line? Reverting moves it it back into the debug block, which makes the headers be installed in debug and debug-and-release builds, but not release
[17:46:18] <jaheikki3> lars: and you see there is no risk to do that?
[17:46:21] <lars> thiago: remove the line IMO
[17:46:24] <thiago> removing the line means installing always, maybe twice
[17:46:44] <kkoehne> Alright guys, so how about approaching this in a pragmatic  way? We'll try to get the one liner in, if this fails on any level (packaging testing) say until Wednesday we'll release anyway.
[17:47:02] <jaheikki3> kkoehne: +1
[17:47:02] <lars> kkoehne: +1. that's what I was aiming for as well
[17:47:03] <akseli> kkoehne: +1
[17:47:17] <thiago> +1
[17:47:29] <thiago> have any changes landed in release post RC2?
[17:47:41] -*- thiago checks
[17:47:59] <sahumada> thiago: only one in qttools .. but qt5.git hasnt changed
[17:48:00] <thiago> no, none have
[17:48:05] <thiago> not in qtbase, at least
[17:48:17] <sahumada> not in any module other than a small change in qttools
[17:48:27] <lars> ok, then let's try that. anybody against this?
[17:48:36] <thiago> we don't include the qttools change either
[17:48:40] <lars> nope
[17:48:54] <lars> at least IMO
[17:49:02] <jaheikki3> only that one change
[17:49:11] <jaheikki3> Fixing this cmake issue
[17:49:18] <sahumada> sounds ok to me .. I can manually push an update to qt5.git with one change in qtbase
[17:49:32] <jaheikki3> Then the last topic: 5.1 final release
[17:49:52] <tuturune> Wait, who will do the 'one line change'?
[17:50:08] <thiago> tuturune: I'm doing it now
[17:50:11] <thiago> I'm testing
[17:50:37] <jaheikki3> Now ok to move last topic?
[17:50:38] <tuturune> So it will be in binaries we have tomorrow morning?
[17:51:31] <jaheikki3> tturune: Not morning, CI takes about 6 hours, then build & packaging about 9 hours...
[17:51:40] <sahumada> tuturune: unlikely
[17:52:15] <jaheikki3> tuturune: But maybe tomorrow, if everything succeed
[17:52:52] <tuturune> What does it mean for subsequent steps? Still time to do online installers etc during tomorrow?
[17:53:10] <lars> jaheikki3: sahumada: we could do the evil thing and shortcut CI. We know anyway that this part is not being tested by the system
[17:53:33] <lars> otherwise we'd have catched it earlier
[17:53:47] <jaheikki3> lars, OK for me
[17:53:58] <sahumada> lars: you mean .. just manually updating qt5.git ?
[17:54:10] <lars> sahumada: yes, and qtbase
[17:54:25] <sahumada> lars: no .. qtbase needs to go through the CI IMHO
[17:54:41] <sahumada> but technically .. it can be done
[17:55:17] <tuturune> If we can cut even the submodule update, it saves 7-8 hours?
[17:55:44] <olhirvon> + possible failures are passed
[17:55:53] <olhirvon> random ones
[17:56:42] <jaheikki3> ok, lets go through qtbase CI and manual update qt5.git, ok for everyone?
[17:56:53] <lars> sahumada: we have the qtdeclarative revdep in place for qtbase, rtight?
[17:56:59] <sahumada> lars: yes
[17:57:25] <lars> ok, so then the headers are tested with a different module. a full qt5 CI run won't give us additional info on top of qtbase CI IMO
[17:58:33] <jaheikki3> So this is clear no: thiago make online fix for issue and when it is approved then QTbase CI + manual qt5.git update+buildin+packagin
[17:58:33] <lars> jaheikki3: sahumada: can we then trigger the packaging script tonight?
[17:58:39] <tuturune> cutting the submodule update means we might have pacakges in the morning, unless something fails?
[17:59:03] <jaheikki3> tuturune: Yes, that should be possible
[17:59:21] <sahumada> lars: yes .. it's scheduled at 22:00 (CEST)
[17:59:24] <lars> ok. sounds like the best approach to me.
[17:59:36] <lars> thiago: any updates on the fix?
[17:59:59] <jaheikki3> And if everything OK, we use these packages as final and if not, current ones is ud
[18:00:02] <jaheikki3> used
[18:00:08] <sahumada> ossi|tt: would you like to do the manual update of qt5.git or should I ?
[18:00:14] <jaheikki3> and this issue will be known issue
[18:00:29] <lars> jaheikki3: yes, I think that was agreed earlier already
[18:01:13] <ossi|tt> sahumada: have fun ;)
[18:01:40] <jaheikki3> sahamuda: I think you need to do it, OK?
[18:02:26] <thiago> lars: uploaded
[18:02:26] <sahumada> jaheikki3: is not ok :) .. but I'll do it if that's what we have decided
[18:02:30] <thiago> https://codereview.qt-project.org/60232
[18:02:45] <jaheikki3> Then last item: 5.1 final
[18:03:19] <jaheikki3> As said many times holiday season will start in next week
[18:03:40] <thiago> the proposal was:
[18:03:45] <thiago> 1) rebuild RC2 as final
[18:03:53] <lars> thiago: last line of the commit message missing
[18:03:54] <thiago> 2) build final with 60232 applied
[18:04:03] <thiago> if #2 works, we release that
[18:04:10] <thiago> otherwise, we release #1
[18:04:24] <sahumada> thiago: 1) means re-building the current packages without -rc2 ?
[18:04:45] <lars> sahumada: can we do both in parallel?
[18:04:50] <sahumada> lars: no
[18:05:02] <sahumada> sadly
[18:05:07] <jaheikki3> thiago: Yes. And I propose releasing this wed because of issues told earlier
[18:05:12] <thiago> sahumada: yes, that was the idea
[18:05:27] <tuturune> but we can do #1 while testing #2
[18:05:43] <sahumada> ok .. just wanted to double check .. because that means we won't get *new* packages tomorrow morning .. just to be clear
[18:06:06] <lars> tuturune: I think we might have to do #1 before #2 :(
[18:06:15] <sahumada> tuturune: that means that #1 will be ready tomorrow morning .. #2 will be ready maybe Wed ... then we should do the qt5.git CI
[18:06:32] <lars> sahumada: or do we have options to do it the other way round?
[18:07:03] <sahumada> lars: dont think so .. I think that what thiago proposed is the right way to do it ..
[18:07:42] <lars> sahumada: only problem is when to check the packages #2...
[18:08:14] <thiago> the only change should be in the Mac packages
[18:08:25] <lars> thiago: true, and that's easy to verify
[18:08:26] <thiago> I volunteer for verifying the fix during US daytime
[18:09:04] <lars> thiago: also verify that the other packages are unchanged, please
[18:09:34] <jaheikki3> OK, so is it ok to do final release Wed 3.7?
[18:09:42] <sahumada> so .. do we do #1 first or #2 first ?
[18:09:51] <jaheikki3> #1 first
[18:09:52] <tuturune> What do we build tonight? RC2 as final or cmake (60232)?
[18:09:59] <thiago> lars: I can try
[18:10:09] <sahumada> tuturune: rc2 as final #1
[18:10:15] <lars> thiago: thx, it's unlikely they're changed though
[18:10:25] <thiago> lars: we can hope :-)
[18:10:31] <thiago> I'll pre-install RC2 today
[18:10:31] <tuturune> ok, good, then there is no need to even shortcut CI for submodule update
[18:10:43] <sahumada> tuturune: that's correct
[18:11:24] <sahumada> tuturune: if we get #1 tomorrow morning .. we could start #2 already and have packages late in the afternoon
[18:11:29] <jaheikki3> OK, now plan should be ready
[18:11:48] <jaheikki3> And release Wed 3.7
[18:12:10] <sahumada> thiago: could you please keep an eye on qtbase and qt5 (will add you) integrations during our night ?
[18:12:20] <thiago> sahumada: sure
[18:12:29] <sahumada> thanks
[18:12:35] <lars> good :)
[18:12:46] <jaheikki3> Ok, long meeting is almost end.
[18:12:52] <ZapB> :)
[18:13:00] <jaheikki3> Hoping everything goes OK...
[18:13:02] <tuturune> What time Wednesday? Shall we aim for 12.00 Oslo time?
[18:13:24] <jaheikki3> tuturune: Ok for me
[18:13:40] <sahumada> https://codereview.qt-project.org/60232 staged
[18:14:13] <jaheikki3> This is then final qt5.1 release team meeting. Next meeting with Qt5.1.1 at the beginning of August
[18:14:29] <jaheikki3> As agreed in last meeting
[18:15:12] <jaheikki3> Let's close this meeting now and continue work for final. Big thanks for everyone!
[18:15:39] <jaheikki3> bye
[18:15:40] <sahumada> I am actually heading home ;)
[18:15:41] <fkleint> bye
[18:15:45] <tuturune> Thanks, bye
[18:15:49] <akseli> bye
[18:16:13] <ZapB> thanks and bye
[18:16:35] <kkoehne> bye
------------------------------------------------------------------
Jani Heikkinen
Release Manager

Digia Plc
Elektroniikkatie 10, FI 90590 Oulu Finland
Email: jani.heikkinen at digia.com<mailto:jani.heikkinen at digia.com>
Mobile: +358-504-873-735
Visit us at: www.digia.com<http://www.digia.com/>
| Blog<http://blog.digia.com/> | Twitter<https://twitter.com/digiaonline> | LinkedIn<http://www.linkedin.com/company/5119> | YouTube<http://www.youtube.com/digiaonline> | Facebook<http://www.facebook.com/digiaonline> |
------------------------------------------------------------------
PRIVACY AND CONFIDENTIALITY NOTICE
This message and any attachments are intended only for use by the named addressee and may contain privileged and/or confidential information. If you are not the named addressee you should not disseminate, copy or take any action in reliance on it. If you have received this message in error, please contact the sender immediately and delete the message and any attachments accompanying it. Digia Plc does not accept liability for any corruption, interception, amendment, tampering or viruses occurring to this message.
------------------------------------------------------------------

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/releasing/attachments/20130701/cebf3d1d/attachment.html>