Re: [Development] Adding CPD support to Qt print dialog

[Tor Arne Vestbø]

That’s awesome, nice work Gaurav!

- Tor Arne

On 26 Sep 2022, at 18:47, Gaurav Guleria  wrote:



Yes, CPDB is just a different backend for the existing print dialog GUI. It's 
merely a different way of enumerating printers and their features.

I have already prepared a simple CPDB plugin (still requires a few changes and 
additions) which can already respond to QPrinterInfo::availablePrinters() 
queries: https://github.com/TinyTrebuchet/qtbase/commits/cpdb.

On 9/26/22 21:30, Shawn Rutledge wrote:

On 2022 Sep 26, at 16:54, Volker Hilsheimer 
mailto:volker.hilshei...@qt.io>> wrote:

I think it will be easier to understand what abstraction we need once we have a 
patch to look at that implements CPDB support. That we don’t have a QPA-level 
abstraction for print dialogs in Qt shouldn’t block adding CPDB support.

However, rather than throwing more #if’ery complexity into 
qprintdialog_unix.cpp it might be best to make a dedicated implementation of a 
CPDB-dialog.

But it was already pointed out that the widget dialog is intended to look 
exactly the same, right?  This is not a native dialog, it’s just a different 
backend that the same old widget dialog should learn how to deal with, AFAIU.  
And qprintdialog_unix.cpp is really building up the widget hierarchy for it.  
It has a complex feature set.  We haven’t been writing new widgets ourselves, 
and a few more #if’s will be less to maintain than a whole new widget-based 
dialog would be.

Refactoring into whatever plugins or QPA stuff is worth discussing, but I guess 
it will be easier to visualize the refactoring after we’ve got something that 
works.  And I haven’t dug into the implementation enough to think about whether 
anything there is reusable in Qt Quick.  QPrinterInfo is public, so I guess the 
first natural “model” for the dialog is going to end up being the list returned 
from QPrinterInfo::availablePrinters() anyway.




___
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] Adding CPD support to Qt print dialog

[Gaurav Guleria]

Yes, CPDB is just a different backend for the existing print dialog GUI. 
It's merely a different way of enumerating printers and their features.


I have already prepared a simple CPDB plugin (still requires a few 
changes and additions) which can already respond to 
QPrinterInfo::availablePrinters() queries: 
https://github.com/TinyTrebuchet/qtbase/commits/cpdb.


On 9/26/22 21:30, Shawn Rutledge wrote:


On 2022 Sep 26, at 16:54, Volker Hilsheimer  
wrote:


I think it will be easier to understand what abstraction we need once 
we have a patch to look at that implements CPDB support. That we 
don’t have a QPA-level abstraction for print dialogs in Qt shouldn’t 
block adding CPDB support.


However, rather than throwing more #if’ery complexity into 
qprintdialog_unix.cpp it might be best to make a dedicated 
implementation of a CPDB-dialog.


But it was already pointed out that the widget dialog is intended to 
look exactly the same, right?  This is not a native dialog, it’s just 
a different backend that the same old widget dialog should learn how 
to deal with, AFAIU.  And qprintdialog_unix.cpp is really building up 
the widget hierarchy for it.  It has a complex feature set.  We 
haven’t been writing new widgets ourselves, and a few more #if’s will 
be less to maintain than a whole new widget-based dialog would be.


Refactoring into whatever plugins or QPA stuff is worth discussing, 
but I guess it will be easier to visualize the refactoring after we’ve 
got something that works.  And I haven’t dug into the implementation 
enough to think about whether anything there is reusable in Qt Quick. 
 QPrinterInfo is public, so I guess the first natural “model” for the 
dialog is going to end up being the list returned from 
QPrinterInfo::availablePrinters() anyway.



___
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] Adding CPD support to Qt print dialog

[Gaurav Guleria]

I am willing to maintain the CPDB code I will add to the Qt print 
dialogs for a while. Though I am currently not familiar with the time 
commitment it will require on my end.


Also, do we currently have a maintainer for the print dialogs?

