Re: [Development] Arttu Tarkiainen as approver

[Tino Pyssysalo]

+1

--
Tino Pyssysalo
Senior Product Manager
The Qt Company


On 10.3.2020, 14.00, "Development on behalf of Katja Marttila" 
mailto:development-boun...@qt-project.org> 
on behalf of katja.martt...@qt.io> wrote:

Hi all,

I’d like to nominate Arttu Tarkiainen as approver for the Qt Project.

Arttu has been working in the installer team as a SW developer since he joined 
the Qt Company about one year ago. First as a trainee and currently as 
full-time employee. Arttu has been focusing mainly to improve and maintain 
Installer Framework and proven to be very skilful developer. I’ll trust that he 
will use the approver rights responsibly and follow the Qt guidelines.

Here is the list of his changes:
https://codereview.qt-project.org/q/owner:arttu.tarkiainen%2540qt.io

Br,
Katja Marttila
Software Engineer | Maintainer of Installer Framework
The Qt Company | Finland | Oulu


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

Re: [Development] Arttu Tarkiainen as approver

[Jani Heikkinen]

+1


From: Development  on behalf of Katja 
Marttila 
Sent: Tuesday, March 10, 2020 1:56 PM
To: development@qt-project.org
Subject: [Development] Arttu Tarkiainen as approver

Hi all,

I’d like to nominate Arttu Tarkiainen as approver for the Qt Project.

Arttu has been working in the installer team as a SW developer since he joined 
the Qt Company about one year ago. First as a trainee and currently as 
full-time employee. Arttu has been focusing mainly to improve and maintain 
Installer Framework and proven to be very skilful developer. I’ll trust that he 
will use the approver rights responsibly and follow the Qt guidelines.

Here is the list of his changes:
https://codereview.qt-project.org/q/owner:arttu.tarkiainen%2540qt.io

Br,
Katja Marttila
Software Engineer | Maintainer of Installer Framework
The Qt Company | Finland | Oulu


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

Re: [Development] GitHub Pull requests

[Konstantin Tokarev]

