Re: [Development] Nominating Jøger Hansegård for approver rights

[Liang Qi via Development]

+1

--Liang

From: Development  on behalf of Tor Arne 
Vestbø via Development 
Sent: Thursday, March 14, 2024 10:06 AM
To: development 
Subject: [Development] Nominating Jøger Hansegård for approver rights

Hi,

I would like to nominate Jøger Hansegård for approver rights in the Qt project.

Jøger joined The Qt Company 10 months ago and has since then been getting his 
hands dirty in Qt Multimedia, and lately focusing on color management.

Jøger is a thorough and responsible engineer and I trust that he will make a 
good approver for the Qt project.

Authored changes: 
https://codereview.qt-project.org/q/owner:joger.hansegard%2540qt.io
Reviews: https://codereview.qt-project.org/q/reviewer:joger.hansegard%2540qt.io

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

Re: [Development] who can fix this bug?

[Liang Qi via Development]

Forgot one thing. If I didn't remember wrong, Nvidia only releases 340.108 
driver for 5.15 and earlier kernel, and there are some community work to modify 
it to work with later versions of kernel. I assume we can't support those cases 
under this situation.

--Liang

From: Development  on behalf of Alexander 
Procenko 
Sent: Wednesday, March 1, 2023 8:36 PM
To: development@qt-project.org 
Subject: [Development] who can fix this bug?

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031489
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] who can fix this bug?

[Liang Qi via Development]

Please report it in jira, https://bugreports.qt.io/ , if you think it's a real 
Qt bug.

Please provide a complete, minimal example with enough information about how to 
reproduce your issue according to https://wiki.qt.io/ReportingBugsInQt .

I have a machine with GT218 [GeForce 210] with 340.108 driver on Ubuntu 18.04 
in office. I could have a check with 5.15 build next week.

Best regards,
Liang

From: Development  on behalf of Alexander 
Procenko 
Sent: Wednesday, March 1, 2023 8:36 PM
To: development@qt-project.org 
Subject: [Development] who can fix this bug?

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031489
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Nominating Axel Spoerl as approver

[Liang Qi via Development]

+1

From: Development  on behalf of Volker 
Hilsheimer via Development 
Sent: Monday, December 5, 2022 10:57 AM
To: development@qt-project.org 
Subject: [Development] Nominating Axel Spoerl as approver

Hi,


I’d like to nominate Axel Spoerl as an approver for the Qt project.

Axel has been working in The Qt Company since January, writing tests, analysing 
and fixing bugs, participating in the port of Qt Speech to Qt 6, investigating 
and stabilising flaky tests across all platforms, and most recently 
implementing platform theme support for GTK3-based Linux desktop environments.

I trust him to be a good approver. Links to gerrit dashboards:

Patches: https://codereview.qt-project.org/q/owner:axel.spoerl%2540qt.io
Reviews: https://codereview.qt-project.org/q/reviewer:axel.spoerl%2540qt.io

Disclosure: I’m Axel’s indirect line manager at The Qt Company in Oslo.


Volker

___
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] QFreedesktopApplication

[Liang Qi]

About the gapplication, I assume it's sth about "man gapplication", see also 
http://manpages.ubuntu.com/manpages/impish/man1/gapplication.1.html .

-
SYNOPSIS

   gapplication help [COMMAND]

   gapplication version

   gapplication list-apps

   gapplication launch APPID

   gapplication launch APPID [FILE...]

   gapplication list-actions APPID

   gapplication action APPID ACTION [PARAMETER]

DESCRIPTION

   gapplication is a commandline implementation of the client-side of the 
org.freedesktop.Application interface as specified by the freedesktop.org 
Desktop Entry Specification.

   gapplication can be used to start applications that have DBusActivatable 
set to true in their .desktop files and can be used to send messages to 
already-running instances of
   other applications.

   It is possible for applications to refer to gapplication in the Exec 
line of their .desktop file to maintain backwards compatibility with 
implementations that do not directly
   support DBusActivatable.

   gapplication ships as part of GLib.
-

If it is correct, you are talking to support it in Qt side.

And in your change, https://codereview.qt-project.org/c/qt/qtbase/+/407263 , it 
is about to expose those functions from gio/gapplication.h into Qt.

As a Qt client app, it should support those features via DBus, perhaps QtDBus 
can't satisfy this request, which you have mentioned 
https://bugreports.qt.io/browse/QTBUG-63884 . Perhaps you could leave a comment 
there to explain your use case for it.

That's my understanding for today.

I agree with Thiago in his reply. And about KDE, found sth like 
https://invent.kde.org/frameworks/kglobalaccel/-/merge_requests/11 , "Use DBus 
activation for applications that are dbus activatable", perhaps related with 
this topic.

See also:

* https://specifications.freedesktop.org/desktop-entry-spec/1.1/index.html 
Desktop Entry Specification
* https://specifications.freedesktop.org/desktop-entry-spec/1.1/ar01s07.html 
D-Bus Activation
* https://github.com/GNOME/glib/blob/main/gio/gapplication.h
* https://docs.gtk.org/gio/class.Application.html

Best regards,
Liang


From: Development  on behalf of Ilya Fedin 

Sent: Monday, April 25, 2022 12:16 PM
To: development@qt-project.org 
Subject: Re: [Development] QFreedesktopApplication

On Sun, 24 Apr 2022 20:01:10 -0700
Thiago Macieira  wrote:

> Then this should be implemented regardless of whether glib is used.
>
> We also need to know whether the KDE equivalent is being used and
> avoid confusing the launcher by emitting twice.

As I said, it's opt-in...

> I don't agree with the value.
>
> Implement it directly with Qt resources.

The reason I implemented that is I don't have enough time/motivation
to implement all the four or even three specs by hand. I just need a
way to interate existing library with Qt...

Also, personally I stopped using QtDBus in my projects due to
QTBUG-63884 and the fact it's unmaintained for 6 years.
___
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] QTouchDevice in Qt 6 ?

[Liang Qi]

https://www.qt.io/blog/input-events-in-qt-6

Hope it helps.

—Liang

> On 8 Oct 2021, at 16:02, Martin Koller  wrote:
> 
> Hi,
> 
> seems QTouchDevice in Qt6 is gone, but I don't see any mentioning of it in
> https://doc.qt.io/qt-6/gui-changes-qt6.html
> 
> Any hint to some information regarding this change ?
> 
> -- 
> Best regards/Schöne Grüße
> 
> Martin
> A: Because it breaks the logical sequence of discussion
> Q: Why is top posting bad?
> 
> ()  ascii ribbon campaign - against html e-mail 
> /\- against proprietary attachments
> 
> Frühstück, Geschenkideen, Accessoires, Kulinarisches: www.lillehus.at
> 
> 
> ___
> 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] Patch workflow in qt5 supermodule (provisioning)

[Liang Qi]

Hi,

I think we haven’t move to “cherry-pick” mode, (dev first, then cherry-pick to 
other branches) yet.

So still like before, do it in the lowest needed branch of 5.14/5.15/dev, then 
cherry-pick to 5.12 if needed.

—Liang

> On 20 Feb 2020, at 13:03, Konstantin Tokarev  wrote:
> 
> Hello,
> 
> In the light of recent changes, should provisioning patches be merged to dev 
> first now and then cherry-picked, or previous workflow remains?
> 
> -- 
> 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] Gerrit comment "Continuous Integration: Running"

[Liang Qi]

Please help to create ticket for Project:Coin(COIN) in jira, thanks.

—Liang

> On 23 Feb 2020, at 15:19, Konstantin Tokarev  wrote:
> 
> Weird thing is happening with Coin or Gerrit - all integrating changes got 
> "Continuous Integration: Running"
> comment. Restaging leads to "Continuous Integration: Running" posted again to 
> gerrit with state changed
> back to Active.
> 
> Affected changes:
> https://codereview.qt-project.org/c/qt/qtwebkit/+/289122
> https://codereview.qt-project.org/c/qt/qtwebengine/+/290492
> https://codereview.qt-project.org/c/qt/qtwebengine/+/291481
> https://codereview.qt-project.org/c/qt/qtwebengine/+/283463
> 
> -- 
> 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] Proposal: Eliminate soft branching phase from release process

[Liang Qi]

We are using soft branching phase for two categories:

1. feature frozen or minor branch, like dev to 5.14, many new changes are 
targeting 5.14 release, but happened in dev branch, and not easy to be 
integrated or verified soon. the one week soft branching phase could help bit 
here.

2. patch releases, 1st one and others, for the first one, like 5.14.0 perhaps 
similar story like above. Anyway, for the patch releases, if the changes missed 
this release, but still could happen in next. So I think it’s better to remove 
the one week soft branching phase.

And for the 1st case, if we want to the "soft branching phase”, we could also 
find some solution for it, perhaps like some feature branches and pre-checking 
things.

Provisioning changes and coin update(perhaps other hardware or IT issues) also 
could affect the whole process. A better plan, not having too many things in 
the short one week for feature frozen period, is perhaps needed.

—Liang

> On 11 Oct 2019, at 14:16, Jani Heikkinen  wrote:
> 
> +1
> 
> This change might also speed up patch level releases a bit
> 
> br,
> Jani
> 
> 
> From: Development  on behalf of Kari 
> Oikarinen 
> Sent: Friday, October 11, 2019 3:04 PM
> To: Qt development mailing list
> Subject: [Development] Proposal: Eliminate soft branching phase from release  
>   process
> 
> I want to propose eliminating soft branching phase and instead use the
> creation of the branch as a cut-off for feature freeze (or bug fixes
> for a patch release). Frederik already alluded that there has been
> some discussion about making this change in the email about the final
> downmerge to 5.13.2.
> 
> Right now a week before feature freeze the new branch is created and
> the release manager sends a heads-up mail that tells people to finish
> their changes within a week or retarget them to the new branch. Then
> after the week is up the original branch is merged into the new
> branch. This is called a "downmerge", since it is in the opposite
> direction compared to the usual merges that go "up" to newer releases.
> Once the downmerge is done, branching is considered complete and
> feature freeze is in effect.
> 
> Similar week of soft branching is also involved when patch level
> branches are created.
> 
> As far as I can tell, the major motivation for providing this week of
> soft branching is to allow people to finish their last changes without
> needing to retarget the change to a new branch. Retargeting of a large
> number of changes would also have provided a large amount of work to
> Gerrit admins, since on our old Gerrit retargeting the change needed
> admin rights. And of course admin response time would have served as a
> bottleneck to work.
> 
> Nowadays everyone can however move their own changes over to a new
> branch. So as our tools have improved, I see a chance to simplify our
> processes as well.
> 
> So instead of the soft branching process I propose the following:
> 
> - A week before feature freeze date release manager sends a reminder
>   email about it. This provides the same useful warning as the
>   initiation of soft branching has so far.
> 
> - On feature freeze day release team creates the new branch. They send
>   an email to development list informing people about the feature
>   freeze being in effect.
> 
> - If your change did not make it into dev before the new branch was
>   created, it did not make the feature freeze cut. If it is a bug fix
>   that should go to the next release still, you need to move it to the
>   new branch. If the change happened to be integrated after branch
>   creation but before you noticed, you need to cherry-pick it to the
>   new branch. But that should hopefully be an exception.
> 
> - There are no more downmerges. All merges happen in the same
>   direction. Hopefully that makes how they happen easier to
>   understand.
> 
> The same approach should be used for patch level branches as well.
> 
> Currently there is a bit of uncertainty about when exactly the
> downmerges happen, since it requires not only someone to do it, but
> also CI not being active in the target branch. That's a requirement
> because downmerges (if they have no conflicts) are pushed directly to
> the repositories instead of going through regular CI. Eliminating them
> also eliminates this irregularity. It hasn't been a big problem, but
> these commits have no corresponding Gerrit changes, which has confused
> people when they can't actually find the review because there wasn't
> one. It can also result in broken state of code, although only rarely.
> By getting rid of downmerges we eliminate the vast majority of direct
> pushes (and all regularly done ones).
> 
> Since branches can be created without waiting for idle CI, the timing
> of feature freeze coming into effect could become better known in
> advance. This helps in avoiding confusion about whether it's in effect
> or not.
> 
> If this is approved, I promise to 

Re: [Development] [Gerrit-admin] Cherry-pick mode for 5.12

[Liang Qi]

One week after previous reply.

I had done the full round of 5.12.5->5.12 merges and most of 5.12->5.13 merges 
including qt5 and submodules except following:

* https://codereview.qt-project.org/c/qt/qtdeclarative/+/273211
* https://codereview.qt-project.org/c/qt/qttranslations/+/266633

If you found anything else is missing, please let me know, thanks.

I think 5.12 could be full cherry-pick mode now.

To provisioning change owners, please do in 5.13 branch first and then 
cherry-pick to 5.12 if needed.

—Liang

> On 3 Sep 2019, at 07:53, Liang Qi  wrote:
> 
> It happened so fast this time.
> 
> But 5.12.5 was branched out before this cherry-pick mode change on 5.12 
> branch, I plan to do the 5.12.5->5.12->5.13 merges after 5.12.5 is out. Is it 
> OK?
> 
> —Liang
> 
>> On 2 Sep 2019, at 15:13, Kari Oikarinen  wrote:
>> 
>> 
>> 
>> On 2.9.2019 15.23, Lars Knoll wrote:
>>> Hi all,
>>> 
>>> According to QUIP-5 (http://quips-qt-io.herokuapp.com/quip-0005.html), we 
>>> should move the 5.12 branch into cherry-pick mode now that we have created 
>>> the 5.14 branch.
>>> 
>>> Gerrit admins, could you please do the required changes in gerrit and for 
>>> the sanity bot? Let’s do one final down-merge of 5.12 to 5.13 once that’s 
>>> done.
>>> 
>> 
>> Sanity bot should now recognize 5.12 as an LTS branch and not complain about
>> cherry-picks there.
>> 
>> -- 
>> 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

Re: [Development] Merge and Integration status report - 2019.09.06

[Liang Qi]

During the weekend,

qt5 dev and 5.15 got integrated.

5.12.5->5.12 merges are done including qt5 and all submodules. 5.12->5.13 
merges are still ongoing.

—Liang

> On 6 Sep 2019, at 14:19, Liang Qi  wrote:
> 
> Integrations
> 
> * qt5 5.12 and 5.13 are healthy, the last submodule update integrated at 2 
> days ago
> * qt5 5.14:
>   * ongoing: https://codereview.qt-project.org/c/qt/qt5/+/272221 , hope 
> it could finish a bit later tonight
>   * previous integrated submodule update is 8 days ago.
> * qt5 dev:
>   * previous integrated submodule update is 2 weeks ago.
>   * will try https://codereview.qt-project.org/c/qt/qt5/+/271472 again 
> after https://codereview.qt-project.org/c/qt/qtquickcontrols2/+/273065 
> integrated, perhaps will happen during this weekend
> * qt5 5.15, guess the situation is similar like dev, haven't tried yet
> 
> Merges
> 
> * 5.13.1->5.13 merges almosted finished except a few modules and qt5 
> 5.13.1->5.13
> * plan to have qt5 5.12.5->5.12->5.13 merges during weekend
> 
> Anyway, with current setup, 5.12/5.12.5/5.13/5.13.5/5.14/5.15/dev and there 
> are two branches which are in active developemnt, wip/qt6 and wip/cmake. Lots 
> of things related with merges are expected. Hope we can impove the situation 
> very soon.
> 
> Nice weekend!
> 
> Report from Liang
> ___
> 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] Merge and Integration status report - 2019.09.06