Regards,
Gaurav Guleria

On 9/26/22 20:57, Tor Arne Vestbø wrote:



On 26 Sep 2022, at 17:19, Till Kamppeter  wrote:

But we must also take into account that Gaurav has not arbitrarily much time. 
His GSoC project is already in the extension. So he needs to know now how he 
can get CPDB support in quickly, especially without need to design a new GUI 
and to create the code for all ins and outs of a print dialog.

Will Gaurav maintain the code if added to the existing print dialogs? If not, I 
guess it’s up to the maintainer of the print dialogs whether they want to take 
on the additional technical debt.

Cheers,
Tor Arne


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

Re: [Development] Adding CPD support to Qt print dialog

[Shawn Rutledge]

On 2022 Sep 26, at 16:54, Volker Hilsheimer 
mailto:volker.hilshei...@qt.io>> wrote:

I think it will be easier to understand what abstraction we need once we have a 
patch to look at that implements CPDB support. That we don’t have a QPA-level 
abstraction for print dialogs in Qt shouldn’t block adding CPDB support.

However, rather than throwing more #if’ery complexity into 
qprintdialog_unix.cpp it might be best to make a dedicated implementation of a 
CPDB-dialog.

But it was already pointed out that the widget dialog is intended to look 
exactly the same, right?  This is not a native dialog, it’s just a different 
backend that the same old widget dialog should learn how to deal with, AFAIU.  
And qprintdialog_unix.cpp is really building up the widget hierarchy for it.  
It has a complex feature set.  We haven’t been writing new widgets ourselves, 
and a few more #if’s will be less to maintain than a whole new widget-based 
dialog would be.

Refactoring into whatever plugins or QPA stuff is worth discussing, but I guess 
it will be easier to visualize the refactoring after we’ve got something that 
works.  And I haven’t dug into the implementation enough to think about whether 
anything there is reusable in Qt Quick.  QPrinterInfo is public, so I guess the 
first natural “model” for the dialog is going to end up being the list returned 
from QPrinterInfo::availablePrinters() anyway.

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

Re: [Development] Adding CPD support to Qt print dialog

[Tor Arne Vestbø]

> On 26 Sep 2022, at 17:19, Till Kamppeter  wrote:
> 
> But we must also take into account that Gaurav has not arbitrarily much time. 
> His GSoC project is already in the extension. So he needs to know now how he 
> can get CPDB support in quickly, especially without need to design a new GUI 
> and to create the code for all ins and outs of a print dialog.

Will Gaurav maintain the code if added to the existing print dialogs? If not, I 
guess it’s up to the maintainer of the print dialogs whether they want to take 
on the additional technical debt.

Cheers,
Tor Arne 

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

Re: [Development] Adding CPD support to Qt print dialog

[Till Kamppeter]

But we must also take into account that Gaurav has not arbitrarily much 
time. His GSoC project is already in the extension. So he needs to know 
now how he can get CPDB support in quickly, especially without need to 
design a new GUI and to create the code for all ins and outs of a print 
dialog.


   Till

On 26/09/2022 17:05, Tor Arne Vestbø wrote:


Yeah, the print dialogs are much more coupled to the print engines than 
I initially thought/expected. I agree that a separate dialog is 
preferable to adding even more #ifdefs to the existing unix dialog. Then 
we have a basis for possible future abstractions.

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

Re: [Development] Adding CPD support to Qt print dialog

[Tor Arne Vestbø]

On 26 Sep 2022, at 16:54, Volker Hilsheimer 
mailto:volker.hilshei...@qt.io>> wrote:



On 25 Sep 2022, at 20:58, Albert Astals Cid 
mailto:aa...@kde.org>> wrote:

El dissabte, 24 de setembre de 2022, a les 12:45:00 (CEST), Tor Arne Vestbø va
escriure:
On 23 Sep 2022, at 19:21+02:00, Gaurav Guleria 
mailto:gaurav.g...@gmail.com>>
wrote:

As far as I know, the CUPS is currently implemented in Qt at two different
places: src/plugins/printsupport/cups/ and directly within the dialog
src/printsupport/dialogs/qprintdialog_unix.cpp. By implementing CPDB
support as a plugin, does it mean that we create a similar
src/plugins/printsupport/cpdb which uses CPDB to enumerate printers
instead of CUPS? If so, what about the unix print dialog, don't we need
to add the CPDB code there too (#if QT_CONFIG(cpdb) ... #endif
constructs, just like CUPS)?

The QCupsJobWidget is documented as "a widget to add to QPrintDialog to
enable extra CUPS options such as Job Scheduling, Job Priority or Job
Billing”, so I don’t think having any CPDB specific code in the UNIX print
dialog is required as a first step to bring a CPDB print backend up.

Once we get to that point we can look at possibly adding new API for the
print engines to deal with the needs of QCupsJobWidget and the like, so
that we don’t need CUPS/CPDB specifics in the dialog code.

The "problem" is not QCupsJobWidget, but the print dialog itself.

qprintdialog_unix.cpp and qpagesetupdialog_unix.cpp are full of
#if QT_CONFIG(cups)

IMHO for now the same solution of adding ifdefs should be accepted for CPDB.

Ideally in the future an abstraction so that those ifdefs are not needed
should be introduced, but I have the feeling that asking that abstraction to
be added now is a bit of "asking too much".

Cheers,
Albert

I think it will be easier to understand what abstraction we need once we have a 
patch to look at that implements CPDB support. That we don’t have a QPA-level 
abstraction for print dialogs in Qt shouldn’t block adding CPDB support.

However, rather than throwing more #if’ery complexity into 
qprintdialog_unix.cpp it might be best to make a dedicated implementation of a 
CPDB-dialog. Or rather two implementations, as Shawn has pointed out: one for 
Qt Widgets and one for Qt Quick. And if those two are then based on a common 
abstraction that provides the logic and is informed by what we already have in 
QAbstractPrintDialog - but without the dependency to Qt Widgets - then that 
might perhaps become a basis for what we want in QPA.

Yeah, the print dialogs are much more coupled to the print engines than I 
initially thought/expected. I agree that a separate dialog is preferable to 
adding even more #ifdefs to the existing unix dialog. Then we have a basis for 
possible future abstractions.

Cheers,
Tor Arne

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

Re: [Development] Adding CPD support to Qt print dialog

[Volker Hilsheimer]

> On 25 Sep 2022, at 20:58, Albert Astals Cid  wrote:
> 
> El dissabte, 24 de setembre de 2022, a les 12:45:00 (CEST), Tor Arne Vestbø 
> va 
> escriure:
>>> On 23 Sep 2022, at 19:21+02:00, Gaurav Guleria 
>>> wrote:
> 
>>> As far as I know, the CUPS is currently implemented in Qt at two different
>>> places: src/plugins/printsupport/cups/ and directly within the dialog
>>> src/printsupport/dialogs/qprintdialog_unix.cpp. By implementing CPDB
>>> support as a plugin, does it mean that we create a similar
>>> src/plugins/printsupport/cpdb which uses CPDB to enumerate printers
>>> instead of CUPS? If so, what about the unix print dialog, don't we need
>>> to add the CPDB code there too (#if QT_CONFIG(cpdb) ... #endif
>>> constructs, just like CUPS)?
>> 
>> The QCupsJobWidget is documented as "a widget to add to QPrintDialog to
>> enable extra CUPS options such as Job Scheduling, Job Priority or Job
>> Billing”, so I don’t think having any CPDB specific code in the UNIX print
>> dialog is required as a first step to bring a CPDB print backend up.
> 
>> Once we get to that point we can look at possibly adding new API for the
>> print engines to deal with the needs of QCupsJobWidget and the like, so
>> that we don’t need CUPS/CPDB specifics in the dialog code.
> 
> The "problem" is not QCupsJobWidget, but the print dialog itself.
> 
> qprintdialog_unix.cpp and qpagesetupdialog_unix.cpp are full of
>  #if QT_CONFIG(cups)
> 
> IMHO for now the same solution of adding ifdefs should be accepted for CPDB.
> 
> Ideally in the future an abstraction so that those ifdefs are not needed 
> should be introduced, but I have the feeling that asking that abstraction to 
> be added now is a bit of "asking too much".
> 
> Cheers,
>  Albert