10.03.2020, 22:26, "Matthew Woehlke" :
> On 10/03/2020 12.19, Cristián Maureira-Fredes wrote:
>>  On 3/10/20 3:40 PM, Cristian Adam wrote:
>>>  What stops us from accepting the contributions via GitHub?
>>>
>>>  Is it:
>>>
>>>   1. The CLA
>>>   2. Qt Account
>>>
>>>  For the CLA one can simply add an instance of:
>>>
>>>  https://github.com/cla-assistant/cla-assistant
>>
>>  I think that's a good idea,
>>  in the past I was told that even a written consent accepting
>>  the CLA was enough (please correct me if I'm wrong),
>>  so if we can also include it on the Github
>>  mirror, that will allow us to get more contributions.
>>
>>  The only thing I wonder is CI,
>>  what do you think could be a good workflow?
>
> In an ideal world...
>
> - Alice opens a pull request on GitHub.
> - A bot sees the PR and opens a corresponding request on Gerrit.
> - Bob comments on the Gerrit request.
> - A bot sees Bob's comment and replicates it to the GitHub PR.
> - Alice replies (on GitHub) to Bob's comment.
> - A bot sees Alice's comment and replicates it to Gerrit.
>
> ...and so on.

Then Bob asks Alice to make a change in commit, and she has to make
push -f in her branch. After that, review comments on GitHub are smashed,
while remain perfectly readable in Gerrit, and Bob can see difference
between patch versions while Alice cannot.

>
> I'm not sure to what extent this is actually plausible, but it would
> seem to solve CI nicely, and would also mean that maintainers don't need
> to look in multiple places.
>
> Note that I believe nothing needs to be done to "merge" the GitHub PR;
> if the commits become reachable from the target branch, it should
> automatically get marked as "merged".
>
> --
> Matthew
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development

-- 
Regards,
Konstantin


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

Re: [Development] GitHub Pull requests

[Matthew Woehlke]

On 10/03/2020 12.19, Cristián Maureira-Fredes wrote:
> On 3/10/20 3:40 PM, Cristian Adam wrote:
>> What stops us from accepting the contributions via GitHub?
>>
>> Is it:
>>
>>  1. The CLA
>>  2. Qt Account
>>
>> For the CLA one can simply add an instance of:
>>
>> https://github.com/cla-assistant/cla-assistant
> 
> I think that's a good idea,
> in the past I was told that even a written consent accepting
> the CLA was enough (please correct me if I'm wrong),
> so if we can also include it on the Github
> mirror, that will allow us to get more contributions.
> 
> The only thing I wonder is CI,
> what do you think could be a good workflow?

In an ideal world...

- Alice opens a pull request on GitHub.
- A bot sees the PR and opens a corresponding request on Gerrit.
- Bob comments on the Gerrit request.
- A bot sees Bob's comment and replicates it to the GitHub PR.
- Alice replies (on GitHub) to Bob's comment.
- A bot sees Alice's comment and replicates it to Gerrit.

...and so on.

I'm not sure to what extent this is actually plausible, but it would
seem to solve CI nicely, and would also mean that maintainers don't need
to look in multiple places.

Note that I believe nothing needs to be done to "merge" the GitHub PR;
if the commits become reachable from the target branch, it should
automatically get marked as "merged".

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

Re: [Development] GitHub Pull requests

[Florian Bruhin]

Hi,

On Tue, Mar 10, 2020 at 05:08:39PM +, Zacruzin via Development wrote:
> Please remove me from this email chain.Thank you!

On the bottom of every mail you find a footer, liking to the website for this
mailinglist:

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

You can unsubscribe yourself there.

Florian

-- 
m...@the-compiler.org (Mail/XMPP) | https://www.qutebrowser.org 
   https://bruhin.software/ | https://github.com/sponsors/The-Compiler/
   GPG: 916E B0C8 FD55 A072 | https://the-compiler.org/pubkey.asc
 I love long mails! | https://email.is-not-s.ms/


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

Re: [Development] GitHub Pull requests

[Tor Arne Vestbø]

Hey hey,

> On 10 Mar 2020, at 15:40, Cristian Adam  wrote:
> 
> What stops us from accepting the contributions via GitHub?

The issues feature should be closed on those GitHub mirrors.

As a project we use Gerrit today, and that’s where contributions should happen. 
If we change review platform, that’s a different discussion, but let’s not 
rehash that now  

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

Re: [Development] GitHub Pull requests

[Zacruzin via Development]

Please remove me from this email chain.Thank you!


-Original Message-
From: Konstantin Tokarev 
To: Cristián Maureira-Fredes ; 
development@qt-project.org 
Sent: Tue, Mar 10, 2020 12:07 pm
Subject: Re: [Development] GitHub Pull requests


10.03.2020, 19:25, "Cristián Maureira-Fredes" :
> Hello,
>
> On 3/10/20 3:48 PM, Konstantin Tokarev wrote:
>>  I think, lowering barrier of entry at expense of reviewers' convenience 
>> should
>>  have its limits
>
> Totally agree,
> so we should plan to accept patches from platform and systems
> made for code development, like Github :)
>
> , otherwise we may end up accepting contributions from Twitter:)
>
> If Twitter becomes on a code development platform
> with pull-requests, reviews, and so on...sure :P

My point is that GitHub is inferior as a code review platform. Lowering entry 
barrier 
for drive-by contributors (who quite likely won't come back to maintain code 
they've
introduced), it reduces quality of life for reviewers.

-- 
Regards,
Konstantin

___
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] GitHub Pull requests

[Konstantin Tokarev]

