[Releasing] Meeting minutes from Qt Release Team meeting 17.11.2020

[Jani Heikkinen]

Meeting minutes from Qt Release Team meeting Tue 10th November 2020

Qt 6.0 status:
- Beta5 published earlier this week
- RC delayed, target is to get the RC out at the end of this week
   * Content needs be in Thu 19th November before noon
   * RC blocker list here: https://bugreports.qt.io/issues/?filter=22682
- Branching from 'dev' to '6.0' and '6.0.0' will happen later this week
      
Qt 5.15.2:
* Release content in place and package testing ongoing
* We will release Qt 5.15.2 later this week if no new surprises found

Next meeting Tue 24th November 2020 16:00 CET

Br,
Jani Heikkinen
Release Manager

irc log below:
[17:00:40] <jaheikki3> akseli: iieklund: thiago: lars: frkleint: vladimir-m: ankokko: mapaaso:carewolf: fregl: ablasche: ping
[17:00:47] <thiago> jaheikki3: pong
[17:00:47] <lars> jaheikki3: pong
[17:02:28] <jaheikki3> Time to start qt release team meeting
[17:02:33] <jaheikki3> On agenda today:
[17:02:40] <jaheikki3> Qt 6.0.0 status
[17:02:48] <jaheikki3> Qt 5.15.2 status
[17:03:00] <jaheikki3> Any additional item to the agenda?
[17:04:51] <jaheikki3> let's start from Qt 6.0.0 status:
[17:05:00] <jaheikki3> Beta5 published earlier this week
[17:05:36] <jaheikki3> Unfortunately we need to delay RC a bit; there is stlll issues open in blocker list
[17:05:51] <jaheikki3> But target is to get the RC out at the end of this week
[17:06:11] <jaheikki3> RC blocker list here: https://bugreports.qt.io/issues/?filter=22682
[17:06:42] <jaheikki3> To be able to get RC out at the end of this week we need to have all fixes in latest thu noon
[17:07:51] <jaheikki3> We should also branch Qt 6.0 and Qt 6.0.0 before RC so I propose we will start branching later this week
[17:08:21] <thiago> I see way too many important changes in flight
[17:08:57] <jaheikki3> thiago: what do you mean?
[17:10:17] <thiago> QtypeInfo, performance in QList, QChar constructors
[17:10:24] <thiago> the name of binaries
[17:10:39] <lars> QList is merged, QTypeInfo should also be done
[17:12:11] <jaheikki3> What is 'the name of binaries' issue?
[17:12:23] <lars> anything missing in QChar can be done in 6.1 afaict
[17:12:58] <lars> name of binaries probably refers to Linux distributors not liking that we didn't change names of apps from 5 to 6.
[17:13:20] <lars> But I am honestly not a fan at all of suffixing everything with a 6 or -6.
[17:14:04] <jaheikki3> Yeah, agree
[17:14:22] <lars> afaict it's only a problem for Linux distributors and only because Linux file system standard insists on installing everything into /usr/bin.
[17:15:28] <lars> we have a solution for it that Thiago developed for Qt 5, and that's actually in use at least in Ubuntu. I still don't get why this is now not a solution anymore.
[17:16:25] <thiago> that tool is deprecated
[17:16:30] <thiago> I am not making releases of it anymore
[17:16:34] <thiago> distributions will not use it
[17:16:40] <lars> ubuntu uses it.
[17:16:45] <thiago> won't for 6
[17:16:57] <thiago> they will rename the binaries. That means this affects everyone, since it's what users need to know to run.
[17:17:08] <thiago> they need to be taught in the documentation what name to use
[17:17:31] <thiago> can we accept that 6.1 changes the names incompatiibly with 6.00?
[17:17:49] <thiago> if the answer is "no", we need to conclude the discussion before 6.0
[17:17:49] <lars> I still don't see why. This makes things harder in so many places IMO. separate different Qt versions by path and you have a simple, working solution
[17:18:02] <thiago> what is the path?
[17:18:10] <lars> a file system path
[17:18:33] <thiago> ok, so the answer is "no Qt binaries in prefix, please ask your distro what the prefix is"
[17:18:37] <thiago> I can live with thtat
[17:18:42] <thiago> no qmake, no qml
[17:18:56] <thiago> no need for qtchooser
[17:19:36] <lars> I think we can consider something for runtime environments such as the 'qml' application
[17:19:37] <thiago> no assistant, no designer, no qdbus, no qdbusviewer
[17:19:54] <thiago> anyway, my point is this discussion needs to be concluded now, whatever the outcome is
[17:21:49] <lars> As said, my problem is that I to some extent struggle to see what the real problem is.  What is python doing for example? As far as I know they didn't do renaming of binaries neither, but I might be wrong.
[17:22:37] <thiago> the real problem is: Qt 5 is installed
[17:22:40] <thiago> now install Qt 6
[17:22:49] <thiago> python has different executable names
[17:22:51] <thiago> it's python3
[17:22:58] <thiago> /usr/bin/python is never python3
[17:23:29] <lars> well, yes and no.... :
[17:23:31] <lars> lrwxrwxrwx 1 root root 7 Apr 15  2020 /usr/bin/python -> python3
[17:23:44] <thiago> $ ls -l /usr/bin/python
[17:23:44] <thiago> lrwxrwxrwx 1 root root 9 ago 25 06:15 /usr/bin/python -> python2.7
[17:24:11] <The-Compiler> Python actually has a document with suggestions for distributions about this
[17:24:26] <The-Compiler> https://www.python.org/dev/peps/pep-0394/
[17:24:27] <lars> do you have a link?
[17:24:29] <lars> thx
[17:24:30] <thiago> if you only have python3, I suppose your distro may have updated the link. Since we're in 2020, that's now possible.
[17:25:15] <thiago> anyway, we need to conclude this discussion before 6.0, so this is a blocking task
[17:25:28] <The-Compiler> tl;dr: /usr/bin/python can be either nonexistent, python 2, or python 3 (and there are many polyglot scripts where this makes sense to use), but if you want python 2 or 3 explicitly, use /usr/bin/python2 or /usr/bin/python3
[17:26:10] <The-Compiler> it feels quite natural to me for Qt to do the same for executables which need to coexist, otherwise every distribution will probably patch it in anyways, except in perhaps slightly incompatible ways
[17:27:55] <jaheikki3> Ok, that sounds something to be concluded in dev ML, right? if so @lars could you sent conclusion proposal/your decision there? For me this sounds too big issue to be changed at this point anymore
[17:28:11] <lars> thiago: ok, how about we talk through this after this meeting and see what can be done. But I think we might need to push the solution to 6.0.1 or 6.1, as I don't think we can solve this without some weeks of work.
[17:28:39] <lars> And we should really have handled this much, much earlier. 
[17:28:57] <thiago> ok
[17:29:01] <jaheikki3> Agree
[17:29:47] <jaheikki3> ok, this was all about Qt 6.0.0 status now.
[17:29:57] <jaheikki3> Then quick Qt 5.15.2 status update
[17:30:12] <jaheikki3> Release content is in place 
[17:30:24] <jaheikki3> package testing is ongoing
[17:30:35] <jaheikki3> We will release Qt 5.15.2 later this week if no new surprises found
[17:30:57] <jaheikki3> That's all about Qt 5.15.2 status at this time. Any comments or questions?
[17:32:40] <jaheikki3> Ok, lets end this meeting now & have new one tue 24th November 2020 at this same time
[17:32:50] <lars> ok, thanks Jani.
[17:32:56] <jaheikki3> thanks for your participation! bye