Re: [Development] moc output from non-local tool build

[Thiago Macieira]

On Wednesday, 10 November 2021 03:29:15 PST Marius Kittler wrote:
> Am Dienstag, 9. November 2021, 19:59:29 CET schrieb Thiago Macieira:
> > On Friday, 5 November 2021 08:28:20 PST Scott Bloom wrote:
> > > Why wouldn’t they simply have two versions of Qt ( or more) the one they
> > > are targeting for desktop, and the previous one they are targeting for
> > > android/"remote"
> > 
> > I don't mind that. If we enforce you must have a matching version of the
> > host tools, then we do it.
> > 
> > Since I don't cross compile, people who do should speak up and explain why
> > it would be too difficult for them to have a native build of the same
> > version of Qt they're going to cross-compile.
> > 
> > Silence will mean consent.
> 
> It would of course be possible to conduct a 2nd host build which would only
> be updated in accordance with the cross-builds. I suppose it would also be
> possible to strip this 2nd build down to "tools only" by specifying some
> CMake variables. It also needed to be installed within a different prefix
> to avoid conflicts with the normal host build.

Please clarify what you meant by "2nd host build". Do mean "2nd build, which 
is host" or did you really mean "another host build for a total of 3 builds"? 
I assume it's the former.

Considering tools aren't going to be bootstrapped any more, the host build of 
the tools might be quite complete. It needs to include at least every library 
that the tools depend on. So for example it will need to go all the way to 
qttools to build QtHelp so qhelpgenerator may link to it. I don't know if 
there's something that we can do in the CMake side to enable only those 
targets by default, but the difference might actually be so small that it's 
not worth maintaining.

> However, it would certainly be more efficient and less packaging work to
> simply be able to reuse the normal host build which is already in the
> distribution. So it would just make packaging easier.

Indeed. The proposal was how old that build can be. Can you count on the host 
Linux distribution being up-to-date enough to have N-1 or even N-3? Because 
you can't, then the point is moot.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel DPG Cloud Engineering



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt Governance: Vote of no confidence

[Lars Knoll]

As the vote was not contested during the last two weeks, the change in approver 
rights has now been implemented.

The voting results will be deleted in another 14 days from now (2 weeks after 
the final decision), as stated in the proposal for the voting procedure.

Best regards,
Lars

On 29 Oct 2021, at 09:53, Lars Knoll 
mailto:lars.kn...@qt.io>> wrote:

Hi all,

The vote has been closed on Tuesday night. 33 Approvers voted, 24 in favour of 
the no confidence vote, 9 against. This means that the no-confidence vote 
passed the required quorum of 2/3 of the votes as defined in QUIP-2.

The detailed voting results by moniker are listed at the end of the email 
again, so people can verify that their own vote got counted correctly.

This result means that the Qt Project doesn’t have confidence in Ossi as an 
Approver and we will therefore remove his general Approver rights. According to 
the voting procedure outlined in the thread starting at 
https://lists.qt-project.org/pipermail/development/2021-October/041833.html 
there is a 14 days period for possible objections, so the change in Approver 
rights will be implemented once that period has passed.

It’s also important to note that Ossi is the Maintainer of qttranslations. He 
will keep the Maintainer and Approver rights for this module, as we have lots 
of precedence where individuals are Maintainers for a specific module without 
having Approver rights for the Qt Project as a whole.

Best regards,
Lars


pale-comparison false
tangy-help  true
subsequent-frametrue
puny-expansion  true
permissible-hammer  true
elastic-needle  true
near-fanfalse
peaceful-look   false
ugliest-reactiontrue
assorted-plot   true
yummy-heart true
frequent-value  true
strange-owner   true
doubtful-flesh  true
dramatic-power  true
humorous-frogs  true
male-bells  true
military-bead   true
dispensable-experience  true
profuse-deertrue
swift-magic true
drab-patch  false
knowing-deerfalse
cheerful-bridge true
petite-rifletrue
energetic-umbrella  true
gifted-volleyball   true
sudden-porter   true
curved-cub  true
finicky-plantation  false
nimble-tablefalse
fluffy-window   false
wakeful-cracker false




On 19 Oct 2021, at 09:57, Lars Knoll 
mailto:lars.kn...@qt.io>> wrote:


Hi all,

We had a request for a vote of no confidence against Oswald Buddenhagen by Ivan 
Komissarov some weeks ago (*). Such a vote can be asked for by another Approver 
according to our governance model (**).

As this was the first time this passus got invoked, we had to do some work to 
put a voting system in place. Thanks to work by Daniel, this is now in place 
and we can now proceed with the request for a vote of no confidence.

The actual voting is open to all Approvers and Maintainers and happens on 
https://governancevoting.qt-project.org/voting. Voting is anonymous, but you 
will get a random moniker assigned after voting. Please store that moniker 
somewhere, as it’ll allow you to verify that your vote has been correctly 
counted when the voting period ends.

