Re: [Development] Qt QML Maintainer change

[Chris Adams]

Thanks for all of your hard work, Simon!  +1 for Ulf from me.

On Mon, Feb 18, 2019 at 11:27 PM Simon Hausmann  wrote:
>
> Hi,
>
> I'd like to step down as the maintainer of the Qt QML module and pass the 
> torch on to Ulf Hermann.
>
> He has been contributing to the module since 2013 with countless features, 
> bug fixes, reviews and re-designs. He's absolutely awesome to work with and 
> his lines break sharply at 100 characters ;-)
>
>
> Simon
> ___
> 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] Qt builtin freetype 2.6.1 needs update

[Joerg Bornemann]

On 2/18/19 1:49 PM, xinxin wrote:

> freetype 2.8 add a new render mode,  Qt program ugly than gtk program on 
> linux now

That's this bugreport: https://bugreports.qt.io/browse/QTBUG-73855

Please let's continue the discussion there.


BR,

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

Re: [Development] Qt QML Maintainer change

[Shawn Rutledge]

> On 18 Feb 2019, at 14:25, Simon Hausmann  wrote:
> 
> Hi,
> 
> I'd like to step down as the maintainer of the Qt QML module and pass the 
> torch on to Ulf Hermann.
> 
> He has been contributing to the module since 2013 with countless features, 
> bug fixes, reviews and re-designs. He's absolutely awesome to work with and 
> his lines break sharply at 100 characters ;-)

I’m sorry to see that Simon won’t be doing that now, but +1 for Ulf.

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

Re: [Development] Qt QML Maintainer change

[Mitch Curtis]

> -Original Message-
> From: Development  On Behalf Of
> Simon Hausmann
> Sent: Monday, 18 February 2019 2:25 PM
> To: development@qt-project.org
> Subject: [Development] Qt QML Maintainer change
> 
> Hi,
> 
> I'd like to step down as the maintainer of the Qt QML module and pass the
> torch on to Ulf Hermann.
> 
> He has been contributing to the module since 2013 with countless features,
> bug fixes, reviews and re-designs. He's absolutely awesome to work with
> and his lines break sharply at 100 characters ;-)
> 
> 
> Simon

Thank you for all of your help with QML engine stuff, Simon!

+1 for Ulf, he seems to know what he's doing. :D
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Qt QML Maintainer change

[Simon Hausmann]

Hi,

I'd like to step down as the maintainer of the Qt QML module and pass the torch 
on to Ulf Hermann.

He has been contributing to the module since 2013 with countless features, bug 
fixes, reviews and re-designs. He's absolutely awesome to work with and his 
lines break sharply at 100 characters ;-)


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

[Development] Qt builtin freetype 2.6.1 needs update

[xinxin]

freetype 2.8 add a new render mode,  Qt program ugly than gtk program on linux 
now
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Nominating Sami Nurmenniemi for Approver status

[Sami Nurmenniemi]

Thank you all, I'll use the rights with great consideration.


Best Regards,
Sami


Lähettäjä: Development  käyttäjän Alex 
Blasche  puolesta
Lähetetty: lauantai 16. helmikuuta 2019 20.31.25
Vastaanottaja: development@qt-project.org
Aihe: Re: [Development] Nominating Sami Nurmenniemi for Approver status

Congratulations to Sami, OGApprover rights have been setup.

--
Alex

> -Original Message-
> From: Development  On Behalf Of Kari
> Oikarinen
> Sent: Friday, 25 January 2019 09:06
> To: development@qt-project.org
> Subject: [Development] Nominating Sami Nurmenniemi for Approver status
>
> Hi!
>
> I'd like to nominate Sami Nurmenniemi for Approver. He has already been
> working in The Qt Company in the same team as I am for a good while.
>
> Sami has worked on (among other things):
>
> - Improving flaky tests
> - CI coverage for ARM platforms by using user mode QEMU
> - Demos for embedded devices
>
> He is a careful and competent developer and reviewer. I trust he would wield 
> his
> new powers with good judgment.
>
> His changes:
>
> https://codereview.qt-
> project.org/#/q/owner:%22Sami+Nurmenniemi+%253Csami.nurmenniemi%254
> 0qt.io%253E%22,n,z
>
> His reviews:
>
> https://codereview.qt-
> project.org/#/q/reviewer:%22Sami+Nurmenniemi+%253Csami.nurmenniemi%2
> 540qt.io%253E%22,n,z
>
> --
> Kari
> ___
> 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] [Gerrit-admin] Branch for Qt 6