[Liang Qi]

Integrations

* qt5 5.12 and 5.13 are healthy, the last submodule update integrated at 2 days 
ago
* qt5 5.14:
* ongoing: https://codereview.qt-project.org/c/qt/qt5/+/272221 , hope 
it could finish a bit later tonight
* previous integrated submodule update is 8 days ago.
* qt5 dev:
* previous integrated submodule update is 2 weeks ago.
* will try https://codereview.qt-project.org/c/qt/qt5/+/271472 again 
after https://codereview.qt-project.org/c/qt/qtquickcontrols2/+/273065 
integrated, perhaps will happen during this weekend
* qt5 5.15, guess the situation is similar like dev, haven't tried yet

Merges

* 5.13.1->5.13 merges almosted finished except a few modules and qt5 
5.13.1->5.13
* plan to have qt5 5.12.5->5.12->5.13 merges during weekend

Anyway, with current setup, 5.12/5.12.5/5.13/5.13.5/5.14/5.15/dev and there are 
two branches which are in active developemnt, wip/qt6 and wip/cmake. Lots of 
things related with merges are expected. Hope we can impove the situation very 
soon.

Nice weekend!

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

Re: [Development] [Gerrit-admin] Cherry-pick mode for 5.12

[Liang Qi]

It happened so fast this time.

But 5.12.5 was branched out before this cherry-pick mode change on 5.12 branch, 
I plan to do the 5.12.5->5.12->5.13 merges after 5.12.5 is out. Is it OK?

—Liang

> On 2 Sep 2019, at 15:13, Kari Oikarinen  wrote:
> 
> 
> 
> On 2.9.2019 15.23, Lars Knoll wrote:
>> Hi all,
>> 
>> According to QUIP-5 (http://quips-qt-io.herokuapp.com/quip-0005.html), we 
>> should move the 5.12 branch into cherry-pick mode now that we have created 
>> the 5.14 branch.
>> 
>> Gerrit admins, could you please do the required changes in gerrit and for 
>> the sanity bot? Let’s do one final down-merge of 5.12 to 5.13 once that’s 
>> done.
>> 
> 
> Sanity bot should now recognize 5.12 as an LTS branch and not complain about
> cherry-picks there.
> 
> -- 
> 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

Re: [Development] [Android] Raising minimum supported Android NDK version to r19

[Liang Qi]

On Thu, 1 Aug 2019 at 18:58, Alexey Rochev  wrote:
>
> Hello,
> I'm currently investigating several problems with building Qt with
> recent (r19 and r20) NDK versions. In NDK r19 Google added a new
> toolchain, and we need to use it for some features to work (e.g.
> LTCG). It would greatly simplify build system configuration if we
> dropped support of previous NDK versions. Doing so will also require
> us to drop support of android-g++ platform (GCC was removed in NDK
> r18) and armv5 (removed in NDK r17). Also it will require clients to
> use r19+ too. What do you think?

See also https://bugreports.qt.io/browse/QTQAINFRA-2568 .

Best Regards,
Liang

>
> Alexey Rochev
> ___
> 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] qtlottie build broken: "Missing CMake tests. Either create tests in tests/auto/cmake"

[Liang Qi]

https://codereview.qt-project.org/c/qt/qtlottie/+/268295
http://bugreports.qt.io/browse/QTBUG-77130

Liang

> On 22 Jul 2019, at 21:22, Simon Hausmann  wrote:
> 
> I think I fixed that last week. What’s your sha1?
> 
> There is not C++ application linkage for the module in question so cmake app 
> linkage tests don’t make sense IMHO.
> 
> Simon
> 
>> On 22. Jul 2019, at 21:16, Thiago Macieira  wrote:
>> 
>> [the "or" part of the either is not applicable]
>> 
>> Can someone please add the tests? Treat as P0.
>> 
>> -- 
>> Thiago Macieira - thiago.macieira (AT) intel.com
>> Software Architect - Intel System Software Products
>> 
>> 
>> 
>> ___
>> 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

[Development] Merge and Integration status report - 2019.06.28

[Liang Qi]

Integrations

* qt5 5.12: submodule updated two days ago. The only issue is qtvirtualkeyboard 
was decoupled from qt5, see https://bugreports.qt.io/browse/QTBUG-76371 , need 
to wait COIN production update

* qt5 5.13: submodule updated three days ago. The only issue is 
https://bugreports.qt.io/browse/QTBUG-76549 , tst_Dialogs failed on macOS 10.13

* qt5 dev: submodule updated this morning. qtwebengine is decoupled from qt5 
because above QTBUG-76549.

Merges

* qt5 5.12.4->5.12 merges are done, all submodules and qt5
* qt5 5.13.0->5.13 merges are still on-going
* and 5.12->5.13->dev will come, especially for qt5

Etc

* In these last few days for the 1st half year of 2019, there are several tasks 
have more priority inside TQtC. So some cancellation of integrations happened 
for this purpose. Hope this doesn't hurt much.

Enjoy summer(or winter)!

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

Re: [Development] Gerrit is back

[Liang Qi]

Gerrit admins,

Thanks for the upgrade.

I like MERGE_LIST feature very much, 
https://codereview.qt-project.org/c/qt/qtbase/+/262306/5..6//MERGE_LIST

But I have one question, when I search a sha1 of one commit, the old gerrit 
only shows the change itself, the new gerrit will also show all changes which 
have comments of that sha1. How should I do if I only want to get the change 
itself? Thanks.

Best regards,
Liang

> On 20 May 2019, at 15:00, Jukka Jokiniva  wrote:
> 
> Dear all,
> 
> we are happy to inform you that Gerrit and COIN are back online and all 
> operation can resume. All access has been restored.
> Please refer to the public wiki for further information, 
> https://wiki.qt.io/Gerrit_Upgrade_2019.
> 
> Bug reports and improvement ideas can be reported to bugreports.qt.io 
> (project=QTQAINFRA component= Gerrit). Here is a tiny link: 
> http://tiny.cc/new-qt-gerrit-issue
> 
> Best regards,
> your friendly Gerrit admin team.
> 
> 
> ___
> 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] Merge and Integration status report - 2019.05.09

[Liang Qi]

Integrations and Provisionings

* qt5 5.9, 5.12, 5.13, 5.13.0 and dev are healthy, after 
https://testresults.qt.io/coin/integration/qt/qt5/tasks/1557406940 , qt5 dev 
finally got integrated after about 4 weeks.

Merges

Please check 
https://codereview.qt-project.org/#/q/owner:%22Qt+Forward+Merge+Bot+%253Cqt_forward_merge_bot%2540qt-project.org%253E%22++status:open,n,z

* Healthy, 5.12.3->5.12 merges are done

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

Re: [Development] Be careful with duplicate Change-Ids in multiple branches in gerrit

[Liang Qi]

> On 7 May 2019, at 22:13, Oswald Buddenhagen  wrote:
> 
> On Tue, May 07, 2019 at 01:52:48PM +0000, Liang Qi wrote:
>> This is a very common issue when I do the integraton work in qt5.
>> 
>> For example, currently we have 5.12->5.13->dev merge order, and the last 
>> round 5.13->5.13.0 today. One change(changeA) had been integrated in 5.13, 
>> and another change(changeB) with duplicate Change-Id was pushed to 5.13.0 
>> branch with status:open. When I try to merge 5.13 to 5.13.0, the changeB 
>> will be picked up by gerrit and be part of the integration, which I found in 
>> COIN. Normally that integation will fail, but I am not 100% sure.
>> 
>> I only know the phenomenon, but not the root cause.
>> 
>> If you have a change was merged in lower branch, please try to avoid use 
>> duplicate Change-Id in upper branch, at least in the current merge order.
>> 
> please don't give such bad advice.

It’s not advice, more strict than that. This situation had wasted quite some 
time and energy from me and CI/COIN.

Here is just the latest case which happened yesterday.

When I tried to do the final down merge qt5 5.13->5.13.0 plus the submodule 
update in 5.13.0, after staged, I got 
https://codereview.qt-project.org/#/c/260927/ included in the integration in 
COIN. I need to cancel it and ask the owner or gerrit admin to abandon it. That 
takes too much time, especially if I tried it during midnight…

I don’t blame the owner of the changes, because they are not familiar with 
gerrit, especially the situation in Qt Project.

Or perhaps this should be one of the reasons of switching to one dev branch and 
cherry-pick to other branches development model.

—Liang

> 
> firstly, the issue occurs only if neither change was integrated yet.
> i've yet to see actual evidence of another case.
> and yes, that's a bug in the gerrit CI customization. one can only hope
> that The Upgrade will fix it.
> 
> secondly, if you're doing a cherry-pick which will be followed by a
> merge, _then you're doing it wrong_. most commonly, that will be the
> effect of client-side re-targeting where the original change was not
> abandoned.
> 
>> If you have a change landed in 5.12, and it's ok to have duplicate Change-Id 
>> when you cherry-picked it to 5.9, because we don't do merge from 5.9 to 5.12.
>> 
>> Best Regards,
>> Liang
>> ___
>> 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

[Development] Be careful with duplicate Change-Ids in multiple branches in gerrit

[Liang Qi]

This is a very common issue when I do the integraton work in qt5.

For example, currently we have 5.12->5.13->dev merge order, and the last round 
5.13->5.13.0 today. One change(changeA) had been integrated in 5.13, and 
another change(changeB) with duplicate Change-Id was pushed to 5.13.0 branch 
with status:open. When I try to merge 5.13 to 5.13.0, the changeB will be 
picked up by gerrit and be part of the integration, which I found in COIN. 
Normally that integation will fail, but I am not 100% sure.

I only know the phenomenon, but not the root cause.

If you have a change was merged in lower branch, please try to avoid use 
duplicate Change-Id in upper branch, at least in the current merge order.

If you have a change landed in 5.12, and it's ok to have duplicate Change-Id 
when you cherry-picked it to 5.9, because we don't do merge from 5.9 to 5.12.

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

[Development] Merge and Integration status report - 2019.03.15

[Liang Qi]

Integrations and Provisionings

* qt5 5.12, 5.13 and dev are healthy, finally after 
https://testresults.qt.io/coin/integration/qt/qt5/tasks/1552656661

Merges

Please check 
https://codereview.qt-project.org/#/q/owner:%22Qt+Forward+Merge+Bot+%253Cqt_forward_merge_bot%2540qt-project.org%253E%22++status:open,n,z

* Healthy, 5.12.2->5.12 merges are ongoing

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

[Development] Merge and Integration status report - 2019.03.08

[Liang Qi]

Integrations and Provisionings

* qt5 5.12 and 5.13 are healthy
* qt5 dev: submodule update on March 4 excluded qtbase, the previous one with 
qtbase in about one month ago on Feb. 7. Currently only known blocker is 
https://bugreports.qt.io/browse/QTBUG-74126 , Parse error at 
"ContactFieldType_Location" and Oliver Wolff has a fix at 
https://codereview.qt-project.org/#/c/254717/ .

Merges

Please check 
https://codereview.qt-project.org/#/q/owner:%22Qt+Forward+Merge+Bot+%253Cqt_forward_merge_bot%2540qt-project.org%253E%22++status:open,n,z

* Need some help on qtdeclarative 5.12->5.13 
https://codereview.qt-project.org/#/c/254450/
* qt5 5.13->dev merge depends on qt5 dev integrated with latest qtbase first, 
see https://codereview.qt-project.org/#/c/254215/

Happy International Women's Day! and nice weekend.

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

Re: [Development] Coin maintenance update

[Liang Qi]

Do you have any records for the qt5 integration history? How many minutes is 
average?

Or what is next step in your plan? For example, let COIN to decide when to pick 
up an approved qt5 submodule update?

I think there is no hope to stage any qt5 changes in work hour, perhaps same in 
midnight.

In same direction of your change, perhaps to limit the qt5 integration numbers 
in parallel is bit better than the 15 minutes one.

—Liang

> On 25 Feb 2019, at 13:41, Aapo Keskimölö  wrote:
> 
> Dear Developers,
> 
> 
> It has recently been raised to our attention that some integrations 
> might be very slow to progress in order to resolve their workitems and 
> we have found out that this is very likely due to some large multimodule 
> builds, eg. qt5, keeping the access to resources for itself.
> 
> Since we are not exclusively building the selfish qt5, I have decided to 
> introduce a new timeout which will cancel integration if its scheduling 
> takes more than 15 minutes. We are expecting to see some integrations to 
> be cancelled due to the related change, but hopefully we will also 
> unblock the scheduler letting rest of the work continue. Let me know if 
> this makes your life impossible and we will see if we can improve that 
> situation, somehow.
> 
> 
> May the forces of CI be with you,
> 
> Aapo
> 
> ___
> 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] Merge and Integration status report - 2019.02.01

[Liang Qi]

Merges

* Submodules and qt5 are fine.

Integrations and Provisionings

* qt5 5.12 are healthy
* Trying to have a few changes from Ryan, about docker based network test 
server for Windows, see 
https://codereview.qt-project.org/#/q/status:open+project:qt/qt5+branch:dev+topic:%22docker-based+testserver%22,n,z
 , but failed, because  https://bugreports.qt.io/browse/QTQAINFRA-2717 , The 
same agent called agentLaunched twice, that should not happen, forcefully 
restarting this workitem . And looks like it also blocks qtbase dev 
integrations.
* qt5 dev is 3 days old, I think it is also affected by above issue.
* qt5 5.13, haven't tried, because the final down merge dev->5.13 is not 
finished yet

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

Re: [Development] Archiving is working

[Liang Qi]

Looks like the index was also regenerated for October 2016,

[Development] Coin news - Jedrzej Nowacki
Tue Oct 25 10:22:41 EEST 2016

Current link: 
https://lists.qt-project.org/pipermail/development/2016-October/055084.html

It was: 
http://lists.qt-project.org/pipermail/development/2016-October/027542.html

via 
https://web.archive.org/web/20161108191742/http://lists.qt-project.org/pipermail/development/2016-October/thread.html

--Liang

On Fri, 25 Jan 2019 at 14:00, Edward Welbourne  wrote:
>
> Hi all,
>
> Again, our sysadmins claim they've fixed what was broken in the
> archives.  Please check up on any archives in which you've seen holes
> lately and let us know if there are still any problems.
>
> If all's well, I'll hope our archives are stable again and begin going
> through all our QUIPs working out where the mails they've linked have
> ended up after all of this - please do likewise for other links you know
> about.
>
> Eddy.
> ___
> 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 Sami Nurmenniemi for Approver status

[Liang Qi]

+1

Thank Sami for lots of help on QEMU build and etc.

