[Releasing] Meeting minutes: Qt release team meeting 10.02.2014
Heikkinen Jani
Jani.Heikkinen at digia.com
Tue Feb 11 09:02:12 CET 2014
Meeting minutes from Qt release team meeting 10.02.2014
- Qt 5.3 feature freeze is this Friday 14.02.2014!
- Merge from dev to stable is planned to be done Mon 17th Feb
o We will wait changes which were in & approved before feature freeze & integration failed because of CI problems
o If change caused build or test failure and requires an update, we won't wait it!
o To be able to do merge from dev to stable we need to finalize merges from rel to stable & stable to dev ASAP. To be checked with Frederik & Matti
- Reviews of large new APIs should be started already now. AP to maintainers!
- libdbus-1 headers will be added to the Mac builders for Qt 5.3
- 5.2.2 content will be merged from stable to release branch before 5.3 content is merged from dev to stable. That way we will have 5.2.2 content in release branch if we decide to release it later.
o We need more input from the wider audience but if we decide to do 5.2.2, it will put pressure in the 5.3 beta.
- Qt 4.8.6 status:
o build system has now mingw 4.8.2 in place
o mac carbon build is broken but work is ongoing to fix that
o build system decided not to work during weekend so "Friday" build had to restarted¨
- Next meeting Mon 17th Feb 2014 16:00 CET
Br,
Jani
Irc log below:
[17:00:29] <jaheikki3> iieklund: kkoehne: sahumada: thiago: fkleint: ZapB: tronical: wolfgang-b: vladimirM: aholza: peter-h: mapaaso: ankokko ping
[17:00:36] <ZapB> jaheikki3: pong
[17:00:38] <akseli> jaheikki3: pong
[17:01:04] <peter-h> jaheikki3: pong
[17:01:08] <thiago> jaheikki3: pong
[17:01:55] <jaheikki3> Time to start Qt 5 release team meeting
[17:01:57] <kkoehne> jaheikki3: pong
[17:02:19] <jaheikki3> On agenda today
[17:02:19] <jaheikki3> Qt 5.3 Feature freeze this Friday
[17:02:19] <jaheikki3> Qt 5.3 api reviews & Binary compatibility checks
[17:02:19] <jaheikki3> Qt 5.2.2 release
[17:02:19] <jaheikki3> Qt 4.8.6 status
[17:02:32] <jaheikki3> Anything else to the agenda?
[17:03:49] <jaheikki3> OK, lets start from 5.3 feature freeze
[17:04:21] <jaheikki3> As agreed earlier feature freeze will be this friday 14th feb
[17:05:33] <jaheikki3> I think there is lots of work still to be done for that, let's see what is ready then
[17:05:52] <kkoehne> jaheikki3: What does that mean? Do we consider extending the deadline a bit?
[17:06:17] <jaheikki3> kkoehne: In my opinion no
[17:06:50] <thiago> but it means this will be a hectic week
[17:07:24] <sahumada> jaheikki3: when will the merge from dev->happen ? on Friday afternoon or Monday morning ?
[17:07:33] <sahumada> dev->stable*
[17:07:48] <jaheikki3> sahumada: It is planned to happen monday morning, see http://qt-project.org/wiki/Qt-5.3-release
[17:07:55] <thiago> my suggestion is to wait stuff that tried to integrate and failed due to CI
[17:08:08] <thiago> if something was approved and attempted to integrate, we'll wait
[17:08:18] <thiago> if it caused a build or test failure and requires an update, we won't
[17:08:33] <jaheikki3> I was just planning to ask that.
[17:09:04] <jaheikki3> Do we close dev temporarily on friday somepoint?
[17:09:49] <thiago> I don't think there's a need
[17:09:53] <thiago> we didn't do it for 5.2
[17:10:00] <sahumada> for 5.2.0 people were staging even on Sunday evening, so I dont think it's a good idea
[17:10:00] <thiago> the weekend sorted things out
[17:10:41] <kkoehne> thiago: Well, we did close some branches for a day or two before, right after an integration.
[17:11:00] <sahumada> after the merge, not before the merge
[17:11:16] <kkoehne> Yes. So let's do this on Monday.
[17:12:02] <jaheikki3> Ok for me. So we will wait integration of those changes which were approve early enough & failed because of ci problems before merge
[17:12:53] <jaheikki3> ANd then close temporarily dev & start merge. Hoping we could start it on Monday morning...
[17:14:10] <sahumada> jaheikki3: are we going to do a ff merge or go through the CI ? if the former, then we also need to be sure that all the stable->dev merges are done
[17:14:33] <thiago> there's no way to do FF merge
[17:14:41] <thiago> we need to get a stable->dev merge ASAP
[17:15:33] <jaheikki3> thiago: I think it is done already
[17:15:35] <thiago> for a possible 5.2.2 release, I recommend a stable->release FF merge of what gets merged into dev (old/5.2)
[17:17:22] <thiago> there are 120 commits in stable that aren't in dev
[17:17:52] <jaheikki3> Yes, I think that is needed. But I think merge from rel to stable needs to succeed first
[17:18:11] <jaheikki3> And then we need new merge from stable to dev I think
[17:19:54] <thiago> release->stable has happened
[17:19:58] <thiago> at least in qtbase
[17:20:06] <thiago> I don't know (don't track) the qt5.git repo
[17:20:49] <jaheikki3> thiago: At least qtserialport is ongoing, see https://codereview.qt-project.org/#change,76220
[17:22:28] <thiago> ok
[17:23:16] <jaheikki3> I'll check those merges with frederik & matti
[17:23:51] <jaheikki3> Then Qt 5.3 api reviews & Binary compatibility checks
[17:24:16] <jaheikki3> We got feedback in 5.2 post mortem that those were done too late then
[17:24:48] <jaheikki3> Comment was that those should be done soon after feature freeze
[17:25:24] <thiago> can't be done then
[17:25:27] <thiago> it needs to wait for the beta
[17:25:34] <jaheikki3> Really?
[17:25:34] <thiago> the API isn't even soft-frozen until the beta
[17:25:40] <thiago> yes
[17:25:53] <thiago> I mean, API reviews can and should start now
[17:26:01] <thiago> but they can only conclude after the beta
[17:26:10] <thiago> alpha = review of functionality
[17:26:14] <thiago> beta = review of the API
[17:26:35] <thiago> so we need to wait for the beta to be released to close reviews. Especially the BC checks.
[17:26:58] <jaheikki3> OK, I understand. Is there anything what we can start already now?
[17:28:08] <thiago> reviews of large new APIs can be started
[17:28:26] <thiago> we just can't freeze the API until the beta
[17:29:13] <jaheikki3> That's true.
[17:31:24] <jaheikki3> what 'reviews of large new APIs can be started' means really? Is it just that we say: please start it or can some of us do something for it?
[17:31:41] <thiago> the release team doesn't have to do it
[17:31:52] <thiago> it's up to the maintainers to ensure that all APIs added to their modules have been reviewed
[17:32:12] <thiago> whether they have to do something or just wait for others to do, they'll determine
[17:32:30] <thiago> the release team will ask the maintainers after the beta, "are you done?". That's all.
[17:32:40] <jaheikki3> OK, I add that "reguest" in memo & send mail to development list
[17:33:22] <jaheikki3> Then Qt 5.2.2 release
[17:33:41] <jaheikki3> There has been some discussion in ML related to it
[17:33:59] <jaheikki3> It seems some are asking us to do it
[17:34:36] <thiago> I propose we merge {stable,old/5.2}-> release and keep it there
[17:34:47] <thiago> we'll release 5.2.2 after 5.3.0 alpha
[17:35:00] <kkoehne> thiago: Is there a smoking gun to have 5.2.2 ?
[17:35:12] <thiago> after that, we merge release back into old/5.2 and then overwrite release with 5.3 (stable)
[17:35:20] <thiago> kkoehne: I think it's just good practice
[17:35:54] <jaheikki3> It would be pretty hard to do all needed thing parallel
[17:36:30] <jaheikki3> After alpha we should be able to produce snapshot for 5.3 beta & same time for 5.2.2
[17:36:44] <sahumada> could somebody document that weird old/* thing under http://qt-project.org/wiki/Branch-Guidelines ? otherwise I dont think it should be use in the official release procedure
[17:36:44] <thiago> $ git submodule foreach -q git rev-list v5.2.1..origin/stable '2>/dev/null' '||' true | wc -l 2>/dev/null
[17:36:46] <jaheikki3> With current resources & systems that would be really difficult
[17:36:47] <thiago> 245
[17:37:21] <thiago> old/5.x is the state of stable right before it's overwritten with the new 5.y
[17:38:05] <jaheikki3> Actually do we need to use these old/5.x branches for this at all?
[17:38:08] <thiago> jaheikki3: why would it be hard?
[17:38:13] <thiago> we don't need them at all
[17:38:15] <kkoehne> We said that 5.3.0 will be a stability oriented release with a shorter release cycle than usual. Id rather prefer working on that.
[17:38:24] <thiago> we need the 5.2.2 state to be merged into release, that's all
[17:38:59] <jaheikki3> Yes, merge current stable to release before merging dev to release
[17:39:15] <thiago> actually, you may want to do it like this:
[17:39:16] <jaheikki3> Then we have release ready for 5.2.2 if that needs to be done
[17:39:27] <thiago> stable->release (5.2.2), release->dev
[17:39:37] <thiago> this will ensure that release has everything that would be necessary for 5.2.2
[17:39:51] <thiago> we can decide later whether we have the time to do 5.2.2. If we do, we have the branches.
[17:40:00] <thiago> if we don't, we haven't spent much work on it
[17:40:05] <kkoehne> For sure we can merge stalbe->release. But let's not underestimate the effort to actually a the 5.2.2 release.
[17:41:21] <thiago> we can try and create packages from release after we have the merge
[17:41:47] <thiago> what are the resources we need to do a release?
[17:41:52] <jaheikki3> I agree. Let's do those merges & be ready to do 5.2.2 if needed. and let's decide that later.
[17:41:53] <thiago> 1) CPU resources to create the binaries
[17:42:03] <thiago> 2) people resources to do a sanity checking
[17:42:37] <jaheikki3> + CPU resources to run release test automation
[17:43:18] <thiago> do you mean the CI?
[17:43:19] <sahumada> + resources to create all the configuration files in qtsdk.git
[17:43:30] <thiago> or is it something specific for a release?
[17:43:46] <jaheikki3> thiago: no, we have also automated test to verify created packages
[17:45:03] <jaheikki3> we have limited set of CPU resources and so on running 2 releases parallel is difficult
[17:45:03] <thiago> ah, I didn't know
[17:45:18] <thiago> ok, let's say we need more input from the wider audience
[17:45:26] <thiago> if we are to do 5.2.2, it will put pressure in the beta
[17:46:02] <jaheikki3> agree
[17:46:21] <jaheikki3> Let's decide that later but be ready to do it if needed
[17:47:19] <jaheikki3> ANd then 4.8.6 status. akseli^
[17:48:18] <akseli> build system has now mingw 4.8.2 in place. it compliles packages correctly but someone(tm) made logical mistake which broke packages. new build ongoing
[17:48:36] <sahumada> thiago: about the RTA http://qt-project.org/wiki/Sanity-Test-Guidelines
[17:48:52] <akseli> also build system decided not to work during weekend so "Friday" build had to restarted
[17:49:07] <akseli> that is ongoin and containing good amount of changes
[17:49:31] <akseli> mac carbon build is broken but work is ongoing to fix that
[17:50:07] <thiago> we have a carbon build?
[17:50:10] <thiago> could we drop it?
[17:50:14] <akseli> and we have to fix that one before sha1 can be frozen
[17:50:26] <akseli> no, cant drop that
[17:50:42] <akseli> it doesn't have installer packages but it should compile
[17:51:06] <thiago> understood
[17:51:45] <akseli> but that's status for 4.8.6 i guess
[17:52:53] <jaheikki3> OK, thanks akseli. Any questions?
[17:53:31] <thiago> one left:
[17:53:31] <thiago> QtDBus on Mac
[17:53:31] <thiago> can we get the libdbus-1 headers added to the Mac builders?
[17:56:48] <jaheikki3> Well, I don't have opinion related to this. I quess those are needed`?
[17:57:18] <jaheikki3> thiago: Was these some error related to this?
[17:57:31] <jaheikki3> these==there
[17:58:13] <thiago> yes
[17:58:20] <thiago> the QtDBus module is missing on our binaries
[17:59:13] <sahumada> the documentation needs to be updated if we provide D-Bus on OS X http://qt-project.org/doc/qt-5/macosx-issues.html#d-bus
[17:59:28] <thiago> also updated
[17:59:40] <thiago> I've removed that section of the docs. Just waiting for approval.
[18:00:40] <jaheikki3> akseli, kkoehne: Any comments/opinions?
[18:01:18] <kkoehne> jaheikki3: No, sorry.
[18:01:57] <sahumada> if D-Bus is added for Qt 5 .. should also be added for 4.8.6 ?
[18:02:07] <thiago> sahumada: it's already done in Qt 4
[18:02:08] <akseli> jaheikki3: i can only remember that we had headache from dbus in the past but not the real reason why
[18:02:11] <thiago> it used to be, at least
[18:02:17] <thiago> since Qt 4.3 or 4.4
[18:02:31] <thiago> but I won't hold it back. 4.8 is jut too difficult for us.
[18:02:43] <sahumada> at least QTBUG-6429 is marked as open for 4.8.2 as well
[18:02:52] <thiago> I reopened the bug
[18:02:58] <thiago> let's forget Qt 4 for now
[18:03:07] <thiago> this is about 5.3. Possibly 5.2.2.
[18:04:07] <thiago> I can adapt the configure detection if necessary. Right now, it rqeuires pkg-config too.
[18:04:47] <jaheikki3> I think we can try that for 5.3
[18:05:46] <jaheikki3> Just to be sure what needs to be done: add libdbus-1 headers to the Mac builders
[18:06:19] <jaheikki3> I'll ask heikki to do this for 5.3. What else?
[18:07:18] <thiago> well, just approve the task and you'll see if the builders fail :-)
[18:07:25] <jaheikki3> ;)
[18:09:52] <jaheikki3> Ok, I think we are almost ready. Let's have new meeting next monday at this same time, OK?
[18:10:21] <thiago> ok
[18:11:23] <jaheikki3> Let's then end this meeting now & meet again next monday. Thanks for everyone!
[18:11:30] <jaheikki3> bye
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/releasing/attachments/20140211/2b020ed8/attachment.html>
More information about the Releasing
mailing list