10.03.2020, 19:25, "Cristián Maureira-Fredes" :
> Hello,
>
> On 3/10/20 3:48 PM, Konstantin Tokarev wrote:
>>  I think, lowering barrier of entry at expense of reviewers' convenience 
>> should
>>  have its limits
>
> Totally agree,
> so we should plan to accept patches from platform and systems
> made for code development, like Github :)
>
> , otherwise we may end up accepting contributions from Twitter:)
>
> If Twitter becomes on a code development platform
> with pull-requests, reviews, and so on...sure :P

My point is that GitHub is inferior as a code review platform. Lowering entry 
barrier 
for drive-by contributors (who quite likely won't come back to maintain code 
they've
introduced), it reduces quality of life for reviewers.

-- 
Regards,
Konstantin

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

Re: [Development] GitHub Pull requests

[Cristián Maureira-Fredes]

Hello,

On 3/10/20 3:48 PM, Konstantin Tokarev wrote:

I think, lowering barrier of entry at expense of reviewers' convenience should
have its limits


Totally agree,
so we should plan to accept patches from platform and systems
made for code development, like Github :)

, otherwise we may end up accepting contributions from Twitter:)

If Twitter becomes on a code development platform
with pull-requests, reviews, and so on...sure :P


Cheers

--
Dr. Cristian Maureira-Fredes
R Manager

The Qt Company GmbH
Erich-Thilo-Str. 10
D-12489 Berlin

Geschäftsführer: Mika Pälsi,
Juha Varelius, Mika Harjuaho
Sitz der Gesellschaft: Berlin,
Registergericht: Amtsgericht
Charlottenburg, HRB 144331 B
--
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] GitHub Pull requests

[Cristián Maureira-Fredes]

Hello Cristian,

On 3/10/20 3:40 PM, Cristian Adam wrote:

What stops us from accepting the contributions via GitHub?

Is it:

 1. The CLA
 2. Qt Account

For the CLA one can simply add an instance of:

https://github.com/cla-assistant/cla-assistant


I think that's a good idea,
in the past I was told that even a written consent accepting
the CLA was enough (please correct me if I'm wrong),
so if we can also include it on the Github
mirror, that will allow us to get more contributions.

The only thing I wonder is CI,
what do you think could be a good workflow?

1)
Pull request accepted, then Patch on Gerrit with the reviewer
as owner and a line crediting the author from Github,
so we can integrate it using COIN?

2) Pull request accepted, run a custom CI on Github
and then merge back into gerrit?

3) others?

Cheers


--
Dr. Cristian Maureira-Fredes
R Manager

The Qt Company GmbH
Erich-Thilo-Str. 10
D-12489 Berlin

Geschäftsführer: Mika Pälsi,
Juha Varelius, Mika Harjuaho
Sitz der Gesellschaft: Berlin,
Registergericht: Amtsgericht
Charlottenburg, HRB 144331 B
--
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 5.15 API review

[Volker Hilsheimer]

> On 10 Mar 2020, at 14:21, Jani Heikkinen  wrote:
> 
>> -Original Message-
>> From: Giuseppe D'Angelo 
>> Sent: tiistai 10. maaliskuuta 2020 14.48
>> To: Jani Heikkinen 
>> Cc: Qt development mailing list 
>> Subject: Re: [Development] Qt 5.15 API review
>> 
>> Il 10/03/20 13:45, Jani Heikkinen ha scritto:
>>> We haven't been blocking Beta (n) lately because of ongoing API review.
>> Earlier when there were only one beta we did that. After we started to
>> deliver several beta releases we stopped to block betas because of not
>> finalized API review.
>>> 
>>> And I think that is correct way to do this; It is better to start 
>>> publishing beta
>> releases as soon as possible instead of waiting until API review is complete
>> 
>> But then, what's the difference between the alpha releases and the beta
>> releases?
>> 
> 
> That is actually really good question especially now when we are delivering 
> binaries also with Alpha release.
> 
> I see that Alpha is a milestone to show what new we get in at FF. And Alpha 
> should be out really soon after feature freeze and it is most important to 
> get src packages out. Binaries are extra and some new modules can be missing 
> from possible binary packages. Alpha is also a checkpoint to see that our 
> releasing machinery will work.
> 
> And Beta1 starts beta phase where we should have all modules in builds & 
> packages. But Beta1 can be still quite unfinished; target is to finalize 
> release during beta phase as long as we are ready for RC. 
> 
> Couple of years ago I even proposed that we should stop doing Alpha and beta 
> releases and just deliver snapshots until we are ready for RC. But that 
> didn't get that much support at that time...
> 
> br,
> Jani