—Liang

> On 25 Jan 2019, at 09:06, Kari Oikarinen  wrote:
> 
> 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%2540qt.io%253E%22,n,z
> 
> His reviews:
> 
> https://codereview.qt-project.org/#/q/reviewer:%22Sami+Nurmenniemi+%253Csami.nurmenniemi%2540qt.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

Re: [Development] Proposal: New branch model

[Liang Qi]

Lots of talks happened already on this thread.

I would like to think old model as "merge" model VS new model as
"cherry-pick" model.

In the old "merge" model, normally we will drop a branch out to
cherry-pick mode after having more than 3 branches and try to have 2
branches(change LTS branch to cherry-pick mode after a while). The
worst case is when we have 5.12/5.13/dev branches with regular
5.12->5.13->dev merges, and also 5.12.x and 5.13.y release branches,
more merges involved. You can imagine the "chaos" when a critical fix
is needed for multiple branches, especially the delay for development
in dev branch.

In this scenario, I will trigger a qt5 integration(with latest sha1
from all submodules) in 5.12, it will take about 1 day(at least 8
hours, a work day) to see whether it is broken or not. After fix
everything in 5.12, I will try 5.13, same process, and dev. The whole
round is quite painful, especially around feature frozen period, if
some API changes happened, more ping-pong rounds are involved, more
details see 
https://lists.qt-project.org/pipermail/development/2016-October/055084.html
(old url was invalid any more, after the mailing list scripts
regenerated the web pages.)

From last year(2018), I had a merge script/bot
(https://codereview.qt-project.org/#/q/owner:%22Qt+Forward+Merge+Bot%22,n,z)
to do the merge work, it checks qtbase and qtdeclarative daily, and do
merge if more than 5 new changes happened. And check other modules
twice a week, and do merge if there is new change old than 1 week.
BTW, qtwebengine is a bit special, and some module maintainers(like
J-P for qtquickcontrols2) triggered the merge regularly by themselves.

With merge model, and the bot, this situation also happened regularly.
Like my current attempt to have a qt5 5.12->dev merge plus a qt5 dev
submodule update,

* https://codereview.qt-project.org/#/c/249863/
* https://codereview.qt-project.org/#/c/250191/

* https://bugreports.qt.io/browse/QTBUG-72953
* https://bugreports.qt.io/browse/QTBUG-73224

Both related with changes in qtdeclarative 5.12(one is a fix for
QTBUG-72953, another is the source of QTBUG-73224), but a 5.12->dev
merge will bring them together to dev, I need to wait for a totally
fixed 5.12 for current qt5 dev integration, including fix in
qtwebengine and other modules. The current estimated time is 3 days or
a week.

In the "cherry-pick" model, we can think every other branches than dev
are in locked mode, controlled by release team or module maintainers.
The developers of patches will not be involved if "cherry-pick" bot
doesn't find conflicts and CI/COIN approved it.

The amount of total conflicts will be same in both models. The
difference is who is reponsible to fix it. I am the center point to
fix them currently, but it's very difficult to know the situation in
different branches in the whole qt5 umbrella. With new cherry-pick
mode, the owner of the change will be notified if conflicts happened.
I suggest it should also notify the module maintainer and release
team. Those people are more responsible than anyone else to have the
change happened in the target branches. And it will not block the
development in dev.

In new model, perhaps a merge monkey is not needed any more, but a
cherry-pick monkey will happen. And with the direct help from the
owner of the change, and not blocking dev branch, I consider it as
less pressure personally.

My concern is about "cherry-pick" a series of changes for a big
feature, especially during the period to have "dev" branches for both
5 and 6. I don't have solution for this issue yet.

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

[Development] Merge and Integration status report - 2019.01.22

[Liang Qi]

First issue on 2019!

Generally, CI/COIN was in a very good mood after the new year update. Then we 
met https://bugreports.qt.io/browse/QTBUG-73116 , 
tst_QString::localeAwareCompare fails (dev) and a few other issues. Now it 
looks like most of them got fixed already.

Merges

* Submodules 5.12->dev merge are fine
* qt5 5.12->dev merge is ongoing, see 
https://codereview.qt-project.org/#/c/249863/ , currently blocked by 
https://bugreports.qt.io/browse/QTQAINFRA-2591 , Windows 10 provisionigs stuck 
on sdkmanager, Tony is working on that, perhaps we need more Yes to those 
questions...

Integrations

* qt5 5.12.1/5.12 are healthy
* qt5 dev is 5 days old, expected to have new round with qt5 5.12->dev merge 
after QTQAINFRA-2591 got fixed

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

Re: [Development] [Releasing] HEADS-UP: Branching from '5.12' to '5.12.1' started

[Liang Qi]

qtbase and qttools final down merges are done,

https://codereview.qt-project.org/#/c/249324/
https://codereview.qt-project.org/#/c/249362/

And also qt5 5.12->5.12.1 final down merge is done,

https://codereview.qt-project.org/#/c/249362/

—Liang

> On 8 Jan 2019, at 08:32, Jani Heikkinen  wrote:
> 
> Hi all,
> 
> Branching from '5.12' -> '5.12.1' is finally (almost) done; qtbase and 
> qttools is  still ongoing, there were some conflicts and so on manual merge + 
> normal integration is needed there. Work is ongoing and should be ready 
> today. 
> 
> So from now on '5.12.1' is for soon coming Qt 5.12.1 release and staging 
> there is restricted to release team only. And '5.12' is for Qt 5.12.2.
> 
> Target is to get Qt 5.12.1 out as soon as possible. We will create initial 
> changes files soon so please finalize those immediately to be able to proceed 
> with the release. Release blocker list here: 
> https://bugreports.qt.io/issues/?filter=20430 Please make sure all release 
> blockers are visible in the list!
> 
> We will release first snapshot for Qt 5.12.1 during this week as well
> 
> br,
> Jani
> 
> From: Development  on behalf of Jani 
> Heikkinen 
> Sent: Monday, January 7, 2019 7:37 AM
> To: Aleksey Kontsevich; ekke; developm...@lists.qt-project.org
> Subject: Re: [Development] HEADS-UP: Branching from '5.12' to   '5.12.1'  
>   started
> 
>> -Original Message-
>> From: Development  On Behalf Of
>> Aleksey Kontsevich
>> Sent: lauantai 5. tammikuuta 2019 12.23
>> To: ekke ; developm...@lists.qt-project.org
>> Subject: Re: [Development] HEADS-UP: Branching from '5.12' to '5.12.1'
>> started
>> 
>> Hi,
>> 
>> What about QTBUG-72687 and QTBUG-72227?
>> 
> QTBUG-72687 or QTBUG-72227 aren't really a release blocker, sorry.
> 
> br,
> Jani
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
> ___
> Releasing mailing list
> releas...@qt-project.org
> https://lists.qt-project.org/listinfo/releasing

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

[Development] Merge and Integration status report - 2018.12.22

[Liang Qi]

Merges

* 5.11.3->5.11 merges are done, including qt5, so 5.11.3 branch could be nuked.
* 5.12.0->5.12, qt5 one https://codereview.qt-project.org/#/c/248857/ is ongoing
* 5.11->5.12, still missing qtwebengine and qt5
* 5.12->dev, need to be done after new year

Integrations

* 5.12 is healthy
* dev got latest submodule update merged in 
https://codereview.qt-project.org/#/c/174522/ this morning.

Happy new year!

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

[Development] Merge and Integration status report - 2018.11.15

[Liang Qi]

Integrations

* qt5 5.9/5.11/5.11.3/5.12/5.12.0 integrations are healthy
* qt5 dev integrations: qtbase didn't update for about two weeks
* https://bugreports.qt.io/browse/QTBUG-71804 'GLsizeiptr' and 
'GLintptr': redefinition; different basic types, qtwebengine team is working on 
it

Gerrit

* qtbase 5.12 is still locked(others repos 5.12 got unlocked on Nov. 13 morning)

-- Liang
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [HEADS UP] 5.12 locked down (Re: Merge and Integration status report - 2018.11.08)

[Liang Qi]

> On 11 Nov 2018, at 22:25, Thiago Macieira  wrote:
> 
> On Sunday, 11 November 2018 11:44:12 PST Liang Qi wrote:
>> I staged a few times from Friday night to now, got some changes integrated
>> and found some issues in them. Do you have some changes need to stage?
> 
> I have a few bug fixes and improvements, but nothing urgent. I was just 
> wondering about the logic of leaving it locked down during the weekend.
> 
> dev is integrating fine.

Here is my working log(Nov. 8 to 12) for qtbase 5.12:

=

Nov. 8

* 1pm, announcement about qtbase 5.12 got locked, but release team and a few 
people still have privilege to stage
* 4pm, staged https://codereview.qt-project.org/#/c/244725/ the fix for bloker 
(got a few other changes staged by another person) - 
http://coin/coin/integration/qt/qtbase/tasks/1543396094

1 stage

Nov. 9

* 7:57am coin sucks(reboot) - 
http://coin/coin/integration/qt/qtbase/tasks/1543397138
* 8:02am coin reboot again - 
http://coin/coin/integration/qt/qtbase/tasks/1543404322 (succeed in 2h18m)
  * a background build for above 
http://coin/coin/integration/qt/qtbase/tasks/web_qt_qtbase_1541747658570
* 10:41am staged https://codereview.qt-project.org/#/c/243826/ - 
http://coin/coin/integration/qt/qtbase/tasks/1543439390 (failed in 2h21m)
* WinRT: tst_QEventDispatcher::registerTimer() QTestLib: This test case 
check ("(((receivedEventType) == (int(QEvent::Timer") failed because the 
requested timeout (20 ms) was too short, 70 ms would have been sufficient this 
time.
* 1:12pm restaged - http://coin/coin/integration/qt/qtbase/tasks/1543464639
* 5:14pm coin reboot - http://coin/coin/integration/qt/qtbase/tasks/1543482384
* 5:25pm coin reboot - http://coin/coin/integration/qt/qtbase/tasks/1543507534
* 5:29pm coin reboot - http://coin/coin/integration/qt/qtbase/tasks/1543507580 
(succeed in 2h3m)
* 10:45pm staged 5 changes together - 
http://coin/coin/integration/qt/qtbase/tasks/1543598167 (succeed in 2h28m)

3 stages/1 background build/5 coin reboot
1 stage->succeed

Nov. 10(Saturday)

* 8:42am staged https://codereview.qt-project.org/#/c/244677/ - 
http://coin/coin/integration/qt/qtbase/tasks/1543619138 (failed in 55m - qmake 
crash on opensuse)
* 9:54am re-taged - http://coin/coin/integration/qt/qtbase/tasks/1543627241 
(failed in 56m - tst_QEventDispatcher::registerTimer() on macOS 10.13)
* 11:37am re-staged - http://coin/coin/integration/qt/qtbase/tasks/1543642827 
(failed in 35m - tst_QEventDispatcher::registerTimer() on macOS 10.13)
* 12:21pm re-stage - http://coin/coin/integration/qt/qtbase/tasks/1543642917 
(failed in 31m - tst_QEventDispatcher::registerTimer() on macOS 10.13)
* 2:42pm re-stage - http://coin/coin/integration/qt/qtbase/tasks/1543651407 
(failed in 1h44m - tst_QEventDispatcher::registerTimer() on WinRT)
* 6:12pm re-stage - http://coin/coin/integration/qt/qtbase/tasks/1543652915 
(failed in 2h44m - "Most likely the test has crashed" on WinRT)
* 9:39pm a background build - 
http://coin/coin/integration/qt/qtbase/tasks/web_qt_qtbase_1541882395456 
(succeed in 1h57m)
* 9:42pm staged https://codereview.qt-project.org/#/c/235713/ - 
http://coin/coin/integration/qt/qtbase/tasks/1543676742 (failed in 1h7m - 
tst_QTcpServer::ipv6Server(WithSocks5Proxy) on macOS 10.12)

7 stages/1 background build/0 coin reboot
0 stage->succeed

Nov. 11(Sunday)

* 9:28am staged https://codereview.qt-project.org/#/c/244677/ - 
http://coin/coin/integration/qt/qtbase/tasks/1543677498 (succeed in 35m)
* 10:12am staged 6 changes together - 
http://coin/coin/integration/qt/qtbase/tasks/1543678216 (succeed in 2h25m)
* 8:06pm staged 8 changes together - 
http://coin/coin/integration/qt/qtbase/tasks/1543687675 (failed in 7m - real 
failure)
* 8:27pm staged 7 changes together - 
http://coin/coin/integration/qt/qtbase/tasks/1543701974 (failed in 35min - 
tst_QEventDispatcher::registerTimer() on macOS 10.13)
* 9:14pm a background build - 
http://coin/coin/integration/qt/qtbase/tasks/web_qt_qtbase_1541967249016 
(succeed in 1h42m)
* 11:13pm staged 7 changes again - 
http://coin/coin/integration/qt/qtbase/tasks/1543709881 (succeed in 19s)

5 stages/1 background build/0 coin reboot
1 stage->succeed

Nov. 12

* 8:19am staged 5 changes together - 
http://coin/coin/integration/qt/qtbase/tasks/1543741463 (succeed in 2h25m)
* 10:53am staged 8 changes togehter - 
http://coin/coin/integration/qt/qtbase/tasks/1543764990 (failed in 53m - 
tst_QEventDispatcher::registerTimer() on macOS 10.13)
* 12:00pm a background build - 
http://coin/coin/integration/qt/qtbase/tasks/web_qt_qtbase_1542020400468 
(succeed in 1h50m)
* 2:01pm re-staged 8 changes - 
https://testresults.qt.io/coin/integration/qt/qtbase/tasks/1543790835 (succeed 
in 24m)

3 stages/1 background build/0 coin reboot
1 stage->succeed

=

I think it’s a much better result compared with previous chaos(random staging, 
and many client lost and etc). I didn't plan to provi

Re: [Development] [HEADS UP] 5.12 locked down (Re: Merge and Integration status report - 2018.11.08)

[Liang Qi]

> On 11 Nov 2018, at 20:01, Thiago Macieira  wrote:
> 
> On Thursday, 8 November 2018 04:00:08 PST Oswald Buddenhagen wrote:
>> On Thu, Nov 08, 2018 at 08:29:47AM +, Liang Qi wrote:
>>> I don't know how to use [Grafana] to show the statistic of qtbase 5.12
>>> integrations in coin. There are only 3 successful integrations
>>> yesterday: [...]
>> 
>> because this situation has been persisting for weeks and we've been
>> essentially just burning energy and motivation with doomed integration
>> attempts, we decided to lock down 5.12 until the situation is under
>> control. a somewhat optimistic ETA is maybe a week, depending on the CI
>> team's progress with deploying infrastructure software updates (it's a
>> bit more involved than it sounds, so bear with them).
>> 
>> if you have critical changes which justify spending extra effort to get
>> them in soon, talk to liang.
> 
> Is this done? When is the lock down getting removed?
> 
> And who's working on 5.12 during the weekend, as it is still locked down.

