[Development] Meeting minutes from Qt Release Team meeting 23.01.2024
Qt 6.6 status * Branching from '6.6' to '6.6.2' done * The target is to freeze the Qt 6.6.2 release content latest by the end of this week * The target is to release Qt 6.6.2 by the end of January Qt 6.7 status: * All known issues from '6.7' dependency update round fixed and new dependency update round ongoing * The target is still to release Qt 6.7.0 Beta2 soon after next successful dependency update round in '6.7' * API review is ongoing & proceeding, see https://bugreports.qt.io/browse/QTBUG-119952 * Updating 3rd party components for Qt 6.7 started, see https://bugreports.qt.io/browse/QTBUG-121323 Next meeting Tue 30th January 2024 16:00 CET br, Jani Heikkinen Release Manager irc log below: [17:00:19] <+jaheikki3> ablasche: akseli: carewolf: frkleint: mapaaso: The-Compiler: thiago: vohi: ping [17:00:29] pong [17:00:39] jaheikki3: pong [17:01:47] <+jaheikki3> time to start qt release team meeting [17:01:54] jaheikki3: pong [17:01:55] <+jaheikki3> on agenda today: [17:01:59] jaheikki3: pong [17:02:01] <+jaheikki3> Qt 6.6 status [17:02:07] <+jaheikki3> Qt 6.7 status [17:02:17] <+jaheikki3> Any additional item to the agenda? [17:03:40] <+jaheikki3> Ok, let's start from Qt 6.6 status [17:04:14] <+jaheikki3> Dependency update issues in '6.6' finally fixed and branching from '6.6' to '6.6.2' finally done [17:04:40] <+jaheikki3> The target is to freeze the Qt 6.6.2 release content latest by the end of this week [17:04:59] <+jaheikki3> And the target is still to release Qt 6.6.2 by the end of January [17:05:32] <+jaheikki3> that's all about Qt 6.6 status at this time. Any comments or questions? [17:05:55] sounds good [17:06:10] <+jaheikki3> great [17:06:22] <+jaheikki3> then Qt 6.7 status: [17:07:20] <+jaheikki3> All known issues from '6.7' dependency update fixed and new dependency update round in it's final steps [17:07:52] <+jaheikki3> Hoping there isn't anymore nothing new and we could get update round finally done in '6.7' [17:08:33] <+jaheikki3> if that succeed it will be then Qt 6.7 beta2content [17:09:32] jaheikki3: https://wiki.qt.io/Main doesn't have any Qt 6.7 timeline, and still talks about 6.6 being in Beta Release status [17:10:02] <+jaheikki3> And if RTA doesn't find anything alarming we will release that as Qt 6.7 beta2. Hoping that can happen either this friday or then at the beginning of next week [17:10:27] <+jaheikki3> vohi: thanks, I'll update the page asap [17:10:48] <+jaheikki3> Qt 6.7 API review is ongoing & proceeding, see https://bugreports.qt.io/browse/QTBUG-119952 [17:11:16] <+jaheikki3> let's try to complete the reviews as soon as possible [17:11:29] <+jaheikki3> Updating 3rd party components for Qt 6.7 also started, see https://bugreports.qt.io/browse/QTBUG-121323 [17:11:51] <+jaheikki3> I think it is all about 6.7 status. Any comments or questions? [17:14:32] not from me [17:14:51] <+jaheikki3> Ok, it was all at this time so let's end this meeting now & have new one Tue 30th January at this same time [17:15:01] <+jaheikki3> Thanks for your participation, bye! [17:15:14] by [17:16:50] bye -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Question about the licensing of the Protobuf-Module
The fix is here: https://codereview.qt-project.org/c/qt/qtgrpc/+/533391 -- Alex From: Development on behalf of Frank Meerkötter Sent: Tuesday, 23 January 2024 09:19 To: development@qt-project.org Subject: Re: [Development] Question about the licensing of the Protobuf-Module Thank you for the clarification On 22.01.24 19:53, Elias Steurer via Development wrote: > This was (sadly) a bug, see comments: > https://bugreports.qt.io/browse/QTBUG-117783 > > Cheers , > > Eli > > On 1/22/2024 10:29 AM, Frank Meerkötter wrote: >> I am looking for a clarification on the licensing of the >> Protobuf-Module. >> >> The code in https://code.qt.io/cgit/qt/qtgrpc.git/tree/src/protobuf >> has // SPDX-License-Identifier: LicenseRef-Qt-Commercial OR >> LGPL-3.0-only OR GPL-2.0-only OR GPL-3.0-only >> >> While the code in >> https://code.qt.io/cgit/qt/qtgrpc.git/tree/src/protobufqttypes/protobufqtcoretypes >> has // SPDX-License-Identifier: LicenseRef-Qt-Commercial OR >> GPL-3.0-only WITH Qt-GPL-exception-1.0 >> >> Is this intentional? >> >> Can I - wearing a LGPL3-hat - use the protobuf module? >> >> Thank you, >> Frank >> -- Frank Meerkötter Development Lead basysKom GmbH Robert-Bosch-Str. 7 | 64293 Darmstadt | Germany Tel: +49 6151 870 589 - 161 | Fax: -199 frank.meerkoet...@basyskom.com | http://www.basyskom.com/ Handelsregister: Darmstadt HRB 9352 Geschaeftsfuehrende Partner: Heike Ziegler, Alexander Sorg -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Marking the Tech Preview APIs as such
Volker Hilsheimer (23 January 2024 10:00) wrote: > I also like the general idea of supporting the header review process > with more information, such as links to the relevant documentation, or > even a documentation diff, or even change on gerrit that introduced > the change; but that’s probably orders of magnitude harder and complex > to implement, so let’s not wait for that. Doing this as part of the api-review-gen process would complicate an already brittle process, but it might be possible to write a gerrit script that would, in similar manner to the inanity 'bot, scan these reviews and post links to docs.qt.io for the new API or, perhaps more valuably, determine whether there *are* docs there and post comments on the review if not. That would decouple the doc-posting from the scripts that generate the reviews. We should also consider coaxing the inanity 'bot and API-change 'bot into recognising the API change reviews (they have a recognisable first line of commit message pattern) and not spamming them with irrelevancies. Eddy. -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Marking the Tech Preview APIs as such
> On 22 Jan 2024, at 22:15, Giuseppe D'Angelo via Development > wrote: > > Il 22/01/24 19:03, Shawn Rutledge via Development ha scritto: >> I guess your goal is to be able to see it in the header rather than having >> to look up the docs in the cpp file or online? (Alternatively we could >> write all docs in headers, but then the headers get to be large, take >> storage space alongside every installation of Qt binaries, and slow down >> everyone’s compilations, so I guess that’s why we don’t do it that way? Or >> we could somehow include doc diffs in API review patches for whatever API >> the script has already decided is “interesting".) > > As I said, it's not just in order to see the tag in the header when the code > is introduced, but also to see that a TP class is getting out of TP status > because the tags are being removed (= the header is being touched, and will > appear in the header review). If \preliminary is removed from the docs, it > won't be obvious at API review time. > > My 2 c, > -- > Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer I like this proposal; having it visible in the header that an API is either new as, or still in, or moving out of tech preview is very useful information for the header review process. A QT_TECH_PREVIEW_API macro that expands to “whatever works” works for me. It can expand to nothing for the purpose of header review, but if we can make it an attribute that qdoc can use to implicitly add the relevant boilerplate to the respective reference documentation, then it removes the need to keep \preliminary documentation tagging in sync. I also like the general idea of supporting the header review process with more information, such as links to the relevant documentation, or even a documentation diff, or even change on gerrit that introduced the change; but that’s probably orders of magnitude harder and complex to implement, so let’s not wait for that. Moving documentation into the headers is a no-go for me, not only because of the overwhelming amount of status quo. Documentation needs to inform the user about what the API does (or, well, is supposed to do), and might need to change when the implementation does. This is less likely to happen when it lives next to the declaration. Volker -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Question about the licensing of the Protobuf-Module
Thank you for the clarification On 22.01.24 19:53, Elias Steurer via Development wrote: This was (sadly) a bug, see comments: https://bugreports.qt.io/browse/QTBUG-117783 Cheers , Eli On 1/22/2024 10:29 AM, Frank Meerkötter wrote: I am looking for a clarification on the licensing of the Protobuf-Module. The code in https://code.qt.io/cgit/qt/qtgrpc.git/tree/src/protobuf has // SPDX-License-Identifier: LicenseRef-Qt-Commercial OR LGPL-3.0-only OR GPL-2.0-only OR GPL-3.0-only While the code in https://code.qt.io/cgit/qt/qtgrpc.git/tree/src/protobufqttypes/protobufqtcoretypes has // SPDX-License-Identifier: LicenseRef-Qt-Commercial OR GPL-3.0-only WITH Qt-GPL-exception-1.0 Is this intentional? Can I - wearing a LGPL3-hat - use the protobuf module? Thank you, Frank -- Frank Meerkötter Development Lead basysKom GmbH Robert-Bosch-Str. 7 | 64293 Darmstadt | Germany Tel: +49 6151 870 589 - 161 | Fax: -199 frank.meerkoet...@basyskom.com | www.basyskom.com Handelsregister: Darmstadt HRB 9352 Geschaeftsfuehrende Partner: Heike Ziegler, Alexander Sorg -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