We discussed that at the contributors summit [1]) that API reviews should be 
part of the code review, not of the last-stage header review.

[1] https://wiki.qt.io/Qt_Contributors_Summit_2019_-_API_Review_Process

No follow up on this discussion yet.


But either way, I think having milestones and corresponding releases is useful. 
Perhaps we have some statistics on whether calling it “beta" makes people that 
don’t live on the bleeding edge to try things out.

In my mind,


Feature freeze != API freeze != header freeze.


Feature freeze: all the new things are in, let’s get some feedback from users - 
to the API, the packaging machinery, and installation process.

API freeze: based on the feedback we made the APIs as good as we could.

Header freeze: we have reviewed that none of the changes have *technical* side 
effects (such as breaking binary compatibility or source compatibility, such as 
changes to includes in headers).


Having an Alpha release after feature freeze, and starting with betas after API 
freeze, seems sensible. The header review can continue beyond that to confirm 
that we haven’t broken any of the technical commitments we are making as a 
project.


Volker

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

Re: [Development] GitHub Pull requests

[Jean-Michaël Celerier]

> otherwise we may end up accepting contributions from Twitter :)

what is the problem if they improve the code  ?

On Tue, Mar 10, 2020 at 3:49 PM Konstantin Tokarev 
wrote:

>
>
> 10.03.2020, 17:42, "Cristian Adam" :
> > Hi,
> >
> > With the “GitHub issues” E-Mail thread we made sure the Issues are gone
> >
> > from the projects.
> >
> > What about Pull requests?
> >
> > For example qtbase has 7 pull requests.  Usually people point out that
> >
> > the Qt project uses a different collaboration method:
> >
> > https://wiki.qt.io/Qt_Contribution_Guidelines
> >
> > What stops us from accepting the contributions via GitHub?
> >
> > Is it:
> >
> > * The CLA
> > * Qt Account
> >
> > For the CLA one can simply add an instance of:
> >
> > https://github.com/cla-assistant/cla-assistant
> >
> > And it’s only one click away.
> >
> > When I contributed to vcpkg, the process of signing the Microsoft
> >
> > CLA was like that, one click.
> >
> > Regarding Qt Account, maybe one can use the GitHub account to
> >
> > create a Qt Account via openid.
> >
> > With GitHub actions (or Azure Pipelines, like vcpkg) we can also validate
> >
> > the pull requests.
> >
> > We should encourage developers to contribute to Qt, not having to learn
> >
> > how to use gerrit, and using a workflow that they are familiar with,
> should
> >
> > be a plus.
>
> I think, lowering barrier of entry at expense of reviewers' convenience
> should
> have its limits, otherwise we may end up accepting contributions from
> Twitter :)
>
> --
> Regards,
> Konstantin
> ___
> 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] Arttu Tarkiainen as approver

[Paul Wicking]

+1

> On 10 Mar 2020, at 12:56, Katja Marttila  wrote:
> 
> Hi all,
>  
> I’d like to nominate Arttu Tarkiainen as approver for the Qt Project.
>  
> Arttu has been working in the installer team as a SW developer since he 
> joined the Qt Company about one year ago. First as a trainee and currently as 
> full-time employee. Arttu has been focusing mainly to improve and maintain 
> Installer Framework and proven to be very skilful developer. I’ll trust that 
> he will use the approver rights responsibly and follow the Qt guidelines.
>  
> Here is the list of his changes:
> https://codereview.qt-project.org/q/owner:arttu.tarkiainen%2540qt.io
>  
And here's a list of changes he’s a reviewer on:
https://codereview.qt-project.org/q/reviewer:arttu.tarkiainen%2540qt.io