I think it will be easier to understand what abstraction we need once we have a 
patch to look at that implements CPDB support. That we don’t have a QPA-level 
abstraction for print dialogs in Qt shouldn’t block adding CPDB support.

However, rather than throwing more #if’ery complexity into 
qprintdialog_unix.cpp it might be best to make a dedicated implementation of a 
CPDB-dialog. Or rather two implementations, as Shawn has pointed out: one for 
Qt Widgets and one for Qt Quick. And if those two are then based on a common 
abstraction that provides the logic and is informed by what we already have in 
QAbstractPrintDialog - but without the dependency to Qt Widgets - then that 
might perhaps become a basis for what we want in QPA.

Cheers,
Volker

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

Re: [Development] Nominating Christian Ehrlicher and Andy Shaw as Qt SQL co-maintainers

[Sze Howe Koh]

On Mon, 26 Sept 2022 at 15:13, Volker Hilsheimer
 wrote:
>
> Hi,
>
>
> I would like to nominate Christian and Andy as co-maintainers for Qt SQL.
>
> Mark Brand, who is currently listed as the maintainer of Qt SQL, hasn’t 
> responded to any of my emails, including one from two weeks ago where I 
> explicitly informed him that he will be removed as maintainer if he doesn’t 
> respond (as per the recent addition to the governance model [1], I cc’ed Alex 
> Blasche as a second maintainer in that email).
>
> Christian and Andy have already agreed to take on the responsibility 
> together. they both have a long history of working with the module, and as we 
> support a number of SQL drivers in Qt it’s good to have more than one person 
> looking after things.
>
>
> Volker
>
> [1] https://codereview.qt-project.org/c/meta/quips/+/423766

+1


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

Re: [Development] Redesigning QML value types

[Ulf Hermann]

Hi,

after some more experimentation, I've realized the problem is actually 
of larger dimension. Since function signatures are ignored when 
interpreting or running JIT-compiled QML code, you already get divergent 
behavior without all the value type write back problems. Take for 
example the following function:


function getLength(a: string) : int { return a.length }

Now this function is nicely compilable to C++. If it's caller is 
compiled to C++, we could enforce the signature at compile time. Suppose 
the caller is _not_ compiled to C++, though. The caller does 
getLength(b) where b is of a value type with a "length" property. When 
getLength is AOT-compiled, the this coerces b into a string (most likely 
"[object Object]", but you can have a custom toString() method) and gets 
the length of that. If it's interpreted, the type annotations is 
ignored, and getLength will get the "length" property of a.


You may argue that the coercion should fail in the case where 
getLength() is AOT-compiled, but since at the call site we're deep in 
JavaScript land, that would be fairly incosistent. When calling 
C++-defined methods, we can coerce everything to string.


(OK, the coercion rules when calling a QObject method are already 
different from what we do when calling a typed JS method ... but let's 
solve that another time.)


So, the clean solution would be to coerce all arguments into their 
declared types even when interpreting or running JIT-compiled code.


Now, the type coercion is not free. If you call from one AOT-compiled 
function into a different one, we don't have to do it because the 
AOT-compiled functions are already using the C++ types. However, when 
calling from an interpreted or JIT'ed function into an AOT-compiled one, 
there is some overhead. Most of the time it's well worth it because the 
actual function then runs much faster.


Considering this, I don't want to force the extra call overhead on calls 
to interpreted or JIT'ed functions, as that would actually be slower. It 
would discourage people from using the type annotations.


Furthermore, as shown above, enforcing the types would introduce subtle 
behavior changes into code that's not compiled to C++. As the 
compilation to C++ envolves a number of other changes to your 
application (such as using qt_add_qml_module), we can probably live with 
a slight difference in behavior between interpreted and AOT-compiled 
code. It would be somewhat worse to introduce deliberate behavior 
changes to code completely unaffected by any of this.