[Kari Oikarinen]

qt/qtbase now has a branch wip/qt6.

On 15.2.2019 10.03, Lars Knoll wrote:
> Let’s also conclude this thread. Majority consensus was that we need a branch 
> and most votes went towards wip/qt6. So let’s use that for Qt 6 related work 
> and 
> create the required branch.
> 
> The following rules apply:
> 
> * We CI test the branch on (at least) a reduced set of platforms/compilers. 
> Minimum is one Windows/Linux/macOS platform.
> * dev gets merged into wip/qt6 on a regular basis
> * Don’t remove any functions from wip/qt6 unless they are marked as 
> deprecated 
> in dev or else you have discussed it on the mailing list and gotten 
> maintainer 
> approval for the removal
> * Do not break source compatibility without maintainer approval
> * Breaking binary compatibility is ok
> * Breaking internal API is in principle ok, but it’s the responsibility of 
> the 
> one doing the changes to help all other modules that are using that API to 
> get 
> ported. Be careful with those changes until we get the new module testing 
> strategy implemented (see my other email on the Qt modules thread)
> 
> Gerrit admins, can you create the branch for qtbase? If others maintainers 
> want 
> a wip/qt6 branch for their repositories, please create those as well.
> 
> Let’s also hope that we now get the now sha1 pinning approach for module 
> testing 
> quickly to make handling of API changes across repo boundaries simpler.
> 
> Cheers,
> Lars
> 
>> On 16 Jan 2019, at 14:28, Shawn Rutledge > > wrote:
>>
>>
>>
>>> On 16 Jan 2019, at 10:08, Lars Knoll >> > wrote:
>>>
 On 16 Jan 2019, at 09:47, Alex Blasche >>> > wrote:

> From: Development  > on behalf of Lars Knoll 
> mailto:lars.kn...@qt.io>>
> For now I’d like to limit this to qtbase, as that’s where pretty much all 
> Qt 6 related work happens,
> and we need to do some work on the CI side to prepare the other modules 
> for 
> Qt 6 related work
> (Frederik will post details in a separate mail).

 Lars, could you please elaborate on this point? What does for now mean? 
 What 
 time frames are we talking about?
 Where does the assumption come from that all Qt 6 related work happens in 
 qtbase only?

 I think I know what you might want to say but the above is too absolutely 
 phrased and I want the statement clear and not fuzzy. Hence please 
 elaborate.
>>>
>>> Currently, most of the efforts towards Qt 6 are preparations that are 
>>> happening in qtbase, so I believe we need the branch there now, so at least 
>>> some work start.
>>>
>>> For other modules, we will of course also need Qt 6 related branches as 
>>> soon 
>>> as possible. But we do need to get the model on how to work in those with 
>>> respect to our CI in order first. The problem here is that our CI makes 
>>> working with source incompatible changes difficult between repositories. I 
>>> believe we’ll need to fix that before we can create qt6 branches for the 
>>> other repositories that compile and test against qtbase/qt6.
>>>
>>> Of course you could create a wip branch for other repositories now as well 
>>> to 
>>> do Qt 6 related work that doesn’t require Qt6 related changes from qtbase.
>>
>> I thought the plan before was to use version checks like
>>
>> #if QT_VERSION >= QT_VERSION_CHECK(6, 0, 0)
>>
>> And so we have some of those.  But it hasn’t been clear how to test them (or 
>> at least I didn’t take the time to figure it out).  I would have liked to 
>> start doing builds like that regularly a couple years ago.  We should have 
>> had 
>> a configure option for that already, as soon as we started doing that, IMO.
>>
>> But as soon as qtbase has a qt6 branch, configure in that branch will set 
>> that 
>> version, and then we can build other modules and test that conditional Qt 6 
>> functionality, right?
>>
>> As soon as we have a qt6 branch for a given module, should we start removing 
>> the version checks and the Qt5-specific code?  Or will we put that off until 
>> nearer the Qt 6 release?
>>
>> Which way is going to make merges easier?
>>
>> ___
>> Development mailing list
>> Development@qt-project.org 
>> https://lists.qt-project.org/listinfo/development
> 
> 
> ___
> Gerrit-admin mailing list
> gerrit-ad...@qt-project.org
> https://lists.qt-project.org/listinfo/gerrit-admin
> 

-- 
---
Kari Oikarinen
Senior Software Engineer

The Qt Company
Elektroniikkatie 13
90590, Oulu, Finland
kari.oikari...@qt.io
+358 50 5281010
http://qt.io
---
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development