I’d like to urge everybody who is going to cast a vote to make themselves 
familiar with the full mailing list thread in (***) and read through the 
relevant parts of QUIP-2 before voting. Voting will be open for one week and 
closes on Monday, 25.10.21 at 23:59 CET.

Best regards,
Lars

(*) 
https://lists.qt-project.org/pipermail/development/2021-September/041799.html
(**) http://quips-qt-io.herokuapp.com/quip-0002.html, How to become an Approver
(***) 
https://lists.qt-project.org/pipermail/development/2021-September/041750.html
___
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

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] HEADS-UP: Qt 6.3 Feature Freeze is getting closer...

[Paul Wicking]

On 10 Nov 2021, at 11:42, Jani Heikkinen 
mailto:jani.heikki...@qt.io>> wrote:

Hi all,

Just a kindly reminder: Qt 6.3.0 Feature Freeze will be in effect 10th December 
2021 so there is a month left for implementing new features, modules etc for Qt 
6.3

It is also time to start listing new features in the release so please start 
updating Qt 6.3 new features page here: 
https://wiki.qt.io/New_Features_in_Qt_6.3

Feel free to also update qtdoc.git/doc/src/whatsnew/whatsnew63.qdoc.

//! Paul

Please also notify me about all new modules which are planned to be released in 
Qt 6.3; we should start adding packaging configurations for those as soon as 
possible

br,
Jani Heikkinen
Release Manager

-Original Message-
From: Development 
mailto:development-boun...@qt-project.org>> 
On Behalf Of
Jani Heikkinen
Sent: tiistai 24. elokuuta 2021 15.22
To: development@qt-project.org
Subject: [Development] Qt 6.3 initial schedule

Hi All,

Here is the proposal for Qt 6.3 schedule:

- Qt 6.3 Feature Freeze 10th December 2021
- Qt 6.3 Alpha release 16th December 2021
- Qt 6.3 Beta1 release 12th January 2022
- Qt 6.3 RC 2nd March 2022
- Qt 6.3 Final release 16th March 2022

The idea behind the schedule:
* Release Qt 6.3.0 ~ 6 months after Qt 6.2.0
* Have the FF as late as possible but on the other hand early enough to
  ** trust we can keep the schedule
  ** get the Alpha release out before Christmas

Any comments/objections?

Br,
Jani Heikkinen
Release Manager





___
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

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] moc output from non-local tool build

[Marius Kittler]

Am Dienstag, 9. November 2021, 19:59:29 CET schrieb Thiago Macieira:
> On Friday, 5 November 2021 08:28:20 PST Scott Bloom wrote:
> > Why wouldn’t they simply have two versions of Qt ( or more) the one they
> > are targeting for desktop, and the previous one they are targeting for
> > android/"remote"
> 
> I don't mind that. If we enforce you must have a matching version of the
> host tools, then we do it.
> 
> Since I don't cross compile, people who do should speak up and explain why
> it would be too difficult for them to have a native build of the same
> version of Qt they're going to cross-compile.
> 
> Silence will mean consent.

It would of course be possible to conduct a 2nd host build which would only be 
updated in accordance with the cross-builds. I suppose it would also be 
possible to strip this 2nd build down to "tools only" by specifying some CMake 
variables. It also needed to be installed within a different prefix to avoid 
conflicts with the normal host build.

However, it would certainly be more efficient and less packaging work to 
simply be able to reuse the normal host build which is already in the 
distribution. So it would just make packaging easier.



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] HEADS-UP: Qt 6.3 Feature Freeze is getting closer...

[Jani Heikkinen]

Hi all,

Just a kindly reminder: Qt 6.3.0 Feature Freeze will be in effect 10th December 
2021 so there is a month left for implementing new features, modules etc for Qt 
6.3

It is also time to start listing new features in the release so please start 
updating Qt 6.3 new features page here: 
https://wiki.qt.io/New_Features_in_Qt_6.3
Please also notify me about all new modules which are planned to be released in 
Qt 6.3; we should start adding packaging configurations for those as soon as 
possible

br,
Jani Heikkinen
Release Manager

> -Original Message-
> From: Development  On Behalf Of
> Jani Heikkinen
> Sent: tiistai 24. elokuuta 2021 15.22
> To: development@qt-project.org
> Subject: [Development] Qt 6.3 initial schedule
> 
> Hi All,
> 
> Here is the proposal for Qt 6.3 schedule:
> 
> - Qt 6.3 Feature Freeze 10th December 2021
> - Qt 6.3 Alpha release 16th December 2021
> - Qt 6.3 Beta1 release 12th January 2022
> - Qt 6.3 RC 2nd March 2022
> - Qt 6.3 Final release 16th March 2022
> 
> The idea behind the schedule:
> * Release Qt 6.3.0 ~ 6 months after Qt 6.2.0
> * Have the FF as late as possible but on the other hand early enough to
>** trust we can keep the schedule
>** get the Alpha release out before Christmas
> 
> Any comments/objections?
> 
> Br,
> Jani Heikkinen
> Release Manager
> 
> 
> 
> 
> 
> ___
> 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