You should be _able_ to enforce the same behavior in either execution 
mode, though. Therefore, my current idea is to introduce a pragma 
FunctionSignatureBehavior that you can set to "Enforced" or "Ignored". 
If explicitly enforced, the engine would coerce the arguments even when 
calling an interpreted or JIT'ed function. If explicitly ignored, 
qmlcachegen and qmlsc would refuse to compile any functions and calls to 
QML-defined function in the component to C++. (they would still compile 
bindings and signal handlers that at most call C++-defined functions, 
though)


You can see my current work in progress at 
https://codereview.qt-project.org/c/qt/qtdeclarative/+/434663


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

Re: [Development] Nominating Christian Ehrlicher and Andy Shaw as Qt SQL co-maintainers

[Alex Blasche]

Hi,


>From: Development  on behalf of Fabian 
>Kosmale 

>for the sake of process, I'd like Alex's confirmation that he indeed was CCed 
>on your mail; 

I can confirm.


> von Volker Hilsheimer 
>I would like to nominate Christian and Andy as co-maintainers for Qt SQL.

+1

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

Re: [Development] Nominating Christian Ehrlicher and Andy Shaw as Qt SQL co-maintainers

[Edward Welbourne]

Volker Hilsheimer (26 September 2022 09:11) wrote:
> I would like to nominate Christian and Andy as co-maintainers for Qt SQL.

+1

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

Re: [Development] Nominating Christian Ehrlicher and Andy Shaw as Qt SQL co-maintainers

[Samuel Gaist via Development]

On lundi, 26 septembre 2022 09.11:23 h CEST Volker Hilsheimer wrote:
> Hi,
> 
> 
> I would like to nominate Christian and Andy as co-maintainers for Qt SQL.
> 
> Mark Brand, who is currently listed as the maintainer of Qt SQL, hasn’t
> responded to any of my emails, including one from two weeks ago where I
> explicitly informed him that he will be removed as maintainer if he doesn’t
> respond (as per the recent addition to the governance model [1], I cc’ed
> Alex Blasche as a second maintainer in that email).
 
> Christian and Andy have already agreed to take on the responsibility
> together. they both have a long history of working with the module, and as
> we support a number of SQL drivers in Qt it’s good to have more than one
> person looking after things.
 
> 
> Volker
> 
> [1] https://codereview.qt-project.org/c/meta/quips/+/423766
> 
> 
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development

+1

Cheers

Samuel
-

signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Nominating Christian Ehrlicher and Andy Shaw as Qt SQL co-maintainers

[Fabian Kosmale]

Hi,


for the sake of process, I'd like Alex's confirmation that he indeed was CCed 
on your mail; but otherwise I'm certain that both Christian and Andy will do a 
good job maintaining Qt SQL. So +1

Fabian


Von: Development  im Auftrag von Volker 
Hilsheimer 
Gesendet: Montag, 26. September 2022 09:11
An: development@qt-project.org
Betreff: [Development] Nominating Christian Ehrlicher and Andy Shaw as Qt SQL 
co-maintainers

Hi,


I would like to nominate Christian and Andy as co-maintainers for Qt SQL.

Mark Brand, who is currently listed as the maintainer of Qt SQL, hasn’t 
responded to any of my emails, including one from two weeks ago where I 
explicitly informed him that he will be removed as maintainer if he doesn’t 
respond (as per the recent addition to the governance model [1], I cc’ed Alex 
Blasche as a second maintainer in that email).

Christian and Andy have already agreed to take on the responsibility together. 
they both have a long history of working with the module, and as we support a 
number of SQL drivers in Qt it’s good to have more than one person looking 
after things.


Volker

[1] https://codereview.qt-project.org/c/meta/quips/+/423766


___
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] Nominating Christian Ehrlicher and Andy Shaw as Qt SQL co-maintainers

[Shawn Rutledge]

+1

It’s good to have active maintainers.

