Meeting minutes from Qt Release Team meeting Tue 1st December 2020 Qt 6.0.0 status: - RC released last Wed * Some new blockers reported & fixed - Target is to release RC2 wed 2nd December - We will release Qt 6.0.0 Tue 8th December 2020
Qt 6.1 schedule - Initial schedule announced by Lars, see https://lists.qt-project.org/pipermail/development/2020-November/040704.html * Feature freeze 30th January 2021 * Qt 6.1.0 final 27th April 2021 Next meeting Tue 15th December 2020 16:00 CET br Jani Heikkinen Release Manager irc log below: [17:00:19] <jaheikki3> akseli: iieklund: thiago: lars: frkleint: vladimir-m: ankokko: mapaaso:carewolf: ablasche: ping [17:00:26] <lars> jaheikki3: pong [17:00:27] <thiago_> jaheikki3: pong [17:00:39] <frkleint> jaheikki3: pong [17:01:25] <jaheikki3> Time to start qt release team meeting [17:01:31] <jaheikki3> On agenda today: [17:01:32] <carewolf> pong [17:01:36] <jaheikki3> Qt 6.0.0 status: [17:01:45] <jaheikki3> Qt 6.1 initial schedule [17:01:58] <jaheikki3> Any additional item to the agenda? [17:03:45] <jaheikki3> Lets start from Qt 6.0.0 status: [17:04:00] <jaheikki3> RC released last Wed [17:04:17] <jaheikki3> Testing done and some new blockers reported [17:04:42] <jaheikki3> All fixes should be in place and sha1 update round ongoing [17:04:55] <jaheikki3> Target is to release RC2 wed 2nd December [17:05:25] <carewolf> tomorrow, are all the blockers fixed? [17:05:45] <jaheikki3> carewolf: yes, those shoiuld be fixed now [17:06:12] <jaheikki3> And as planned we will release Qt 6.0.0 Tue 8th December [17:06:35] <jaheikki3> But that's all about Qt 6.0.0 status at this time. Any more comments or questions? [17:08:10] <thiago_> lars: do we ewant to fix the member order in the containers? [17:08:20] <thiago_> looks like it's a task we said "we'd do later" but haven't done yet [17:08:52] <lars> good question. I wonder how much it matters, given that the accesses are inline where things matters. [17:08:54] <frkleint> is this tool binary renaming story settled? [17:09:12] <frkleint> [as raised by distro maintainers] [17:09:48] <lars> frkleint: that's delayed until after 6.0.0. I'm still unsure how much we should or need to rename. [17:10:00] <frkleint> Hm [17:10:05] <thiago_> frkleint: we agreed on publishing a recommendation for 6.0.0 and aplying the actual change to the buildsystem later [17:10:11] <thiago_> that is, 6.0.0 will *not* install correctly [17:10:30] <lars> thiago_: fixing the member order would require another round of updates in CI. We could prepare the change and do it if we need other changes anyway. [17:11:26] <jaheikki3> lars: is that really something which has to be in Qt 6.0.0 or could it be part of Qt 6.0.1? For me it sounds a bit risky at this point... [17:11:40] <lars> it's either 6.0.0 or 7 [17:11:47] <hiago> right [17:12:03] <hiago> it's a performane improvement for something that is done hundreds of thousands of times per appliation [17:12:05] <lars> the change itself is pretty low risk, but it's not BC [17:13:05] <lars> (t) hiago: do we have any idea how much of a difference it would make? [17:14:25] <hiago> depends on the processor and how good the compiler is, but one or two cycles [17:14:43] <hiago> typically one cycle, from what I measured in the QAnyStringView case [17:15:23] <hiago> well, it's one *instruction*; the cycle itself might not be felt if the CPU speculated correctly ahead [17:16:11] <lars> so pretty small. I'd say we live with it, and add a fixme for Qt 7. [17:16:33] <hiago> if we want to [17:17:47] <hiago> it's very rare that compilers emit code that allows the CPU to run at max issue rate. We need to take care of those when it's in a loop and operating on memory. [17:17:53] <hiago> it's not the case here [17:18:49] <hiago> regular code is somewhat inefficient, so the CPU will absorb those inefficiencies by running slightly ahead anyway. Real-life performance won't match micro-benchmarks. [17:19:31] <lars> yes, so it won't really matter in real life [17:20:40] <hiago> not by a measurable amount [17:21:09] <hiago> any work carewolf or I or otheres do in pixel manipulation or string searches will drown it out [17:22:32] <carewolf> ok, so leaving it for qt7 if we remember or care [17:22:40] <lars> yep [17:22:48] <jaheikki3> agree [17:23:57] <jaheikki3> Ok, then Qt 6.1 initial schedule [17:24:18] <jaheikki3> Qt 6.1 initial schedule announced by Lars, see https://lists.qt-project.org/pipermail/development/2020-November/040704.html [17:24:20] <hiago> I think the accelerated schedule posted on the ML makes a lot of sense [17:24:37] <lars> great :) [17:24:45] <carewolf> so going on a 5 month cadence for two releases, and then back to 6 month cadencE? [17:24:54] <lars> that's the idea [17:24:58] <hiago> just remember that the buildsystem tool-renaming fix must land at 6.1 at the latest [17:24:59] <carewolf> sounds good [17:25:14] <carewolf> though it might make 6.1 tricky with all the property stuff [17:25:27] <lars> t hiago: yes, but we'll first need to work out what exactly needs to be done. [17:25:49] <lars> Maybe start writing things up in a QUIP? [17:26:14] <lars> carewolf: the property changes can be done incrementally, as adding binding support is BC :) [17:26:32] <lars> so whatever doesn't make it in 6.1, can be done in 6.2. [17:26:42] <carewolf> ok, as long as the base is done [17:27:00] <lars> we should try to get as much as possible done, I agree. [17:27:54] <jaheikki3> there isn't that much time to do new feature implementation for Qt 6.1 but we need to respect to FF to be able to keep the planned schedule [17:28:37] <hiago> I thought we agreed "all tools end in '6' except for tools we'll extract to a repository of their own" [17:29:30] <hiago> or am I mis-remebering and "all tools are private except for qmake6, qtdiag6, qtpaths6 and qml6"? [17:29:53] <hiago> sorry, scratch the comments, I need to re-read what I posted of what we agreed [17:30:08] <lars> well, the discussion on the ML didn't have agreement yet. I think most tools are private is something everybody was happy with though. [17:30:11] <hiago> I only remember we agreed and the 6.1 buildsystem (at the latest) will install correctly [17:32:16] <lars> the problem is the large amount of users that aren't linux distributions. Most of them prefer non postfixed names, because they work with multiple versions of Qt (both minor and now also major) [17:32:58] <carewolf> we could install symlinks by default? [17:33:22] <hiago> we discussed this, the vast majority of users don't run any of our tools directly, except qmake [17:33:39] <lars> but the ones they don't run directly do not need renaming anyway ;-) [17:33:53] <hiago> let's not re-discuss this here [17:34:14] <hiago> I'm just saying the buildsystem must do the right thing by 6.1 [17:34:22] <hiago> whatever the right thing is [17:34:26] <carewolf> :) [17:34:38] <jaheikki3> Yeah, let's complete that discusion in ML as soon as possible to be able to do needed things early enough for Qt 6.1 FF [17:34:43] <hiago> that means 6.0 docs or change log or release notes must warn that the tool names and paths will change [17:34:46] <lars> yes, wrong meeting. I think it's probably better to try to write up a proposal in a QUIP, and then work on it until we have a solution people can live with. [17:36:27] <jaheikki3> But it seems we all agree the schedule for Qt 6.1: FF at the end of January and Final at the end of April. Let's set target dates: FF 30th January.2021 and Final 27th April 2021 [17:36:50] -*- hiago checks on Easter [17:37:19] <jaheikki3> Easter is at the beginning of April [17:37:23] <lars> jaheikki3: we've been discussing this before, so I'm fine with the schedule :) [17:37:45] <carewolf> +1 [17:37:49] <frkleint> [definiton of FF probably needs refinement since the goal is to bring back the modules left out from 6.0.0..that will take more time than Jan I think] [17:37:51] <thiago> yep, not at release time, so good [17:37:56] -*- thiago still uses kalender.no [17:38:21] <thiago> which modules? If this includes qtwebengine, do you think you have enough time? [17:38:26] <lars> frkleint: those can and probably will get delivered indepenently when they are ready [17:38:34] <carewolf> it doesn't, qtwebengine is decoupled [17:38:38] <frkleint> Nope, WinExtras ActiveQt...canvas whatnot [17:38:45] <frkleint> 3d module of the day [17:38:54] <carewolf> qtwebsocket and qtwebchannel should be, but they are mostly ready, just cleaning them up [17:39:06] <lars> same plan for most others. we release them when they are ready. [17:39:16] <jaheikki3> frkleint: I don't think we are planning to do all but those which will be ready early enough. Others will be postponed to 6.2 [17:39:31] <frkleint> hm ok [17:39:39] <thiago> customers and distros alike will want to know when the plan calls for [17:40:01] <thiago> so I suggest a "best known estimate" to be published [17:40:09] <lars> the plan is to try to have the important add-ons back by 6.2 time. There might be one or two exceptions though, QtMM comes to my mind... [17:40:37] <lars> thiago: yes. I'm pushing for having a roadmap blog published together with or before the 6.0.0 release blog. [17:41:54] <thiago> ok, so announce 6.2 and say that some of simpler ones may be delivered in 6.1, but don't count on it [17:42:26] <lars> something like that. I think we can be a bit more specific than that though :) [17:42:51] <jaheikki3> I think this was all at this time. I think we can skip tue 8th Dec & have next meeting 15th December, OK [17:43:23] <frkleint> bye [17:45:20] <akseli> +1 for the next meeting 15th December [17:45:26] <jaheikki3> Great, let's end this meeting now. Thanks for your participation, bye! [17:45:42] <thiago> bye [17:46:58] <lars> bye _______________________________________________ Releasing mailing list Releasing@qt-project.org https://lists.qt-project.org/listinfo/releasing