> Br,
> Katja Marttila
> Software Engineer | Maintainer of Installer Framework
> The Qt Company | Finland | Oulu
>  
>  
> ___
> 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] GitHub Pull requests

[Konstantin Tokarev]

10.03.2020, 17:42, "Cristian Adam" :
> Hi,
>
> With the “GitHub issues” E-Mail thread we made sure the Issues are gone
>
> from the projects.
>
> What about Pull requests?
>
> For example qtbase has 7 pull requests.  Usually people point out that
>
> the Qt project uses a different collaboration method:
>
> https://wiki.qt.io/Qt_Contribution_Guidelines
>
> What stops us from accepting the contributions via GitHub?
>
> Is it:
>
> * The CLA
> * Qt Account
>
> For the CLA one can simply add an instance of:
>
> https://github.com/cla-assistant/cla-assistant
>
> And it’s only one click away.
>
> When I contributed to vcpkg, the process of signing the Microsoft
>
> CLA was like that, one click.
>
> Regarding Qt Account, maybe one can use the GitHub account to
>
> create a Qt Account via openid.
>
> With GitHub actions (or Azure Pipelines, like vcpkg) we can also validate
>
> the pull requests.
>
> We should encourage developers to contribute to Qt, not having to learn
>
> how to use gerrit, and using a workflow that they are familiar with, should
>
> be a plus.

I think, lowering barrier of entry at expense of reviewers' convenience should
have its limits, otherwise we may end up accepting contributions from Twitter :)

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

[Development] GitHub Pull requests

[Cristian Adam]

Hi,

With the “GitHub issues” E-Mail thread we made sure the Issues are gone
from the projects.

What about Pull requests?

For example qtbase has 7 pull requests.  
Usually people point out that
the Qt project uses a different collaboration method:
https://wiki.qt.io/Qt_Contribution_Guidelines

What stops us from accepting the contributions via GitHub?

Is it:

  1.  The CLA
  2.  Qt Account

For the CLA one can simply add an instance of:
https://github.com/cla-assistant/cla-assistant

And it’s only one click away.

When I contributed to vcpkg, the process of signing the Microsoft
CLA was like that, one click.

Regarding Qt Account, maybe one can use the GitHub account to
create a Qt Account via openid.

With GitHub actions (or Azure Pipelines, like vcpkg) we can also validate
the pull requests.

We should encourage developers to contribute to Qt, not having to learn
how to use gerrit, and using a workflow that they are familiar with, should
be a plus.

Cheers,
Cristian.

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

Re: [Development] Qt 5.15 API review

[Jani Heikkinen]

> -Original Message-
> From: Giuseppe D'Angelo 
> Sent: tiistai 10. maaliskuuta 2020 14.48
> To: Jani Heikkinen 
> Cc: Qt development mailing list 
> Subject: Re: [Development] Qt 5.15 API review
> 
> Il 10/03/20 13:45, Jani Heikkinen ha scritto:
> > We haven't been blocking Beta (n) lately because of ongoing API review.
> Earlier when there were only one beta we did that. After we started to
> deliver several beta releases we stopped to block betas because of not
> finalized API review.
> >
> > And I think that is correct way to do this; It is better to start 
> > publishing beta
> releases as soon as possible instead of waiting until API review is complete
> 
> But then, what's the difference between the alpha releases and the beta
> releases?
>

That is actually really good question especially now when we are delivering 
binaries also with Alpha release.

I see that Alpha is a milestone to show what new we get in at FF. And Alpha 
should be out really soon after feature freeze and it is most important to get 
src packages out. Binaries are extra and some new modules can be missing from 
possible binary packages. Alpha is also a checkpoint to see that our releasing 
machinery will work.

