[Releasing] Meeting minutes from Qt Release Team meeting 26.03.2019
jani.heikkinen at qt.io
Wed Mar 27 08:13:49 CET 2019
Meeting minutes from Qt Release Team meeting 26th March 2019
- We start using openSSL 1.1* in 5.12.x and 5.13.0 ->
* Let's see if infra is in place for 5.12.4 and 5.13.0 beta n
** We won't block beta n because of missing openSSL 1.1 update but there needs to be at least one beta after the update.
- We will ship openSSL 1.1* libraries with our prebuild binaries for windows and linux. in macOS (&iOS) we don't use those and so on doesn't need to ship openSSL there
- Qt 5.9 will continue with openSSL 1.0*
Qt 5.13 status:
- API review still ongoing, see https://bugreports.qt.io/browse/QTBUG-73484
* 4 modules still missing '+2' (qtbase, qttools, qt3d & qtwebengine)
- Beta2 preparations started, target is to get beta2 out at the beginning of next week
* Beta2 blocker list here: https://bugreports.qt.io/issues/?filter=20729
** Few issues open atm. Work ongoing to get those fixed early enough
- Branching from '5.12' -> '5.12.3' started. Final downmerge from '5.12' to '5.12.3' will happen Monday 1st April
- Creating first snapshot ongoing
- Target is to get the release out latest April 12th
- Branching from '5.8' to '5.9.8' done
- Initial changes files created, see https://codereview.qt-project.org/#/q/message:%22Add+changes+file+for+Qt+5.9.8%22,n,z
* Maintainers: Please finalize changes files as soon as possible
- Target is to get the release out before Easter
* Release blocker list here: https://bugreports.qt.io/issues/?filter=20723
* RTA for first snapshot ongoing
Removing unsupported releases from online installer
- Proposal of removal done a week ago, see https://lists.qt-project.org/pipermail/development/2019-March/035441.html
* No objections -> unsupported releases will be removed from online installer at same time when new installers based on IFW 3.1 will be launched
Next meeting Tue 2nd April 2019 16:00 CET
irc log below:
[17:00:13] <jaheikki3> akseli: iieklund: thiago: fkleint: ZapB: tronical: vladimirM: aholza: peter-h: mapaaso: ankokko: fkleint: carewolf: fregl:ablasche:lars: ping
[17:00:16] <thiago> jaheikki3: pong
[17:00:19] <lars> jaheikki3: pong
[17:00:25] <ankokko_> jaheikki3: pong
[17:00:32] <akseli> jaheikki3: pong
[17:01:01] <jaheikki3> time to start qt release team meeting
[17:01:06] <jaheikki3> On agenda today:
[17:01:17] <jaheikki3> Qt 5.13 status
[17:01:19] <carewolf> pong
[17:01:24] <jaheikki3> Qt 5.12.3 status
[17:01:30] <jaheikki3> Qt 5.9.8 status
[17:01:30] <frkleint> jaheikki3: pong
[17:01:41] <jaheikki3> Removing unsupported releases from online installer
[17:01:44] <thiago> we need to discuss OpenSSL 1.1 for all three releases
[17:01:50] <jaheikki3> OpenSSL update
[17:02:09] <jaheikki3> thiago: yes, agree
[17:02:10] <lars> quite an agenda for today then :)
[17:02:45] <jaheikki3> We can start from openSSL issue because it is affecting all releases
[17:03:04] <jaheikki3> So let's start from it
[17:03:21] <jaheikki3> It seems we should start using openSSL 1.1*
[17:03:43] <thiago> well, it starts with the CI
[17:03:44] <jaheikki3> work to start using it is already ongoing, see QTQAINFRA-2327
[17:03:45] <qt_gerrit> jaheikki3: Latest OpenSSL 1.1.1 to provisioning - https://bugreports.qt.io/browse/QTQAINFRA-2327 (Need More Info)
[17:03:57] <thiago> ok
[17:04:14] <thiago> but let's discuss where we want to be
[17:04:34] <thiago> I'd say that 5.13 branch and further should test 1.1 and ship that one only
[17:04:40] <lars> I'd prefer if we can avoid having to create more binary packages.
[17:04:50] <jaheikki3> lars: Agree
[17:05:02] <lars> thiago: +1 on that. but it depends on having 1.1 in CI
[17:05:07] <thiago> right
[17:05:18] <jaheikki3> thiago: +1 for that as well
[17:05:24] <thiago> what about 5.12? Do we make the switch? Or do we provide both binaries?
[17:05:42] <thiago> BTW, how does the *installer* itself use OpenSSL?
[17:05:55] <lars> if we switch, we loose support for some 'older' linux distributions
[17:05:59] <jaheikki3> Unfortunately we need coin production update to be able to take that 1.1 in the use
[17:06:48] <lars> jaheikki3: I'd propose that we do the next 5.12 patch level release with 1.0, otherwise we'd delay that one for quite some time
[17:06:59] <thiago> does the installer ship with a bundled build of OpenSSL, a dynamic build of it, or does it depend on the system?
[17:07:19] <jaheikki3> thiago: according to my understadning it is bundled one
[17:07:24] -*- thiago agrees on 5.12.3 being still 1.0
[17:07:39] <jaheikki3> ankokko_: akseli:could you confirm
[17:07:49] <thiago> ok, so the installer isn't affected by our decision
[17:07:54] <jaheikki3> lars: Yeah, I agree
[17:08:20] <lars> thiago: not directly. but we should get that one upgraded to 1.1 independently
[17:08:30] <thiago> agreed
[17:08:47] <thiago> and please point out to the team to do so frequently
[17:08:53] <lars> jaheikki3: ankokko_: akseli: so one more task: upgrade installer to use 1.1
[17:09:10] <lars> (and keep it updated ;-)
[17:09:11] <jaheikki3> lars: thiago: I discussed that with kamartti today & she promised to do a task for that
[17:09:19] <thiago> ok, thanks
[17:09:23] <lars> great :)
[17:09:35] <thiago> but do we see any solution for 5.12 besides keeping two builds until the end of the yaer?
[17:10:39] <lars> thiago: the only other options would be:
[17:10:43] <lars> (1) dlopen/detect 1.0 vs 1.1 at runtime. Not sure that's possible, and probably quite some work to implement
[17:10:53] <lars> or (2) drop 1.0 support at some point
[17:11:13] <lars> (in the binaries, which means we leave some older linux distros behind)
[17:11:16] <thiago> I don't think (1) can. If it were possible, we'd already have done that, since OpenSSL is already dlopened
[17:11:23] <thiago> the problem is that the API did change
[17:11:26] <lars> jaheikki3: btw, what about other platforms?
[17:11:29] <carewolf> the way our code is ifdefing right now it is not possible, it would require some restructuring
[17:11:52] <thiago> we will drop 1.0, the only question is whether we do it before Dec 31.
[17:12:08] <jaheikki3> lars: to be honest I am not sure
[17:12:27] <thiago> what about other platforms?
[17:12:34] <lars> one solution to move to 1.1 and keep supporting older systems is to ship a copy of the lib
[17:12:40] <lars> in the binary packages
[17:12:48] <thiago> ship a copy of openssl?
[17:12:55] <lars> yep
[17:12:59] <thiago> that's... not a bad idea
[17:13:18] <thiago> but it needs to be kept up-to-date, frequently. I'd say no more than a monthly update.
[17:13:34] <lars> the installer has a copy already. and we should do that on windows anyways (long outstanding issue with our binary packages)
[17:13:49] <thiago> the installer has a copy but only the installer uses that copy
[17:14:04] <thiago> the worry is that people will ship our copy and then run into issues later
[17:14:33] <thiago> they've so far had to download the libs from somewhere and remember to keep that up to date. Whether they have or not is besides the point.
[17:14:45] <lars> thiago: that goes for other 3rd party libs as well (although I agree that those are less critical)
[17:15:09] <thiago> in some ways, libjpeg and libpng are worse
[17:15:10] <lars> thiago: it's probably less likely they keep them up to date that way than if we ship them
[17:15:37] <thiago> I'm not going to guess either way, but let's say we do ship 1.1:
[17:15:46] <thiago> a) do we do it for Linux only or do we do it for all?
[17:15:49] <lars> jaheikki3: with the new installer, is there a way to separate some of those 3rd party libs into a different section that we could update independently of Qt?
[17:15:56] <thiago> b) do we do it in 5.12 only or do we do it for 5.13 and ondwards?
[17:16:30] <jaheikki3> lars: hmm
[17:17:14] <jaheikki3> lars: so you mean 3.1 IFW
[17:17:16] <lars> thiago: if we start doing it for 5.12, we might as well continue. And on windows our Qt binaries are crippled currently because we do not ship it (and customers don't know how to fix it...)
[17:17:58] <lars> jaheikki3: was just thinking out loud :) It would be great if we could somehow decouple those 3rd party libs from Qt release cycles
[17:18:23] <lars> mac shouldn't be a problem btw, as we're not using openssl there.
[17:18:25] <jaheikki3> lars: it should be possible but requires some work of course
[17:18:49] <lars> jaheikki3: well, we have some time to get it done.
[17:19:01] <jaheikki3> that's true
[17:19:07] <thiago> so our current proposal is that we ship OpenSSL 1.1, keep it updated, starting in 5.12.4 and onwards
[17:19:30] <thiago> 5.13.0 beta may not ship with that if the infra isn't in place, but it should be *built* for 1.1.
[17:19:58] <lars> thiago: ideally from 5.12.4 onwards, yes. but as it requires some infra work, let's see when things are in place
[17:20:02] <thiago> it looks like OpenSSL 3.0 (the next release over, they're skipping 2.0) may break again, so this sounds like a good solution
[17:20:03] <carewolf> only shiping it where the platforms in questions might not have it?
[17:20:29] <thiago> carewolf: Windows never has it, I don't think macOS has. Older Linux don't and detecting sounds difficult.
[17:20:40] <thiago> strike that about macOS, we don't use OpenSSL there
[17:20:44] <carewolf> but on windowsn and mac we can use the builting ssl support
[17:20:52] <carewolf> right
[17:21:03] <thiago> but that ends up with detection not being worth it
[17:21:07] <lars> carewolf: I thought we're still using openssl on windows?
[17:21:14] <carewolf> you are right
[17:22:00] <lars> ok, I see a plan emerging. what about 5.9 though?
[17:22:09] <thiago> now that's a difficult one.
[17:22:11] <carewolf> I was thinking of linux distros that switched to having 1.1 a long time ago, where we don't support any versions without
[17:22:31] <thiago> carewolf: we don't have a per-distro binary. It's "Linux".
[17:22:47] <lars> carewolf: unfortunately there are a few that still use 1.0, so best option is to ship 1.1 ourselves
[17:22:48] <thiago> options for 5.9, that I can think of:
[17:22:52] <carewolf> ohh. ok
[17:23:13] <thiago> a) do nothing and keep releasing 5.9 until May/2020, which means it'll be 6 months beyond its SSL expiry date
[17:23:24] <thiago> b) shorten 5.9 cycle to Dec/2019
[17:23:42] <thiago> c) backport the OpenSSL 1.1 code
[17:23:53] <thiago> c.1) same branch; c.2) new 5.9 branch
[17:24:05] <lars> hmmm... does anybody have an idea how much work (c) is?
[17:24:11] <jaheikki3> I vote a)
[17:24:25] <thiago> the original patch was backportable. Several Linux distros did it.
[17:24:37] <carewolf> lars: it is a lot of code, but I think it would apply cleanly, it was commited right after the branch point
[17:24:40] <lars> jaheikki3: possible, but we should then be rather pro-active in communicating this.
[17:24:41] <thiago> the problem are the corrections after that
[17:25:06] <carewolf> the real question is: what is the point if bumbing openssl breaks ABI anyway?
[17:25:07] <thiago> but if we pick them all, the corrections should apply too
[17:25:26] <lars> carewolf: it wouldn't break Qt's ABI
[17:25:27] <carewolf> or does it break it if we ship it?
[17:25:44] <thiago> (a) would be simplest for us and we advise people that QSslSocket should no longer be used in 5.9 after the end of this year
[17:25:48] <thiago> they should upgrade
[17:27:00] <thiago> I vote for (a) too
[17:28:17] <lars> I agree. We could keep option (c) open if someone does the required work. It could e.g. happen that one of our larger customers needs it and is willing to pay for the work.
[17:28:54] <lars> but (a) would be what we plan for right now.
[17:29:03] <thiago> they should commission that work sometime before June
[17:29:24] <lars> yes, or it will most likely not happen in time
[17:30:15] <thiago> do we need any communication? Since we're not doing anything special and we're not shipping OpenSSL
[17:31:31] <lars> we should write something about us moving to 1.1 in our packages. Then we can at the same time communicate the 5.9 status
[17:31:39] <lars> blog post is enough IMO
[17:31:41] <thiago> ok
[17:31:59] <thiago> changelogs for 5.12.3 and 5.13.0 too
[17:32:11] <lars> yes
[17:32:19] <thiago> I'll take the action to write those when the time comes
[17:32:57] <jaheikki3> thiago: why changelogs for 5.12.3? Didn't we ageed to deliver that with old openSSL still
[17:33:03] <lars> ok. blog post, we either add it to the release blog post or do a separate one.
[17:33:11] <thiago> a warning that it will change
[17:33:19] <jaheikki3> ahh, OK.
[17:33:42] <jaheikki3> So is our desixion following:
[17:33:56] <jaheikki3> - We start using openSSL 1.1 in 5.12.x and 5.13.0
[17:33:56] <jaheikki3> * Let's see if infra is in place for 5.12.4 and 5.13.0 beta n
[17:33:56] <jaheikki3> - We will ship openSSL 1.1 libraies with our prebuild binaries for windows and linux. in macOS we don't use those & so on doesn't need to ship those
[17:33:56] <jaheikki3> - Qt 5.9 will continue with openSSL 1.0*
[17:34:46] <thiago> macOS and iOS, yes
[17:35:12] <carewolf> what about android?
[17:35:59] -*- thiago has no idea about how Android works
[17:36:04] <jaheikki3> there is QTBUG-71391 already for that
[17:36:04] <qt_gerrit> jaheikki3: Android: Use OpenSSL 1.1 for Android SDK - https://bugreports.qt.io/browse/QTBUG-71391 (Open)
[17:36:13] <thiago> do we use a system OpenSSL or do people bundle one?
[17:36:40] <lars> we probably need to bundle unless we want to drop support for older android versions
[17:36:50] <lars> but I'm unsure about that.
[17:37:09] <lars> let's check with the people who know android
[17:37:29] <carewolf> going through the ssl qmake files, it also appears winrt has its own thing
[17:37:38] <thiago> anyone who wants to continue using OpenSSL 1.0 after the end of this year will need to get fixes from their vendors, not from OpenSSL
[17:37:53] <thiago> it stands to reason Android vendors will do that if they won't upgrade
[17:37:58] <thiago> (I say that with a straight face)
[17:38:41] <thiago> winrt is not using OpenSSL, so it's not an issue
[17:39:21] <carewolf> exactly
[17:39:26] <thiago> I think we need more info on Android. Let's see what those in the know reply when the minutes are posted.
[17:39:51] <jaheikki3> yeah
[17:40:07] <lars> thiago: at least, it's not really our responsibility to do the fixes
[17:41:09] <jaheikki3> Ok, was this all about openSSL issue at this time?
[17:41:15] <thiago> no, but the point is that we could get users/customers arguing that their vendor *is* providing the fixes and therefore we should continue to support OpenSSL 1.0. (RHEL 7 might be a more acceptable case)
[17:41:32] <thiago> yeah, i think we should close it for now. there'll be more discussion, but we need to move on :-)
[17:41:45] <jaheikki3> :D
[17:42:28] <jaheikki3> Ok, then let's browse through quickly release statuses
[17:42:36] <jaheikki3> First Qt 5.13
[17:42:52] <jaheikki3> API review still ongoing, see https://bugreports.qt.io/browse/QTBUG-73484
[17:42:53] <qt_gerrit> jaheikki3: API change review for 5.13 vs v5.12.0 - https://bugreports.qt.io/browse/QTBUG-73484 (Reported)
[17:43:01] <jaheikki3> * 4 modules still missing '+2' (qtbase, qttools, qt3d & qtwebengine)
[17:43:24] <jaheikki3> Beta2 preparations started, target is to get beta2 out at the beginning of next week
[17:43:34] <jaheikki3> Beta2 blocker list here: https://bugreports.qt.io/issues/?filter=20729
[17:44:03] <thiago> we have one more blocker now: the CI update for OpenSSL 1.1
[17:44:05] <jaheikki3> There is that androin openSSL issue but as agreed above let's not block beta2 because of it
[17:44:07] <thiago> well, RC blocker
[17:44:30] <jaheikki3> thiago: yes, i'll add that in rc blocker list
[17:44:56] <thiago> I'd say we need at least one beta after the CI switches
[17:45:07] <jaheikki3> agree
[17:45:43] <lars> sounds ok. I'll make a note to have a look at the missing API reviews tomorrow
[17:45:56] <jaheikki3> thanks
[17:46:05] <jaheikki3> that was all about 5.13 status at this time
[17:46:12] <jaheikki3> then Qt 5.12.3
[17:46:20] <jaheikki3> Branching from '5.12' -> '5.12.3' started. Final downmerge from '5.12' to '5.12.3' will happen Monday 1st April
[17:47:10] <jaheikki3> Creation of first snapshot started. Target is to get it done for RTA during this week
[17:47:32] <jaheikki3> initial changes files will be created after branching is finalized (as usual)
[17:47:55] <jaheikki3> That's all about 5.12.3 status at this time Any comments or questions?
[17:48:04] <thiago> ah, there's the branch
[17:48:25] <thiago> we're looking at a release when?
[17:48:36] <thiago> if the downmerge happens next Monday
[17:48:41] <jaheikki3> Target is to get it out before easter
[17:49:06] <jaheikki3> but it depends how quickly we can get changes files ready
[17:49:07] <thiago> ok, so latest Friday April 12
[17:49:32] <lars> sounds good.
[17:49:49] <thiago> I should have time on the plane on the way back from QtDay.it next Tuesday to edit the changes file
[17:49:59] <jaheikki3> thiago: I would say latest wed 17 april
[17:50:13] <thiago> I'd say the week of the 15 is risky
[17:50:21] <thiago> you're already losing people left and right to vacations
[17:50:28] <jaheikki3> that's true
[17:50:30] <thiago> so let's aim for the 12th
[17:50:40] <jaheikki3> Ok for me
[17:50:50] <thiago> I promise the qtbase changes file by Wednesday morning Europe time
[17:51:01] -*- thiago goes to buy a one month on-board WiFi subscription
[17:51:28] <jaheikki3> :D Thanks
[17:51:41] <jaheikki3> Ok, it was all about 5.12.3 at this time.
[17:51:44] <jaheikki3> Then Qt 5.9.8
[17:51:54] <jaheikki3> Branching from '5.8' to '5.9.8' done
[17:52:03] <jaheikki3> Initial changes files created, see https://codereview.qt-project.org/#/q/message:%22Add+changes+file+for+Qt+5.9.8%22,n,z
[17:52:29] <jaheikki3> Release blocker list here: https://bugreports.qt.io/issues/?filter=20723
[17:52:34] <jaheikki3> Empty at the moment
[17:53:06] <jaheikki3> carewolf: what about chromium update for 5.9.8?
[17:53:26] <jaheikki3> First snapshot created & RTA is ongoing
[17:53:43] <jaheikki3> Let's see what is found from there...
[17:55:03] <thiago> carewolf: ^^
[17:55:19] <lars> jaheikki3: maybe check that offline with carewolf :)
[17:55:20] <carewolf> jaheikki3: we prioritized 5.12.3 first
[17:55:39] <carewolf> but is on the schedule
[17:56:22] <jaheikki3> great. So it is pretty much that + changes files + possilbe new blockers from RTA
[17:56:38] <jaheikki3> so we should be ready to be release quite soon
[17:56:49] <lars> great
[17:56:58] <jaheikki3> That's all about 5.9.8 at this time
[17:57:00] <thiago> so after easter for 5.9.8
[17:57:32] <jaheikki3> thiago: i would say that might happen already before if there isn't any suprises
[17:57:50] <jaheikki3> it is already .8 and so on should be quite easy
[17:58:25] <jaheikki3> but we are more wiser after rta is completed for that first snapshot
[17:58:47] <jaheikki3> Then the final item: Removing unsupported releases from online installer
[17:58:56] <jaheikki3> Proposal of removal done a week ago, see https://lists.qt-project.org/pipermail/development/2019-March/035441.html
[17:59:20] <jaheikki3> there weren't any objections so far
[18:00:20] <jaheikki3> so I think we can proceed with that plan & remove those unsupported releases from online installer at same time when new installers based on IFW 3.1 is launched
[18:00:31] <lars> +1 from my side
[18:00:31] <jaheikki3> any comments or questions?
[18:02:25] <akseli> +1
[18:02:33] <ankokko_> +1
[18:02:40] <jaheikki3> Ok, great. Let's proceed with that plan
[18:03:14] <jaheikki3> It was all at this time. Let's end this meeting now & have new one Tue 2nd April as planned
[18:03:24] <jaheikki3> Thanks for your participation, bye!
[18:03:26] <lars> jaheikki3: thanks! see you next week
[18:03:35] -*- thiago will be on a plane at this time next week
[18:03:39] <ankokko_> thanks, bye
[18:04:07] <thiago> oh, but I'll have internet
More information about the Releasing