> On 2022 Sep 26, at 09:11, Volker Hilsheimer  wrote:
> 
> Hi,
> 
> 
> I would like to nominate Christian and Andy as co-maintainers for Qt SQL.
> 
> Mark Brand, who is currently listed as the maintainer of Qt SQL, hasn’t 
> responded to any of my emails, including one from two weeks ago where I 
> explicitly informed him that he will be removed as maintainer if he doesn’t 
> respond (as per the recent addition to the governance model [1], I cc’ed Alex 
> Blasche as a second maintainer in that email).
> 
> Christian and Andy have already agreed to take on the responsibility 
> together. they both have a long history of working with the module, and as we 
> support a number of SQL drivers in Qt it’s good to have more than one person 
> looking after things.
> 
> 
> Volker
> 
> [1] https://codereview.qt-project.org/c/meta/quips/+/423766
> 
> 
> ___
> 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] Requesting a repository for Qt Quick Effect Maker

[Tomi Korpipää]

The license will be GPL + Commercial.

-Tomi


From: EXT Mitch Curtis 
Sent: Friday, September 23, 2022 04:32
To: Tomi Korpipää ; development@qt-project.org 

Subject: Re: [Development] Requesting a repository for Qt Quick Effect Maker


I asked this back in April but there was no official answer at that stage: what 
will the license be?



From: Development  On Behalf Of Tomi 
Korpipää
Sent: Wednesday, 21 September 2022 6:56 PM
To: development@qt-project.org
Subject: Re: [Development] Requesting a repository for Qt Quick Effect Maker



Anyone to second this?



-Tomi



From: Volker Hilsheimer 
mailto:volker.hilshei...@qt.io>>
Sent: Wednesday, August 31, 2022 11:43
To: Tomi Korpipää mailto:tomi.korpi...@qt.io>>; 
development@qt-project.org 
mailto:development@qt-project.org>>
Subject: Re: [Development] Requesting a repository for Qt Quick Effect Maker



+1

Volker


> On 29 Aug 2022, at 12:15, Tomi Korpipää 
> mailto:tomi.korpi...@qt.io>> wrote:
>
> Hi,
>
> I’d like to request a new repository on codereview.qt-project.org.
>
> Name of the repository: qt/qtquickeffectmaker.git
>
> Name: Qt Quick Effect Maker
> Description: Qt Quick Effect Maker (QQEM) for creating custom shader effects.
> Responsible person: Kaj Grönholm
> Content: https://git.qt.io/kagronho/qt-quick-effect-maker/ master branch, 
> fresh without git history.
> No CI for now.
>
> Thank you,
>
> Tomi Korpipää
> Senior Manager, R
>
> The Qt Company
> Tutkijantie 4 C
> 90590, Oulu, Finland
> tomi.korpi...@qt.io
> +358 44 5312522
> http://qt.io
>
>
> The Future is Written with Qt
>
> ___
> 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] Nominating Christian Ehrlicher and Andy Shaw as Qt SQL co-maintainers

[Volker Hilsheimer]

Hi,


I would like to nominate Christian and Andy as co-maintainers for Qt SQL.

Mark Brand, who is currently listed as the maintainer of Qt SQL, hasn’t 
responded to any of my emails, including one from two weeks ago where I 
explicitly informed him that he will be removed as maintainer if he doesn’t 
respond (as per the recent addition to the governance model [1], I cc’ed Alex 
Blasche as a second maintainer in that email).

Christian and Andy have already agreed to take on the responsibility together. 
they both have a long history of working with the module, and as we support a 
number of SQL drivers in Qt it’s good to have more than one person looking 
after things.


Volker

[1] https://codereview.qt-project.org/c/meta/quips/+/423766


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

[Development] Monthly CI maintenance break - October (Mon 3rd Oct 2022)

[Ville-Pekka Karhu]

Hi all!

We’ll have our scheduled maintenance break on next Monday (3rd of October). 
We’ll begin our work at 5:00 UTC and you can prepare for 6 hours of CI not 
working.

Br,
VP

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