And Beta1 starts beta phase where we should have all modules in builds & 
packages. But Beta1 can be still quite unfinished; target is to finalize 
release during beta phase as long as we are ready for RC. 

Couple of years ago I even proposed that we should stop doing Alpha and beta 
releases and just deliver snapshots until we are ready for RC. But that didn't 
get that much support at that time...

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

Re: [Development] Qt 5.15 API review

[Giuseppe D'Angelo via Development]

Il 10/03/20 13:45, Jani Heikkinen ha scritto:

We haven't been blocking Beta (n) lately because of ongoing API review. Earlier 
when there were only one beta we did that. After we started to deliver several 
beta releases we stopped to block betas because of not finalized API review.

And I think that is correct way to do this; It is better to start publishing 
beta releases as soon as possible instead of waiting until API review is 
complete


But then, what's the difference between the alpha releases and the beta 
releases?


Thanks,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts



smime.p7s
Description: Firma crittografica S/MIME
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 5.15 API review

[Jani Heikkinen]

> -Original Message-
> From: Development  On Behalf Of
> Giuseppe D'Angelo via Development
> Sent: tiistai 10. maaliskuuta 2020 14.32
> To: development@qt-project.org
> Subject: Re: [Development] Qt 5.15 API review
> 
> Il 10/03/20 10:53, Jani Heikkinen ha scritto:
> > It seems API review is still ongoing and many reviews are missing +2:
> 
> But, out of curiosity, why was the beta published when API review was still
> ongoing?

We haven't been blocking Beta (n) lately because of ongoing API review. Earlier 
when there were only one beta we did that. After we started to deliver several 
beta releases we stopped to block betas because of not finalized API review. 

And I think that is correct way to do this; It is better to start publishing 
beta releases as soon as possible instead of waiting until API review is 
complete

br,
Jani


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

Re: [Development] Qt 5.15 API review

[Giuseppe D'Angelo via Development]

Il 10/03/20 10:53, Jani Heikkinen ha scritto:

It seems API review is still ongoing and many reviews are missing +2:


But, out of curiosity, why was the beta published when API review was 
still ongoing?


Thanks,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts



smime.p7s
Description: Firma crittografica S/MIME
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Arttu Tarkiainen as approver

[Katja Marttila]

Hi all,

I'd like to nominate Arttu Tarkiainen as approver for the Qt Project.

Arttu has been working in the installer team as a SW developer since he joined 
the Qt Company about one year ago. First as a trainee and currently as 
full-time employee. Arttu has been focusing mainly to improve and maintain 
Installer Framework and proven to be very skilful developer. I'll trust that he 
will use the approver rights responsibly and follow the Qt guidelines.

Here is the list of his changes:
https://codereview.qt-project.org/q/owner:arttu.tarkiainen%2540qt.io

Br,
Katja Marttila
Software Engineer | Maintainer of Installer Framework
The Qt Company | Finland | Oulu


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

Re: [Development] Qt 5.15 API review

[Jani Heikkinen]

Hi all,

It seems API review is still ongoing and many reviews are missing +2:
- qtbase: https://codereview.qt-project.org/c/qt/qtbase/+/289203
- qtdeclarative: https://codereview.qt-project.org/c/qt/qtdeclarative/+/289205
- qttools: https://codereview.qt-project.org/c/qt/qttools/+/289207
- qtwebengine: https://codereview.qt-project.org/c/qt/qtwebengine/+/289212
- qtquick3d: https://codereview.qt-project.org/c/qt/qtquick3d/+/289214

+ Few from QML API review:
- qt3d: https://codereview.qt-project.org/c/qt/qt3d/+/291189
- qtquickcontrols2: 
https://codereview.qt-project.org/c/qt/qtquickcontrols2/+/291782
- qtremoteobjects: 
ttps://codereview.qt-project.org/c/qt/qtremoteobjects/+/291783
- qtdeclarative: https://codereview.qt-project.org/c/qt/qtdeclarative/+/292657 
& https://codereview.qt-project.org/c/qt/qtdeclarative/+/292664

Please fix reported issues and finalize API reviews as soon as possible 

br,
Jani
___
From: Jani Heikkinen
Sent: Monday, February 24, 2020 12:31 PM
To: development@qt-project.org
Subject: Qt 5.15 API review

Hi,

It seems Qt 5.15 API review is still quite badly ongoing, see 
https://bugreports.qt.io/browse/QTBUG-81853

* qtbase (https://codereview.qt-project.org/c/qt/qtbase/+/289203): started but 
pretty low activity there.
* qtdeclarative 
(https://codereview.qt-project.org/c/qt/qtdeclarative/+/289205): started & +1 
already
* qtmultimedia (https://codereview.qt-project.org/c/qt/qtmultimedia/+/289206): 
started & +1 already
* qttools (https://codereview.qt-project.org/c/qt/qttools/+/289207): started 
but pretty low activity there.
* qtlocation (https://codereview.qt-project.org/c/qt/qtlocation/+/289208): 
started but pretty low activity there.
* qtconnectivity 
(https://codereview.qt-project.org/c/qt/qtconnectivity/+/289209) : started & +1 
already
* qtwayland (https://codereview.qt-project.org/c/qt/qtwayland/+/289210) : 
started & +1 already
* qt3d (https://codereview.qt-project.org/c/qt/qt3d/+/289211): Not started at 
all
* qtwebengine (https://codereview.qt-project.org/c/qt/qtwebengine/+/289212): 
started
* qtquick3D (https://codereview.qt-project.org/c/qt/qtquick3d/+/289214): started

Please try to do reviews ASAP, thanks!

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

Re: [Development] mobile-to-mobile connection for p2p game

[Eike Ziller]

This sounds like better being asked on the interest@ mailing list.

Br, Eike

> On 9. Mar 2020, at 19:42, Zoltán Lutor  wrote:
> 
> Hi,
> 
> What to use (especially in Qt/QML) for connection to (mobile) devices in p2p 
> game?
> 
> E.g. one device is server, other is client, playing against each other in a 
> game. Like ping-pong?
> 
> One option can be Bluetooth for "close-combat" but what about Internet 
> buddies?
> 
> I was thinking about websocket but got stuck with handshaking... :(
> 
> Thx,
> 
> Zoltan
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development

-- 
Eike Ziller
Principal Software Engineer

The Qt Company GmbH
Erich-Thilo-Straße 10
D-12489 Berlin
eike.zil...@qt.io
http://qt.io
Geschäftsführer: Mika Pälsi,
Juha Varelius, Mika Harjuaho
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

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

[Development] Maintainers, your actions needed: Qt 5.14.2 changes files

[Jani Heikkinen]

Hi,

Initial ones here: 
https://codereview.qt-project.org/q/message:+%2522Add+changes+file+for+Qt+5.14.2%2522

Please finalize these asap; we are targeting to release Qt 5.14.2 Tue 17th 
March so we need to get all these in during this week

br,
Jani Heikkinen
Release Manager
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] HEADS-UP: Branching from '5.14' to '5.14.2' done

[Jani Heikkinen]

Hi all,

Branching from '5.14' to '5.14.2' is now ready and staging in '5.14.2' is 
restricted to release team only. So from now on all changes targeted to Qt 
5.14.2 release must be done in '5.14.2' and '5.14' is for changes targeted to 
Qt 5.14.3 release.

br,
Jani


From: Development  on behalf of Jani 
Heikkinen 
Sent: Friday, February 28, 2020 10:24 AM
To: development@qt-project.org
Subject: [Development] HEADS-UP: Branching from '5.14' to '5.14.2' started

Hi,

We have soft branched '5.14.2' from '5.14'. So please start using '5.14.2' for 
all new changes targeted to Qt 5.14.2 release.

Final downmerge from '5.14' to '5.14.2' will happen Monday 9th March. We are 
targeting to release Qt 5.14.2 Tue 17th March

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