The fix of the blocker got merged into qtbase 5.12. But the issue of ci/coin is 
not fixed yet. Talked with Oswald on Friday, we agreed to keep qtbase 5.12 lock 
a bit longer.

I staged a few times from Friday night to now, got some changes integrated and 
found some issues in them. Do you have some changes need to stage?

Recently the qtbase integration takes a bit longer, 2.5 hours like 
https://testresults.qt.io/coin/integration/qt/qtbase/tasks/1543678216 , is a 
bit lucky. More details see https://bugreports.qt.io/browse/QTQAINFRA-2161 .

—Liang 
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [HEADS UP] 5.12 locked down (Re: Merge and Integration status report - 2018.11.08)

[Liang Qi]

> On 8 Nov 2018, at 13:00, Oswald Buddenhagen  wrote:
> 
> On Thu, Nov 08, 2018 at 08:29:47AM +0000, Liang Qi wrote:
>> I don't know how to use [Grafana] to show the statistic of qtbase 5.12
>> integrations in coin. There are only 3 successful integrations
>> yesterday: [...]
>> 
> because this situation has been persisting for weeks and we've been
> essentially just burning energy and motivation with doomed integration
> attempts, we decided to lock down 5.12 until the situation is under
> control. a somewhat optimistic ETA is maybe a week, depending on the CI
> team's progress with deploying infrastructure software updates (it's a
> bit more involved than it sounds, so bear with them).
> 
> if you have critical changes which justify spending extra effort to get
> them in soon, talk to liang.

I thought qtbase 5.12 got locked since previous email. Looks like not, or some 
people(with privilege) are still eager to hit the stage button. I will not try 
more during tonight.

—Liang

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

Re: [Development] The CI has been integrating for 38 hours

[Liang Qi]

A CI/COIN reboot happened on 11am on Saturday, and sucked. Once more around 9am 
this morning(Oslo time). Let’s see.

—Liang

> On 4 Nov 2018, at 06:25, Thiago Macieira  wrote:
> 
> https://codereview.qt-project.org/244145
> Integration started Friday 16:45 CET. I guess everyone shortly left for the 
> weekend after that.
> 
> -- 
> Thiago Macieira - thiago.macieira (AT) intel.com
>  Software Architect - Intel Open Source Technology Center
> 
> 
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

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

[Development] Merge and Integration status report - 2018.10.29

[Liang Qi]

Integrations

* qt5 5.9/5.11/5.12/dev integrations are healthy

Merges

* qtdeclarative 5.11->5.12 merge(10 days) is ongoing, 
https://codereview.qt-project.org/#/c/243050/
* qtbase 5.11->5.12 merge, need help, 
https://codereview.qt-project.org/#/c/243826/
* qtbase 5.12->dev merged on Saturday, 
https://codereview.qt-project.org/#/c/243500/

I will check other 5.11->5.12 merges today before the latest 5.12->5.12.0 final 
down merge.

Provisionings

* qt5 5.12: Android NDK(r18b) and SDK updated on all host platforms on Oct. 20
* qt5 dev: Trying to integrate https://codereview.qt-project.org/#/c/240554/ 
(Docker Provisioning: Install Docker-based test servers on macOS) soon

-- Liang
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Shutting down the CI right now!

[Liang Qi]

Hi, Tony,

Now the current integration for https://codereview.qt-project.org/#/c/239542/ 
and another change looks promising. Thanks.

And I plan to hi-jack qtbase 5.12 branch for a batch of qmake and android 
changes after this integration once more.

—Liang

> On 12 Oct 2018, at 08:12, Tony Sarajärvi  wrote:
> 
> Liang: Ok, one thing is my bad in all of this. I told you yesterday after 
> noon that I've reverted the host-passthrough thing. Well...yeah, the 
> configuration. I just forgot to host the setting to the hosts. Just realized 
> it. So _now_ the old settings of qemu64 instead of host-passthrough is in 
> effect. See if that helps.
> 
> -Tony
> 
> -----Original Message-
> From: Liang Qi 
> Sent: perjantai 12. lokakuuta 2018 8.21
> To: Tony Sarajärvi 
> Cc: development@qt-project.org
> Subject: Re: [Development] Shutting down the CI right now!
> 
> Thanks for the work, and sometimes in spare time.
> 
> But there is no success for qt5 integrations and qtbase in any branch since 
> the work from Wednesday night. See 
> https://bugreports.qt.io/browse/QTQAINFRA-2273 , Angle building timeout (on 
> Windows)
> 
> So I suggest not to restage in above areas at least before the issue got 
> fixed.
> 
> Best Regards,
> Liang
> 
>> On 12 Oct 2018, at 07:16, Tony Sarajärvi  wrote:
>> 
>> Wow… ok it took longer than expected (as usual). Not only did we have to 
>> remove snapshots, we also had to run unmap on the Compellent, so this whole 
>> thing took a while. But nothing got lost, thanks to a last minute 
>> intervention.
>> 
>> So, the CI is up again, and good luck stage storming it
>> 
>> -Tony
>> 
>> From: Tony Sarajärvi 
>> Sent: torstai 11. lokakuuta 2018 14.49
>> To: development@qt-project.org
>> Subject: Shutting down the CI right now!
>> 
>> Hi
>> 
>> Due to a lot of changes while developing and snapshots being huge, our 
>> Compellent backend is nearly 100% full. I’ll shut down the CI for a few 
>> hours to avoid everything breaking due to lack of disk space. We’ll be back 
>> after snapshots have been deleted.
>> 
>> -Tony
>> ___
>> Development mailing list
>> Development@qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/development
> 

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

Re: [Development] Shutting down the CI right now!

[Liang Qi]

Thanks for the work, and sometimes in spare time.

But there is no success for qt5 integrations and qtbase in any branch since the 
work from Wednesday night. See https://bugreports.qt.io/browse/QTQAINFRA-2273 , 
Angle building timeout (on Windows)

So I suggest not to restage in above areas at least before the issue got fixed.

Best Regards,
Liang

> On 12 Oct 2018, at 07:16, Tony Sarajärvi  wrote:
> 
> Wow… ok it took longer than expected (as usual). Not only did we have to 
> remove snapshots, we also had to run unmap on the Compellent, so this whole 
> thing took a while. But nothing got lost, thanks to a last minute 
> intervention.
>  
> So, the CI is up again, and good luck stage storming it
>  
> -Tony
>  
> From: Tony Sarajärvi 
> Sent: torstai 11. lokakuuta 2018 14.49
> To: development@qt-project.org
> Subject: Shutting down the CI right now!
>  
> Hi
>  
> Due to a lot of changes while developing and snapshots being huge, our 
> Compellent backend is nearly 100% full. I’ll shut down the CI for a few hours 
> to avoid everything breaking due to lack of disk space. We’ll be back after 
> snapshots have been deleted.
>  
> -Tony
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

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

[Development] Merge and Integration status report - 2018.09.28

[Liang Qi]

Integrations

* qt5 5.9/5.11 integrations are healthy
* qt5 5.12, one integration was done this morning, but qtbase was two days old.
* * https://bugreports.qt.io/browse/QTBUG-70779 libqtgeoservices_mapboxgl.so 
link failure on android. Root cause was found, need help to find final solution.
* qt5 dev, last integration was two weeks ago, will try a new one after 
qtwebengine 5.12->dev merge finished, see 
https://codereview.qt-project.org/#/c/241338/ , still need someone's +2.

-- Liang
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Merge and Integration status report - 2018.09.05

[Liang Qi]

Integrations

* qt5 5.11/5.11.2/5.12 integrations are healthy, finally for 5.12

* qt5 dev, 5.12->dev merge + dev submodule update integration just started, 
let's see

COIN is a bit slow recently, the difference between backend vm numbers and coin 
running numbers is a bit too much. Colleagues are working on that. During this 
period, perhaps qmake timeout issue is very common on all platforms, including 
Linux, Windows and macOS.

-- Liang
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Strange behavior on 5.12 branch and moc genrated file ( KDE application )

[Liang Qi]

Perhaps it's related with https://codereview.qt-project.org/#/c/235352/ .

--Liang

On Wed, 5 Sep 2018 at 09:20, Helio Chissini de Castro  wrote:

> Morning guys
>
> After compile 5.12 branch from yesterday morning, i got one KDE
> application failing due a compiler error on a generated moc file.
> Is there any moc relevant change ? I didn't change my compiler environment
> from previous 5.11 and always compile all in a clean chroot, with no
> previous versions installed.
> Qt itself was build with clang 6.0.1
>
> Here's the logs
>
> With gcc 8.1.1 x86_64:
>
> In file included from
> /code/kde/src/frameworks/kcoreaddons/autotests/jsonplugin2.cpp:23:
> /code/kde/src/frameworks/kcoreaddons/src/lib/plugin/kpluginfactory.h: In
> member function ‘void KPluginFactory::registerPlugin(const QString&,
> KPluginFactory::CreateInstanceFunction) [with T = JsonPlugin2;
> KPluginFactory::CreateInstanceFunction = QObject* (*)(QWidget*, QObject*,
> const QList&); QVariantList = QList]’:
> /code/kde/src/frameworks/kcoreaddons/src/lib/plugin/kpluginfactory.h:487:74:
> warning: zero as null pointer constant [-Wzero-as-null-pointer-constant]
>  =
> InheritanceChecker().createInstanceFunction(reinterpret_cast(0)))
>
> ^~~~
> In file included from
> /code/kde/src/frameworks/kcoreaddons/autotests/jsonplugin2.cpp:34:
> /code/kde/build-kde/frameworks/kcoreaddons/autotests/jsonplugin2_autogen/include/jsonplugin2.moc:
> At global scope:
> /code/kde/build-kde/frameworks/kcoreaddons/autotests/jsonplugin2_autogen/include/jsonplugin2.moc:153:1:
> error: narrowing conversion of ‘'\303'’ from ‘char’ to ‘unsigned
> char’ inside { } [-Wnarrowing]
>  };
>  ^
> /code/kde/build-kde/frameworks/kcoreaddons/autotests/jsonplugin2_autogen/include/jsonplugin2.moc:153:1:
> error: narrowing conversion of ‘'\3777651'’ from ‘char’ to ‘unsigned
> char’ inside { } [-Wnarrowing]
> 
>
>
> With clang 6.0.1 x86_64
>
> [ 63%] Building CXX object
> autotests/CMakeFiles/jsonplugin2.dir/jsonplugin2.cpp.o
> In file included from
> /code/kde/src/frameworks/kcoreaddons/autotests/jsonplugin2.cpp:34:
> /code/kde/build-kde/frameworks/kcoreaddons/autotests/jsonplugin2_autogen/include/jsonplugin2.moc:123:48:
> error: constant expression evaluates to -61
>   which cannot be narrowed to type 'unsigned char' [-Wc++11-narrowing]
> ']',  0x76,  'E',  's',  't',  'e',  ' ',  '\xc3',
>^~
> /code/kde/build-kde/frameworks/kcoreaddons/autotests/jsonplugin2_autogen/include/jsonplugin2.moc:123:48:
> note: insert an explicit cast to silence
>   this issue
> ']',  0x76,  'E',  's',  't',  'e',  ' ',  '\xc3',
>^~
>static_cast(
> )
> /code/kde/build-kde/frameworks/kcoreaddons/autotests/jsonplugin2_autogen/include/jsonplugin2.moc:124:5:
> error: constant expression evaluates to -87
>   which cannot be narrowed to type 'unsigned char' [-Wc++11-narrowing]
> '\xa9', ' ',  'o',  'u',  't',  'r',  'o',  ' ',
> ^~
>
> Any idea ?
>
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] HEADS-UP: Branching from 'dev' to '5.12' completed

[Liang Qi]

qt5 dev->5.12 is also done last night, 
https://codereview.qt-project.org/#/c/237349/ .

Please remember to retarget your provisioning changes in qt5 if agreed for 5.12.

— Liang

> On 21 Aug 2018, at 11:04, Jani Heikkinen  wrote:
> 
> Branching from 'dev' to '5.12' is now complete and Qt 5.12 Feature Freeze is 
> in effect. So from now on all changes for Qt 5.12 release must be done in 
> '5.12' and 'dev' is for Qt 5.13.
> 
> If not already done please update Qt 5.12 new features page: 
> https://wiki.qt.io/New_Features_in_Qt_5.12
> 
> Our plan is to publish Qt 5.12 alpha release as soon as possible. Alpha 
> blocker list here: https://bugreports.qt.io/issues/?filter=19449
> 
> br,
> Jani

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

[Development] Merge and Integration status report - 2018.08.13

[Liang Qi]

Integrations

* qt5 5.11 integration is healthy, last one is yesterday, August 12

* qt5 dev, last one is August 11, excluding qtbase since August 8
* * http://bugreports.qt.io/browse/QTBUG-69891 tests/auto/quick/drawingmodes 
hanging
Tor Arne is working on that. But if can't get fix soon, suggest to revert
https://codereview.qt-project.org/#/c/235685/ for now, because there are 
about 20-30
changes including a 5.11->dev merge in qtbase which are not integrated in 
qt5 dev yet.

Merges - healthy!

Thanks Simon and Edward for their work during July!

-- Liang
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Upgrade the XCode running in the CI's macOS 10.11

[Liang Qi]

For enabling test on 10.13, see
https://codereview.qt-project.org/#/c/231978/ and a few other changes from
Tony. Hope that will be done soon after summer vacation.

-- Liang

On Thu, 12 Jul 2018 at 06:13, Tor Arne Vestbø  wrote:

>
> > On 11 Jul 2018, at 18:21, Thiago Macieira 
> wrote:
> >
> > On Monday, 9 July 2018 07:31:27 PDT Alexandru Croitor wrote:
> >> I believe that's something for the macOS maintainers to decide.
> >
> > Thanks. Any opinions?
> >
> > The fix for XCode 8.2 broke XCode 9.
> >
> > Can we PLEASE drop XCode 8.2? Like, right now? I can't integrate the
> > performance improvement until that happens.
>
> I would love to drop any Xcode except the latest, but unfortunately our CI
> isn’t set up to build once (against latest SDK/Xcode) and then run tests on
> older macOS versions. Removing Xcode 8.2 effectively removes 10.11 testing.
> Seeing as we’re not building/testing on 10.13 (the latest macOS release),
> or 10.14 (the upcoming release), that would leave us with 10.12 as the
> single build/test target for macOS.
>
> Tor Arne
>
> >
> > --
> > Thiago Macieira - thiago.macieira (AT) intel.com
> >  Software Architect - Intel Open Source Technology Center
> >
> >
> >
> > ___
> > Development mailing list
> > Development@qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/development
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Raising the minimum Android NDK version

[Liang Qi]

https://bugreports.qt.io/browse/QTQAINFRA-1681
https://codereview.qt-project.org/#/c/216306/
https://codereview.qt-project.org/#/c/229465/

People are working on that, hope will get update after summer vacations.

-- Liang

On Fri, 6 Jul 2018 at 03:54, Thiago Macieira 
wrote:

> I've just been told that Android's libc contains a definition that is
> invalid
> for Android: the _PATH_MOUNTED definition in  points to a file
> that
> does not exist on Android systems.
>
> Instead of applying a workaround, can we just raise the minimum NDK to one
> that fixes the issue? Are there still valid reasons for requiring old NDKs?
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
>
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Merge and Integration status report - 2018.07.04

[Liang Qi]

Merges

* qtbase 5.11->dev, https://codereview.qt-project.org/#/c/231959/ finally got 
merged after blocked about 3 weeks. A new round is ongoing, 
https://codereview.qt-project.org/#/c/233803/ 

Integrations

* qt5 dev, last one is June 29, 4 days ago. A new one is at 
https://codereview.qt-project.org/#/c/233675/ , but wait for other provisioning 
changes.
* * Issue: https://bugreports.qt.io/browse/QTBUG-69280 qtlocation: 
declarative_ui crash. Haven’t have time to check it yet.
* qt5 5.11 is healthy, last one is yesterday

During summer holiday, please help to keep an eye on merges at 
https://codereview.qt-project.org/#/q/owner:qt_forward_merge_bot%2540qt-project.org+status:open,n,z
 and integrations at 
https://codereview.qt-project.org/#/q/owner:qt_submodule_update_bot%2540qt-project.org+status:open,n,z
 .

-- Liang
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Urgent: increase timeout for tst_qcomplextext

[Liang Qi]

On Tue, 3 Jul 2018 at 10:05, Lars Knoll  wrote:

> > On 3 Jul 2018, at 05:55, Thiago Macieira 
> wrote:
> >
> > On Saturday, 30 June 2018 10:09:11 PDT Lars Knoll wrote:
> >> Hi Thiago,
> >>
> >> maybe https://codereview.qt-project.org/#/c/233693/ helps with this
> case.
> >
> > It did help some.  It went from
> >
> > PASS   : tst_QComplexText::bidiTest(line #201771 (LTR)
> >
> > to
> >
> > PASS   : tst_QComplexText::bidiTest(line #456371 (RTL))
> >
> > So we doubled the performance. But it wasn't enough.
>
> Are you sure you already have the fix (it went into 5.11 first)? Because
> with the patch, you shouldn't see those 'line #xxx' things at all anymore.
> bidiTest should just report one single line.
>
>
> Latest qtbase 5.11->dev merge is just integrated about 10-20 minutes ago
this morning.

-- Liang
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Merge and Integration status report - 2018.07.01

[Liang Qi]

Integrations

* qt5 dev integration is healthy, last one is June 29

* qt5 5.11 integration is healthy finally again, last one is June 30

Merges

* qtbase 5.11->dev is ongoing, https://codereview.qt-project.org/#/c/231959/ , 
which was blocked about 3 weeks, lots of changes from 5.11. I really want to 
have this merged as soon as possible.

Looks like there is some issue with coin, need someone's help to check, perhaps 
reboot is needed.

-- Liang

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

[Development] Merge and Integration status report

[Liang Qi]

Integrations

* qt5 dev integration is healthy, last one is yesterday

* qt5 5.11 integration failed from June 9, last integration was done on June 
22, but skipped qtbase and qtwayland.
* * Issue: [QTBUG-68773][1] qtwayland build failed - can't find some headers
* * * https://codereview.qt-project.org/#/c/232288/ Robert Griebl has a fix, 
Oswald please help to review it. Suggest to revert to get 5.11 integrated 
again, [see the revert][2]

Merges

* qtbase 5.11->dev, the merge is blocked because [QTBUG-68773][1] is not fixed 
yet.

-- Liang

[1]: https://bugreports.qt.io/browse/QTBUG-68773
[2]: https://codereview.qt-project.org/#/c/233198/
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Merge and Integration status report

[Liang Qi]

Integrations

* qt5 dev integration failed from June 18
* * Issue: [QTBUG-68848][1] tst_QQmlDebugJS fails too often in CI, perhaps a 
duplicate of [QTBUG-68741][2], the issue is there about two weeks, more talks 
in [previous report][4]

* qt5 5.11 integration failed from June 9
* * Issue: [QTBUG-68773][3] qtwayland build failed - can't find some headers
* * * https://codereview.qt-project.org/#/c/232288/ Robert Griebl has a fix, 
Oswald please help to review it. Suggest to revert to get 5.11 integrated again.

Merges

* qtbase 5.11->dev, the merge is blocked because [QTBUG-68773][3] is not fixed 
yet.

-- Liang

[1]: https://bugreports.qt.io/browse/QTBUG-68666
[2]: https://bugreports.qt.io/browse/QTBUG-68741
[3]: https://bugreports.qt.io/browse/QTBUG-68773
[4]: http://lists.qt-project.org/pipermail/development/2018-June/032893.html

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

Re: [Development] clang-format

[Liang Qi]

> On 19 Jun 2018, at 09:58, Joerg Bornemann  wrote:
> 
>> * Which branch do you run it in? If an early one, there's many merges to do. 
>> If
>>   a late one, all the subsequent merges are tricky.
> 
> Our commit policy suggests that the right branch would be dev.
> You're right that the merges will be harder. What's the opinion of our merge 
> master?
> 
> 

We will have 5.11 for a while, perhaps a 5.11.2 after summer at least. So 
better to do it in 5.11, and after it got merged in dev, then do it in dev 
again. That should help merge a lot.

— Liang
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] clang-format

[Liang Qi]

On Mon, 18 Jun 2018 at 11:23, Kari Oikarinen  wrote:

> On 18.06.2018 12:04, Frederik Gladhorn wrote:
> 
>
> Other parts sound good, so I'll just touch on the big question.
>
>  > And then there is the big question when we run it once over the entire
>  > codebase.
>
> I'd hesitate to ever run it over the entire codebase.
>
> * It will ruin plain git blame, since so much will point to that particular
>commit. Yes, you can use `git blame -w` to avoid whitespace changes,
> but that
>does not catch rewrapped lines.
>
> git-hyper-blame ?
https://commondatastorage.googleapis.com/chrome-infra-docs/flat/depot_tools/docs/html/git-hyper-blame.html

--Liang
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Merge and Integration status report

[Liang Qi]

Integrations

* qt5 dev integration failed from June 2, a submodule update without 
qtdeclarative was done on June. 9
* * Issue: https://bugreports.qt.io/browse/QTBUG-68666 
declarative_core::MappingManagerError::test_error() failed
* * * https://codereview.qt-project.org/#/c/222768 Simon is working on that 
since yesterday

* qt5 5.11 integration failed from June 9
* * Issue: https://bugreports.qt.io/browse/QTBUG-68773 qtwayland build failed - 
can't find some headers
* * * https://codereview.qt-project.org/#/c/232288/ Robert Griebl has a fix, 
Oswald please help to review it.
* * Issue: https://bugreports.qt.io/browse/QTBUG-68741 
tst_QQmlDebuggingEnabler::qmlscene() failed
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtCS 2018 - Serialisation session notes

[Liang Qi]

On Mon, 11 Jun 2018 at 13:17, Thiago Macieira 
wrote:

> Link: https://wiki.qt.io/QtCS2018_Serialisation
>
> === Protobuf ===
>
> * Need volunteers to write a Proof of Concept
> ** plugin to protoc?
>
> About protobuf support in Qt, I have an old WIP change at
https://codereview.qt-project.org/#/c/205316/ . But not sure whether it can
help here or not.

Best Regards,
Liang
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] CI "wave-through"

[Liang Qi]

5.11.0 is fine. Latest one is successful, 
https://testresults.qt.io/coin/integration/qt/qt5/tasks/1525572833

But looks like there are issues in qt5 dev integration, please check 
https://codereview.qt-project.org/#/c/227670/  and 
https://testresults.qt.io/coin/integration/qt/qt5/tasks/1525573813 .

My proposal is switch qtdeclarative back to 
913dc3f4f2be7c2c23237bcb9bffb3192cb10d60 . The new patch set PS5 is pushed 
there, and have a background build(status check) running, looks good by now.

— Liang

> On 27 Apr 2018, at 12:28, Tuukka Turunen  wrote:
> 
>  
> Hi,
>  
> So we should probably restart https://codereview.qt-project.org/#/c/227410/ 
> and re-run other qt5.git runs to make sure all tests are properly run in 
> those?
>  
> Yours,
>  
> Tuukka
>  
> From: Development  
> on behalf of Sami Nurmenniemi 
> Date: Friday, 27 April 2018 at 13.06
> To: Simon Hausmann , "development@qt-project.org" 
> 
> Cc: Qt CI 
> Subject: Re: [Development] CI "wave-through"
>  
> Hi,
> 
>  
> 
> Increasing the "non-zero change" there a bit, the "wave-through window" was 
> from "25th of April 15:30 CET" to "27th of April 12:00 CET".
> 
>  
> 
> Best Regards,
> 
> Sami
> 
> Lähettäjä: Development 
>  käyttäjän Simon 
> Hausmann  puolesta
> Lähetetty: 27. huhtikuuta 2018 12:54:11
> Vastaanottaja: development@qt-project.org
> Kopio: Qt CI
> Aihe: [Development] CI "wave-through"
>  
> Hi,
> 
>  
> 
> Since yesterday afternoon around 15:30 central european time the CI has 
> experienced a "failure" that resulted in each and all tests being skipped. So 
> if a change broke the build, the CI would reject it. But if the change would 
> normally result in a test failing, then the CI waved the change through 
> regardless as it did not run any tests at all (apart from the BIC tests).
> 
>  
> 
> The issue has been corrected as of a few minutes ago, but there is a non-zero 
> chance that faulty changes may have slipped through and may result in test 
> failures that are not related to changes you're trying to integrate.
> 
>  
> 
>  
> 
> Simon
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

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

Re: [Development] Qt Sanity Bot down

[Liang Qi]

When Qt Sanity Bot is on vacation, here is the temporary solution, click
"Review" button, unfold the "Sanity-Review" section under "Code-Review",
just do a "+1 Sanity review passed".

--Liang

On 4 April 2018 at 10:14, Dominik Holland 
wrote:

> Hi,
>
> it looks like the Qt Sanity Bot is down for several days now. Is anyone
> working on this ? Or is this repository specific ?
>
> Atleast i can see some commits not having the bot as reviewer at all and
> adding it manually also doesn't help
> (https://codereview.qt-project.org/#/c/224989/)
>
> Dominik
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposing Albert Astals Cid for Approver

[Liang Qi]

https://codereview.qt-project.org/#/q/owner:%22Albert+Astals+Cid+%253Calbert.astals.cid%2540kdab.com%253E%22,n,z


https://codereview.qt-project.org/#/q/owner:albert.astals%2540canonical.com,n,z


https://codereview.qt-project.org/#/q/owner:%22Albert+Astals+Cid+%253Caacid%2540kde.org%253E%22,n,z


Chrome is good to copy and paste those urls.

+1, but which one of above three gerrit accounts will get the permission?
And how about his career future?

--Liang


On 21 March 2018 at 12:33, Sérgio Martins  wrote:

> Hi,
>
>
> Albert has been a long time contributor to KDE and Qt and very well known
> in the community.
>
> His dashboards speak for himself, with many bugs fixed:
> (For some reason pasting-and-opening URLs from gerrit is broken, so you'll
> have to search yourself)
>
>
> at KDAB:
> owner:"Albert Astals Cid "
>
>
> at Canonical:
> owner:albert.ast...@canonical.com
>
>
> on his free-time with KDE hat:
> owner:"Albert Astals Cid "
>
>
>
> And recently he was tricked into fixing many printing and CUPS bugs, so
> thanks Albert!
>
>
> Disclaimer: He's a collegue of mine at KDAB, knew him from KDE and lives
> somewhat near me, in the Iberian peninsula.
>
>
>
> Regards,
> --
> Sérgio Martins | sergio.mart...@kdab.com | Senior Software Engineer
> Klarälvdalens Datakonsult AB, a KDAB Group company
> Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
> KDAB - The Qt, C++ and OpenGL Experts
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Rebasing

[Liang Qi]

https://wiki.qt.io/Branch_Guidelines

search "cherry-pick"

BTW, you always can ask in #qt-labs channel at freenode, see
https://wiki.qt.io/Online_Communities . Perhaps will get reply much faster
without sending emails in mailing list.

--Liang


On 26 January 2018 at 16:14, Igor Mironchik 
wrote:

> Hi,
>
> What if you have a patch based on 5.11 branch and you want to rebase it to
> 5.9, how do you do such work? Do you use regular git rebase? Or maybe you
> just do a new branch based on 5.9, do changes, commit and changes Change-Id
> to the existing and do push?
>
> Thank you.
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] CI is suffering from problems

[Liang Qi]

both are known and fixes are available.

https://codereview.qt-project.org/#/c/215113/
https://codereview.qt-project.org/#/c/215046/

— Liang

> On 21 Dec 2017, at 14:17, Ulf Hermann  wrote:
> 
>> You have probably already noticed this, but here’s an email notifying
>> you that we’re on it. Our OpenNebula isn’t able to clone any new virtual
>> machines, complaining that the disk is full even though it isn’t. As
>> said…we continue investigating.
> 
> In addition to that we suddenly get failures when compiling QtCore and 
> QtNetwork, even if nothing has changed there:
> 
>> Module "qt/qtbase" (9ec8da01004481027df83361b998b24c63ab5a6d) The make 
>> execution failed. The CI rejected the staged commits due to the 
>> beforementioned reason. Possible reason could be flakiness in the system, 
>> but could also be a bug in one of the commits.:
>> /home/qt/work/qt/qtbase/src/corelib/global/qfloat16_f16c.c:61: undefined 
>> reference to `_mm256_cvtps_ph'
>> /home/qt/work/qt/qtbase/src/corelib/global/qfloat16_f16c.c:76: undefined 
>> reference to `_mm256_cvtph_ps'
>> Makefile:1152: recipe for target '../../lib/libQt5Core.so.5.11.0' failed
>> make[2]: *** [../../lib/libQt5Core.so.5.11.0] Error 1
>> make[1]: *** [sub-corelib-make_first] Error 2
>> make: *** [sub-src-make_first] Error 2
> 
> and
> 
>> Module "qt/qtbase" (99b12531013516c060eed60157f8b0be5eafa1e5) The make 
>> execution failed. The CI rejected the staged commits due to the 
>> beforementioned reason. Possible reason could be flakiness in the system, 
>> but could also be a bug in one of the commits.:
>> /opt/yocto-armv7/sysroots/x86_64-pokysdk-linux/usr/bin/arm-poky-linux-gnueabi/arm-poky-linux-gnueabi-g++
>>  -c -include .pch/Qt5Network -pipe -march=armv7-a -mfpu=neon -DLINUX=1 
>> -mfloat-abi=hard 
>> --sysroot=/opt/yocto-armv7/sysroots/armv7ahf-neon-poky-linux-gnueabi -g 
>> -std=c++1z -fvisibility=hidden -fvisibility-inlines-hidden -fno-exceptions 
>> -Wall -W -Wvla -Wdate-time -Wshift-overflow=2 -Wduplicated-cond -Werror 
>> -Wno-error=cpp -Wno-error=deprecated-declarations -Wno-error=strict-overflow 
>> -D_REENTRANT -fPIC -DQT_NO_USING_NAMESPACE -DQT_NO_FOREACH 
>> -DQT_USE_SYSTEM_PROXIES -DQT_NO_NARROWING_CONVERSIONS_IN_CONNECT 
>> -DQT_BUILD_NETWORK_LIB -DQT_BUILDING_QT -DQT_NO_CAST_TO_ASCII 
>> -DQT_ASCII_CAST_WARNINGS -DQT_MOC_COMPAT -DQT_USE_QSTRINGBUILDER 
>> -DQT_DEPRECATED_WARNINGS -DQT_DISABLE_DEPRECATED_BEFORE=0x05 
>> -DQT_NO_EXCEPTIONS -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_CORE_LIB 
>> -I. -Ikernel -I../../include -I../../include/QtNetwork 
>> -I../../include/QtNetwork/5.11.0 -I../../include/QtNetw
>> ork/5.11.0/QtNetwork -I../../include/QtCore/5.11.0 
>> -I../../include/QtCore/5.11.0/QtCore -I../../include/QtCore -I.moc 
>> -I../../mkspecs/devices/linux-imx7-g++ -o .obj/qnetworkinterface_linux.o 
>> kernel/qnetworkinterface_linux.cpp
>> kernel/qnetworkinterface_linux.cpp: In instantiation of ‘void 
>> {anonymous}::ProcessNetlinkRequest::operator()(int, nlmsghdr*, 
>> char*, size_t, Lambda&&) [with Lambda = getInterfaces(int, 
>> char*)::; size_t = unsigned int]’:
>> kernel/qnetworkinterface_linux.cpp:216:36:   required from ‘void 
>> {anonymous}::processNetlinkRequest(int, nlmsghdr*, char*, size_t, Lambda&&) 
>> [with Lambda = getInterfaces(int, char*)::; 
>> size_t = unsigned int]’
>> kernel/qnetworkinterface_linux.cpp:319:6:   required from here
>> kernel/qnetworkinterface_linux.cpp:161:48: error: comparison between signed 
>> and unsigned integer expressions [-Werror=sign-compare]
>> kernel/qnetworkinterface_linux.cpp: In instantiation of ‘void 
>> {anonymous}::ProcessNetlinkRequest::operator()(int, nlmsghdr*, 
>> char*, size_t, Lambda&&) [with Lambda = getAddresses(int, char*, 
>> QList&)::; size_t = 
>> unsigned int]’:
>> kernel/qnetworkinterface_linux.cpp:216:36:   required from ‘void 
>> {anonymous}::processNetlinkRequest(int, nlmsghdr*, char*, size_t, Lambda&&) 
>> [with Lambda = getAddresses(int, char*, 
>> QList&)::; size_t = 
>> unsigned int]’
>> kernel/qnetworkinterface_linux.cpp:423:6:   required from here
>> kernel/qnetworkinterface_linux.cpp:161:48: error: comparison between signed 
>> and unsigned integer expressions [-Werror=sign-compare]
>> Makefile:26401: recipe for target '.obj/qnetworkinterface_linux.o' failed
>> make[2]: *** [.obj/qnetworkinterface_linux.o] Error 1
>> make[1]: *** [sub-network-make_first] Error 2
>> make: *** [sub-src-make_first] Error 2
> 
> I guess in the first case the system headers changed and in the second case 
> the compiler changed. Do you actually test machine configuration changes 
> against the current state of Qt before you switch them live? I think that 
> should be done and any fixes to Qt for the new configuration should be 
> applied before the configuration goes live.
> 
> br,
> Ulf

Re: [Development] QtBase broken in 5.9 and 5.10. Fix is already inbound.

[Liang Qi]

https://codereview.qt-project.org/#/c/214045/ was merged. dev is fixed now.

— Liang

> On 11 Dec 2017, at 12:22, Liang Qi <liang...@qt.io> wrote:
> 
> dev is blocked by "Module "" () Failed to provision template 
> 'qtci-osx-10.11-x86_64-3-9946c2’:” issue, should be fixed by following change:
> https://codereview.qt-project.org/#/c/214045/

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

Re: [Development] QtBase broken in 5.9 and 5.10. Fix is already inbound.

[Liang Qi]

5.10 was fixed.

— Liang

> On 11 Dec 2017, at 12:22, Liang Qi <liang...@qt.io> wrote:
> 
> 5.9 was fixed. The merge to 5.10 is on the way.
> https://codereview.qt-project.org/#/c/214051/
> 
> dev is blocked by "Module "" () Failed to provision template 
> 'qtci-osx-10.11-x86_64-3-9946c2’:” issue, should be fixed by following change:
> https://codereview.qt-project.org/#/c/214045/
> 
> — Liang
> 
>> On 11 Dec 2017, at 11:03, Tony Sarajärvi <tony.saraja...@qt.io> wrote:
>> 
>> Hi
>> 
>> QtBase in 5.9 and 5.10 are broken currently. We found the bug, and it was 
>> sadly approved by yours sincerely :/
>> Fix is inbound: https://codereview.qt-project.org/#/c/214032/
>> 
>> -Tony
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

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

Re: [Development] QtBase broken in 5.9 and 5.10. Fix is already inbound.

[Liang Qi]

5.9 was fixed. The merge to 5.10 is on the way.
https://codereview.qt-project.org/#/c/214051/

dev is blocked by "Module "" () Failed to provision template 
'qtci-osx-10.11-x86_64-3-9946c2’:” issue, should be fixed by following change:
https://codereview.qt-project.org/#/c/214045/

— Liang

> On 11 Dec 2017, at 11:03, Tony Sarajärvi  wrote:
> 
> Hi
>  
> QtBase in 5.9 and 5.10 are broken currently. We found the bug, and it was 
> sadly approved by yours sincerely :/
> Fix is inbound: https://codereview.qt-project.org/#/c/214032/
>  
> -Tony

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

Re: [Development] Suggestion to add labels when changing API

[Liang Qi]

I really don’t think switch back to a monolithic repo is a good idea…

But if I understand atomic commits across submodules as successful integrations 
in qt5, I think it has some meaning to me. Here are a few tasks which I think 
perhaps related with this topic.

https://bugreports.qt.io/browse/QTBUG-19580
https://bugreports.qt.io/browse/QTQAINFRA-824

— Liang

> On 7 Dec 2017, at 18:17, Adam Treat <adam.tr...@qt.io> wrote:
> 
> Hi,
> 
> I think it is high time that we fix the underlying problem: supporting atomic 
> commits across submodules.
> 
> Once this is done we should revert our CI to test changes against latest 
> version of all modules. As for how this could be done:
> 
> * Adopt something like Google's repo tool: 
> https://code.google.com/archive/p/git-repo/
> * Stop using submodules and use a monolithic repo
> * Git subtree
> * Implement atomic commit across submodules not in Git, but in the 
> gerrit/COIN layer so that COIN effectively locks integrations until commits 
> that span submodules are finished
> * Something else?
> 
> Cheers,
> Adam
> 
> On 12/07/2017 11:22 AM, Liang Qi wrote:
>> Since 
>> http://lists.qt-project.org/pipermail/development/2016-October/027542.html , 
>> Coin tests all changes against Qt5 instead of the latest version of all 
>> modules.
>> 
>> The situation is sth like, some new APIs were added to qtbase in 5.10, and 
>> other modules were adapted. But around beta or sometime(before release), 
>> some refactoring work happened on those APIs. We adjusted them in qtbase, 
>> and other modules. We have several steps to make sure those thing to be 
>> approved in CI/COIN. But the order of things gets lost easily when merging 
>> the changes up, for example to the dev branch.
>> 
>> Here are some suggestions to make those steps more clearer to the people who 
>> maintain merge and integration.
>> 
>> The changes that are important to be merged up before other changes should 
>> have a special tag, such as API_CHANGE in the commit message. Then the 
>> script used to do the merges could stop and/or warn about commits with this 
>> tag in the message, which would make the merge easier. We can also apply 
>> this check into the submodule update script.
>> 
>> The situation is also valid for some private API changes(which were used 
>> cross qt submodules).
>> 
>> About which labels are better to be used for this purpose, please give your 
>> suggestion and votes. Thanks.
>> 
>> Best Regards,
>> Liang
>> 
>> ___
>> Development mailing list
>> Development@qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/development
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

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

[Development] Suggestion to add labels when changing API

[Liang Qi]

Since 
http://lists.qt-project.org/pipermail/development/2016-October/027542.html , 
Coin tests all changes against Qt5 instead of the latest version of all modules.

The situation is sth like, some new APIs were added to qtbase in 5.10, and 
other modules were adapted. But around beta or sometime(before release), some 
refactoring work happened on those APIs. We adjusted them in qtbase, and other 
modules. We have several steps to make sure those thing to be approved in 
CI/COIN. But the order of things gets lost easily when merging the changes up, 
for example to the dev branch.

Here are some suggestions to make those steps more clearer to the people who 
maintain merge and integration.

The changes that are important to be merged up before other changes should have 
a special tag, such as API_CHANGE in the commit message. Then the script used 
to do the merges could stop and/or warn about commits with this tag in the 
message, which would make the merge easier. We can also apply this check into 
the submodule update script.

The situation is also valid for some private API changes(which were used cross 
qt submodules).

About which labels are better to be used for this purpose, please give your 
suggestion and votes. Thanks.

Best Regards,
Liang

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

Re: [Development] qtbase 5.9 is locked down for the time being

[Liang Qi]

qtbase 5.9 is unlocked now. I didn’t see flaky things happened since yesterday.

—Liang

> On 24 Oct 2017, at 13:32, Liang Qi <liang...@qt.io> wrote:
> 
> Hi, all,
> 
> Since Oct. 20, only one change landed in qtbase 5.9, 
> https://codereview.qt-project.org/#/c/209093/
> 
> I will try to do manual stage in qtbase 5.9 to check whether it is because 
> flakiness test or others.
> 
> —Liang 
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] qtbase 5.9 is locked down for the time being

[Liang Qi]

Hi, all,

Since Oct. 20, only one change landed in qtbase 5.9, 
https://codereview.qt-project.org/#/c/209093/

I will try to do manual stage in qtbase 5.9 to check whether it is because 
flakiness test or others.

—Liang 
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] qtbase 5.9 is in chaos mode now

[Liang Qi]

There is a gap in 6.19-6.26, only 2 changes are merged in qtbase 5.9.

https://codereview.qt-project.org/#/q/project:qt/qtbase+branch:5.9+status:merged,n,z

And now we have about 40 changes in staged mode, I don’t see much chance to get 
them in.

https://codereview.qt-project.org/#/q/project:qt/qtbase+branch:5.9+status:open,n,z

Perhaps I can try to be the stage monkey, but I need to know which batch/set of 
changes need to be staged together. Please report here or irc, thanks.

Regards,
Liang
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] qtbase dev is blocked in CI

[Liang Qi]

Hi,

There is an integration sucks from last night for qtbase dev branch. And we 
can’t restart coin to cancel it due to current 5.9.1 integrations. Hope we can 
fix the issue this afternoon or a bit later today.

So please don’t stage changes in qtbase dev for now, thanks.

Best Regards,
Liang
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposal for Qt 5.10 platforms and configurations changes

[Liang Qi]

On 27 April 2017 at 22:50, Wolfgang Baron  wrote:

> Hi,
>
> I would like to see msvc_2017 support on the Windows plattform for any
> version as soon as possible.


That will happen soon in 5.9, please follow up
https://codereview.qt-project.org/#/c/191981/ and etc.

Regards,
Liang
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17

[Liang Qi]

On 11 April 2017 at 10:22, Ville Voutilainen 
wrote:

> On 11 April 2017 at 10:30, Marc Mutz  wrote:
> > On Tuesday 11 April 2017 07:49:28 Tuukka Turunen wrote:
> >> There has been a lot of discussion about this in the mailing lists, I
> think
> >> the two ones below sum it up quite well.
> >
> > They sum up *your* POV well. But up to a few weeks ago, more fixes went
> into
> > 5.8 QtBase than changes into 5.9, even though TQC personell was asked to
> > ignore 5.8.
> >
> > You can close 5.8 on all other modules, if you wish, but I'd ask to keep
> it
> > open on QtBase, which has a lively development going on in 5.8 to this
> day.
>
>
> Here's an anecdote: this https://codereview.qt-project.org/#/c/189229/
> hasn't been merged
> to 5.9, as far as I can see. I find it curious that bugfixes from two
> weeks ago haven't trickled
> into 5.9 from 5.8 yet. Such matters may well raise the bar for users
> for working with 5.9 rather than
> with 5.8.
>
> You could check which changes in 5.8 are not merged in 5.9 yet:
https://gist.github.com/liangqi/afd4dea47e7ee84e017f4113844df5b1

There are only 6 changes in qtdeclarative.

Here is the merge for you: https://codereview.qt-project.org/191380

I normally will do merge if more than 10 changes, asked by someone, or just
before some releases(like 5.9 rc) and etc.

Certainly, there will be merges when 5.8 branch were closed. Don't worry
about that.

Best Regards,
Liang
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17

[Liang Qi]

On 11 April 2017 at 09:30, Marc Mutz  wrote:

> On Tuesday 11 April 2017 07:49:28 Tuukka Turunen wrote:
> > There has been a lot of discussion about this in the mailing lists, I
> think
> > the two ones below sum it up quite well.
>
> ..
>
> You can close 5.8 on all other modules, if you wish, but I'd ask to keep it
> open on QtBase, which has a lively development going on in 5.8 to this day.
>

 Any new change in qtbase means need a new round of qt5.git integration and
rebuild all other modules, because they depend on qtbase.

Best Regards,
Liang
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Who's responsible for 3rdparty these days (QTBUG-59586)?

[Liang Qi]

On 19 March 2017 at 20:01, Thiago Macieira 
wrote:

> The rules are that only Qt Company people can import 3rdparty code, so I
> know
> I am not responsible.
>
> Who do I assign the bug to?
> https://bugreports.qt.io/browse/QTBUG-59586


For QTBUG-59586, I have https://codereview.qt-project.org/189977 and
https://github.com/liangqi/zlib/tree/qt .

Please give some feedback. And I still have a general question:

I have seen this new git submodule way in qtlocation, like
http://code.qt.io/cgit/qt/qtlocation-mapboxgl.git/ .
So should we do a mirror in code.qt.io first and then add this in the
modules? And there is common procedure for this purpose? for example,
patches and qt_attribution.json file if upstream doesn't have it.

Best Regards,
Liang
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Shall we turn on /utf-8 compiler option when build qt for Windows?

[Liang Qi]

http://doc.qt.io/qt-5/supported-platforms.html
msvc 2013 is still supported in 5.8

http://doc.qt.io/qt-5.6/supported-platforms.html
msvc 2010/2012/2013 are still supported in 5.6

Compiler options for msvc 2015: 
https://msdn.microsoft.com/en-us/library/fwkeyyhe.aspx
Compiler options for msvc 2013: 
https://msdn.microsoft.com/en-us/library/fwkeyyhe(v=vs.120).aspx

If not all supported compilers support /utf-8 or similar options, what should 
be done next step?

Best Regards,
Liang

> On 30 Jan 2017, at 17:30, Thiago Macieira  wrote:
> 
> On segunda-feira, 30 de janeiro de 2017 09:56:46 PST Giuseppe D'Angelo wrote:
>> Il 30/01/2017 02:21, Thiago Macieira ha scritto:
>>> So, we should:
>>> a) still avoid non-ASCII in our source files, aside from comments
>>> b) allow non-ASCII in comments, as needed
>> 
>> Didn't we have issues with UTF-8 in comments too, when using MSVC?
> 
> Yes, which means that if it chokes on KDAB's name in qglobal.h, too bad.
> 
>>> c) turn the -utf-8 option on for MSVC2015U3.
>> 
>> But just for Qt own build, not push this option onto the users. Also,
>> does this fix anything? Is MSVC 2015 U3 the only one complaining, and we
>> can live with UTF-8 in the source when using other compilers?
> 
> This will affect the Qt build only. Only MSVC 2015 U3 gets the fix, the older 
> versions and MSVC 2013 will still be affected.
> 
> Sorry, tough luck for the others.
> 
> -- 
> Thiago Macieira - thiago.macieira (AT) intel.com
>  Software Architect - Intel Open Source Technology Center
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

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

Re: [Development] HEADS-UP: Branching from '5.8' to '5.8.0' started

[Liang Qi]

Then there will be batches of merges 5.6->5.7->5.8 before the final down
merge 5.8->5.8.0. If your changes are after those merges, it will miss the
5.8.0 release normally. (cherry-pick only for the critical things after the
final down merge.)

And I plan to do the merges during weekends, if CI/COIN works fine. Or if
you want your changes not missing this chance, please send some
notification to me, for example, reply this email to me(not all).

Best Regards,
Liang


On 21 November 2016 at 14:50, Jani Heikkinen  wrote:

> Hi,
> We have started branching from '5.8' to '5.8.0'. Please start using
> '5.8.0' for new changes targeted to Qt 5.8.0 release. There should be
> enough time to finalize ongoing changes in '5.8'; final downmerge will
> happen Monday 28th November.
>
> br,
> Jani
>
>
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] COIN

[Liang Qi]

On 27 September 2016 at 19:23, manish sharma <83.man...@gmail.com> wrote:

> Hi,
>
> I am working on a project which consists of around 20 git submodules and
> we use jenkins as our CI. I was searching for an alternative to manage
> builds and I came across COIN scripts which qt uses to run its CI. And it
> perfectly suits our requirement especially dependency resolver and storage.
>
> http://testresults.qt.io/coin/doc/overview.html
>
> I search over google and checked code.qt.io/cgit/ but could not find COIN
> scripts. Is it public domain? Let me know if someone knows the repo link.
>

https://blog.qt.io/blog/2016/08/08/coin-continuous-integration-for-qt/

It's not in public domain yet.

Regards,
Liang
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] dev doesnt builds

[Liang Qi]

On 22 September 2016 at 13:17, Vlad Stelmahovsky  wrote:

> Hi
>
> trying build dev branch and got this error all the time:
>
>
> Cannot read .qt5/qtbase/src/corelib/qtcore-config.pri: No such file
> or directory
> Cannot read .qt5/qtbase/src/gui/qtgui-config.pri: No such file or
> directory
> Project ERROR: Could not find feature system-zlib.
> Makefile:45: recipe for target 'sub-src-make_first' failed
> make[1]: *** [sub-src-make_first] Error 3
> make[1]: Leaving directory '../qt5/qtbase'
> Makefile:78: recipe for target 'module-qtbase-make_first' failed
> make: *** [module-qtbase-make_first] Error 2
>
>
> is there a workaround for this?
>

Perhaps missing a qt5 5.8->dev merge to include
https://github.com/qt/qt5/commit/64cc947ded527197168f5d16f25a15638e58 .

Anyway, the dev branch for all modules except qtbase are blocked by
https://bugreports.qt.io/browse/QTBUG-56122 .

Regards,
Liang
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Notes on "Managing Qt's branches" session @ QCS 2016

[Liang Qi]

On 12 September 2016 at 11:20, Edward Welbourne 
 wrote:

> Marc Mutz said:
> > The obvious question is, then, why is only "the one person" doing merges?
> > Allow more people to upload merges, and you will get the spreading you
> desire.
>
> Several people can upload merges.
> One person looks after integration in qt5 and all its sub-modules.
> We can spread the load (indeed, I carried it for a few weeks while
> Liang was on holiday), and I believe module owners can do their own
> merges (which saves the integration team work), but the integration team
> takes responsibility for ensuring merges are happening.
> So it ends up being that Liang, as integrator, does most merges.
>

We have some/many modules are in not active mode, so the merges for them
are normally based on the release schedules. That's one of the reason to
have a merger.

A heavy load for mergers and integrators is that the new CI, COIN, doesn't
have reverse dependency check like old CI. Then if sth changed in qtbase or
qtdeclarative, the merge and integration will trigger the issue. Then very
often it's a bit difficult for us to analysis the root cause and find right
persons to fix it.

Perhaps we should set up a rule for deprecated sth, for example,
1. notify merger/integrator/others, or just add them into a list in a
wiki/web page
2. the dev of the deprecated change should do a "git grep" in all qt
project, and at least provide a fix for one of them, better to do all

For merges, the maintainers of modules should take care. At least,
qtquickcontrols2/qtwebengine are very well, it's also because developers
there are working on different features in different branches, they care
the merge themselves.

For some other modules, like qt3d/qtmultimedia/qtwayland, the help from the
maintainers and developers are also very good.

But for qtbase, it's a totally different story, too many areas, so normally
we(or I) can't say there is an active maintainer for the whole of qtbase. A
regular merge for qtbase is needed, for example, weekly. And if we can't
get response from devs very soon, who can help?

Give the merge permission to everyone is obiviously not a solution. But it
will help a lot if we have an active merger/integrator group, at least for
review.

Regards,
Liang
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] No Gerrit notification email?

[Liang Qi]

http://lists.qt-project.org/pipermail/development/2016-September/027083.html

On 9 September 2016 at 08:39, Marc Mutz  wrote:

> Hi,
>
> I don't get notification emails from Gerrit anymore, and since the big
> downtime of Gerrit and dev ML two(?) days ago only sporadically.
>
> Anyone else seeing this? Or is it KDAB's mail server problem?
>
> Thanks,
> Marc
>
> --
> Marc Mutz  | Senior Software Engineer
> KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
> Tel: +49-30-521325470
> KDAB - Qt, C++ and OpenGL Experts
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Notes on "Managing Qt's branches" session @ QCS 2016

[Liang Qi]

On 8 September 2016 at 09:36, Alexander Blasche 
wrote:

> 
> From: Marc Mutz 
>
> >On Wednesday 07 September 2016 08:37:01 Friedemann Kleint wrote:
> >> ** After 5.7 is closed and sanity bot is upgraded (to handle
> >> cherry-picking), go into cherrypicking mode for 5.6. Developer is
> >> responsible for doing the cherrypicking
> >> ** Cherry-picking technicalities need to be figured out: Let sanity bot
> >> verify source ("cherrypicked from") the SHA1
>
> >I'm sorry, but this is nonsense.
>
> I agree with Marc. Why cant we do 5.6->5.8 merges once the 5.7 branch is
> closed? Since the 5.6 branch will get fewer and fewer patches as the
> strictness of its commits increases I see no reason why 5.6->5.8 could pose
> a problem.
>
> Maybe you sb can elaborate why we have to go to cherry-picking? The notes
> don't say and I wasn't in this QtCon meeting.
>

This is mainly because we did heavy refactoring in upstream branches, for
example, rewriting configure system, then any small fix in 5.6 will trigger
a huge conflicts.

https://codereview.qt-project.org/#/c/163938/

Other cases are sth like directories reorganization, class renaming and
etc, it's very annoying when developers have changes in similar places in
5.6 and upper branches.

Best Regards,
Liang



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

Re: [Development] Notes on "Managing Qt's branches" session @ QCS 2016

[Liang Qi]

On 7 September 2016 at 08:37, Friedemann Kleint 
wrote:

> Hi,
>
> the notes are at: https://wiki.qt.io/QtCS2016_Managing_Qt_Branches
>
> * Number of existing branches (5.6LTS, 5.7.,5.8 dev) causes a number of
> problems
>
> ** Strain on COIN which also has release branches
> ** Merging becomes increasingly difficult
> ** Hard to manage for individual developers
>
> * Branches
>
> ** Close 5.7 after 5.7.1. We then have LTS, stable, dev.
>

Is it better to have 5.7.2 around 5.8.0 final release and close 5.7 after
that? 5.7.1 is very soon in a few weeks. There will be a few months gap
between 5.7.1 and 5.8.0/5.8.1. The first release of new branch, like 5.8.0,
sometimes it's not tested enough in user(or application developers) side,
so some regressions or a bit critical issues will be found between 5.8.0
and 5.8.1. It's good for users to have a more stable release of 5.7.2.

If we stick to do release like this kind of order, 5.6.2->5.7.1->5.8.0
Beta, it's not very difficult to have a 5.6.3->5.7.2->5.8.0 or similar.

And I would like to see it becomes a convention for future releases.

Best Regards,
Liang


> ** After 5.7 is closed and sanity bot is upgraded (to handle
> cherry-picking), go into cherrypicking mode for 5.6. Developer is
> responsible for doing the cherrypicking
> ** Cherry-picking technicalities need to be figured out: Let sanity bot
> verify source ("cherrypicked from") the SHA1
> ** In the future, exact time for closing stable branches will be discussed
> for each one individually
>
> * Submit Policy
>
> ** Target which branch?
>
> ** Long Term Support (5.6) Branch
> *** Initially equal to stable, increasingly strict over time: Fix only
> severe issues, avoid regressions.
>
> *** Bugs: For example, P2 for the first year, P1 for year 2, rest
> Security. Try to further objectify that: Jedrzei + Friedemann
> *** Tests: Fix/stabilize tests itself, add tests
> *** No performance improvements unless really significant
> (relevant/reduces O(n))
> *** Upgrading 3rd party (including WebEngine)
> *** Support new OS versions unless introducing new platforms, no rewrite
> of QPA
> *** No cleanups, positively: -> dev
> *** To aid customers with issues, patches for issues in LTS to be locally
> applied can be provided, but the fixes will be pushed to higher versions of
> Qt.
>
>
> Regards,
> Friedemann
>
> --
> Friedemann Kleint
> The Qt Company GmbH
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] RHEL 7.2 added to Coin

[Liang Qi]

Could we disable RHEL 7.2? at least for QtScript. There is a failure in qt5.git 
dev integration. It is the only blocker for it now.


https://codereview.qt-project.org/162195


Best Regards,

Liang


From: Development  on behalf 
of Frederik Gladhorn 
Sent: Monday, June 27, 2016 3:26:49 PM
To: development@qt-project.org
Subject: Re: [Development] RHEL 7.2 added to Coin

On mandag 27. juni 2016 14.30.48 CEST Frederik Gladhorn wrote:
> Hi all,
>
> good news when it comes to packaging on Linux, we added red hat 7.2 as the
> new packaging config for the dev branch - Qt 5.8 that is. We'll also run it
> as developer build with the 5.7 branch. I'll flip the switch to actually
> run it in a few minutes.

... and temporarily reverted again, not sure what is wrong with the VM, but it
didn't start reliably. I'll try re-enabling this in a bit...

Frederik

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

Re: [Development] Qt 5.8 branching & Feature Freeze

[Liang Qi]

"Currently we can’t put anything new in, since Coin setup is frozen."

Due to my limited knowledge with coin, I don't understand this.

Coin, the new CI, should not bind with any paticular branch of Qt, but some
options and scripts could.

For the listed new OSes, openSUSE 42.1, Ubuntu 16.04, RHEL 7.2, OS X 10.11,
if qt libs built failed, it should be P1 or P0 in current development
branches, from 5.6. And for autotest failures, most could be blacklisted or
skipped in the first step. The work for adding new untested platforms, need
to be done in 5.6, as lower as possible. Like now, working with dev, then a
fix need to be in 5.6, and a few more merges after that. I don't think it's
smart. tvOS is a different story.

For the integration of qt5.git dev branch was not a priority job before,
because it will not be a blocker of near future releases. After a new 5.x
branch out, it has more priority. And who is/are the integrator is also not
very clear. Perhaps the thing is changing now.

And recently 5.6, 5.6.1, 5.7, 5.7.0, dev, five branches and two releases
together, some critical issues were found in 5.6.1, then needed to be in
5.7.0 too... Not a very good experience, at least for me. Perhaps it's
because lacking of binaries for 5.6 snapshots, then not enough usage and
testing.

Best Regards,
Liang


On 16 June 2016 at 08:57, Tony Sarajärvi  wrote:

> Hi,
>
>
>
> Our aim was to get new platforms in immediately after the previous
> platforms branched away from dev branch. Meaning, when 5.7 branch was
> created and it branched away from dev branch, all new platforms aiming for
> 5.8 should have been put into dev branch. However, in practice it didn’t
> quite go as expected. Not to blame anyone, but all focus was to get 5.6.x
> and 5.7.x out. Meaning, dev branch was left broken for several months. The
> individual submodules did pass in the CI, but the last time Qt5 has passed
> is 4 months ago.
>
>
>
> To tackle this we agreed that we can start inserting new platforms
> submodule by submodule, but right after that we froze Coin setup so that we
> don’t break 5.7.x by accident. And by having several branches, with alphas,
> betas, release candidates and releases themselves we have a lot of these
> freezes, which means that the time window, where we can put in any new
> platform, is very short. And if the submodule in dev don’t happen to have
> everything merged from earlier branches and finally work, an insertion
> won’t happen.
>
>
>
> This is why we’ve not been successful in bringing openSUSE 42.1, Ubuntu
> 16.04, RHEL 7.2, OS X 10.11 in into dev branch albeit trying to do that for
> months.
>
>
>
> So back to this day. Currently we can’t put anything new in, since Coin
> setup is frozen. We have holidays coming up and we have a skeleton crew
> working the entire summer. Right as we get back to work, we have 5.8 branch
> coming up and feature freeze right after that. When did you expect us to
> push in these new platforms? According to process, we shouldn’t put them
> into 5.8 after FF. If we bend this rule (as we usually do), we might get
> them in there as people focus on fixing issues there, or the same thing
> happens as happened with 5.7: the new platforms simply never passed
> autotests so that they could be brought in (we actually did try to get them
> into 5.7 early on, but not lately due to release being too close).
>
>
>
> Ok...perhaps I should propose something. Let’s postpone branching 5.8. As
> much as I like the motto of Blizzard Entertainment “done when it’s done” ,
> I’ve found that people like time schedules as well. Alas, I have to suggest
> that we postpone it as much as possible. I think that we can fix the things
> we want to fix in 5.8 in dev branch as well. When we get a more mature dev
> branch that actually works, we can generate the alpha package for 5.8 much
> faster after the branch, as 5.8 already worked right of the bat (because
> dev worked). Also, we’ll get a working dev branch as well simultaneously.
>
>
>
> Also, we’ve noticed that often when people fix problems found in
> autotests, being it a bug in the autotest itself or as it actually more
> often is, a problem in Qt sources themselves, people push the fix to the
> most mature branch available. In this case, when we report that we can’t
> get openSUSE 42.1 in, because this and that fails, the fix is pushed into
> 5.6 as it already appears there but haven’t been found or studied before.
> Then we have to sit down and in worst case wait for a 5.6.1 -> 5.6 -> 5.7
> -> dev merge. With all the general flakiness in the system, that usually
> takes a fortnight at least.
>
>
>
> So by fixing dev, we can skip doing merges from 5.8 -> dev when we
> eventually find the problems for these new platforms.
>
>
>
> With regards,
>
> -Tony
>
>
>
> PS: The list with new platforms actually increases yet with OS X…ehm macOS
> Sierra (10.12) beta coming up, tvOS etc…
>
>
>
> *From:* Development 

Re: [Development] Qt + GCC 6 no joy ?

[Liang Qi]

https://bugreports.qt.io/browse/QTBUG-53373 ?

On 18 May 2016 at 10:01, Bogdan Vatra  wrote:

> Hi,
>
> Did anyone tried Qt (5.7) with GCC 6 ?
> I compiled Qt and QtCreator (using debian's gcc 6) but it crashes in v4
> when I
> start QtCreator :(. It's a know issue or just me?
>
> Cheers,
> BogDan.
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] http://testresults.qt.io/ci/status/ stale?

[Liang Qi]

The status of new CI: http://testresults.qt.io/coin/

On 21 March 2016 at 18:19, MrMstormo .  wrote:

>
> Looks like
> http://testresults.qt.io/ci/status/
> is stale? All reports are erroring out, and there's no reports for 5.6,
> 5.7 etc?
>
> Is the CI system on an early Easter break? :)
>
> --
> .marius
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
>


-- 
http://www.qiliang.net
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] INTEGRITY changes for 5.7

[Liang Qi]

Do you plan to have them in 5.7 release? Current dev branch means 5.8...

On 2 March 2016 at 08:24, Rolland Dudemaine  wrote:

> Hi,
>
> I understand that 5.7 has now reached feature freeze, but I would like
> to ask for an exception for patches that have been pushed a few months
> ago already but never got merged (partially because of the CI woes).
>
> This would cover all the patches with a positive code review status at
>
> https://codereview.qt-project.org/#/q/owner:rolland%2540ghs.com+status:open,n,z
>
> Thanks,
> Best regards,
>
> --
> --
> Rolland Dudemaine   tel direct:+33 143 143 702
> Green Hills Software   tel:+33 143 143 700
> 4 rue de la Pierre Leveemailto:roll...@ghs.com
> 75011 Paris   fax: +33 143 143 707
> France web: http://www.ghs.com
> --
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>



-- 
http://www.qiliang.net
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Closing the 5.5 branch

[Liang Qi]

https://codereview.qt-project.org/146557 still need to be integrated.

On 8 February 2016 at 14:03, Frederik Gladhorn <
frederik.gladh...@theqtcompany.com> wrote:

> Hi all,
>
> due to the strain that we put on the VMs that are supposed to get the
> releases
> out and do the testing, we decided to "shut down" the CI for Qt 5.5
> branches.
> This means literally that we shut down the VMs but we'll keep them around
> in
> case we ever need to make a 5.5 release.
> The goal is to free capacity to let us finally get 5.6 and just after 5.7
> out
> of the door.
>
> Cheers,
> Frederik
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>



-- 
http://www.qiliang.net
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] A simple analysis of apps using qtbase's private headers

[Liang Qi]

On 22 January 2016 at 04:15, Lisandro Damián Nicanor Pérez <
perezme...@gmail.com> wrote:

> The following three have something in common: they are all apps coded for
> Chinese people. I've been told that they need QPA's private stuff in order
> to
> have proper input systems, but I haven't checked.
>
> * fcitx-qt5 1.0.5
> * gcin 2.8.4
> * hime 0.9.10
>

Above three are not applications, they must be input context plugin of Qt,
just like ibus in
https://github.com/qtproject/qtbase/tree/5.5/src/plugins/platforminputcontexts/ibus
. Normally every input method software could/should have one of this kind
of plugin for Qt 5, so there is no question when they use private headers.

Regards,
Liang

-- 
http://www.qiliang.net
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QFont::setFamily("monospace") on OS X

[Liang Qi]

Perhaps QPlatformTheme::font() is related.

https://github.com/qtproject/qtbase/blob/5.6/src/gui/kernel/qplatformtheme.h

Regards,
Liang

On 21 January 2016 at 18:29, René J.V.  wrote:

> Hello,
>
> Not sure if this is the best place to ask:
> I think QFont::setFamily("monospace") should allow to obtain an
> appropriate monospace font on all platforms. It does with the XCB QPA ,
> giving me the Consolas font (ideally it should return the fixed-width font
> that goes with the active (platform) style, though).
> On OS X with the cocoa QPA however, this gives Lucida Grande, i.e. the
> system fallback font.
>
> I suppose that's a bug, or is there a reason why this doesn't work as
> expected?
>
> Cf: https://bugreports.qt.io/browse/QTBUG-50564
>
> R.
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>



-- 
http://www.qiliang.net
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.5.0 header diff: QtDeclarative.diff

[Liang Qi]

On 6 June 2015 at 10:52, Allan Sandfeld Jensen k...@carewolf.com wrote:

 On Friday 05 June 2015, Frederik Gladhorn wrote:
 

 Would there be any way to generate diffs or changes for QML APIs?


Perhaps a diff for all plugins.qmltypes files? But I guess that not all
were updated yet.

-- 
http://www.qiliang.net
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Updating of 3rdparty stuff

[Liang Qi]

qtimageformats: libwebp 0.4.3 update

https://codereview.qt-project.org/109955
https://codereview.qt-project.org/109956

And checked other 3rdparty: jasper, libmng, libtiff, there is no update
from upstream.

After Beta released, I will help to update qt doc and
https://wiki.qt.io/Third_Party_In_Qt

Regards,
Liang


On 7 April 2015 at 06:56, Thiago Macieira thiago.macie...@intel.com wrote:

 Any volunteers?
 --
 Thiago Macieira - thiago.macieira (AT) intel.com
   Software Architect - Intel Open Source Technology Center

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




-- 
http://www.qiliang.net
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Outdated Branch Guidelines and Commit Policy?

[Liang Qi]

https://wiki.qt.io/Branch_Guidelines
It's still in dev/stable mode, not the current 5.3/5.4/5.5/dev mode.

https://wiki.qt.io/Commit_Policy
Make sure to follow the Branch Guidelines. Submit against the lowest
applicable branch from which a release is still planned.

I have seen more and more bug fixes are going to 5.5 branch instead of 5.4.
And many reviewers prefer to do that.

5.4 is much more stable than 5.5, that's for sure, and I think the patches
for 5.4 are still valuable for customers and users.

If 5.4.2 is not planned, then it's ok. Otherwise... please update the wiki,
thanks.

Regards,
Liang
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] what's the latest status about tests/auto/bic/data?

[Liang Qi]

Hi,

Looks like we have binary compatible check things(at least for
linux-gcc-ia32) before, but I only found 5.0.0 and 5.1.0 data. For example,

https://github.com/qtproject/qtbase/tree/dev/tests/auto/bic/data
https://github.com/qtproject/qtdeclarative/tree/dev/tests/auto/bic/data

I forgot how it works. And what's the latest status of them?

Regards,
Liang

-- 
http://www.qiliang.net
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] GIMP QML exporter script (project not on Gerrit)

[Liang Qi]

I guess you mean this on github,
https://github.com/qtproject/qt-labs-gimp-qmlexporter

Then please contribute to
https://codereview.qt-project.org/#/admin/projects/qt-labs/gimp-qmlexporter

Good luck!

Regards,
Liang

On 7 January 2015 at 08:33, William Hallatt goblincod...@gmail.com wrote:

 Good day,

 I forked and made some changes to Jens Bache-Wiig's original QML exporter
 script (GIMP only) on GitHub and was wondering if I could simply create a
 pull request for my changes?

 I have searched for the project on Gerrit, but it does not seem to exist
 there.

 Advice would be appreciated.

 Kind regards,
 William Hallatt

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




-- 
http://www.qiliang.net
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Platform maintainers

[Liang Qi]

Is it possible also to add sub categories under QtPorts for Windows/XCB/OS
X and etc in bug tracker?

Regards,
Liang


On 10 January 2014 23:51, Knoll Lars wrote:

 Yes, I was about to write a mail about it. We don't currently officially
 have maintainers for platforms, but they exist in reality, and I'd like to
 make them explicit.

 So if nobody disagrees, I'll add them to the list next week.

 Cheers,
 Lars


 On 10/01/14 18:22, David Faure wrote:

 Could we add a table at the bottom of
 http://qt-project.org/wiki/Maintainers
 with the platform maintainers, for each platform?
 ... unless I'm wrong and the concept doesn't exist within the Qt
 community,
 but AFAIK it does?
 I can't find who's the official maintainer for each platform.
 
 --
 David Faure | david.fa...@kdab.com | Managing Director KDAB France
 KDAB (France) S.A.S., a KDAB Group company
 Tel. France +33 (0)4 90 84 08 53, Sweden (HQ) +46-563-540090
 KDAB - Qt Experts - Platform-independent software solutions



-- 
http://www.qiliang.net
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] gitorious error

[Liang Qi]

Try github mirror?

git clone git://github.com/qtproject/qt.git

More in https://github.com/qtproject/

On 30 December 2013 19:35, Jiergir Ogoerg f35f22...@gmail.com wrote:

 Hi,
 I'm trying to follow the pile of tutorials to be able to contribute code
 to qt.

 At
 http://qt-project.org/wiki/Git_Introduction
 at Getting the Qt source code
 I must do
 git clone git://gitorious.org/qt/qt.git

 but it yields this on the command line:
 Cloning into 'qt'...
 fatal: unable to connect to gitorious.org:
 gitorious.org: Name or service not known

 Yesterday it gave me the same thing.
 Any idea what's wrong?

 I'm on Kubuntu 13.10 amd64.


-- 
http://www.qiliang.net
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QSettings, OS X

[Liang Qi]

On 18 December 2013 13:41, Samuel Gaist samuel.ga...@edeltech.ch wrote:

 Hi,

 I recently came across several posts talking about QSettings not working
 as expected on OS X (things not yet reported on the bug tracker).

 On OS X 10.9, it seems that Apple has decided to cache the application
 preferences more aggressively so if one users erases the plist file and
 restarts its application, the preferences are restored because of the
 cached version. The only current solution is to kill cfprefsd. So I
 wondered if some sort of cleanup/don't load should be added when reading
 the first time if the plist file doesn't exist ?

 While looking at QSettings code, I have found that it uses several
 platform specific helper classes. Wouldn't they better fit in qpa ? if so,
 I'll be happy to move them and in this case should I open a report for that
 ? Also which branch should I target: dev or stable ?

 I also saw that the current implementation doesn't use the mac specialized
 version for parsing configuration files when NativeFormat is used. Would
 adding support for that in QMacSettingsPrivate be a good idea ?

 And lastly would a NSUsersDefaults powered helper class be interesting ?
 (Just thinking about it, I didn't implement anything yet)


There is bug report for that,
https://bugreports.qt-project.org/browse/QTBUG-34899

QPA is most for GUI and things depend on GUI. The QPA of Qt Core has not
started yet. If anyone wants to contribute about this topic, go to dev,
obviously.

Regards,
Liang

-- 
http://www.qiliang.net
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt5 release integration build

[Liang Qi]

Those changes happened in stable branch, it means they will be part of
5.2.1, then doesn't block 5.2.0 final release.

Anyway, patches are welcome!

Regards,
Liang


On 10 December 2013 20:06, Kurt Pattyn pattyn.k...@gmail.com wrote:

 I suppose that the warnings in the list beneath are still unsolved. Is
 that correct?
 How critical is it to solve those warnings? If they are critical for the
 release, I want to give a helping hand to remove them (after all there are
 more than 900, the list below is a synopsis).
 Cheers,

 Kurt

 On 10 Dec 2013, at 17:30, Mitch Curtis mitch.cur...@digia.com wrote:

  https://codereview.qt-project.org/#change,65936
  https://codereview.qt-project.org/#change,66052
  https://codereview.qt-project.org/#change,66018
  https://codereview.qt-project.org/#change,66061
  https://codereview.qt-project.org/#change,66041
 
  You can see more by searching through gerrit. E.g.:
 
 
 https://codereview.qt-project.org/#q,owner:Friedemann.Kleint%2540digia.com+message:warnings,n,z
 
  or Git:
 
  git submodule foreach git log | grep warning ||:
 
  Patches are welcome. :)
 
  On 12/10/2013 11:40 AM, Kurt Pattyn wrote:
  Hi,
 
  is anybody aware of the many warnings of Qt5 release build for Windows?
  For instance the build
  win32-msvc2010_developer-build_qtnamespace_Windows_7 (build log:
 
 http://testresults.qt-project.org/ci/Qt5_release_Integration/build_00286/win32-msvc2010_developer-build_qtnamespace_Windows_7/log.txt.gz
 ),
  contains the following warnings: ...
 
  Cheers,
 
  Kurt
 
 




-- 
http://www.qiliang.net
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Wiki: 3rd party in Qt

[Liang Qi]

Hi, all,

I just spent some time to gather the information of 3rd party in Qt(5).

http://qt-project.org/wiki/Third_Party_In_Qt

Please help to update or maintain it.

Maybe there is a legal issue about wintab, more details in their webpage:
http://www.pointing.com/Wintab.html

Regards,
Liang
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Asking for review: webp support in qtimageformats

[Liang Qi]

Hi, all,

Just see many people are interest in JP2 and ICNS things. I want to ask for
review about webp support in qtimageformats again. There are changes
available since May and June,

https://codereview.qt-project.org/54689
https://codereview.qt-project.org/54690
https://codereview.qt-project.org/54691
https://codereview.qt-project.org/56026

Best Regards,
Liang

-- 
http://www.qiliang.net
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt-5.1, qglobal.h and PIC detection

[Liang Qi]

On Wednesday 06 November 2013 12:17:56 Christian Gagneraud wrote:
 Hi,

 I'm using CLang build-analize tool, and when I switched from Qt 4.8 to
 Qt 5.1 (insalled from Qt project's download area), I got a Qt #error,
 basically the code is built with -fPIC, but CLang doesn't define a PIC
 macro, so the build fails due to a check in qglobal.h (see details below).
 ...

That's a bug in scan-build script, already fixed in clang upstream.  More
details in
https://bugreports.qt-project.org/browse/QTBUG-33698

Regards,
Liang

-- 
http://www.qiliang.net
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development